[toolchain] Improve plugin API to ease configuration sharing between plugins

Details

  • Complexity:
    Intermediate

Description

Plugins that need to introspect other plugin's configuration have to go via the Xpp3Dom configuration object. It'd be nice if this was easier for plugin authors. Some current use-cases are:

  • Eclipse plugin requires compiler plugin's configuration to write .settings file
  • Tomcat plugin requires war plugin's configuration to locate final war file and exploded state

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-823 Ability to allow mojos to communicate with each others - other than project's source root and project's attachment

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-2021 Allow properties to be dom objects

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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 -

How much of this can be handled by POM-level properties? I'm not wild about providing a direct line of communications between any two plugins, since that could easily establish a de facto dependency between them. Mediating through the POM seems like a good idea, if it's feasible.

Show
John Casey added a comment - How much of this can be handled by POM-level properties? I'm not wild about providing a direct line of communications between any two plugins, since that could easily establish a de facto dependency between them. Mediating through the POM seems like a good idea, if it's feasible.
Hide
Permalink
Brett Porter added a comment -

I agree with John. This is covered by properties and MNG-823 (assuming you are after it in the lifecycle and using its modified configuration). A plugin must expose what configuration to share.

Show
Brett Porter added a comment - I agree with John. This is covered by properties and MNG-823 (assuming you are after it in the lifecycle and using its modified configuration). A plugin must expose what configuration to share.
Hide
Permalink
Mark Hobson added a comment -

As long as the properties that a plugin sets are well documented and namespaced. My only concern is property name clashes with user pom properties - would it be safer using the plugin context from MNG-823 across multiple plugins? That way the properties are isolated from the user and only accessible by the plugin developers.

Show
Mark Hobson added a comment - As long as the properties that a plugin sets are well documented and namespaced. My only concern is property name clashes with user pom properties - would it be safer using the plugin context from MNG-823 across multiple plugins? That way the properties are isolated from the user and only accessible by the plugin developers.
Hide
Permalink
Brett Porter added a comment -

I misunderstood what 823 was - it is only within the same plugin.

I have this use case for the IDEA plugin too - so I'll check whether it is necessary. Making such dependencies between plugins is one of the big pitfalls we had in m1 however, so this needs to be very carefully considered.

Show
Brett Porter added a comment - I misunderstood what 823 was - it is only within the same plugin. I have this use case for the IDEA plugin too - so I'll check whether it is necessary. Making such dependencies between plugins is one of the big pitfalls we had in m1 however, so this needs to be very carefully considered.
Hide
Permalink
Brett Porter added a comment -

I think toolchain + build context eliminates the need for this

Show
Brett Porter added a comment - I think toolchain + build context eliminates the need for this

People

  • Assignee:
    Unassigned
    Reporter:
    Mark Hobson
Vote (2)
Watch (2)

Dates

  • Created:
    Updated: