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]
