shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [VOTE] Release Shale version 1.0.4
Date Wed, 03 Jan 2007 16:44:43 GMT
On 1/3/07, Craig McClanahan <> wrote:
> On 1/2/07, Rahul Akolkar <> wrote:
> >
> >    org.apache.shale:shale-apps-parent:1.0.4
> As part of my review of the proposed 1.0.4 release (all the sigs match ...
> but let's see what happens when I try to *use* this stuff :-), I want to try
> building our distribution artifacts.  I could build the framework with no
> problems -- but trying to build an app fails because this artifact is
> (correctly) not available in any repository yet.  Thinking about it a bit
> more, we aren't officially distributing *source* artifacts for this POM, or
> for "org.apache.shale:shale-master:2" either -- both of which you would need
> to install if you're trying to build Shale.  On the other hand, once the
> distribution is voted in and released, the artifacts will be available (but
> only if you know to go get them).
> One could certainly argue that, since our source build system is Maven
> based, we could expect this to "just work" for our downstream users after a
> release.  But what about folks who are not "always on" connected to the
> Internet?  Or folks who need to be able to build Shale, from source, in
> Maven's "offline" mode?  Maybe we should publish these two POM artifacts as
> part of some "source distribution" somewhere, like we do all the other POMs?

A m2 bootstrap distro having shale-{master,parent,apps-parent}.pom is
a possibility (the mechanics would need fleshing out since they're not
in the same source subtree), but that is also no guarantee that a
build will just work when there is no connectivity (or for an offline
build). For example, the build may not have:
 * A dependency version we need (workaround: install it manually from -- assumes that was downloaded, not just the
sample app zip)
 * A plugin we need (such as gpg with -Prelease, and while its
debatable whether using the release profile is a reasonable thing to
do, there are probably better examples elsewhere)

In my experience, for any sizeable m2 build, I've had to be connected
the first time. Ofcourse, thereafter, it may be possible to work
offline. Using build tooling that has a notion of central management
of artifact metadata (for dependencies and tooling components
themselves) implies, IMO, waiving some of our expectations about
things working when that (remote) metadata is no longer accessible.

> Craig
> PS:  I'm not done reviewing the proposed 1.0.4 bits, but things look good
> (outside of the issue raised here) so far.

No rush, please take your time.


View raw message