Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-14 Thread Peter Lynch
On Sun, Jan 10, 2010 at 2:48 PM, Brett Porter br...@apache.org wrote:


 What is the original use case that led to the bug? I'm wondering if it is
 sane and needs the runtime info, or if it actually should have just the POM
 as fully resolved from the repo.

 Cheers,
 Brett

 The code involved is at line 1797 in 
 EclipsePlugin.javahttp://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.7/src/main/java/org/apache/maven/plugin/eclipse/EclipsePlugin.java?view=markup.
   The
issue was opened in response to http://jira.codehaus.org/browse/MECLIPSE-633 .
The plugin code is kinda suspect as I'm not quite sure why the EclipseMojo
just can't rely on the injected parameter it is looking for rather than
parsing its Xpp3Dom directly - guessing as some previous bug work around?
Still, I don't think the project model should change this drastically unless
there is a good reason and it is well documented.

Meanwhile Jason is pushing for a release of the eclipse plugin and until we
reach a consensus on what to do then maven-eclipse-plugin will remain not
passing integration tests for maven 3.

-Peter


Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-10 Thread Brett Porter

On 09/01/2010, at 10:43 PM, Benjamin Bentmann wrote:

 Hi,
 
 in response to http://jira.codehaus.org/browse/MNG-4523, I would like to  
 double-check that the behavior observed in Maven 2 is by design/intention and 
 needs to be reproduced by Maven 3. It looks odd to me that the effective POM 
 is a function of the plugin being invoked on CLI.

I would have added this intentionally, and I think the behaviour is correct, 
but I agree it's confusing when reflected differently in the effective POM. 

From an execution PoV, I would still expect my pluginManagement blocks to apply 
to a plugin called on the command line that is not otherwise in the POM. 
However, if this makes things too complicated and we want to require a change 
to include the plugin in the POM as well as the management for it to apply - 
that is probably ok if it is documented.

What Brian says is the right way to go from a plugin API position:

On 10/01/2010, at 5:02 AM, Brian Fox wrote:
 I think there are several things a plugin
 should be able to get:
 1) the original model as parsed from disk with no interpolation or inheritence
 2) the effective original model
 3) the model as executed - this would be where the lifecycle plugins
 get included.


We didn't really have the notion of (2) before, the calls to project methods 
gives you (3).

I haven't looked recently at how the models are handled internally in the 
project instance now, but support methods like getPluginsAsMap probably need to 
be deprecated at the project level and pushed into the individual 
representations of the model, with the API providing the 3 above?

Then again, if we can do less implicit stuff in the future (say, if packaging 
became a mixin rather than a runtime modification of the model for the 
lifecycle), the 3rd may not be needed.

I'd need to take a closer look to comment more here - hopefully these thoughts 
are helpful nonetheless :)

Cheers,
Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-10 Thread Benjamin Bentmann

Brett Porter wrote:


From an execution PoV, I would still expect my pluginManagement blocks to apply 
to a plugin called on the command line that is not otherwise in the POM. 
However, if this makes things too complicated and we want to require a change 
to include the plugin in the POM as well as the management for it to apply - 
that is probably ok if it is documented.


Please don't mix different aspects here. I have not asked how a plugin 
should be configured when it gets executed. My question is about how


  MavenProject.getModel()

should look like. This is related but nevertheless independent from 
plugin configuration.



Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-10 Thread Brett Porter

On 11/01/2010, at 5:47 AM, Benjamin Bentmann wrote:

 Brett Porter wrote:
 
 From an execution PoV, I would still expect my pluginManagement blocks to 
 apply to a plugin called on the command line that is not otherwise in the 
 POM. However, if this makes things too complicated and we want to require a 
 change to include the plugin in the POM as well as the management for it to 
 apply - that is probably ok if it is documented.
 
 Please don't mix different aspects here. I have not asked how a plugin should 
 be configured when it gets executed. My question is about how
 
  MavenProject.getModel()
 
 should look like. This is related but nevertheless independent from plugin 
 configuration.
 


That's why I answered addressing both aspects :) If the execution side still 
works that way, that's great. It may still impact how you want the API to look 
for consistency.

Sorry, so having trouble distilling my thoughts - something tells me that 
getModel() might need to return the 'runtime' model for most compatibility, and 
a more distinct method name (say, getResolvedModel()) is needed for the one 
that should always look the same, but I'm not convinced as in a green field I'd 
prefer the 'runtime' model be the 'optional' one and as I said before, maybe 
not even necessary. Also coming to mind is that -D and environmental factors 
from profile activation probably affect the model you get back as well?

What is the original use case that led to the bug? I'm wondering if it is sane 
and needs the runtime info, or if it actually should have just the POM as fully 
resolved from the repo.

Cheers,
Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



[DISCUSS] Effect of direct plugin invocation on model

2010-01-09 Thread Benjamin Bentmann

Hi,

in response to http://jira.codehaus.org/browse/MNG-4523, I would like to 
 double-check that the behavior observed in Maven 2 is by 
design/intention and needs to be reproduced by Maven 3. It looks odd to 
me that the effective POM is a function of the plugin being invoked on CLI.



Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-09 Thread Stephen Connolly
2010/1/9 Benjamin Bentmann benjamin.bentm...@udo.edu:
 Hi,

 in response to http://jira.codehaus.org/browse/MNG-4523, I would like to
  double-check that the behavior observed in Maven 2 is by design/intention
 and needs to be reproduced by Maven 3. It looks odd to me that the effective
 POM is a function of the plugin being invoked on CLI.

I agree that it looks odd.

IMHO, the effective pom should be invariant.



 Benjamin

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-09 Thread Peter Lynch
On Sat, Jan 9, 2010 at 7:36 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 2010/1/9 Benjamin Bentmann benjamin.bentm...@udo.edu:
  Hi,
 
  in response to http://jira.codehaus.org/browse/MNG-4523, I would like to
   double-check that the behavior observed in Maven 2 is by
 design/intention
  and needs to be reproduced by Maven 3. It looks odd to me that the
 effective
  POM is a function of the plugin being invoked on CLI.

 I agree that it looks odd.

 IMHO, the effective pom should be invariant.


It is far from invariant. I noticed in the debugger that the project model
contained 4 plugins ( clean,site, install, deploy if i recall), none being
the one explicitly called in Maven 3. In Maven 2, the only plugin in the
model was the one being called. After that I thought I'd better share my
findings...


 
 
  Benjamin
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-09 Thread Benjamin Bentmann

Peter Lynch wrote:


It is far from invariant. I noticed in the debugger that the project model
contained 4 plugins ( clean,site, install, deploy if i recall), none being
the one explicitly called in Maven 3.


Those plugins are contributed by lifecycle mappings corresponding to the 
packaging of the project, i.e. their presence in the effective POM is 
induced by contents of the raw POM (just like with inherited plugins). 
In contrast, the CLI is something external to the POM.



Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-09 Thread Stephen Connolly
2010/1/9 Peter Lynch pe...@peterlynch.ca:
 On Sat, Jan 9, 2010 at 7:36 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 2010/1/9 Benjamin Bentmann benjamin.bentm...@udo.edu:
  Hi,
 
  in response to http://jira.codehaus.org/browse/MNG-4523, I would like to
   double-check that the behavior observed in Maven 2 is by
 design/intention
  and needs to be reproduced by Maven 3. It looks odd to me that the
 effective
  POM is a function of the plugin being invoked on CLI.

 I agree that it looks odd.

 IMHO, the effective pom should be invariant.


 It is far from invariant. I noticed in the debugger that the project model
 contained 4 plugins ( clean,site, install, deploy if i recall), none being
 the one explicitly called in Maven 3. In Maven 2, the only plugin in the
 model was the one being called. After that I thought I'd better share my
 findings...



I would expect to see the plugins from the default lifecycle bindings,
which for a pom project should be clean, site, install and deploy
IIRC. I would not expect to see the plugin executed on the command
line.

I would expect to see the plugin executed from the command line to
have been configured according to the def from pluginMgmt, but I would
not expect to see it in the project model (i.e. in
/project/build/plugins/plugin) unless it is explicitly listed in the
pom.

IMHO the Maven 2 behaviour is the bug and Maven 3 fixes it.

-Stephen

P.S we still await Jason to weigh in on this one though! ;-)

 
 
  Benjamin
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-09 Thread Brian Fox
In 2.x the plugins you get from the lifecycle depend on which phase
was executed, and it frankly drove me crazy trying to write the
enforcer plugin rules. I think there are several things a plugin
should be able to get:
1) the original model as parsed from disk with no interpolation or inheritence
2) the effective original model
3) the model as executed - this would be where the lifecycle plugins
get included.

On Sat, Jan 9, 2010 at 12:57 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 2010/1/9 Peter Lynch pe...@peterlynch.ca:
 On Sat, Jan 9, 2010 at 7:36 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 2010/1/9 Benjamin Bentmann benjamin.bentm...@udo.edu:
  Hi,
 
  in response to http://jira.codehaus.org/browse/MNG-4523, I would like to
   double-check that the behavior observed in Maven 2 is by
 design/intention
  and needs to be reproduced by Maven 3. It looks odd to me that the
 effective
  POM is a function of the plugin being invoked on CLI.

 I agree that it looks odd.

 IMHO, the effective pom should be invariant.


 It is far from invariant. I noticed in the debugger that the project model
 contained 4 plugins ( clean,site, install, deploy if i recall), none being
 the one explicitly called in Maven 3. In Maven 2, the only plugin in the
 model was the one being called. After that I thought I'd better share my
 findings...



 I would expect to see the plugins from the default lifecycle bindings,
 which for a pom project should be clean, site, install and deploy
 IIRC. I would not expect to see the plugin executed on the command
 line.

 I would expect to see the plugin executed from the command line to
 have been configured according to the def from pluginMgmt, but I would
 not expect to see it in the project model (i.e. in
 /project/build/plugins/plugin) unless it is explicitly listed in the
 pom.

 IMHO the Maven 2 behaviour is the bug and Maven 3 fixes it.

 -Stephen

 P.S we still await Jason to weigh in on this one though! ;-)

 
 
  Benjamin
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org