On Wed, May 7, 2008 at 7:44 PM, Shane Witbeck <[EMAIL PROTECTED]> wrote:
> Expanding on the notion of deploying, I extended Buildr to allow > deployments to various server environments (local, development, > production, etc.). The command looks something like this: > > buildr projectname:deploy-dev > > The above command automagically packages and deploys the artifact(s) > to a specific server which makes it nice for turning around changes > quickly. To accomplish this I used a combination of extending > Buildr::Project and the Net::SFTP project. Have you looked into environments in 1.3? You could do something like: buildr -e dev projectname:deploy or set the environment variable BUILDR_ENV=dev. http://incubator.apache.org/buildr/settings_profiles.html#environments Assaf > > > > > > On Wed, May 7, 2008 at 9:44 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > On Wed, May 7, 2008 at 6:19 PM, Shane Witbeck <[EMAIL PROTECTED]> > > wrote: > > > > > > > I second the idea of going the way of OSGI. It's clearly the next step > > > in Java's evolution. > > > > > > In terms of pre-1.3 dependency support, we resorted to doing something > > > like the following to support a subset of compile dependencies for > > > runtime packages: > > > > > > project.runtime.with(specs) > > > > > > +1 for adding runtime dependencies. > > > > > > > > > > > > > > > Because some of our environments had shared runtime classpaths, it > > > wasn't always necessary to include certain libraries. I did this by > > > extending Buildr::Project to support the different kinds of internal > > > projects we have such as WebProject, StandaloneProject, BatchProject, > > > etc. > > > > > > Something else that was needed in our projects was a way of putting > > > together different packages for different environments. Again, by > > > extending Buildr::Project, I introduced a way to package and deploy > > > (via SSH) the various projects. > > > > > > I mention the ways that I've extended Buildr to possibly touch on new > > > features to incorporate such as: > > > > > > 1. Being able to define different sets of dependencies for projects > > > (in my case it was compile vs. runtime). I like the direction Assaf > > > mentions with being able to merge dependency arrays and better > > > transitive support. This is huge in terms of being able to make the > > > buildfile less verbose. > > > 2. A way to easily deploy (via SSH, etc.) packages > > > > > > Can you expand on that? > > > > > > > > > > > > 3. Better integration with IDE's. It's a struggle to keep the > > > dependencies in sync without having to regenerate the IDE files and in > > > the process losing other project-specific IDE settings. Perhaps this > > > is better solved via IDE-specific plugins for Buildr? > > > > > > Good point. It might be possible to retain those project-specific IDE > > settings, though I don't know what it would look like. > > > > > > > > > > > > 4. In terms of additional language support, my vote is for Flex. With > > > the recent open sourced SDK, I believe there will be a surge in usage > > > among not only Java developers but developers of other languages as > > > well. > > > > > > We'll need someone who's using Flex to help develop it. > > > > Also, this is something we don't have to tie to the release schedule. > We > > finally have an API for adding new languages and delivering extensions > using > > Ruby Gems, so you can get people to use it without waiting for the next > > release. Separately, once we add it to the code base it will show up in > the > > next release, but I think independent Gem would be the way to start. > > > > Assaf > > > > > > > > > > > > > > > > > I'd be glad to elaborate further on the points I've brought up and > > > look forward to contributing more. > > > > > > Thanks, > > > Shane > > > > > > > > > On Fri, May 2, 2008 at 5:41 PM, Assaf Arkin <[EMAIL PROTECTED]> > wrote: > > > > Now that 1.3 is out, it's time to start talking about future > releases. > > > > We've got the 1.3.x line of releases, for dealing with outstanding > > > issues, > > > > new ones we'll find along the way, and building on new features > that > > > showed > > > > up in 1.3. > > > > > > > > Separately, there's 1.4, the next major release and a place to make > more > > > > significant changes. We just have to decide what those would be. > > > > > > > > I propose that we focus 1.4 on improving the way we handle > dependencies. > > > > > > > > Specifically what I have in mind are transitive dependencies, > version > > > > matching, and OSGi support. So I'll start by talking about some > things > > > I've > > > > been looking into recently. > > > > > > > > > > > > For starters, adding a dependency method to artifact (which also > > > includes > > > > packages) that returns an array of all the known dependencies for > that > > > > artifacts. Ruby arrays are pretty powerful, you can do things > like: > > > > > > > > # Does it have a particular dependency? > > > > foo.dependencies.any? { |dep| ... } > > > > # Add new dependencies > > > > bar.dependencies << .... > > > > # Merge foo's dependencies into bar > > > > bar.dependencies |= foo.dependencies > > > > > > > > One problem that comes up frequently are broken dependency lists, > they > > > may > > > > be missing a dependency, or reference the wrong version, or include > one > > > you > > > > don't want to use. Mutable arrays would make it easy to fix these > > > broken > > > > dependency lists, for example: > > > > > > > > # Change the artifact in memory > > > > artifact( spec ).exclude( dont-want-this ).include( but want this ) > > > > # And use it > > > > compile.with spec > > > > > > > > It will be even better to introduce a Dependencies class that > extends > > > array > > > > and adds all sorts of convenience methods and lazy expansion, > similar to > > > > Rake's FileList. Then you could do things like: > > > > > > > > # Find dependency by its specification > > > > foo.dependencies.has?( spec ) > > > > # Exclude all dependencies that match a pattern > > > > foo.dependencies.exclude!( pattern ) > > > > # Expand all transitive dependencies and return flat list > > > > foo.dependencies.expand > > > > # Replace one with another > > > > foo.dependencies.replace!( dont-want, want ) > > > > > > > > The API for methods like compile.with and compile.dependencies > remain > > > the > > > > same, just changing the underlying implementation. > > > > > > > > Packages would acquire dependencies from the project, for example, > > > > package(:jar) would add all the dependencies from > compile.dependencies, > > > > which of course you can fix to your heart's content. > > > > > > > > > > > > Version matching makes it possible to point at the most recent > version > > > that > > > > satisfies a particular version requirement, so >=1.2 to get 1.2.0 > or > > > later, > > > > or ~>1.2.3 to get any version between 1.2.3 and 1.3 (excluding). > > > > > > > > > > > > OSGi is a set of big specs that boil a lot of oceans, the part I'm > > > > particularly interested in, is managing dependencies. When we > started > > > > working on Buildr, OSGi was used almost exclusively by Eclipse. > That > > > > changed. We're seeing more and more servers and frameworks > adopting > > > OSGi. > > > > > > > > Imagine that we had OSGi support. You will specify all the > dependencies > > > > once in the buildfile. Those will be used to build the project, > and > > > also > > > > incorporated into the package manifest. Other projects could use > these > > > > packages, reading the dependency list from the package manifest. > More > > > > important, when you get to deploy those packages, the runtime can > use > > > that > > > > information to bring in the right dependencies. > > > > > > > > That's one of those things that, once you use it, you won't want to > go > > > back. > > > > > > > > > > > > The problem is, OSGi and Maven are incompatible with each other. > I'll > > > try > > > > to summarize the differences: > > > > > > > > 1. The OSGi package identifier is typically the same as the file > name. > > > The > > > > Maven package identifier combines group and artifact identifiers, > only > > > the > > > > later is used as the file name. > > > > > > > > 2. Both use four-part version numbers. The first three are > numerical > > > (e.g. > > > > 1.2.3) and managed the same way, the fourth one is the qualifier. > OSGi > > > > qualifiers are alphanumeric and compared lexically, so R1 comes > before > > > R2; > > > > using number is not advised, 10 comes before 2. Maven qualifiers > are > > > > numeric for releases, and alphanumeric for pre-releases; the > qualifier > > > 10 > > > > comes after 2, and 2 comes after R2. > > > > > > > > 3. The rules for version matching are therefore not the same. The > same > > > > rule could match different versions, depending on whethr you use > OSGi or > > > > Maven. > > > > > > > > There's also the issue that OSGi keeps the meta-data inside the > package, > > > > while Maven requires the additional POM file, and if both are > present we > > > > have to decide which one to rely on. > > > > > > > > It's possible to some extent to support both at the same time, but > there > > > > will always be that impedence mismatch. If we do a good enough > job, it > > > will > > > > probably only affect edge cases, but we need to be aware. > > > > > > > > It will definitely be easier to pick one of the two, either OSGi or > > > Maven, > > > > and add transitive support and version matching based on that > model, > > > then do > > > > translation when necessary (e.g. when reading POM file, generating > OSGi > > > > manifest). > > > > > > > > If I had to start all over again, I would go for OSGi with Maven > > > > compatibility layer for three simple reasons: > > > > > > > > 1. Runtime deployment > > > > 2. Simpler to implement, and if your build doesn't quite work, > > > troubleshoot > > > > and fix. > > > > 3. Works the same way as most other packaging schemes (e.g. Gems, > > > Debian, > > > > RPM). > > > > > > > > > > > > Comments, ideas? > > > > > > > > Assaf > > > > > > > > > > > > > > > > -- > > > -Shane > > > > > > > > > -- > -Shane >
