Maven 2 & 3

Lifecycle mappings should specify phase bindings in terms of general functionality type

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0-alpha-3
  • Fix Version/s: 3.2
  • Component/s: Plugins and Lifecycle
  • Labels:
    None
  • Number of attachments :
    0

Description

Currently, the 'jar' lifecycle mapping specifies that the 'compiler:complie' mojo will be bound to the 'compile' phase. The 'compiler' prefix is mapped concretely to the maven-compiler-plugin. This means that it's not currently possible to use a different mojo to compile jar projects.

How can a third party implementor touch this lifecycle phase for jars without implementing a new plexus-compiler implementation, and even then, how is the new compiler impl supposed to be added to the plugin container?

Issue Links

depends upon

New Feature - A new feature of the product, which has yet to be developed. MNG-2806 Provide a means of replacing one mojo binding with another, without knowing the location of the first binding in the lifecycle

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

I should mention that I think the solution is to provide a way of binding a mojo api-type to the phase, and let maven determine which implementation to use.

Show
John Casey added a comment - I should mention that I think the solution is to provide a way of binding a mojo api-type to the phase, and let maven determine which implementation to use.
Hide
Permalink
Brett Porter added a comment -

I don't think it is intended that a different mojo be used to compile jar projects - the compiler mojo should be able to take better configuration and delegate to the appropriate plexus compiler.

do you think this is something that is necessary for other goals than compiling?

Show
Brett Porter added a comment - I don't think it is intended that a different mojo be used to compile jar projects - the compiler mojo should be able to take better configuration and delegate to the appropriate plexus compiler. do you think this is something that is necessary for other goals than compiling?
Hide
Permalink
Brett Porter added a comment -

John - did you want to reinclude this with a proposal, or does some of the current stuff consider it already?

Show
Brett Porter added a comment - John - did you want to reinclude this with a proposal, or does some of the current stuff consider it already?
Hide
Permalink
John Casey added a comment -

This is related to MNG-2806.

Implementation of 2806 would allow people to substitute their own alternatives to the "standard" mojos provided by a given packaging, and should be approachable now that we have a decent build-planning system.

Show
John Casey added a comment - This is related to MNG-2806 . Implementation of 2806 would allow people to substitute their own alternatives to the "standard" mojos provided by a given packaging, and should be approachable now that we have a decent build-planning system.

People

  • Assignee:
    Unassigned
    Reporter:
    John Casey
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: