Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 16:51, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare
a dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be
physically located in a parent directory, but is an artifact on its own),
that declares both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
Sorry, I mean in this case the pluginMgmt section.
Typically you define one parent POM for your complete project where you use
the depenencyManagement section to define the versions (and standard scopes)
of all your dependencies and a pluginManagement section with all plugins
used in this project again with versions and configuration shared everywhere
they are in use. This project POM is directly or indirectly inherited by all
your POMs within this project. Then you do not have to define anywhere a
version for a plugin (well, not for the plugins in the report sections, but
that's a different story) or dependency.
In the pluginManagement section you will also define any additional
dependency for the individual plugins (e.g. custom tasks for the antrun-
plugin or additional wagon providers) and also set the extension flag for
the plugins with custom extensions. Remember, each plugin can be loaded only
once and the first activation will also define its classpath.
- Jörg
Ok, I have tried several combinations of parent and child pom, but
nothing had an effect. I think, we have to use maven 2.2.1 for this
project.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Maven 2.0.10 with two plugins with custom packaging types
Hi Maven users, I'm having problems with two plugins, which both define a custom packaging type. The packaging types are source-plugin and binary-plugin, which are defined in a private maven plugin and warpath, which is defined in the warpath plugin. If I run the project with both plugins defined, only the first plugin seems to be taken into account. E.g. if our private plugin is defined above the warputh plugin, source-plugin and binary-plugin can be resolved and warpath cannot be resolved. Same thing vice versa, if the warputh plugin is defined above out plugin, warpath can be resolved, source-plugin and binary-plugin not. Plugins are defined this way: plugin groupIdcom.company/groupId artifactIdmaven-rcpbuild-plugin/artifactId version1.0.3/version extensionstrue/extensions /plugin plugin groupIdorg.appfuse/groupId artifactIdmaven-warpath-plugin/artifactId version2.0.2/version extensionstrue/extensions executions execution goals goaladd-classes/goal /goals /execution /executions /plugin Running the project with our plugin and without the warpath plugin works and vice versa. If I run the same configuration with maven 2.2.1, it works as expected. Also the plugin order is irrelevant. Is this a limitation of maven 2.0.*, or a bug or am I doing something wrong? I'm lost with this problem. Any hints are appreciated. Let me know, if some relevant information is missing. Thanks in advance, Henrik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Hi Henrik, Henrik Niehaus wrote: Hi Maven users, I'm having problems with two plugins, which both define a custom packaging type. The packaging types are source-plugin and binary-plugin, which are defined in a private maven plugin and warpath, which is defined in the warpath plugin. If I run the project with both plugins defined, only the first plugin seems to be taken into account. E.g. if our private plugin is defined above the warputh plugin, source-plugin and binary-plugin can be resolved and warpath cannot be resolved. Same thing vice versa, if the warputh plugin is defined above out plugin, warpath can be resolved, source-plugin and binary-plugin not. Plugins are defined this way: plugin groupIdcom.company/groupId artifactIdmaven-rcpbuild-plugin/artifactId version1.0.3/version extensionstrue/extensions /plugin plugin groupIdorg.appfuse/groupId artifactIdmaven-warpath-plugin/artifactId version2.0.2/version extensionstrue/extensions executions execution goals goaladd-classes/goal /goals /execution /executions /plugin Running the project with our plugin and without the warpath plugin works and vice versa. If I run the same configuration with maven 2.2.1, it works as expected. Also the plugin order is irrelevant. Is this a limitation of maven 2.0.*, or a bug or am I doing something wrong? I'm lost with this problem. Any hints are appreciated. Let me know, if some relevant information is missing. Please look into the POMs of the plugins and tell whether they declare a dependency to another plugin themselves. If yes, which ones? - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 14:54, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Hi Maven users,
I'm having problems with two plugins, which both define a custom
packaging type. The packaging types are source-plugin and binary-plugin,
which are defined in a private maven plugin and warpath, which is
defined in the warpath plugin.
If I run the project with both plugins defined, only the first plugin
seems to be taken into account. E.g. if our private plugin is defined
above the warputh plugin, source-plugin and binary-plugin can be
resolved and warpath cannot be resolved. Same thing vice versa, if the
warputh plugin is defined above out plugin, warpath can be resolved,
source-plugin and binary-plugin not.
Plugins are defined this way:
plugin
groupIdcom.company/groupId
artifactIdmaven-rcpbuild-plugin/artifactId
version1.0.3/version
extensionstrue/extensions
/plugin
plugin
groupIdorg.appfuse/groupId
artifactIdmaven-warpath-plugin/artifactId
version2.0.2/version
extensionstrue/extensions
executions
execution
goals
goaladd-classes/goal
/goals
/execution
/executions
/plugin
Running the project with our plugin and without the warpath plugin works
and vice versa.
If I run the same configuration with maven 2.2.1, it works as expected.
Also the plugin order is irrelevant.
Is this a limitation of maven 2.0.*, or a bug or am I doing something
wrong? I'm lost with this problem. Any hints are appreciated.
Let me know, if some relevant information is missing.
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be physically
located in a parent directory, but is an artifact on its own), that declares
both plugins in the depMgmt section.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be physically
located in a parent directory, but is an artifact on its own), that declares
both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare
a dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be
physically located in a parent directory, but is an artifact on its own),
that declares both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
Sorry, I mean in this case the pluginMgmt section.
Typically you define one parent POM for your complete project where you use
the depenencyManagement section to define the versions (and standard scopes)
of all your dependencies and a pluginManagement section with all plugins
used in this project again with versions and configuration shared everywhere
they are in use. This project POM is directly or indirectly inherited by all
your POMs within this project. Then you do not have to define anywhere a
version for a plugin (well, not for the plugins in the report sections, but
that's a different story) or dependency.
In the pluginManagement section you will also define any additional
dependency for the individual plugins (e.g. custom tasks for the antrun-
plugin or additional wagon providers) and also set the extension flag for
the plugins with custom extensions. Remember, each plugin can be loaded only
once and the first activation will also define its classpath.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Custom Packaging Types
Hello everybody maybe are repost but my subscribing went wrong, I am new to maven 2.0. but experienced 1.0 user. Do i understand correctly that packaging defines the type of product that is being build. If so, can you define more than one and define your own custom types. like installer and application. With matching plugins. Thanks
Re: Custom Packaging Types
take a look at http://mojo.codehause.org/maven-native/native-maven-plugin it uses build lifecyle extension to provide its own packaging type. -Dan On 4/25/06, Marteijn Nouwens [EMAIL PROTECTED] wrote: Hello everybody maybe are repost but my subscribing went wrong, I am new to maven 2.0. but experienced 1.0 user. Do i understand correctly that packaging defines the type of product that is being build. If so, can you define more than one and define your own custom types. like installer and application. With matching plugins. Thanks
Re: Custom Packaging Types
On 4/25/06, dan tran [EMAIL PROTECTED] wrote: take a look at http://mojo.codehause.org/maven-native/native-maven-plugin That would be: http://mojo.codehaus.org/maven-native/native-maven-plugin/ (No 'e' on the end of codehaus ;) -- Martin Cooper it uses build lifecyle extension to provide its own packaging type. -Dan On 4/25/06, Marteijn Nouwens [EMAIL PROTECTED] wrote: Hello everybody maybe are repost but my subscribing went wrong, I am new to maven 2.0. but experienced 1.0 user. Do i understand correctly that packaging defines the type of product that is being build. If so, can you define more than one and define your own custom types. like installer and application. With matching plugins. Thanks
Re: Custom Packaging Types
on the second thought, if you can whip you installer easily thru a small ant script, you can use maven-antrun-plugin to create the installer, then use build-helper-maven-plugin to attach your output to be installed/deploy -D On 4/25/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/25/06, dan tran [EMAIL PROTECTED] wrote: take a look at http://mojo.codehause.org/maven-native/native-maven-plugin That would be: http://mojo.codehaus.org/maven-native/native-maven-plugin/ (No 'e' on the end of codehaus ;) -- Martin Cooper it uses build lifecyle extension to provide its own packaging type. -Dan On 4/25/06, Marteijn Nouwens [EMAIL PROTECTED] wrote: Hello everybody maybe are repost but my subscribing went wrong, I am new to maven 2.0. but experienced 1.0 user. Do i understand correctly that packaging defines the type of product that is being build. If so, can you define more than one and define your own custom types. like installer and application. With matching plugins. Thanks
