Naming of JavaEE-APIs (and 'Provides' in spec-file)
by Chris Spike
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/
13 years, 4 months
Looking for java co-maintainers (will help out in return)
by Stanislav Ochotnicky
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
13 years, 4 months
apache-commons and javadoc symlinks
by Chris Spike
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
13 years, 5 months
building quartz with maven and missing jms dependencies
by Chris Spike
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/
13 years, 5 months
Java packages in EPEL
by Lubomir Rintel
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
13 years, 5 months
Re: [fedora-java] [Fedora-packaging] correct name for maven pom-file
by Andrew Overholt
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
13 years, 5 months
Trouble with commons-compress
by Orion Poplawski
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
13 years, 5 months
Maven for EL-6
by Orion Poplawski
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
13 years, 5 months
