You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/02/07 11:30:35 UTC

[DISCUSS] Refactoring of maven plugins

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

Re: [DISCUSS] Refactoring of maven plugins

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
>

Re: [DISCUSS] Refactoring of maven plugins

Posted by David Jencks <da...@yahoo.com>.
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

Re: [DISCUSS] Refactoring of maven plugins

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
- archive-server => create-instance
- generate-features-file => create-features
- generate-features-xml => create-features
- generate-features-xml2 => create-features
- install-kars => resolve-kars
- 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 ?

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

Re: [DISCUSS] Refactoring of maven plugins

Posted by Andreas Pieber <an...@gmail.com>.
On Mon, Feb 07, 2011 at 11:30:35AM +0100, 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>

+1

> 
> 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)

I don't think that there are any circular deps (but please check yourself).

if there are none: +1 for moving to itest; otherwise I personally would prefer a
tooling/testing, altough there's (for the moment) only this project

kind regards,
andreas

> 2/ I create a new testing project dedicated to the itests of maven plugin
> 
> WDYT ?
> 
> Regards
> JB