At the OSGi we have been working on the OSGi Bundle Repository. One
such repository is hosted on
http://bundles.osgi.org/browse.php
There is a description at http://bundles.osgi.org/vendors.php (see the
RFC). The repo hosts all the Eclipse bundles, Prosyst, and I am
waiting for Apache to leave incubation; they promised to link in as
well.
The OBR uses a very generic requirement/capability model that I think
is far more powerful than anything I have seen so far. The rules for
resolving are clear and specified in an abstract API. Richard has made
an implementation, I think Eclipse has worked on their Framework
resolver and I made a resolver. It is work in progress because we have
some hard OSGi related problems like "uses" that are hard to catch in
the requirement/capability model of today.
Can this model be interesting for a new repository?
Kind regards,
Peter Kriens
RH> Niclas Hedhman schrieb:
>> Quite a lot of Ivy activities. Perhaps should come up with an
>> umbrella project for that (similar to what Pax is to OSGi) and start
>> looking at consolidating these efforts, stake out some visions and
>> perhaps a road map...
RH> I think, some umbrella project would be nice, OTOH, currently, I'm the
RH> only one who's really working on this stuff.
RH> Peter already suggested to put our OPS4J Ivyrep in projects, instead of
RH> laboratory or something, because obvioulsy, Ivy is used by many people
RH> at OPS4J in their non-OSS projects.
RH> Now, my idea about this repository is quite simple: Build a clean
RH> repository, keep it consistent, let it grow to a repository that
RH> contains about everything people need. ivyrep.jayasoft.org is crap,
RH> mainly because it's very small, but also because some of the ivy.xml
RH> files there are just plain wrong. M2 is getting a mess. There's e.g.
RH> the groups commons-http and commons-httpclient which are probably the
RH> same thing. More and more things get somewhere in org.apache.*, but the
RH> commons are all still top-level. Except, when we include the JBoss
RH> repo, which puts JCI under org.apache.commons ... in Drools, you can
RH> see it very well: It depends on antlr:antlr:2.7.6 AND
RH> org.antlr:antlr:3.0ea8. One reason for this is maybe that M2's conflict
RH> resolver isn't able to select *both* and would just select the newer
RH> one in this case (I'm quite ignorant when it gets to M2, so this may be
RH> wrong). But it's inconsistent and worse, if my theory about M2's
RH> conflict resolver is true, it's a workaround.
RH> And this is the motivation for my building a new repository from
RH> scratch: All the existing repos contain lots of legacy, people made
RH> experiences and changed strategies, and repos are getting more and more
messed up =>> let's take what we learned the past few years, drop the
RH> legacy and build up a new repository.
RH> Quite a lot of work. There are lots of OSS projects out there, and we
RH> live in an actual JAR/dependency hell. E.g., the ivy.xml I made for
RH> Drools is wrong, because I was too lazy to 'ivyize' it all. Drools
RH> itself only has very few dependencies, the rest is deps of deps of
RH> deps. This is exactly, where that tool jumps in: The command
RH> pom2ivy -t -r http://www.ibiblio.org/maven2 \
RH> -r http://repository.jboss.com/maven2 \
RH> org.drools:drools-core:3.0.3 \
RH> org.drools:drools-decisiontables:3.0.3 \
RH> org.drools:drools-compiler:3.0.3 \
RH> org.drools:drools-jsr94:3.0.3
RH> gives me 28 new Ivy files containing all the information it could gather
RH> from the existing POMs, which is a good point to start off with that
RH> work (BTW, the people at JBoss still didn't put Drools 3.0.4 in their
RH> M2 repository). BTW, just to prove my point, this will still be wrong:
RH> The pom.xml of drools-core states that it depends on xstream and xpp3.
RH> I made a dependency graph on the Drools JARs[1] which shows that Drools
RH> only depends on xstream, but xstream depends on xpp3.
RH> Do we need an umbrella project for our Ivy efforts? Well, what other
RH> efforts are there? The only other effort towards Ivy I can see doing a
RH> quick filter on my notifications folder is the Ivy module Andreas is
RH> adding to builder. And, there's the idea of using Ivy in Loom, which
RH> probably won't ever be finished, because we will join forces and
RH> resurrect Silk (at least I hope so). So, I think, the umbrella project
RH> already exists in projects and is called ivyrep (maybe rename it to
RH> ops4jrep or something).
RH> But pushing this repository a bit might be a good idea. It will never be
RH> a real alternative to the existing repositories if it doesn't get
RH> populated. pom2ivy is actually a subproject of that. Before I committed
RH> it I already considered putting it in projects/ivyrep/pom2ivy instead
RH> of the lab, but I decided to keep it in the lab for now.
RH> cu,
RH> Raffi
RH> [1] http://www.kirkk.com/main/Main/JarAnalyzer
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
