You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by nicolas de loof <ni...@apache.org> on 2007/12/20 15:56:47 UTC
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 <ni...@apache.org>:
>
>
> 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 < nicolas@apache.org>:
> >
> > 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.
> >
>
>
Re: how to bypass dependency resolution ?
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org>:
>>
>>
>> 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 <br...@reply.infinity.nu>:
>>>>
>>>> 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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ni...@apache.org>:
>>>>>
>>>>>
>>>>> 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 < nicolas@apache.org>:
>>>>>>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: how to bypass dependency resolution ?
Posted by nicolas de loof <ni...@apache.org>.
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
Nico.
2007/12/22, Jason van Zyl <ja...@maven.org>:
>
>
> 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 <br...@reply.infinity.nu>:
> >>
> >> 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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ni...@apache.org>:
> >>>
> >>>
> >>> 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 < nicolas@apache.org>:
> >>>>
> >>>> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: how to bypass dependency resolution ?
Posted by Jason van Zyl <ja...@maven.org>.
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 <br...@reply.infinity.nu>:
>>
>> 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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ni...@apache.org>:
>>>
>>>
>>> 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 < nicolas@apache.org>:
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: how to bypass dependency resolution ?
Posted by nicolas de loof <ni...@apache.org>.
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
- 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.
Nico.
2007/12/20, Brian E. Fox <br...@reply.infinity.nu>:
>
> 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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ni...@apache.org>:
> >
> >
> > 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 < nicolas@apache.org>:
> > >
> > > 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: how to bypass dependency resolution ?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ni...@apache.org>:
>
>
> 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 < nicolas@apache.org>:
> >
> > 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org