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
On 04.03.2014 17:59, Guillaume Nodet wrote:
Btw, i pushed some commits to my branch. Karaf seems fully functional and
a compatibility layer has been extracted as a fragment to the console, so
that the shell.console bundle only contains the api and implementation of
the new stuff.
2014-03-04 9:1
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
-
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 s
Github user grgrzybek closed the pull request at:
https://github.com/apache/karaf/pull/29
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is ena
It's why I put on master, not on the karaf-3.0.x branch.
Master is 3.1.0-SNAPSHOT but should become 4.0.0-SNAPSHOT (as soon as we
will create the 3.1.x branch).
Regards
JB
On 03/05/2014 12:47 AM, Christoph Gritschenberger wrote:
I think it's a bad idea to _rename_ plugin-goals. That would br
I'm with Christoph on this one. I think people wont like us too much for
changing things during minor releases. Maybe we could print a deprecation
comment if the original commands are used instead of the new ones helping
the users switch.
Kind regards,
Andreas
On Wed, Mar 5, 2014 at 12:47 AM, Ch
I think it's a bad idea to _rename_ plugin-goals. That would break
compatibility with 3.0-plugin-configurations.
Maybe the new names should be provided as aliases and the old names
removed in 4.0
kind regards,
christoph
On 04/03/14 20:27, Jean-Baptiste Onofré wrote:
The refactoring is on ma
The refactoring is on master (3.1.x), I don't change on 3.0.x as it's a
maintenance branch now.
Regards
JB
On 03/04/2014 07:48 PM, Jamie G. wrote:
1a. Refactoring/Renaming goals - on the 3.0.x or for 3.1.x? The
shorter names are good, just want a clarification on target.
1b. New Goals - Sound
I second Jamie on this.
sounds like a big improvement, good job.
regards, Achim
2014-03-04 19:48 GMT+01:00 Jamie G. :
> 1a. Refactoring/Renaming goals - on the 3.0.x or for 3.1.x? The
> shorter names are good, just want a clarification on target.
>
> 1b. New Goals - Sounds good.
>
> 2. New tes
1a. Refactoring/Renaming goals - on the 3.0.x or for 3.1.x? The
shorter names are good, just want a clarification on target.
1b. New Goals - Sounds good.
2. New tests are always welcome :)
On Tue, Mar 4, 2014 at 3:09 PM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I would like to discuss with you
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
Hi all,
FYI, the assembly archetype build fails on master and karaf-3.0.x
branches right now.
I'm fixing it now.
Sorry about that.
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Btw, i pushed some commits to my branch. Karaf seems fully functional and
a compatibility layer has been extracted as a fragment to the console, so
that the shell.console bundle only contains the api and implementation of
the new stuff.
2014-03-04 9:11 GMT+01:00 Christian Schneider :
> Hi Guilla
Hi,
standard Servlet API 3.0 annotations should work with Pax Web by just
installing the war feature.
Though I just found and fixed a bug for Filter annotations (Pax Web
3.0.7-SNAPSHOT comes with Karaf 3.0.1-SNAPSHOT).
Concerning the @MultipartConfig I'm not sure if it'll work right away, if
not p
Hi Guillaume,
I like the abstraction from console and jline in your proposal.
The extender pattern in fact solves the classloading problem. So you can
now hide the impl classes. As the extender is independent of the user
framework
it is of course also "compatible" to other frameworks.
The pro
16 matches
Mail list logo
