java-devel July 2010

java-devel@lists.fedoraproject.org

9 participants
9 discussions

Naming of JavaEE-APIs (and 'Provides' in spec-file)
by Chris Spike 20 Jul '10

20 Jul '10

Hi folks, We currently have some JavaEE-API packages on the way[1][2][3], and there is a need for discussion. We already exchanged some arguments on IRC (and some of us have some strong opinions :)), but eventually we agreed, that the list is the proper place for this. As you can see in bugzilla, the packages are named differently. One approach is <api provider>-<api name> (like geronimo-jpa), another one is <api provider>-<api name>-<api version>-api (like geronimo-annotation-1.0-api). So the question is, how to do it. The first thing you'll probably say is "Hey, version names don't belong it the package name according to the naming guidelines". That's right. But actually, annotation-1.0 has several different versions while annotation-1.1 is a whole different animal. So the actual version of annotation-1.0 would be 1.1.1 at the moment.[4] Next argument was: "Well Fedora is bleeding edge, just do the lasted version". Good point actually. But that is not always possible (maybe impossible at all). Let's say, we just do the latest version of an api and we would like to package ejb-3.1. ejb-3.1 explicitly requires annotation-1.1 (great, the latest version there is) but also interceptor-1.1 (damn, there is interceptor-3.0). The pom-file is very specific about those version number and I wouln't bet on compatibility. Some packages just rely on a certain API version (not package version) and upstream does not always want to fix it. (i've seen asm ClassWriter constructors with one boolean argument in one api version, and one int argument in another. The upstream project just use the int-version, explicitly demanded the corresponding API and said, there no necessity to fix). So the "ship only lastest"-approach probably won't work here. If you do a package that requires a certain version of an api, you have to check the version. To do this with the <api provider>-<api name>, every api package has to 'Provide: <api name> = spec_version'. This is a bad idea, because it doesn't provide <api name> at all. It just provides the interfaces (no implementation), and if someone comes along and does a package that actually implements the interface, this could lead to real trouble. With the <api provider>-<api name>-<api version>-api approach, every api would do a 'Provides: <api name>_<api version>_api = package version' . You could just check for a certain api version and even for a package version if you like. No troubles, if someone actually implements it. (Actually tomcat does it like this) It may be a good idead to look at the JPackage guys and how they did it. Some of the Jpackage geronimo-spec (co-)maintainers should be on this list (and probably some other JPackage guys, too) and maybe they can tell us why they did it like they did it (or why we shouldn't do is like they did at all :)) Regards, Chris [1] https://bugzilla.redhat.com/show_bug.cgi?id=616354 [2] https://bugzilla.redhat.com/show_bug.cgi?id=615812 [3] https://bugzilla.redhat.com/show_bug.cgi?id=615809 [4] http://svn.apache.org/repos/asf/geronimo/specs/tags/

1 0

Looking for java co-maintainers (will help out in return)
by Stanislav Ochotnicky 19 Jul '10

19 Jul '10

Hi, I have quite a few java packages and for most of these I am the sole maintainer. This is no good in case something comes up... The list is here: https://admin.fedoraproject.org/pkgdb/users/packages/sochotni?acls=owner There are for example: * several apache-commons-* packages * log4j * few maven2 plugins * xbean * several non-java packages (you are welcome to help with that too). Most of these packages have been recently updated to latest versions and are pretty nice and clean. If you own a java package or two and would like another co-maintainer...just drop me a line. I tend to think that sharing responsibilities for packages is better than "This is my package! Hands off!", so if you feel the same: Great! Enjoy beginning of new week everyone, -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com

1 0

apache-commons and javadoc symlinks
by Chris Spike 16 Jul '10

16 Jul '10

Hi, While most of the java libraries copy their javadocs to {_javadocdir}/%{name}-%{version} and provide a symlink {_javadocdir}/%{name}, some simply copy the files to {_javadocdir}/%{name} (like commons-compress or commons-math). As long as there is an unversioned dir, I actually don't see any problems (or necessity for the versioned symlink), but I'm curious: Is there any recommendation on this? Regards, Chris

3 3

building quartz with maven and missing jms dependencies
by Chris Spike 12 Jul '10

12 Jul '10

Hi, I'm trying to make a package for quartz[1], but I'm running into some dependency troubles when I try to compile it with maven. It semms to require a Java Message Service[2] implementation to build (though I know, that jms is not a runtime requirement): mvn-jpp -Dmaven.repo.local=/home/makerpm/rpmbuild/BUILD/quartz-1.8.3/.m2/repository -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar -Dfile=/usr/share/java/jms.jar install javadoc:javadoc [..] Missing: ---------- [..] 2) javax.jms:jms:jar:1.1 [..] Path to dependency: 1) org.quartz-scheduler:quartz:jar:1.8.3 2) javax.jms:jms:jar:1.1 One jms implementation is provided by the package geronimo-jms, but obviously, maven can't find during the build process (yes, it's definitely installed). I guess, the culprit is the following entry in maven2-depmap: <dependency> <maven> <groupId>org.apache.geronimo.specs</groupId> <artifactId>geronimo-jms_1.1_spec</artifactId> <version>1.1.1</version> </maven> <jpp> <groupId>JPP</groupId> <artifactId>geronimo-jms</artifactId> <version>1.1.1</version> </jpp> </dependency> So how can I bend this to find the classes in javax.jms? Is there a way of telling maven during build that javax.jms is somewhere else? Or do I have to ask the maintainer of geronimo-jms to change groupId and artifactId? And what happens then, if someone else packages a different jms implementation like openjms? Regards, Chris [1] http://www.quartz-scheduler.org/ [2] http://java.sun.com/products/jms/

2 2

Java packages in EPEL
by Lubomir Rintel 09 Jul '10

09 Jul '10

Hi, I intend to get selenium remote control into EPEL 6. Unfortunately, its dependency chain is rather big, including whole Maven stack. I've compiled a list of packages (run-time, for now, probably more are needed to build) and would like to know if there's anyone with similar interest around (Orion, I've seen your message in the archives). Maintainers of the packages (in Cc): It would be awesome if you could request the branch and maintain your packages. Maintenance of the package in EPEL is basically rather low-overhead. It mostly involves patching the package for few serious and security bugs if there are any, with rebases to new versions strongly discouraged). If you for some reason don't want to, or for whatever reason can't maintain the package in EPEL for EL-6, please let me know. There are also some packages which are already branched an need to be built. Respective maintainers, could you please trigger a rebuild if you are not waiting for dependencies? Thanks! Also, there's a rather large number of orphaned packages. I doubt they are obsoleted somehow, since they're being still dependent on. Unless anyone else volunteers, I'll take them, at least for EPEL branches. Now, here's the list (ordered by maintainer name): plexus-digest akurtakov Branch maven-plugin-tools akurtakov Branch jaxen devrim Branch tomcat5 devrim Branch modello fnasser Branch aqute-bndlib fnasser Branch httpunit fnasser Branch maven-wagon fnasser Branch nekohtml fnasser Branch plexus-utils fnasser Branch plexus-classworlds fnasser Branch plexus-containers fnasser Branch maven-scm guidograzioli Branch maven2-common-poms guidograzioli Branch pmd jjames Branch swing-layout lkundrak Branch msv mbooth Branch plexus-velocity mbooth Branch plexus-container-defaul mbooth Branch plexus-interactivity mbooth Branch xml-commons-apis12 mbooth Branch jakarta-commons-validator mbooth Branch geronimo-jms mef Branch dom4j nsantos Branch xom nsantos Branch xpp2 nsantos Branch xpp3 nsantos Branch classworlds nsantos Branch dtdparser nsantos Branch gnu-regexp nsantos Branch relaxngDatatype nsantos Branch xmlrpc orphan Branch isorelax orphan Branch maven-doxia orphan Branch maven-jxr orphan Branch maven-surefire orphan Branch plexus-compiler orphan Branch plexus-ant-factory orphan Branch plexus-bsh-factory orphan Branch maven-embedder overholt Branch maven-enforcer-rule-api overholt Branch xmlunit pcheung Branch plexus-archiver pcheung Branch plexus-i18n pcheung Branch checkstyle rmyers Build jakarta-commons-cli rmyers Build ganymed-ssh2 robmv Build ini4j victorv Branch freemarker victorv Branch javahelp2 victorv Branch netbeans victorv Branch netbeans-resolver victorv Branch netbeans-svnclientadapter victorv Branch netbeans-platform victorv Build maven2 yyang Branch maven-shared yyang Branch Thank you in advance! Lubo

1 0

Re: [fedora-java] [Fedora-packaging] correct name for maven pom-file
by Andrew Overholt 09 Jul '10

09 Jul '10

Hi Chris, Java/Maven-specific questions like this should probably be directed to java-devel(a)lists.fedoraproject.org first. Andrew * Chris Spike <chris.spike(a)arcor.de> [2010-07-08 15:59]: > Hi, > > Is there a recommendation on the name of the pom file for java packages? > There is a template in the wiki[1] that tells me to name it > JPP-%{name}.pom, but actually most packages call it JPP.%{name}.pom or > JPP-%{short_name}.pom. > Even apache-commons packages are non consistent (e.g. > JPP-commons-codec.pom, JPP-apache-commons-math.pom, > JPP.jakarta-commons-io.pom or JPP-jakarta-commons-net.pom) so I guess > this is up to taste? > > Regards, Chris > > [1] https://fedoraproject.org/wiki/Packaging/Java#maven_2 > -- > packaging mailing list > packaging(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/packaging

6 6

Trouble with commons-compress
by Orion Poplawski 07 Jul '10

07 Jul '10

I'm trying to build an apache-rat package that depends on commons-compress. I've installed apache-commons-compress-1.0-7.fc13.noarch which appears to contain a pom: /usr/share/maven2/poms/JPP-commons-compress.pom But my build doesn't appear to find it. Any ideas? Perhaps: %add_to_maven_depmap org.apache.maven %{shortname} %{version} JPP %{shortname} in apache-commons-compress.spec needs to be: %add_to_maven_depmap org.apache.commons %{shortname} %{version} JPP %{shortname} Logs: Downloading: file:///usr/share/maven2/repository/JPP/maven2/default_poms/org.apache.commons-commons-compress.pom Downloading: file:///usr/share/maven2/repository/org.apache.commons/commons-compress.jar [WARNING] Skipping non filebased repository http://repo1.maven.org/maven2 in full offline mode [INFO] Failed to resolve artifact. Missing: ---------- 1) org.apache.commons:commons-compress:jar:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-compress -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-compress -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.rat:apache-rat-core:jar:0.8-SNAPSHOT 2) org.apache.commons:commons-compress:jar:1.0 ---------- 1 required artifact is missing. for artifact: org.apache.rat:apache-rat-core:jar:0.8-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/maven-snapshot-repository) __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) [INFO] ------------------------------------------------------------------------ [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: ---------- 1) org.apache.commons:commons-compress:jar:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-compress -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-compress -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.rat:apache-rat-core:jar:0.8-SNAPSHOT 2) org.apache.commons:commons-compress:jar:1.0 ---------- 1 required artifact is missing. for artifact: org.apache.rat:apache-rat-core:jar:0.8-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/maven-snapshot-repository) __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: ---------- 1) org.apache.commons:commons-compress:jar:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-compress -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-compress -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.rat:apache-rat-core:jar:0.8-SNAPSHOT 2) org.apache.commons:commons-compress:jar:1.0 ---------- 1 required artifact is missing. for artifact: org.apache.rat:apache-rat-core:jar:0.8-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/maven-snapshot-repository) __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:318) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:282) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1246) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:401) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more [INFO] ------------------------------------------------------------------------ -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 1

Help with pdfbox maven build
by Orion Poplawski 01 Jul '10

01 Jul '10

I'm getting a build error with pdfbox-1.2 on F14: [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /builddir/build/BUILD/pdfbox-1.2.0/fontbox/src/test/java/org/apache/fontbox/cff/Type1CharStringTest.java:[19,23] package org.junit does not exist /builddir/build/BUILD/pdfbox-1.2.0/fontbox/src/test/java/org/apache/fontbox/cff/Type1CharStringTest.java:[19,0] static import only from classes and interfaces Scratch build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2288228 No idea what to do next, help would be greatly appreciated. http://www.cora.nwra.com/~orion/fedora/pdfbox.spec ttp://www.cora.nwra.com/~orion/fedora/pdfbox-1.2.0-1.fc13.src.rpm Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

Maven for EL-6
by Orion Poplawski 01 Jul '10

01 Jul '10

What's the status of maven for EL-6? Is it in RHEL? Does it need to get branched from the fedora packages? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2010