Hi,
Reply is below.
Brett Porter wrote:
Hi Kenney,
On 14/09/2007, at 9:15 PM, Kenney Westerhof wrote:
Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies), and project artifacts.
The separation isn't clear in maven itself - repo's get mixed up,
wrong repo's consulted; build artifacts interfering with plugin
artifacts.
Having a separate directory containing information on what build
artifacts
are used makes it easy to freeze a maven environment, and see what
was used runtime.
Also see [1], which you, Brett, weren't in favour of back then. Perhaps
now this can be taken into consideration with this proposal.
[1] http://jira.codehaus.org/browse/MNG-724
I definitely like the idea of separating the different contexts of the
build (plugin/extension) dependencies from the project dependencies. I
think this is most important for the metadata and snapshots - I don't
think we need duplicate copies of plexus container releases, etc
floating around in the local repository.
Definitely not. Though in fact only snapshot plugins and their dependencies
can cause problems with this; that is, their presence and availability
to maven, not wheter or not their versions are specified in the pom. If you
leave out the plugin version you get whatever is latest in the local repo,
which can be a snapshot. This makes builds unstable when you're developing
plugins.
This will help to some extent by already separating some things out (in
particular the ability to have a different place for locally built
plugins) - but plugins that come from the same place as other artifacts
will still be grouped together.
Indeed - we'd group the artifacts by their source (repo or local),
but also their role in the build - required by maven, or required by
the project's you're building. The latter can be accomplished by
the workspaces. Plugins and their dependencies needed by the build
can go in the 'cache' or 'snapshot' locations in the ~/.m2/,
but artifacts generated during build will first be put in a workspace,
and can then be merged to the snapshot location in ~/.m2/ after
the build completes. We still want to build a plugin or one of it's dependencies
and be able to use it in another build.
How would you like to see that worked out in practice -
pluginRepositories and build extensions stored separately? Or do you
think that with the other plugin lockdown/enforcer uses enough can be
achieved already?
Enforcer etc. will certainly help, but if you don't have a rule, or allow
snapshot versions, then you still don't know which one is used. Consider
using a snapshot plugin with a dep on a snapshot artifact. Somewhere during
the build that snapshot artifact is built, and somewhere later in the build
that plugin is used with that new snapshot artifact - it could break the build.
One way to solve this is to pre-resolve all plugins and their dependencies
before
the build starts, but that only works if you use timestamped snapshots,
otherwise
the artifacts can be copied over during the build.
Separating the installation location _during the build_ can solve this and make builds
more stable. The 'install' goal would become an aggregator.
During the build, we now already have several sources for artifacts: local repo,
remote repos, and reactor. In the current scheme, reactor artifacts can come
from the local repo source and vice versa. I believe that having this
separation,
even just during the build, makes the code easier, and we have more control on
where to look for what artifacts without having to worry about side effects
during
the build and contamination of the artifact sources. We can then more easily say
which source gets precedence over another, and most importantly, for what type
of artifact (build or project). I imagine that we would have the precedence
order
for project artifacts as [reactor (or workspace), remote repos, local repo],
and the order for build artifacts as [remote repos, local repo], so that during
one build, the artifacts available to maven for plugins and extensions remain
the same.
One more thought on the workspace: if we change the install mojo to be an
aggregator,
there's really no need to have separate workspaces to accomplish the above,
since we have a 'workspace' artifact source already: the reactor.
But workspaces are handy because when you're working on several projects at once,
like maven and plexus, you can have 2 workspaces containing the snapshots for
both,
if you don't want them to interfere with eachother. One of the two could just
use
deployed versions (like maven would only use deployed snapshots from plexus,
for instance),
and the other (plexus) would use it's own snapshots. Making cross-project
artifacts
available to other projects would mean, if you use workspaces, that you have to
deploy them.
This reduces the risk on build failures (for instance) on maven, when someone updates
plexus and maven to work together, and does not deploy plexus.
I still have a lot of thinking to do on this, but I hope more people will since
it's
rather complex. I'm not sure on what would be the best approach.
-- Kenney
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
