buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: OSGi support round two
Date Thu, 08 May 2008 04:00:09 GMT
On Wed, May 7, 2008 at 8:10 PM, Tommy Knowlton <> wrote:

> IMO, Buildr is the migration path for those of us who got 2/3 of our
> projects mavenized before we found out how screwed we were. That being the
> case, I think maven versions and repositories should continue to be
> supported in as intuitive and direct a manner as possible, regardless of the
> outcome of this particular debate. Anything that would make it harder for
> folks like me to use Buildr in a migratory path away from maven would be a
> negative for the project.

I agree, adding OSGi should not come at the expense of less support for
Maven repositories.


> Just one opinion.
> Tommy
> Sent from my iPod.
> On May 7, 2008, at 20:10, "Assaf Arkin" <> wrote:
>  I circulated a proposal on buildr-dev to make transitive dependencies and
>> version matching the focal point for Buildr 1.4.  Briefly it will allow
>> you
>> to do something like this:
>>  compile.with foo
>> Which will download, install and compile with foo, but also all of foo's
>> dependencies.  Or if foo is another project, bring all of that project's
>> dependencies with it.  It will help keep buildfiles smaller by only
>> specifying the top packages it's using, and let Buildr figure out the
>> rest.
>> Version matching means that foo can specify the package name but no
>> version
>> number, and Buildr will attempt to match the most recent version for that
>> package.  Or you can specify some constraints, like >= 1.2 or != 1.3.
>> Right now we provide support for using and publishing packages, and it's
>> loosely based on the Maven 2 repository model.  We got the basics working,
>> just no support for transitive dependencies (other than an experimental
>> transitive method) and version matching.  To that we can also add OSGi
>> support, which means putting OSGi meta-data inside the packages (in
>> MANIFEST.MF) and reading it from them, in addition or instead of POM
>> (depending on source and target).
>> The problem is, doing both Maven and OSGi, and transitive dependencies and
>> version matching.  They don't like to co-exist, because OSGi and Maven
>> handle dependencies and version numbers differently.  Without going into
>> too
>> much details, I'll illustrate with a simple example.
>> Let's say you have three versions of the same JAR: 1.2.0-RC2, 1.2.0-2 and
>> 1.2.0-10.  The way Maven works, if the dependency just specifies "1.2",
>> then
>> the most recent version is 1.2.0-10 because 10 is higher than 2 and
>> numbers
>> are higher than alphanumeric.
>> The way OSGi (and most other packaging mechanisms) work, the last part of
>> the version number (qualifier) is just a string.  Being a string, the most
>> recent version is RC2, next is 2, and 10 is the oldest.  Developers who
>> use
>> OSGi never run into this problem because they package everything using
>> versions like 1.2.0, 1.2.0-B45 or 1.2.0-R20080506.
>> If we pick one model and support it natively, it will get all the cool
>> features and we'll do best effort on the other model.  Say we pick OSGi,
>> then we'll have a local repository that looks like an OSGi repository,
>> we'll
>> use OSGi version numbers, and make Maven artifacts look like OSGi bundles.
>> In reverse, if we go with Maven, we keep the same local repository model,
>> etc
>> Some things I'm not sure we can even do, e.g. Maven snapshots mess with
>> OSGi, not sure we can support them if we do both, but OSGi has timestamped
>> version numbers that achieve the same thing.
>> So part two is which one of these two models we do natively for transitive
>> dependencies and version matching, and which one we fake to work like the
>> other?
>> Assaf

CTO, Intalio

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message