On 22 Dec 07, at 12:09 PM 22 Dec 07, nicolas de loof wrote:
Seems I have missed some interesting threads on the dev list !
What is this "build plan" ?
Is this related to http://docs.codehaus.org/display/MAVEN/Toolchains
I didn't find proposal / description of this mechanism on
http://docs.codehaus.org/display/MAVEN/Home
This happened long, long ago before I asked everyone to put their
proposals. It originated in trying to get profile and plugin
information as part of the c tool chain that was created almost two
years ago I guess.
The build plan in short is the execution path that will be taken by
Maven for a given POM, or set of POMs. We make a pass at collecting
the information so that it can be subsequently modified if desired,
then that plan is executed by Maven. The build plan separates the
collection of information, and the execution of Maven's lifecycle.
Ideally what we're looking at is being able to visually display the
lifecycle, any plugin configuration and allow a user to modify that
before Maven's execution. This collection first, execute later also
allows us to see all the information first so that we can correctly
optimize, if possible, before executing.
You can see evidence of some overzealous setup in what Milos found
where resolution is happening too many times. If we collected all the
information, found out exactly what is necessary and do that instead
of applying blanket coverage to make sure everything is setup correctly.
Much the same is happening with the artifact mechanism where too much
is done while the system is running. The general pattern for
everything is shifting toward 1) collect all the information, 2)
analyze, 3) execute.
I'm not really going to be back until the first week of January and
John is away at the moment too, but it's easy enough for us to give a
brief description. It would be nice to have more people interested in
the core. For now I would suggest looking in the
org.apache.maven.lifecycle package in maven-core.
Nico.
2007/12/22, Jason van Zyl <[EMAIL PROTECTED]>:
On 22 Dec 07, at 4:49 AM 22 Dec 07, nicolas de loof wrote:
The "checkMissingArtifactsInReactor" method is only used when the
plugin is
an aggregator.
The eclipse plugin may fail when it ask for execution of
phase=generate-sources, as some plugins requires dependency
resolution
(sample : an ear having dependency on a war). But in this case, the
execution is not done in reactor.
To solve this issue, I have two options :
- make enhancements to core and plugin api to support a new
ConfigureMojo
API for plugins that have to declare some project level metadatas
(generated
source folders, or other...). This would require a new maven
release, and
maybe wiat for 2.1
You should sync up with John Casey as the build plan is the mechanism
by which the lifecycle can be controlled before execution. So you we
make the plan available, the plan can be altered before execution,
then the plan is executed. Imagine visually the plan in an IDE so
that
the user can change anything before it does in fact execute.
Not in favor of your general approach there, the build plan is the
way
to go.
- change the way the eclipse plugin force a generate-resources phase
to be
executed. AS this is NOT done in reactor, even when the eclipse
plugin does,
the "*can't be resolved but has been found in the reactor*" does not
occur. I've no idea how a plugin can access the current MavenSession
and
execute a phase/plugin, as @execute phase="" is not enough for this
use
case.
If this works for the eclipse plugin then I would build up what it is
exactly you need an put it on the proposals page. You can get
something working quickly and think about the long term.
The plugin configuration gets tricky because you want it before
artifact resolution proper, but you may want the POM or plugin
metadata to alter the build plan. So doing it properly would really
entail putting the plugin metadata somewhere available outside the
JAR
so that we don't need to pull down everything for the user to make
changes to the build plan.
Nico.
2007/12/20, Brian E. Fox <[EMAIL PROTECTED]>:
This is done automatically by the core. If you inspect the file
handle
of artifacts passed to a plugin in a reactor build: if the phase
compile
was executed, it will point to /foo/target/classes. If the phase
package
was executed, it will be /foo/target/foo-version.jar, and if
install, it
will point to the repo.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of nicolas de loof
Sent: Thursday, December 20, 2007 9:57 AM
To: Maven Developers List
Subject: Re: how to bypass dependency resolution ?
I just noticed when running release:prepare
"
[WARNING] The dependency: test:test2:jar:2-SNAPSHOT can't be
resolved
but
has been found in the reactor.
"
This sounds like a project running in the reactor CAN bypass
dependency
resolution on its artifacts.
Could someone explain me HOW it is done by the releaseManager and
how we
could port this code to IDE-plugins ?
2007/12/18, nicolas de loof <[EMAIL PROTECTED]>:
For those who didn't follow my provious post, the issue is about
IDE-support plugins that require a previously-built project to
setup
the dev
environment. When the source code is broken, you have to fix it
under
VI /
notepad.
I experimented Kenney
Westerhof<http://jira.codehaus.org/secure/ViewProfile.jspa?name=kenneyw
idea, as exposed in MECLIPSE-37 :
- I created a ConfigureMojo interface with single method
configureProject()
- I updated AbsractMojo to do nothing on this method
- I enhanced JavaMojoDescriptorExrtaction to support a new
@configure
phase=""
that was the simple part ;-)
I now need to update maven core to support a "configure" lifecycle
execution mode, so that the eclipse plugin can trigger a forked
lifecycle in
sort of "dry run" mode. In this mode, the lifecycle should not
fail
when
resolving dependencies, or maybe not honnor
@requiresDependecyResolution at
all. Existing Mojos will not be affected, and updated ones will
declare
generated folders or any other setting usefull at configuration-
time.
What is the good place to add such a "configure" (dry-run)
support ?
It would require to enlarge the (allready long)
DefaultLifecycleExecutor.forkProjectLifecycle method for the "
if (
mojoDescriptor.getConfigurePhase() != null)" case.
It would also require to bypass the
DefaultPluginManager.executeMojo
"if (
mojoDescriptor.isDependencyResolutionRequired )"
Maybe the simplier would be to cerate a DryRunLifecycleExecutor
and
DryRunPluginManager ?
Any suggestion is welcome...
Nico.
2007/12/14, nicolas de loof < [EMAIL PROTECTED]>:
Hello,
some MECLIPSE issues are related to the phase executed by the
eclipse
plugin to collect generated-* folders.
Here is a simple example of the side-effect of this strategy
pom.xml
|_ ear project
|_ jar project
|_ war project
Lets supose the jar project is broken and can't compile.
Checking the project from svn and running mvn eclipse:eclipse
fails,
as
the maven-ear-plugin has @RequireDependencyResolustion(test) (is
this really
required ?) on GenerateApplicationXMLMojo
mvn install also fails as the jar plugin is broken
There is NO way to configure eclipse and fix the project !
My first idea is to find some hook in the ArtifactResolver (or
other) to
register the multiproject modules as "fake" artifacts, so that
dependency
resolution doesn't fail. I looked at DefaultArtifactResolver ...
but
is far
too complex for me and can't find where the Artifact objects are
created,
and how the associated File object could be hacked
A cleaner fix would be to have an early phase for generate-*
Mojos
to
register generated folders... but hits requires changes on most
plugins -
maybe could be planned for maven 2.1 ?
Any suggestion ?
Nico.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
