Bug 840634 - Define an rhq-agent-plugin Maven packaging type
Define an rhq-agent-plugin Maven packaging type
Status: NEW
Product: RHQ Project
Classification: Other
Component: Build System (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2012-07-16 14:35 EDT by Elias Ross
Modified: 2012-07-19 14:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Elias Ross 2012-07-16 14:35:23 EDT
The problem is the 'copy-dependencies' plugin doesn't work with RHQ plugins.

Hence the bug below.


Bug 787264 - Plugin dependencies; commons-logging and cobertura have wrong scope (edit) [NEEDINFO] 

[reply] [-] Comment 2 Ian Springer 2012-06-06 10:48:22 EDT 

Defining an rhq-agent-plugin Maven packaging type that encapsulates things like copying runtime deps into the lib dir and validating the plugin descriptor is a good idea and something I have been wanting to do for a while. Can you create a separate BZ for that?


Ian, here is your bug.
Comment 1 Heiko W. Rupp 2012-07-19 14:20:58 EDT
Had a conversation with Ian, has he unfortunately is no longer with the RHQ team

Ian: so maven has different packaging types - pom, jar, war, ear, etc.
you define a module's packaging type in its pom via <packaging>
there is a way to define custom packaging types (i think via a maven plugin)
so the idea here would be to define an rhq-agent-plugin packaging type
and then certain stuff specific to rhq plugins could be done under the covers
and perhaps some custom config could be done via props or custom elements in 
the pom

me: So instead creating foo-plugin.jar we'd create foo-plugin.rpl ? Or would 
that be sort of transient and the final outcome would still be a jar?

Ian Springer:
final outcome would still be a jar, but the pom would look a little different
hopefully would be less verbose

Ian Springer:
for example, you would not need to use the dependency plugin to copy all 
runtime deps into the plugin jar's lib dir
this could be done automatically be the rhq-plugin packaging impl code
Ah, now I start to understand. That sounds cool and very helpful

Ian: it would cut down the size of plugin poms and improve readability

Note You need to log in before you can comment on or make changes to this bug.