On Wed, May 7, 2008 at 8:10 PM, Tommy Knowlton <[EMAIL PROTECTED]> 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" <[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 >> > -- CTO, Intalio http://www.intalio.com
