Hi David,
could you spot to me which one you're thinking about ?
Thanks
Regards
JB
On 02/07/2011 08:31 PM, David Jencks wrote:
I don't agree with some of these, since they are not intended to be used
standalone but as part of a packaging that use several mojos and your proposed
names make it sound like these are the entire packaging.
On Feb 7, 2011, at 7:58 AM, Jean-Baptiste Onofré wrote:
Hi all,
already around the Karaf maven plugin workload, it could be the good time to
rename the goals.
I propose the following goals rename:
- add-features-to-repo => resolve-features
- archive-kar => create-kar
I don't agree with this one The kar packaging requires generate-features-xml2
and this one. create-kar sounds like this is the only step.
- archive-server => create-instance
again, this is the final packaging step in the karaf-assembly packaging and
doesn't make much sense as an independent goal
- generate-features-file => create-features
- generate-features-xml => create-features
- generate-features-xml2 => create-features
I don't understand what the original 2 generate-features-* mojos are supposed
to do. I have strong doubts that if we want to keep the originals we can
squeeze both sets of functionality into one mojo. In any case the
generate-features-xml2 is part of some packagings and the other 2 aren't yet.
- install-kars => resolve-kars
I don't understand how "resolve" relates to the action of this mojo. Install
seems pretty clear to me. And I think it's only appropriate as part of the
karaf-assembly packaging.
- validate => validate-features
- cmdhelp => generate-comands-help
As reminder, we plan to add the following goals:
- run to start a Karaf instance
- shell to connect remotely to a running Karaf instance
WDYT ?
I sure hope mixing non-packaging and packaging goals in one maven plugin
doesn't lead to too much confusion.
thanks
david jencks
Thanks
Regards
JB
On 02/07/2011 11:30 AM, Jean-Baptiste Onofré wrote:
Hi all,
I'm beginning to work on KARAF-402.
The purpose is to gather all goals available into one central maven
plugin and, later, extend this plugin with new goals depending of
current opened discussions (run, profiles, etc :)).
I think that the tooling groupId is not more required as we will have
only one maven plugin.
So I propose the following naming convention:
groupId: org.apache.karaf
artifactId: karaf-maven-plugin.
So for the users, the POM definition will look like:
<plugins>
<plugin>
<groupId>org.apache.karaf</groupId>
<artifactId>karaf-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>add-features-to-repo</id>
<phase>generate-resources</phase>
<goals>
<goal>add-features-to-repo</goal>
</goals>
[...]
</execution>
</executions>
</plugin>
</plugins>
I think it's clear for the users.
The question is now more on tooling/testing module.
This tooling/testing module should be moved on the trunk root too.
We have to ways to see that:
1/ I move tooling/testing logic in itests modules (but maybe it
introduces circular dependencies, I have to check)
2/ I create a new testing project dedicated to the itests of maven plugin
WDYT ?
Regards
JB
