-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > compatibility. > >> 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 request? https://bugzilla.redhat.com/show_bug.cgi?id=830933 > 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 issues 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 5 a miss altogether. > 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 > stack. > Same irony with e.g. the Medical SIG -- sometimes other distributions are further ahead and there's nothing wrong with collaboration. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: salimma@xxxxxxxxxxxxxxxxx | GPG key ID: A36A937A Jabber: hircus@xxxxxxxxxxxxx | IRC: hircus@xxxxxxxxxxxxxxxx () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2ZNIAAoJEEr1VKujapN6+34H/iaa9Sh4I/lvWIHi3ko5KCLG fUtFAZrwksYI6RKmM00bRuk6JUBIWBqBPJWDswwEj+gqO+nb8JT/GFJ5szttZH+R mxRZNSZ2eNdLAGPe54VgkFgdrU6HCnA9SQHel1dDRu7oVryOoQ89+Rm98w4IRGMw nfrma40tWK+s5s0ccVEIfIidxg0OqW9wj/CEXEA9uh27U2m2uLJ/z8NmAAz5NVYf fB/0FJxIMEHuQ54D25THsyKZW3PP0B04cjcJhncRZOx7PIr2USLqMtmyER4J39QN 5faoskYd6VuDXNgD1s5F31ARcwUYwPEF6kxjaV4uwZq8QVeHDYRQ9QYKvR458bU= =CpQQ -----END PGP SIGNATURE----- -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
