Bug 830933

Summary: maven2 needs to provide maven-artifact as a subpackage
Product: [Fedora] Fedora Reporter: Michel Alexandre Salim <michel>
Component: maven2Assignee: Stanislav Ochotnicky <sochotni>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: akurtako, dbhole, java-sig-commits, sochotni, tradej, yyang
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-17 19:16:23 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 830784    
Attachments:
Description Flags
Patch to maven2 spec
none
Updated patch for maven2.spec
none
Updated patch for F18 and Rawhide, adding maven-artifact and maven-settings none

Description Michel Alexandre Salim 2012-06-11 13:26:04 EDT
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):
maven-artifact-manager-2.2.1-33.fc17.noarch
maven-3.0.4-5.fc17.noarch

How reproducible:
Always

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-11 21:23:27 EDT
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-11 22:34:18 EDT
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 12:05:44 EDT
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-25 23:21:43 EDT
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 10:20:38 EDT
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.
Comment 6 Stanislav Ochotnicky 2012-07-25 10:20:59 EDT
I meant leiningen of course :-)
Comment 7 Michel Alexandre Salim 2012-08-03 05:17:03 EDT
(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 04:19:34 EDT
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-18 20:44:42 EDT
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-18 22:25:03 EDT
http://salimma.fedorapeople.org/specs/clojure/leiningen-1.7.1-3.fc17.src.rpm
http://salimma.fedorapeople.org/specs/clojure/leiningen.spec

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

http://kojipkgs.fedoraproject.org//work/tasks/2608/4402608/build.log

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 01:30:17 EDT
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 05:18:02 EDT
maven2-2.2.1-37.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/maven2-2.2.1-37.fc18
Comment 13 Fedora Update System 2012-08-20 15:50:43 EDT
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:
https://admin.fedoraproject.org/updates/FEDORA-2012-12314/maven2-2.2.1-37.fc18
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2012-09-17 19:16:23 EDT
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.