Bug 830933 - maven2 needs to provide maven-artifact as a subpackage
Summary: maven2 needs to provide maven-artifact as a subpackage
Alias: None
Product: Fedora
Classification: Fedora
Component: maven2
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Stanislav Ochotnicky
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 830784
TreeView+ depends on / blocked
Reported: 2012-06-11 17:26 UTC by Michel Alexandre Salim
Modified: 2012-09-17 23:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-09-17 23:16:23 UTC
Type: Bug

Attachments (Terms of Use)
Patch to maven2 spec (2.60 KB, patch)
2012-06-12 01:23 UTC, Michel Alexandre Salim
no flags Details | Diff
Updated patch for maven2.spec (4.25 KB, patch)
2012-06-12 02:34 UTC, Michel Alexandre Salim
no flags Details | Diff
Updated patch for F18 and Rawhide, adding maven-artifact and maven-settings (4.23 KB, patch)
2012-08-20 05:30 UTC, Michel Alexandre Salim
no flags Details | Diff

Description Michel Alexandre Salim 2012-06-11 17:26:04 UTC
Description of problem:
maven2 provides maven-artifact-manager as a subpackage, but not maven-artifact. This breaks packages that use maven-artifact-manager as it actually requires a class in maven-artifact that is no longer provided in maven-artifact 3.x

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Build and install leiningen and its dependencies - https://bugzilla.redhat.com/show_bug.cgi?id=830784
2. lein | grep maven/artifact

Actual results:
leiningen.pom  Problem loading: java.lang.NoClassDefFoundError: org/apache/maven/artifact/metadata/AbstractArtifactMetadata (maven.clj:1)

Expected results:

Additional info:

The class should still be in Maven 3.0.4: http://maven.apache.org/ref/3.0.4/apidocs/org/apache/maven/artifact/metadata/AbstractArtifactMetadata.html

but the Maven 3 RPM's maven-artifact.jar does not seem to contain it.

Comment 1 Michel Alexandre Salim 2012-06-12 01:23:27 UTC
Created attachment 591054 [details]
Patch to maven2 spec

Attached patch defines a separate maven-artifact subpackage and make maven-artifact-manager requires it at runtime (since the API of maven-artifact 3.0.x is not 100% compatible with maven-artifact-manager 2.x)

Comment 2 Michel Alexandre Salim 2012-06-12 02:34:18 UTC
Created attachment 591061 [details]
Updated patch for maven2.spec

This patch defines two new subpackages -- in addition to maven-artifact, it turns out that maven-settings (required by maven-project) is also not 100% API compatible between 2.x and 3.x

Comment 3 Stanislav Ochotnicky 2012-06-25 16:05:44 UTC
Just to make sure this doesn't look like I didn't look at this at all...Whilte maven2 could just add those new subpackages, I'd rather do it in the way of [1]. And I don't want to change it until it goes through guideline approval process because I've been burned like that before

[1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Compatibility_packages

Comment 4 Michel Alexandre Salim 2012-06-26 03:21:43 UTC
Hi Stanislav,

As discussed in the Java SIG list, sure, I understand the reasoning. Listing several questions I asked on the mailing list, as they relate to this request:

1. any estimate for when the guideline changes will be voted on? The Clojure feature for F18 is stalled waiting on this

2. I identified several subpackages currently generated from maven2 that are actually broken without the compatibility maven-artifact and maven-settings -- presumably they'd have to follow these guidelines too

3. Given that the subpackages are shipped together with the Maven tarball, do you foresee maintaining these *within* the Maven2 srpm, just with updated packaging rules, or do you want to maintain them as separate SRPMs? As I mentioned on the list, these subpackages are configured to pick up the version number of the Maven used to build them, so maintaining them separately is a hassle (as Maven2 is not installable on F17, see below)

4. Should we fix the maven package as well not to provide and obsolete maven2? That's preventing maven2 from actually being installed at all, in which case, we might as well only ship the compatibility subpackages and not maven2 itself.

Thanks, and sorry for all the questions!

Comment 5 Stanislav Ochotnicky 2012-07-25 14:20:38 UTC
I was almost done with packaging maven-artifact when I actually tried to rebuild lenigan and got success:

So I am closing this as won't fix in the end (sorry it took so long), but feel free to reopen if it's really needed.

Comment 6 Stanislav Ochotnicky 2012-07-25 14:20:59 UTC
I meant leiningen of course :-)

Comment 7 Michel Alexandre Salim 2012-08-03 09:17:03 UTC
(In reply to comment #5)
> I was almost done with packaging maven-artifact when I actually tried to
> rebuild lenigan and got success:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4328694
> So I am closing this as won't fix in the end (sorry it took so long), but
> feel free to reopen if it's really needed.

Re-opening -- while Leiningen can be built without the correct version of maven-artifact, just typing 'lein' on the command line with it installed will trigger errors due to some methods not available in the artifact JAR that comes with Maven 3.

Could you finish the maven-artifact packaging? Apologies for the delay in responding, was traveling.

Comment 8 Stanislav Ochotnicky 2012-08-06 08:19:34 UTC
Hmm, I wanted to have a look but I can't really reproduce this. Instead jars inside rpm of leiningen that I built are practically empty:
Archive:  /usr/share/java/leiningen.jar
Zip file size: 100164 bytes, number of entries: 17
drwxr-xr-x  3.0 unx        0 b- stor 80-Jan-01 00:00 META-INF/
-rw-r--r--  3.0 unx      139 t- defX 80-Jan-01 00:00 META-INF/MANIFEST.MF
drwxr-xr-x  3.0 unx        0 b- stor 80-Jan-01 00:00 META-INF/maven/
drwxr-xr-x  3.0 unx        0 b- stor 80-Jan-01 00:00 META-INF/maven/leiningen/
drwxr-xr-x  3.0 unx        0 b- stor 80-Jan-01 00:00 META-INF/maven/leiningen/leiningen/
-rw-r--r--  3.0 unx      104 t- defX 80-Jan-01 00:00 META-INF/maven/leiningen/leiningen/pom.properties
-rw-r--r--  3.0 unx     3138 t- defX 80-Jan-01 00:00 META-INF/maven/leiningen/leiningen/pom.xml
drwxr-xr-x  3.0 unx        0 b- stor 80-Jan-01 00:00 leiningen/
-rw-r--r--  3.0 unx    73583 b- defX 80-Jan-01 00:00 leiningen.png
drwxr-xr-x  3.0 unx        0 b- stor 80-Jan-01 00:00 leiningen/help/
-rw-r--r--  3.0 unx    11252 t- defX 80-Jan-01 00:00 leiningen/help/copying
-rw-r--r--  3.0 unx     4202 t- defX 80-Jan-01 00:00 leiningen/help/deploying
-rw-r--r--  3.0 unx    12335 t- defX 80-Jan-01 00:00 leiningen/help/readme
-rw-r--r--  3.0 unx    11992 t- defX 80-Jan-01 00:00 leiningen/help/sample
-rw-r--r--  3.0 unx    17611 t- defX 80-Jan-01 00:00 leiningen/help/tutorial
-rw-r--r--  3.0 unx      408 t- defX 80-Jan-01 00:00 script-template
-rw-r--r--  3.0 unx      342 t- defX 80-Jan-01 00:00 script-template.bat

And I get errors about missing leiningen classes instead of maven ones. Maven issues should be solved by adding maven-core/maven-compat from maven-3.x package on classpath instead of maven-artifact from m2. Some classes were moved to different jars in m3 but they are still compatible (mostly :-) )

Comment 9 Michel Alexandre Salim 2012-08-19 00:44:42 UTC
Something was wrong in the way I originally packaged Leiningen; not sure how it even worked in the first place. I'm borrowing Debian's packaging script this time. Will post the log here but I'm definitely getting stuck on a missing class that's in maven-artifact 2.x and not in 3.x anymore.

Comment 10 Michel Alexandre Salim 2012-08-19 02:25:03 UTC

Without maven-artifact from Maven2, the following error is triggered on build. It works fine on my computer where I have a maven-artifact installed, generated using the patch attached on this bug report


Exception in thread "main" java.lang.ClassNotFoundException: org.apache.maven.artifact.versioning.DefaultArtifactVersion (core.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:5440)
	at clojure.lang.Compiler.eval(Compiler.java:5415)
	at clojure.lang.Compiler.load(Compiler.java:5857)
	at clojure.lang.RT.loadResourceScript(RT.java:340)
	at clojure.lang.RT.loadResourceScript(RT.java:331)
	at clojure.lang.RT.load(RT.java:409)
	at clojure.lang.RT.load(RT.java:381)
	at clojure.core$load$fn__4519.invoke(core.clj:4915)
	at clojure.core$load.doInvoke(core.clj:4914)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invoke(core.clj:4729)
	at clojure.core$load_lib.doInvoke(core.clj:4766)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invoke(core.clj:542)
	at clojure.core$load_libs.doInvoke(core.clj:4800)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invoke(core.clj:544)
	at clojure.core$use.doInvoke(core.clj:4892)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at user$eval1.invoke(NO_SOURCE_FILE:1)
	at clojure.lang.Compiler.eval(Compiler.java:5424)
	at clojure.lang.Compiler.eval(Compiler.java:5391)
	at clojure.core$eval.invoke(core.clj:2382)
	at clojure.main$eval_opt.invoke(main.clj:235)
	at clojure.main$initialize.invoke(main.clj:254)
	at clojure.main$script_opt.invoke(main.clj:270)
	at clojure.main$main.doInvoke(main.clj:354)
	at clojure.lang.RestFn.invoke(RestFn.java:512)
	at clojure.lang.Var.invoke(Var.java:385)
	at clojure.lang.AFn.applyToHelper(AFn.java:185)
	at clojure.lang.Var.applyTo(Var.java:482)
	at clojure.main.main(main.java:37)
Caused by: java.lang.ClassNotFoundException: org.apache.maven.artifact.versioning.DefaultArtifactVersion
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:61)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:186)
	at leiningen.core$eval5$loading__4414__auto____6.invoke(core.clj:1)
	at leiningen.core$eval5.invoke(core.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:5424)
	... 31 more

Comment 11 Michel Alexandre Salim 2012-08-20 05:30:17 UTC
Created attachment 605575 [details]
Updated patch for F18 and Rawhide, adding maven-artifact and maven-settings

This follows the new layout of providing versioned compatibility packages for JARs that Maven 3 also ships, instead of using maven2/maven-{the_artifact}.jar without versioning

I'm updating the Leiningen review request to use the classpath provided by this patch; a precompiled RPM is already uploaded, built using Mock to verify that dependencies are complete

Comment 12 Fedora Update System 2012-08-20 09:18:02 UTC
maven2-2.2.1-37.fc18 has been submitted as an update for Fedora 18.

Comment 13 Fedora Update System 2012-08-20 19:50:43 UTC
Package maven2-2.2.1-37.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing maven2-2.2.1-37.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2012-09-17 23:16:23 UTC
maven2-2.2.1-37.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.