On 1/3/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 1/2/07, Rahul Akolkar <[EMAIL PROTECTED]> 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?
<snip/>
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
shale-framework.zip/lib -- 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.
<snap/>
No rush, please take your time.
-Rahul
