By the way, let see what the others think about that.
Regards
JB
On 03/05/2014 09:36 AM, Jean-Baptiste Onofré wrote:
Yeah, I'm also "split" in my mind ;)
I really think that an unique plugin with multiple goal is better for
the users.
It's likely the Maven approach (for instance deploy:deploy and
deploy:deploy-file).
So, I'm hesitating.
I move forward on the enhancements anyway, I will come back with a
couple of proposals to discuss.
Regards
JB
On 03/05/2014 09:31 AM, Achim Nierbeck wrote:
Don't know,
I would have prefered a one-to-rule-them-all maven plugin.
It is still a maven plugin, and everything else would distract from the
main purpose.
But this is just my 2 cents and I don't want to be ignorant.
regards, Achim
2014-03-05 9:23 GMT+01:00 Jean-Baptiste Onofré <[email protected]>:
Rethinking about this, I propose:
groupId: org.apache.karaf.maven.plugins
artifactId: [scr-maven-plugin, instance-maven-plugin,
feature-maven-plugin, kar-maven-plugin, ...]
The plugin module will be in each module:
- instance/instance-maven-plugin
- scr/scr-maven-plugin
- features/feature-maven-plugin
- kar/kar-maven-plugin
- ...
With tests/itests in each plugin
The tooling module will disappear.
WDYT ?
Regards
JB
On 03/05/2014 08:57 AM, Christian Schneider wrote:
I think the big problem with one big plugin project is that the code
will be very difficult to maintain and test.
The command names below sound good. Especially that they sound similar
to karaf commands. So it it easier for users to know what they do.
I think it should be possible to split the plugin into projects
based on
the name before the ":". These goals should do similar things and so
should have similar
dependencies and make good candidates for modules.
Christian
On 05.03.2014 08:45, Jean-Baptiste Onofré wrote:
I would prefer to have one plugin with multiple goal (I think it's
better for the users).
I have no problem to rename/split plugins for future. What do you
think about:
- karaf-commands:documentation
- karaf-scr:scr
- karaf-kar:create
- karaf-kar:install
- karaf-features:populate-repository
- karaf-features:generate
- karaf-features:validate
- karaf-instance:archive
- karaf-instance:run
- karaf-instance:deploy
- karaf-instance:client
?
Regards
JB
On 03/05/2014 08:40 AM, Christian Schneider wrote:
I think we should not put all karaf plugins into one maven plugin.
Instead I think it makes more
sense to analyze which goals have similar dependencies and put them
together.
For example the karaf-scr plugin has very few dependencies and is
better
suited to be kept as a separate plugin.
The same may apply for others but I have not looked into them in
detail.
Christian
Am 04.03.2014 19:39, schrieb Jean-Baptiste Onofré:
Hi all,
I would like to discuss with you about my current work on the
karaf-maven-plugin:
1/ on master, I refactored the karaf-maven-plugin to use the Maven
annotations. It's simpler and cleaner, and compatible with all Maven
version. I also added the Maven 3.1 and 3.2 support. I also fixed
the
same issue as on karaf-3.0.x (see below) and cleanup the code (using
global
I propose the following cleanup/refactoring/renaming on the goals:
- karaf:commands-generate-help renamed to
karaf:commands-documentation
- karaf:create-instance-archive renamed to karaf:instance-archive
- karaf:features-add-to-repository renamed to
karaf:populate-repository
- karaf:features-create-kar renamed to karaf:create-kar
- karaf:features-export-meta-data renamed to karaf:export-metadata
- karaf:features-generate-descriptor renames to
karaf:create-features
- karaf:features-validate-descriptor renamed to
karaf:validate-features
Introduction of new goals:
- karaf:client to interact with a running instance
- karaf:instance to interact with instances (start, stop, etc)
- karaf:deploy to deploy bundles or features (and eventually
populate
the system repository using scp)
- karaf:run to bootstrap and run a Karaf container
I also merged the scr-karaf-maven-plugin in karaf-maven-plugin as a
dedicated goal (karaf:scr).
2/ on karaf-3.0.x branch, I introduced a set of new integration
tests
(using the maven-invoker-plugin). I fixed the different issues
(construct global features set to resolve all features including
transitive ones, support of file and http URLs, support of
<configfile/> in features repository XML, etc).
Thoughts ?
Regards
JB
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
