----- Original Message -----
From: "Michel Alexandre Salim"
Sent: Thursday, June 14, 2012 10:31:20 AM
Subject: Re: [fedora-java] [java-sig-commits] Maven packages in EPEL 6?
-----BEGIN PGP SIGNED MESSAGE-----
On 06/11/2012 10:46 PM, Stanislav Ochotnicky wrote:
> Quoting Michel Alexandre Salim (2012-06-08 15:55:29)
>> Part of the rationale is that Kushal Das (cc:ed) and myself would
>> like to eventually write some Fedora infrastructure in Clojure --
>> which would, of course, necessitate having the whole stack in
>> RHEL/EPEL 6 as well.
> Unless you have a really, really good reason to do it in Clojure
> I'd urge you to look into using something that is already available
> on RHEL/EPEL/Fedora. No? Read on then...
That was the original motivation, but between the Java tooling issue
and that Fedora infrastructure is mostly Python (and there are
understandable reluctance to switching), we're currently aiming for
parallel Python (for Fedora) and Clojure (for OpenShift) development
for Kushal's Darkserver build ID information repository.
> There have been more than one requests before. The truth is
> however, that getting whole Maven stack into EPEL will require
> *substantial* time investment. Certainly not a 1-man job, and I
> assume there will be hard-to-identify bugs resulting from mixing of
> older RHEL java packages and requirements of new packages from
> Fedora. You will probably have to package additional packages for
>> Is there any technical difficulty involved in making these
>> packages available on EPEL? If it's a lack of interest, Kushal
>> and myself hereby volunteer to be the ones in charge of doing the
>> EPEL maintenance work.
> Problem is that just figuring out those problems is sometimes
> non-trivial because the error messages suck most of the time. You
> *will* have to modify a lot of Java packages, such as your new
> reviews. It will mean longer and uglier spec files, so at least in
> my packages I'd prefer to keep those spec files separate. You will
> find that not all RPMs in Fedora correctly state their required
> versions for example. Or that some packages are named differently.
> Or that we have patches packages to work on JDK 7, so they don't
> work on JDK 6 anymore (we don't have it in Fedora anymore).
Yes, I've already noticed several bugs in maven2 subpackages --
normally when some compatibility submodules are not shipped, but it
turns out that the ones that are shipped depend on Maven submodules
where the APIs have changed between 2.x and 3.x.
Speaking of which, could someone take a look at this maven2 bugfix
> Another issue is that current Maven was bootstrapped using older
> maven2 package. However we don't have that anymore and
> bootstrapping maven would have to be reworked from scratch.
We'd actually only need maven2 at the moment -- do you see many
in making that available for EPEL? It's not a high priority for us
right now (see first paragraph of response), but it seems to me that
the longer we wait the harder it'd be to do the bootstrapping.
> I would suggest making a list of maven dependency tree and have a
> look at the number of packages you'd need to package. If that
> doesn't scare you off, make a list of packages that are already in
> RHEL but different versions. Those might need compat packages. Also
> note that for example jakarta-commons-* packages have been renamed
> to apache-commons-*.
Yikes. But yes, will take a look. When is RHEL 7 arriving again? :)
> In short: no one really tried to get Maven 3.x into EPEL because
> just figuring out scope of such task is non-trivial. There's too
> many unknowns in play there.
That's understandable. It looks like if we're going to do this we
(those who want to see Maven in EPEL) would have to commit to
maintaining the EPEL 6 branch ourselves. Probably going to give EPEL
a miss altogether.
RHEL 6 already has a substantial amount of java libraries included and they are not that
old. Just to get EPEL 5 to the level of RHEL 6 would be huge effort itself. :)
> I am also sorry to say that you are unlikely to receive much
> support from me (as Maven maintainer) and most probably some other
> Java folks. Not because we don't want to help, but because you will
> be facing issues we haven't seen and just to figure out what needs
> to be done would take too much of our time we'd rather spend
> working on improving Java packaging for the future. A paradox: you
> might get more help from some other distributions who had to go
> through bootstrapping Maven when they started using our Java
Same irony with e.g. the Medical SIG -- sometimes other distributions
are further ahead and there's nothing wrong with collaboration.
The difference this time is that Fedora is way ahead of others in moving to Maven 3 and
abandoning v2 and this happened enough in the past to make any bootstrapping nowadays
quite different from what we had done in the past. That's why other distros migrating
just now might have better info on how to bootstrap Maven 3. And most RPM based distros
are more or less basing on what we do in Fedora (at least for the Java work) so it
shouldn't be that different.
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
- against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
java-devel mailing list