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.
Just one opinion.
Tommy
Sent from my iPod.
On May 7, 2008, at 20:10, "Assaf Arkin" <[EMAIL PROTECTED]> 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
