java-devel October 2013

java-devel@lists.fedoraproject.org

19 participants
19 discussions

Apache TomEE rpms
by David Blevins 12 Feb '16

12 Feb '16

Hello Fedora/Java people, First post to the list, so hello! We've crafted up some RPMs for Apache TomEE and are looking to contribute them to Fedora if at all possible. * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-jaxrs-1.5.2-1.noarc… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-webprofile-1.5.2-1.… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-plus-1.5.2-1.noarch… I haven't much of an idea on what the process for this might be. Dan Allen (RedHat) pointed us this way. Hoping someone here might have insight, even if that is some other list. -David

5 5

Why no Class-Path manifest attribute?
by Florian Weimer 06 Feb '14

06 Feb '14

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

10 23

Packaging tomcat shell scripts
by Robert Rati 16 Jan '14

16 Jan '14

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

5 22

Heads-up: Upcoming netty major version update in Rawhide (Will Break Stuff)
by Jon VanAlten 02 Jan '14

02 Jan '14

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/8237afff64509520865c08bf4f5fd130e06ae…

5 11

Gradle upgrade issues (#976330)
by Michael Ekstrand 12 Nov '13

12 Nov '13

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/

6 12

Time for new Guidelines:Java (Call for Action)
by Stanislav Ochotnicky 31 Oct '13

31 Oct '13

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

2 1

Apache Solr (4.5.1) first import - remaining open bugs
by gil 29 Oct '13

29 Oct '13

1 0

guava update in rawhide
by Mikolaj Izdebski 29 Oct '13

29 Oct '13

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

1 0

The trouble with metadata-extractor
by Andrea Musuruane 28 Oct '13

28 Oct '13

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.

2 3

Gradle upgrade issues (#976330)
by gil 27 Oct '13

27 Oct '13

/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?h=… > 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

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2013