On 2011-08-18 11:58:51 (+0200), Duncan Mac-Vicar P. <dmacvicar@suse.de> wrote:
On 08/15/2011 01:13 AM, Pascal Bleser wrote: [...]
Stephen Shaw has been putting a lot of effort into doing it properly since some time and while he's made a lot of progress already, I think we're still far away from having a useful set of common Java libraries (there are gazillions of open source Java libraries and frameworks out there).
I agree with your view on the matter.
I can speak with some experience here because we had to build a hundred of package in order to get SUSE Manager running. We are now in the process to reconcile those packages in a project called Java:base, merging our packages with stuff we rebuilt from Fedora, stuff from Java:packages and stuff from Stephen.
Ah, very good! First time I hear about it :)
The main issue for us (my team) with this approach is that we need to be able to patch sources to give L3 support (we can't wait for the next upstream release).
Understandable. I listed that as one of the drawbacks ;)
When building Java:base, we gave up with maven. We have a maven3 package from binaries, but we are not using it. We continued packaging every maven dependent package using the maven ant plugin, generating build.xml and maven-build.xml and then using ant. Worked very well on most of the cases. However, we will never be able to package more complex stuff: think glassfish. Just imagine Redhat is still unable to build JBoss, which they own, and they are resorting to add mvn-build support directly to koji to handle the complexity.
mmmmyeah, those are quite different beasts. Never tried to build them from source though, can't say much about it (except that no one should use JEE containers in the first place. I hope you don't use one for SUSE Manager. But that's another discussion ;))
Still, I think your tool covers the 90% of the cases where people just want to run stuff, and this should not get lost.
I propose to build a self-contained repository for Java based on this tool, it would be lot of value for the community and SUSE customers. The main goal of this repo would be more completeness and being vanilla instead of patches and bugfixes.
Yeah, had something like that in mind as well. At least to have something to start with. We (or I) should set a goal and see whether that approach works sufficiently well for that, e.g. packaging Glassfish or Tomcat.
Then we could work to make Java:base compatible with the "evil" packages, so that they can be mixed without much trouble: Provides, locations, etc.
And replace the "evil" packages by "proper" ones. IMHO what pom2spec brings to the table is an interim solution. It's far from perfect, but it's something.
For the Provides part, we should give a look at what Fedora is doing as they are already adding provides for OSGi at least, and being compatible would be nice.
Okay, didn't know about that. Yes, it would be utterly stupid to be incompatible, we have enough differences already.
Now that you are still playing with the technology, another project that looks interesting is Ivy Roundup, with is a self-contained and consistent repository of packager.xml metadata to be used with the Ivy packager resolver, this allows ivy to resolve an artifact directly from the upstream project (even unziping dist files) allowing the Roundup project itself to contain only metadata: http://code.google.com/p/ivyroundup/
Didn't have that one on my radar. I've pretty much given up on Ivy metadata, as what almost everyone is using is Maven Central. It's pretty much the authoritative source. And I know about the many issues with Maven Central, quite a lot of pom files there are b0rked, learned that the hard way. Most of them don't even include the license. But I do expect the dependency information to be rather dependable, and that's definitely the toughest part to get right (the license, summary or description can easily be looked up). But sure, pom2spec is simple and stupid enough to collect metadata from different sources, including Ivy RoundUp or other Maven repos (e.g. the one from JBoss). Having a look at the Ivy RoundUp metadata [1], they definitely seem to get a few things right, and have much more reliable metadata. But the <configurations/> thingy in Ivy is way too flexible (or, rather, loosely defined) to be useful. [1] curl \ https://ivyroundup.googlecode.com/svn/trunk/repo/modules/org.apache.wicket/w... \ | xmllint format -|view - Could be feasible to use the ivy.xml + packager.xml [2] to generate a spec file, within limits. We can't run ivyroundup itself, as it downloads the artifacts (jars, zips) by itself, which doesn't work in OBS. [2] curl \ https://ivyroundup.googlecode.com/svn/trunk/repo/modules/org.apache.wicket/w... \ | xmllint format -|view - I wonder whether we could find some time at the openSUSE conf to sit in a room for an hour and see whether we come up with a few ideas and gotchas. Right now, I'm stuck with pom2spec because I'm not sure how we should handle the versioning (see original post). * wicket = 1.4.3 * org.apache.wicket-wicket = 1.4.3 * wicket-1_4_3 = 1.4.3 * org.apache.wicket-wicket_1_4_3 = 1.4.3 * wicket-1_4 = 1.4.3 * org.apache.wicket-wicket-1_4 = 1.4.3 ? The same applies to the Provides, although we're a lot more flexible there as one package can make several provides. I would suggest something along the lines of Provides: java(org.apache.wicket:wicket) = 1.4.3 That way, packages that depend on it can choose the granularity: * Requires: java(org.apache.wicket:wicket) = 1.4.3 * Requires: java(org.apache.wicket:wicket) >= 1.4.1 Requires: java(org.apache.wicket:wicket) < 1.5 etc... That way the name of the package in itself doesn't matter too much, and it could be kept as simple as e.g. "wicket-1.4.3" (that's %{name}-%{version}), or "apache-wicket-1.4.3". Thoughts ? cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf