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
