[jira] Reopened: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue

2010-01-04 Thread Alfie Kirkpatrick (JIRA)

 [ 
http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alfie Kirkpatrick reopened MNG-3283:



Am pretty sure this is not fixed. In fact it seems to be worse in 2.1.0.

I downloaded my repro project (attached) and ran 'mvn generate-sources' using 
mvn 2.1.0. This gives the error. Whereas before 'mvn process-classes' would 
succeed this fails now too, which makes this workaround no longer viable. The 
earliest phase that works is 'mvn package'...

Thanks, Alfie.

> Plugins that require dependency resolution in early phases cause dependency 
> resolution issue
> 
>
> Key: MNG-3283
> URL: http://jira.codehaus.org/browse/MNG-3283
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies, Plugins and Lifecycle, Reactor and 
> workspace
>Affects Versions: 2.0.7
>Reporter: Alfie Kirkpatrick
>Assignee: Brian Fox
> Attachments: maven-dependency-bug.zip
>
>
> What we're seeing is that some multi-project configurations succeed on
> 'mvn package' but fail on 'mvn generate-sources'. They are failing when
> one project in the reactor references another project in the reactor
> which is not installed in the local repo. It seems that the referenced
> project has not quite "made it" into the reactor this early in the phase
> lifecycle. But it does work correctly if you target a later phase at the
> outset which is really confusing.
> The problem only occurs when a plugin binds itself to the
> generate-sources phase and has @requiresDependencyResolution, presumably
> because this is what triggers resolution of the referenced dependency
> too early in the lifecycle, and hence the error.
> We are seeing this problem when trying to run 'mvn eclipse:eclipse'
> because this only executes the generate-sources phase by default and we
> have other mojos which genuinely do generate source, such as java2wsdl.
> A workaround we're using is to run 'mvn process-classes eclipse:eclipse'.
> Attached is a really simple project that exhibits this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue

2010-01-04 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204993#action_204993
 ] 

Alfie Kirkpatrick commented on MNG-3283:


Another comment... The only other workaround is to run 'mvn install' on your 
project. However, I have found working with teams that people can get in a real 
muddle when working with a mixture of 'dynamic' and local repository 
references. Therefore I try to encourage people to NEVER run mvn install on 
their project(s). This issue makes this nearly impossible.

> Plugins that require dependency resolution in early phases cause dependency 
> resolution issue
> 
>
> Key: MNG-3283
> URL: http://jira.codehaus.org/browse/MNG-3283
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies, Plugins and Lifecycle, Reactor and 
> workspace
>Affects Versions: 2.0.7
>Reporter: Alfie Kirkpatrick
>Assignee: Brian Fox
> Attachments: maven-dependency-bug.zip
>
>
> What we're seeing is that some multi-project configurations succeed on
> 'mvn package' but fail on 'mvn generate-sources'. They are failing when
> one project in the reactor references another project in the reactor
> which is not installed in the local repo. It seems that the referenced
> project has not quite "made it" into the reactor this early in the phase
> lifecycle. But it does work correctly if you target a later phase at the
> outset which is really confusing.
> The problem only occurs when a plugin binds itself to the
> generate-sources phase and has @requiresDependencyResolution, presumably
> because this is what triggers resolution of the referenced dependency
> too early in the lifecycle, and hence the error.
> We are seeing this problem when trying to run 'mvn eclipse:eclipse'
> because this only executes the generate-sources phase by default and we
> have other mojos which genuinely do generate source, such as java2wsdl.
> A workaround we're using is to run 'mvn process-classes eclipse:eclipse'.
> Attached is a really simple project that exhibits this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue

2010-01-06 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205350#action_205350
 ] 

Alfie Kirkpatrick commented on MNG-3283:


Same result in alpha-5. Both generate-sources and process-classes fail but 
package works. Sorry.

> Plugins that require dependency resolution in early phases cause dependency 
> resolution issue
> 
>
> Key: MNG-3283
> URL: http://jira.codehaus.org/browse/MNG-3283
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies, Plugins and Lifecycle, Reactor and 
> workspace
>Affects Versions: 2.0.7
>Reporter: Alfie Kirkpatrick
>Assignee: Brian Fox
> Attachments: maven-dependency-bug.zip
>
>
> What we're seeing is that some multi-project configurations succeed on
> 'mvn package' but fail on 'mvn generate-sources'. They are failing when
> one project in the reactor references another project in the reactor
> which is not installed in the local repo. It seems that the referenced
> project has not quite "made it" into the reactor this early in the phase
> lifecycle. But it does work correctly if you target a later phase at the
> outset which is really confusing.
> The problem only occurs when a plugin binds itself to the
> generate-sources phase and has @requiresDependencyResolution, presumably
> because this is what triggers resolution of the referenced dependency
> too early in the lifecycle, and hence the error.
> We are seeing this problem when trying to run 'mvn eclipse:eclipse'
> because this only executes the generate-sources phase by default and we
> have other mojos which genuinely do generate source, such as java2wsdl.
> A workaround we're using is to run 'mvn process-classes eclipse:eclipse'.
> Attached is a really simple project that exhibits this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MNG-3920) Problem using velocity component

2008-12-17 Thread Alfie Kirkpatrick (JIRA)
Problem using velocity component


 Key: MNG-3920
 URL: http://jira.codehaus.org/browse/MNG-3920
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.1.0-M1
Reporter: Alfie Kirkpatrick


Jason van Zyl asked me to raise this here so he could take a look. Not 
convinced it is a genuine bug...

I am attempting to write a plugin that uses Velocity to template
some config files. I have been developing the plugin using m2eclipse
embedded maven runtime and it works fine. But it gives a NPE when I run 
it in maven standalone, even with the 2.1M1 release.

I have the following in my class:

 /**
  * @component
  */
 protected VelocityComponent velocityComponent;

The line giving the NPE is:

 Template template =
velocityComponent.getEngine().getTemplate("/"+templateName+".vm");

When running standalone the velocityComponent is initialised with a
DefaultVelocityComponent but with a null engine, so getTemplate gives
the NPE.

Am struggling to understand if I'm doing this correctly and why it
should work in maven embedder (in m2eclipse) but not standalone?

As an aside, my class implements org.codehaus.plexus.logging.LogEnabled and 
running with maven embedder, the enableLogging method is called with a 
PlexusLoggerAdapter, but running standalone this method is not called. Can't 
help feeling this is related...

I have made use of a class from the eclipse plugin project and have a 
dependency on other eclipse plugin support classes. This is a mojo to generate 
project files for FlexBuilder and I ultimately want to contribute this to the 
flex-mojos project.

Thanks again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MNG-3920) Problem using velocity component

2008-12-17 Thread Alfie Kirkpatrick (JIRA)

 [ 
http://jira.codehaus.org/browse/MNG-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alfie Kirkpatrick updated MNG-3920:
---

Attachment: pom.xml
swfclipse.zip

Attached are the zipped mojo project and small test pom to reproduce the error. 
I am mvn installing the plugin then running with:

{code}
mvn com.akirkpatrick:swfclipse:0.0.1-SNAPSHOT:eclipse
{code}

> Problem using velocity component
> 
>
> Key: MNG-3920
> URL: http://jira.codehaus.org/browse/MNG-3920
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 2.1.0-M1
>Reporter: Alfie Kirkpatrick
> Attachments: pom.xml, swfclipse.zip
>
>
> Jason van Zyl asked me to raise this here so he could take a look. Not 
> convinced it is a genuine bug...
> I am attempting to write a plugin that uses Velocity to template
> some config files. I have been developing the plugin using m2eclipse
> embedded maven runtime and it works fine. But it gives a NPE when I run 
> it in maven standalone, even with the 2.1M1 release.
> I have the following in my class:
>  /**
>   * @component
>   */
>  protected VelocityComponent velocityComponent;
> The line giving the NPE is:
>  Template template =
> velocityComponent.getEngine().getTemplate("/"+templateName+".vm");
> When running standalone the velocityComponent is initialised with a
> DefaultVelocityComponent but with a null engine, so getTemplate gives
> the NPE.
> Am struggling to understand if I'm doing this correctly and why it
> should work in maven embedder (in m2eclipse) but not standalone?
> As an aside, my class implements org.codehaus.plexus.logging.LogEnabled and 
> running with maven embedder, the enableLogging method is called with a 
> PlexusLoggerAdapter, but running standalone this method is not called. Can't 
> help feeling this is related...
> I have made use of a class from the eclipse plugin project and have a 
> dependency on other eclipse plugin support classes. This is a mojo to 
> generate project files for FlexBuilder and I ultimately want to contribute 
> this to the flex-mojos project.
> Thanks again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue

2007-10-29 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111929
 ] 

Alfie Kirkpatrick commented on MNG-2277:


I checked out this evening from 
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x 
(identifies itself as version 2.0.8-SNAPSHOT) and I'm still seeing an error 
when running mvn generate-sources on my simple test project where child1 
depends on child2 (with single parent project that includes both child1 and 
child2).

> aggregating plugins in submodules of the reactor return all projects causing 
> a chicken/egg issue
> 
>
> Key: MNG-2277
> URL: http://jira.codehaus.org/browse/MNG-2277
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugin API, Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 2.0.4
>Reporter: Brett Porter
>Assignee: Brian Fox
> Fix For: 2.0.8
>
>
> eg, assembly:attached
> when this is put in maven-core, and a build is run from the root project with 
> a clean repo, it fails, as the original project sorter doesn't consider the 
> dependencies, building plugin-tools after maven-core.
> However, hitting the aggregator when building maven-core then tries to 
> resolve all of the projects as dependencies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue

2007-10-30 Thread Alfie Kirkpatrick (JIRA)

 [ 
http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alfie Kirkpatrick updated MNG-2277:
---

Attachment: maven-dependency-bug.zip

See attached. Running 'mvn generate-sources' returns an error, whereas running 
'mvn package' completes successfully.

Best regards, Alfie.

> aggregating plugins in submodules of the reactor return all projects causing 
> a chicken/egg issue
> 
>
> Key: MNG-2277
> URL: http://jira.codehaus.org/browse/MNG-2277
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugin API, Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 2.0.4
>Reporter: Brett Porter
>Assignee: Brian Fox
> Fix For: 2.0.8
>
> Attachments: maven-dependency-bug.zip
>
>
> eg, assembly:attached
> when this is put in maven-core, and a build is run from the root project with 
> a clean repo, it fails, as the original project sorter doesn't consider the 
> dependencies, building plugin-tools after maven-core.
> However, hitting the aggregator when building maven-core then tries to 
> resolve all of the projects as dependencies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue

2007-10-30 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112056
 ] 

Alfie Kirkpatrick commented on MNG-2277:


Hi Brian, thanks for taking a look at the project. Maybe this isn't the right 
forum to discuss this now you've made it clear this is a different issue. 
However, I can't see how this is 'normal' behaviour because the dependency does 
exist in the reactor and targeting a later phase is successful. Also we only 
see the problem if a plugin is invoked by the build at an early phase and the 
plugin requires dependency resolution. At the moment our team is working around 
this issue by running 'mvn package eclipse:eclipse' which just seems crazy to 
me. If you need a fuller description of what we tried see my post on the 
mailing list (http://www.mail-archive.com/[EMAIL PROTECTED]/msg75053.html) 
where someone identified it (perhaps wrongly) as an instance of MNG-2277 -- 
hence my interest in this issue. Many thanks, Alfie.

> aggregating plugins in submodules of the reactor return all projects causing 
> a chicken/egg issue
> 
>
> Key: MNG-2277
> URL: http://jira.codehaus.org/browse/MNG-2277
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugin API, Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 2.0.4
>Reporter: Brett Porter
>Assignee: Brian Fox
> Fix For: 2.0.8
>
> Attachments: maven-dependency-bug.zip
>
>
> eg, assembly:attached
> when this is put in maven-core, and a build is run from the root project with 
> a clean repo, it fails, as the original project sorter doesn't consider the 
> dependencies, building plugin-tools after maven-core.
> However, hitting the aggregator when building maven-core then tries to 
> resolve all of the projects as dependencies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue

2007-11-12 Thread Alfie Kirkpatrick (JIRA)
Plugins that require dependency resolution in early phases cause dependency 
resolution issue


 Key: MNG-3283
 URL: http://jira.codehaus.org/browse/MNG-3283
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies, Plugins and Lifecycle, Reactor and workspace
Affects Versions: 2.0.7
Reporter: Alfie Kirkpatrick
 Attachments: maven-dependency-bug.zip

What we're seeing is that some multi-project configurations succeed on
'mvn package' but fail on 'mvn generate-sources'. They are failing when
one project in the reactor references another project in the reactor
which is not installed in the local repo. It seems that the referenced
project has not quite "made it" into the reactor this early in the phase
lifecycle. But it does work correctly if you target a later phase at the
outset which is really confusing.

The problem only occurs when a plugin binds itself to the
generate-sources phase and has @requiresDependencyResolution, presumably
because this is what triggers resolution of the referenced dependency
too early in the lifecycle, and hence the error.

We are seeing this problem when trying to run 'mvn eclipse:eclipse'
because this only executes the generate-sources phase by default and we
have other mojos which genuinely do generate source, such as java2wsdl.

A workaround we're using is to run 'mvn process-classes eclipse:eclipse'.

Attached is a really simple project that exhibits this problem.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue

2008-05-06 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133691#action_133691
 ] 

Alfie Kirkpatrick commented on MNG-2277:


For info I had already raised MNG-3283 for the specific issue we're facing. 
I'll comment on MECLIPSE-380 now to link to it.

> aggregating plugins in submodules of the reactor return all projects causing 
> a chicken/egg issue
> 
>
> Key: MNG-2277
> URL: http://jira.codehaus.org/browse/MNG-2277
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugin API, Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 2.0.4
>Reporter: Brett Porter
>Assignee: Brian Fox
> Fix For: 2.0.8
>
> Attachments: maven-dependency-bug.zip
>
>
> eg, assembly:attached
> when this is put in maven-core, and a build is run from the root project with 
> a clean repo, it fails, as the original project sorter doesn't consider the 
> dependencies, building plugin-tools after maven-core.
> However, hitting the aggregator when building maven-core then tries to 
> resolve all of the projects as dependencies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MECLIPSE-380) dependencies in multi-module may projects require a 'mvn install' before using

2008-05-06 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133692#action_133692
 ] 

Alfie Kirkpatrick commented on MECLIPSE-380:


I think this issue can be closed as a duplicate of MNG-3283. This issue is not 
specifically related to the eclipse plugin, although that is the context we 
found it in.

Note that you can work around this issue as siarhei suggested in the 
maven-users thread by running 'mvn process-classes eclipse:eclipse' because 
this goes further in the artifact resolution.

> dependencies in multi-module may projects require a 'mvn install' before using
> --
>
> Key: MECLIPSE-380
> URL: http://jira.codehaus.org/browse/MECLIPSE-380
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>  Components: Core : Dependencies resolution and build path, Core : 
> Multi-projects
>Affects Versions: 2.4, 2.5
> Environment: Maven 2.0.8
>Reporter: Martin Höller
>
> The scenario is as follows:
> Parent Project P
> |
> +-- Project A
> |
>  `- Project B 
> B has a dependency on A (B requires A).
> A user with an empty local repository cannot checkout the whole project and 
> run 'mvn eclipse:eclipse' due to unsatisfied dependencies. The build will 
> fail in Project B because Project A is missing from the repository.
> A 'mvn install' has to be executed before (at least for Project A). But what 
> if the project is in a state where it doesn't compile? It's not possible in 
> this case for a new user to start developing with eclipse.
> See also 
> http://www.nabble.com/maven-eclipse-plugin-with-multi-module-projects-to15222495s177.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue

2008-05-06 Thread Alfie Kirkpatrick (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133693#action_133693
 ] 

Alfie Kirkpatrick commented on MNG-3283:


Note that am pretty sure this issue is seen in m2eclipse which uses maven 
embedder from the 2.1.x version of maven. This issue may become more apparent 
as people start using these tools and probably harder to roll out fixes also...

> Plugins that require dependency resolution in early phases cause dependency 
> resolution issue
> 
>
> Key: MNG-3283
> URL: http://jira.codehaus.org/browse/MNG-3283
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies, Plugins and Lifecycle, Reactor and 
> workspace
>Affects Versions: 2.0.7
>Reporter: Alfie Kirkpatrick
>Assignee: Brian Fox
> Attachments: maven-dependency-bug.zip
>
>
> What we're seeing is that some multi-project configurations succeed on
> 'mvn package' but fail on 'mvn generate-sources'. They are failing when
> one project in the reactor references another project in the reactor
> which is not installed in the local repo. It seems that the referenced
> project has not quite "made it" into the reactor this early in the phase
> lifecycle. But it does work correctly if you target a later phase at the
> outset which is really confusing.
> The problem only occurs when a plugin binds itself to the
> generate-sources phase and has @requiresDependencyResolution, presumably
> because this is what triggers resolution of the referenced dependency
> too early in the lifecycle, and hence the error.
> We are seeing this problem when trying to run 'mvn eclipse:eclipse'
> because this only executes the generate-sources phase by default and we
> have other mojos which genuinely do generate source, such as java2wsdl.
> A workaround we're using is to run 'mvn process-classes eclipse:eclipse'.
> Attached is a really simple project that exhibits this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira