buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Toulme" <anto...@lunar-ocean.com>
Subject Re: OSGi support round two
Date Thu, 08 May 2008 07:32:22 GMT
Hi Assaf,

I don't know if that is feasible, but can you identify if the artifact is a
Maven artifact or a OSGi artifact before fetching it ?
Then depending on the nature of the artifact you would apply the right
algorithm to check out the right resource.

Sounds easy to say though.

Thanks,

Antoine

On Thu, May 8, 2008 at 6:00 AM, Assaf Arkin <arkin@intalio.com> wrote:

> On Wed, May 7, 2008 at 8:10 PM, Tommy Knowlton <tommy@ke4kug.net> 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.
>
> Assaf
>
>
> >
> >
> > Just one opinion.
> >
> > Tommy
> >
> > Sent from my iPod.
> >
> >
> > On May 7, 2008, at 20:10, "Assaf Arkin" <arkin@intalio.com> 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
> http://www.intalio.com
>



-- 
http://www.lunar-ocean.com/blog

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