Bug 963323

Summary: Making Maven officially available in openSUSE
Product: [openSUSE] openSUSE Tumbleweed Reporter: Denisart Benjamin <p.drouand>
Component: JavaAssignee: E-mail List <bnc-team-java>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: abonilla, afaerber, antoine.belvire, benedikt, bg, dvaleev, fstrba, javier, matthias, mpluskal, normand, plinnell, rombert, sbahling, wolfgang.engel
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: SUSE Other   
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 976102, 1074181    

Description Denisart Benjamin 2016-01-23 16:35:43 UTC
This is a kind of metabug to track progress made by people actually involved in Maven packaging. We will update this bug progressively according to progresses done themselves.
Comment 1 Denisart Benjamin 2016-01-24 12:00:13 UTC
According to Fedora's maven spec file, here is our missing dependencies for improving our own :
* aether-api
* aether-connector-basic
* aether-impl
* aether-spi
* aether-util
* aether-transport-wagon
* aopalliance
* apache-commons-lang3
* apache-commons-codec
* apache-commons-jxpath
* apache-commons-logging
* apache-resource-bundles
* atinject
* buildnumber-maven-plugin
* cglib
* easymock3
* google-guice
* hamcrest
* httpcomponents-core
* httpcomponents-client
* jsoup
* jsr-305
* junit
* maven-assembly-plugin
* maven-compiler-plugin
* maven-install-plugin
* maven-jar-plugin
* maven-javadoc-plugin
* maven-remote-resources-plugin
* maven-resources-plugin
* maven-site-plugin
* maven-surefire-plugin
* maven-wagon-file
* maven-wagon-http
* maven-wagon-http-shared
* maven-wagon-provider-api
* objectweb-asm
* plexus-classworlds
* plexus-containers-component-annotations
* plexus-containers-component-metadata
* plexus-sec-dispatcher
* plexus-utils
* sisu-inject
* sisu-plexus
* sisu-mojos
* xmlunit
* mvn(ch.qos.logback:logback-classic)
* mvn(org.mockito:mockito-core)
* mvn(org.codehaus.modello:modello-maven-plugin)
Comment 2 Denisart Benjamin 2016-01-24 13:20:35 UTC
About cycle dependencies : shall we make them depend on bootstrap packages ?
Comment 3 Matthias Mailänder 2016-01-24 20:03:52 UTC
Not sure if we have another choice if we won't to solve it clean and transparent. See https://build.opensuse.org/project/show/home:Mailaender:branches:Java:packages for what we already have.
Comment 4 Tomáš Chvátal 2016-01-27 13:20:40 UTC
(In reply to Denisart Benjamin from comment #2)
> About cycle dependencies : shall we make them depend on bootstrap packages ?

Cycle dependencies are not allowed, everything needs to be bootstraped for integration.
Comment 5 Denisart Benjamin 2016-01-27 19:58:29 UTC
Ok so we agree we have to use maven-boostrap to build these packages, right ?
Comment 7 Andreas Färber 2016-09-27 16:44:36 UTC
Not getting any SRs from community members or hearing any reports of progress, I have recently re-enabled my project:

The weekend I added a package maven-macros, whose centerpiece is automatic RPM Provides and Requires. With this, I have gone from some 29 failures to be investigated to lots of unresolvable packages that either need to be packaged or need to have .pom files added or installed to the new place.
Comment 8 Matthias Mailänder 2016-09-27 17:59:21 UTC
I tried to make some progress on the last Eclipse Hamburg Hackathon. The people who tried to help me were astonished about how twisted the dependencies are when we looked at the Fedora packaging, which isn't reproducible on OBS. I made minimal progress getting the build tools to work https://build.opensuse.org/package/show/home:Mailaender:branches:Java:packages/gradle-bootstrap but my biggest open issue is that I still can't build https://build.opensuse.org/package/show/home:Mailaender:branches:Java:packages/xmvn which is the key to success I assume.
Comment 9 Denisart Benjamin 2016-09-27 18:07:03 UTC
Sorry for not being much involved in this. I just lack of time lately. 
@Mailander : it looks like xmvn needs to be bootstraped in a first place.
Comment 10 Matthias Mailänder 2016-09-27 18:39:31 UTC
Yes, it also needs itself to build. Sadly binary packages aren't available https://bugzilla.redhat.com/show_bug.cgi?id=1329272 and I also have a hard time building it locally myself.
Comment 11 Andreas Färber 2016-09-27 20:26:57 UTC
If we stay with my approach then I believe no "xmvn" is needed at all.

I am not copying Fedora, I am cooking a new solution that works well for openSUSE - specifically I don't want to copy those weird Fedora depmap thingies in a flat directory in favor of the KISS paradigm. We have no compatibility requirements since we never had Maven working in the first place, so all that XML-duplicating .spec file cruft can be dropped from our packages like Duncan started in a few places (e.g., slf4j).

Also note that the current build setup is very ugly. Not just are you building the packages needlessly for 9 repositories, but since you don't have my repository in your path, your linked packages are now unresolvable for lack of my maven-macros and possibly other new packages from my project. We really need a proper staging project - either we use mine directly or we submit my packages to a new one (Java:packages:maven?) and drop my project.

My new approach has led to slf4j gaining a dependency on avalon-framework, which I have newly packaged as avalon-framework-api and am now seeing more dependencies on, e.g., classpathx-mail that need to install .pom files to get the needed Provides.

I was hoping no separate gradle-bootstrap would be needed - I tried bootstrapping it in gradle (but the gradle -bin.zip includes an older copy of Maven not patched to use the flatter repository layout, so not yet finding guava etc. libraries and needing some more symlinks).

If someone has any insights on how to build osgi-compendium (wants javax.microedition and Servlet stuff), SRs would be very welcome.
Comment 12 Matthias Mailänder 2016-09-28 05:23:35 UTC
Yes, a new central devel project like Java:packages:maven or Java:Maven would be helpful. My repository is effectively unmaintained. I only forked your packages as last year all builds were disabled and the many bootstrap packages at least sounded promising.
Comment 13 Denisart Benjamin 2016-09-29 09:28:56 UTC
Java:Maven has been setup.
Comment 14 Matthias Mailänder 2017-12-28 13:50:42 UTC
We have https://en.opensuse.org/User:A_faerber/Maven_packaging as a rough documentation, but not much progress. I sadly don't really understand the bootstrap process, so I am not of much help.
Comment 15 Andreas Färber 2017-12-28 17:53:09 UTC
Someone broke my current Java:maven setup by introducing a dependency on javapackages-tools[-local] in some core, presumably Java:packages package. Figuring out which one would allow to address the current failures.

Some packages forked from Java:packages also got conflicts with updates in Java:packages that will need to be resolved after the above issue.
Comment 16 Fridrich Strba 2018-11-15 16:23:22 UTC
Now, if you are interested, I worked during 3-4 weeks on a bootstrapping of maven/xmvn combo inside OBS. The result is to be found in https://build.opensuse.org/project/show/home:fstrba:maven

It has already only stuff built from source. But it is not as easy as that, because this whole thing has circular dependencies and I had to bootstrap it first building the stuff that I could with javac/jar/javadoc tools and have binary maven and binary xmvn inside. I was changing the rpms to xmvn built ones as soon as it was possible to run the binary xmvn against them. Once the dependencies were correctly rebuilt, maven and xmvn could be built.

If OBS is kind to us, this whole repository could settle in 1-2 days.
Comment 17 Denisart Benjamin 2018-12-11 13:30:38 UTC
Hi Fridrich !

So glad to see someone stepping in and be part of the project. I'm (finally) back from a long period of inactivity on OBS. 

Can you let us know how we can help achieve your project ?

Comment 18 Javier Llorente 2020-04-16 20:08:19 UTC
Fridrich Strba has packaged Maven. Therefore I am closing this bug.