Why no Class-Path manifest attribute?
by Florian Weimer
It seems that a significant number of JAR files under /usr/share/java do
not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included
with the final link (typically, in the -classpath argument to
/usr/bin/java). This is mightily inconvenient and leaks implementation
details across Java RPM package boundaries. (I don't think
%jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
--
Florian Weimer / Red Hat Product Security Team
9 years, 7 months
Packaging tomcat shell scripts
by Robert Rati
I logged a bz (https://bugzilla.redhat.com/show_bug.cgi?id=990588) to
request that the tomcat shell scripts (catalina.sh and the rest) be
packaged. I've had some discussions with the person the bz is assigned
to and few others, but no one knows why the scripts were not packaged.
Nor, it seems, does anyone see a problem with them being packaged as far
as I can tell.
Does anyone know some history here?
Rob
9 years, 8 months
Heads-up: Upcoming netty major version update in Rawhide (Will Break Stuff)
by Jon VanAlten
Hi Java folks,
The current netty in Fedora is 3.6.3. There are newer updates to 3.X series
upstream but also for some time now 4.X series has been available. In the
spirit of keeping the most up to date version in our distro, I aim/plan to
update this in rawhide in the coming weeks. However, there have been some
changes upstream that any maintainers of packages which depend on netty will
need to be aware of. Those packages are:
async-http-client
bookkeeper
eclipse-m2e-core
hadoop
hornetq
littleproxy
resteasy
thermostat
zookeeper
In addition, we currently have a compat netty31 package, which is used only
by the eucalyptus package. I'd also like to encourage the maintainer of
eucalyptus to look into porting to the newer netty, so this longstanding
compat package can be retired. (Well, there are other packages that
"repoquery --whatrequires netty31" returns, but inspection of .spec shows
that they only Require: netty without a version; only eucalyptus has an
explicit requirement for netty31.)
So, what are the implications of this update? Well, upstream netty has
moved from being a jboss project to being independent at netty.io, and has
changed their package namespace accordingly. In addition, some key API
classes have slightly changed names. Finally, and I haven't looked deep at
this part yet, but it seems there are some other incompatible API changes.
Any package currently using netty will *at least* require a search-and-
replace for package/class name changes, and may require more indepth fixes
in order to work with the most recent upstream releases.
The bulk of the changes came with the 4.0 release, and conveniently enough
upstream made a single commit updating most of their example code at once[1]
which is likely to be a good reference for anyone porting an application.
I'll be starting on this work around mid-November. My plan is to first
create package of the newest netty release at the time but not push to
rawhide just yet, rather make srpm available to interested maintainers via
other means. Then, as co-maintainer of thermostat, I will help to port that
package to the new netty API. I hope around this same time maintainers of
other packages will do same. To me, this will act as "sanity check" for the
updated netty package, and if this check is successful, I'll then push the
netty changes to rawhide. If all goes well, this should be done by the end
of November (modulo a week or so).
Please, if you have any concerns with this plan, speak up! Otherwise, wait
for my email in a few weeks with .srpm to play with :)
cheers,
jon
P.S. I *really* hope that at the end of all this we are not left with *two*
compat packages for netty, ie I hope that either eucalyptus is able to port
or that all of the others are able to port, or even better both of the
above.
[1] https://github.com/netty/netty/commit/8237afff64509520865c08bf4f5fd130e06...
9 years, 9 months
Gradle upgrade issues (#976330)
by Michael Ekstrand
In bug #976330[1], there's been some discussion of the desire to
upgrade Gradle from 1.0 to a new version (currently 1.8), and that
there is significant hassle to actually do so. Some of this hassle I
see in the bugs blocking 976330 - upgrading to Aether, newer Plexus
containers, and maybe Polyglot Maven.
What are the key issues that make it difficult to upgrade and maintain
Gradle in Fedora? The likely ones I see:
- Incompatible dependencies (Gradle may require package versions no
longer shipped in Fedora)
- Bootstrapping problems (the Gradle 1.8 sources won't build with
Gradle 1.8, they seem to require 1.7)
- Possibly library embedding (although the Gradle sources do seem to
pull in the dependencies from Maven)
1. https://bugzilla.redhat.com/show_bug.cgi?id=976330
--
Michael Ekstrand — http://elehack.net/
9 years, 10 months
Time for new Guidelines:Java (Call for Action)
by Stanislav Ochotnicky
If you want to get involved skip to the bottom :-)
There's that time of year again...our guidelines have become unwieldy, long and
complicated as we were adding features into our stack. Time to get back to
basics... In that spirit I have started stripping stuff from our previous
draft[1] (i.e. our current guidelines).
Most significant changes:
* Removal of several examples, templates
* Move pom_ and mvn_ macros into Java Packaging HOWTO[2]
* Simplify filename naming guideline (and make it more lax)
* Simplify (Build)Requires section (and account for java-headless)
* Lot of other removals/simplifications
One notable thing: perhaps with the exception of java-headless change, the
guidelines are not really different from our current version. I just removed
mentions of old stuff.
As I mentioned some months ago high-level goal is this:
* Rules go into Packaging:Java and should be simple
* Best practices, tips, techniques in Java Packaging HOWTO
"How can I help?" you ask? Great! There are two ways currently:
1. Work on the Guidelines themselves. Keep in mind goal of simplicity. We
don't want a lot of "If X then A else B" parts. Current version is a
relatively quick stripping of current guidelines so expect inaccuracies
and/or outright conflicts. Feel free to edit wiki directly as you see fit.
Worst case I'll just undo your changes or we'll have to discuss them at next
SIG meeting in a few weeks
2. Send us fixes and additions for Java Packaging HOWTO[3] (doc
subdirectory). Michal Srb and Mikolaj Izdebski have done great amount of
work already but there are several missing parts and generally *a lot* of
work ahead of us. If you can commit to javapackages git just go ahead and
claim sections you'd like to help us with.
[1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
[2] https://fedorahosted.org/released/javapackages/doc/
[3] https://git.fedorahosted.org/cgit/javapackages.git/
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
9 years, 11 months
guava update in rawhide
by Mikolaj Izdebski
Fedora Rawhide has version 13.0 of Guava (formerly known as Google
Collections). Latest upstream version is 15.0, but it may be
incompatible with 13.0.
Per request in [1] I'm going to try to update guava package to 15.0 next
week. I'll try to rebuild each dependant package and file bug reports
if needed. Please let me know if you have any comments.
Dependant components possibly affected by the update:
async-http-client
bookkeeper
checkstyle
eclipse-checkstyle
eclipse-m2e-core
eclipse-mylyn
eucalyptus
gooddata-cl
google-guice
gradle
hadoop
jboss-interceptor
maven-shade-plugin
maven-stapler-plugin
owasp-java-html-sanitizer
plexus-containers
sisu
sisu-maven-plugin
solr3
stapler
weld-core
wildfly
zanata-client
zanata-common
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1023832
--
Mikolaj Izdebski
IRC: mizdebsk
9 years, 11 months
The trouble with metadata-extractor
by Andrea Musuruane
Hi all,
last April the following bug report was opened:
https://bugzilla.redhat.com/show_bug.cgi?id=947457
As I stated on bugzilla, metadata-extractor was just needed by JOSM.
Updating metadata-extractor would break JOSM. Anyway I suggested to
patch JOSM to use a newer version of metadata-extractor if he really
needed it. I had no response at all.
BTW, I am metadata-extractor maintainer, and not JOSM maintainer.
This evening the submitter emailed me privately and I discovered that
meanwhile, a new review request for a newer version of
metadata-extractor was approved and now it is part of Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1004563
As I understand now, newer metadata-extractor is required by Apache
Sorl and Apache Tika, which are not yet part of Fedora.
He asked me to "exchange our repository" "to simplify some build with
maven". And with that I presume that he would like to have his package
called metadata-extractor because he has troubles to build sorl and
tika.
I think all this have been handled very badly. He could have told why
he needed a more recent version of metadata-extractor in the first
place, the reviewer of #1004563 could have checked if the package
followed the naming guidelines and/or have checked if the package was
already in Fedora.
I still think that my original plan (i.e. patching JOSM). was more sensible.
What to do now? What do you think?
If it helps, if it makes things easier, I can release the ownership of
metadata-extractor and someone else can have good care. I just
packaged it because, as an openstreetmap mapper, I longed to have JOSM
in Fedora.
Regards,
Andrea.
9 years, 11 months
Gradle upgrade issues (#976330)
by gil
/hi//
> or obtain an
> exception from FPC to build using prebuilt binaries. Currently Fedora
i don't want use this approach,
> ships Ant build.xml for Gradle, but it requires substantial amount of
> manual work to synchronize it with upstream build. (I would prefer to
> use Maven here. It would not only ease dependency management, but also
> allow easier installation of Gradle artifacts.)
/would be the same, because both with maven or ant must be generated for each artifact
a file properties, or more, that its contents can vary from one version to another
gradle-core 1.8
gradle-core-classpath.properties
#module definition
#Tue Sep 24 09:33:38 CEST 2013
projects=gradle-docs,gradle-base-services-groovy,gradle-resources,gradle-cli,gradle-native,gradle-base-services,gradle-messaging
runtime=groovy-all-1.8.6.jar,asm-all-4.0.jar,ant-1.9.2.jar,commons-collections-3.2.1.jar,commons-io-1.4.jar,commons-lang-2.6.jar,ivy-2.2.0.jar,logback-core-1.0.9.jar,logback-classic-1.0.9.jar,guava-11.0.2.jar,jcip-annotations-1.0.jar,jul-to-slf4j-1.7.2.jar,jarjar-1.3.jar,javax.inject-1.jar,slf4j-api-1.7.2.jar,log4j-over-slf4j-1.7.2.jar,jcl-over-slf4j-1.7.2.jar,ant-launcher-1.9.2.jar,jsch-0.1.46.jar
gradle-plugins.properties
#plugin definitions
#Tue Sep 24 09:33:50 CEST 2013
plugins=gradle-plugins,gradle-code-quality,gradle-jetty,gradle-antlr,gradle-wrapper,gradle-osgi,gradle-maven,gradle-ide,gradle-announce,gradle-scala,gradle-sonar,gradle-signing,gradle-cpp,gradle-ear,gradle-javascript,gradle-build-comparison,gradle-diagnostics,gradle-reporting,gradle-publish,gradle-ivy,gradle-jacoco,gradle-build-setup,gradle-language-jvm,gradle-language-base,gradle-build-setup
(this file properties are unusable because some modules are not importable,
e.g.
gradle-jetty use jetty 6.x
gradle-sonar use https://bugzilla.redhat.com/show_bug.cgi?id=848096 == 3.2 and not newer release)
> That's a generic problem and it's not really Gradle-specific. But yes,
> there are some version problems, most notably Objectweb ASM. Different
> Gradle dependencies use versions 3 and 4 (shaded to avoid namespace
> conflicts). Fedora does not allow bundled libraries, which causes
> conflict between ASM 3 and 4. (Porting from ASM 3 to ASM 4 is possible,
> but non-trivial as there were major changes. This would again require
> some work.)
solved ... i think ... see http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.7-asm3.patch?...
> To sum up, Gradle maintainence requires substantial amount of work.
> Currently only few packages in Fedora are using Gradle which means that
> maintenance costs of Gradle outweight costs of porting other packages to
> different build systems.
regards
gil
/Polyglot Maven/https://bugzilla.redhat.com/show_bug.cgi?id=855331
9 years, 11 months
