Here's another batch comment...sorry for the bursty communication
style! :-)
Local Repo Separation Notes:
1. Having a strict (automatic) one-workspace-per-build approach kills
any idea of having integration-test runs that themselves have
predictable, isolated environments, and puts us back to using the
plugin contortions I've been using lately. Two things are key here:
(a) you don't want to pollute *anything* else with the artifacts
subjected to integration-testing, and (b) you want to ensure that
integration tests "resolve" the subject artifact accurately every
time, regardless of what else is going on in the build. If you want
to adopt workspaces as a transactional approach to building (which
IMO implies having something to bulk-transfer the resulting artifacts
out of the workspace to some common location for reuse elsewhere on
localhost) that's one thing, but we really shouldn't limit the
capability for creating other workspaces for different use cases
within a single build. It'd be nice if we had a delete-on-exit
mechanism that didn't cause problems with embedded environments;
then, there wouldn't even be a reason to worry about the accumulation
of "orphaned" workspaces, I suppose...but planting these sorts of
things under the target directory would eliminate this concern to a
large degree too.
2. Kenney brings up a good point about the reactor artifacts, and in
addition to making the artifact-resolution process clearer it also
virtually eliminates the need to cache resolution results. In a
reactor build where there are interdependencies, we simply use those
interdependencies to sort the build order...then, the local workspace
for that build is used to resolve them first, then local repo, then
remote repo. If the sort order is correct, and the build fails
appropriately if one of the projects fails to build, there should be
no caching or other magic necessary here. One slight hitch is that
the install mojo being an aggregator may not be as simple as it
sounds. IIRC, there are issues with the way we're approaching these
aggregators in the build now...I think Bad Things tend to happen when
you bind them into the lifecycle, for example...so that's something
that would need some proving.
IMO, it would be cleaner to avoid implementing the reactor workspace
using the existing resolution cache, since plugins don't have easy
access to cached information or the replace semantics that IIRC
currently exist in the MavenProject instance when coping with
interdependent project. It would be MUCH cleaner to use the
filesystem and a more simplistic artifact resolution mechanism, then
optimize that iff we need to. In-memory caching can be pretty evil
when it comes to this stuff; it's been a source of constant headache
in things like the assembly plugin up to now.
-john
On Sep 19, 2007, at 8:31 PM, Brett Porter wrote:
On 18/09/2007, at 10:22 PM, Kenney Westerhof wrote:
Hi,
2. Workspaces should be something you have to set consciously,
not automatically created. This allows an integration-testing
run (for example) to run in isolation by using a different
workspace id, and clean up after itself when finished.
Agreed.
I think they should always be created, and after the entire build
finished,
merged to the main tree. Look at it as build transactions.
I had listed this as a separate feature that could be built on top
of this, under "Rolling back a reactor build" - I don't think it
impacts the base implementation, though.
In your other mail you indicated likewise that it might need more
thought (as it could be avoided altogether by making the install
plugin an aggregator).
WDYT? Do I need to make some additional changes to the proposal?
Cheers,
Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
