+1
regards, Achim
2014-03-05 18:17 GMT+01:00 Andreas Pieber :
> +1
>
> Kind regards,
> Andreas
> On 5 Mar 2014 15:39, "Jean-Baptiste Onofré" wrote:
>
> > Hi all,
> >
> > I prepared the board report for March 2014:
> > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
> >
> > Plea
Apache Karaf provides higher level features and services
specifically designed for creating OSGi-based servers.
Community
=
The new Karaf 3.0.0 has been a good message to the community.
The website has been a bit polished to give more visibility to the
documentation of the two active Kar
+1
Kind regards,
Andreas
On 5 Mar 2014 15:39, "Jean-Baptiste Onofré" wrote:
> Hi all,
>
> I prepared the board report for March 2014:
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>
> Please, review and keep me posted asap. I would like to submit it today.
>
> Regards
> JB
>
The report reads fine to me.
--Jamie
On Wed, Mar 5, 2014 at 11:09 AM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I prepared the board report for March 2014:
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>
> Please, review and keep me posted asap. I would like to submit it toda
Hi all,
I prepared the board report for March 2014:
https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
Please, review and keep me posted asap. I would like to submit it today.
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend
Why not simply refactore/enhance the ActiveMQ commands ?
I think it makes more sense.
As soon as we have some "stable", I will tackle that.
Regards
JB
On 03/05/2014 01:57 PM, Christian Schneider wrote:
On 05.03.2014 13:10, Guillaume Nodet wrote:
I think ActiveMQ might be a good case for us
On 05.03.2014 13:10, Guillaume Nodet wrote:
I think ActiveMQ might be a good case for using an extended gogo api.
Not sure to follow. They're currently using the old api and
implementation, so they do work unchanged (I've actually fixed a few things
in the compatibility layer and tested agai
Hi Jamie,
we are inline: it was the purpose of my proposal. Enable the itests on
Jenkins is a must have, but for convenience, it would be interesting to
enable it by hand on "local" build.
However, I follow Christian and Achim advices and I clean up a bit to
enable *all* itests by default.
+1 for shell.core name.
Regards
JB
On 03/05/2014 11:51 AM, Guillaume Nodet wrote:
2014-03-05 11:07 GMT+01:00 Christian Schneider :
The only problem I see is the incompatibility for old modules.
I propose a slightly different layout:
Leave the old code in shell.console and move the new api an
2014-03-05 12:12 GMT+01:00 Christian Schneider :
> On 05.03.2014 11:51, Guillaume Nodet wrote:
>
>> 2014-03-05 11:07 GMT+01:00 Christian Schneider :
>>
>> The only problem I see is the incompatibility for old modules.
>>> I propose a slightly different layout:
>>>
>>> Leave the old code in shell.
Being able to skip itests would be good from my Point of View - often
during RC builds an itest will randomly fail, causing a step to be
reissued. I'd still want my Jenkins builds to be running all tests
however by default.
--Jamie
On Wed, Mar 5, 2014 at 7:40 AM, Jean-Baptiste Onofré wrote:
> Al
On 05.03.2014 11:51, Guillaume Nodet wrote:
2014-03-05 11:07 GMT+01:00 Christian Schneider :
The only problem I see is the incompatibility for old modules.
I propose a slightly different layout:
Leave the old code in shell.console and move the new api and impl
to a new module. Perhaps shell.co
Allright guys. I follow you.
In that case, I'm cleaning the pom, fixing and enabling tooling itests
by default.
Thanks
Regards
JB
On 03/05/2014 11:30 AM, Achim Nierbeck wrote:
Hi,
I'd rather skipt integration tests per usage, cause at this point I'm in
charge and should know what I do ;)
Th
I agree with Christian.
For the name, maybe directly console (package org.apache.karaf.console
and artifactId org.apache.karaf.console too) ?
For ActiveMQ and Hadoop, it's not a problem as it uses
CommandWithAction, so it should work straight forward.
Regards
JB
On 03/05/2014 11:07 AM, Chr
2014-03-05 11:07 GMT+01:00 Christian Schneider :
> The only problem I see is the incompatibility for old modules.
> I propose a slightly different layout:
>
> Leave the old code in shell.console and move the new api and impl
> to a new module. Perhaps shell.console2. Not sure about the name.
>
> S
2014-03-05 8:51 GMT+01:00 Christian Schneider :
> 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
Hi,
I'd rather skipt integration tests per usage, cause at this point I'm in
charge and should know what I do ;)
That's why I object on disabling the itests per default.
regards, Achim
2014-03-05 10:16 GMT+01:00 j...@nanthrax.net :
> The only drawback is that itests consume resources and take
The only problem I see is the incompatibility for old modules.
I propose a slightly different layout:
Leave the old code in shell.console and move the new api and impl
to a new module. Perhaps shell.console2. Not sure about the name.
So existing users do not have to change anything. For karaf we
I'd like to start a discussion on how and where (in terms of branch /
version) we can integrate the new console I worked on those past days.
https://github.com/gnodet/karaf/tree/console-api/
It provides two apis, one for the console and one for the action model.
Both apis have no dependencies
The only drawback is that itests consume resources and take times.
I'm ok to enable it by default (I will fix in tooling as it's not the case for
now).
Let see the feedback from the others.
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://wwx.talen
I think the tests are currently fast enough to run by default.
Having a default to not run itests often tends to let people skip itests
before a commit.
In the end it is just a question of default as we currently also can
skip the itests but I think
the default of running the itests communicates
Interesting proposal. Never thought about that but it could make sense.
Christian
On 05.03.2014 09:23, Jean-Baptiste Onofré wrote:
Rethinking about this, I propose:
groupId: org.apache.karaf.maven.plugins
artifactId: [scr-maven-plugin, instance-maven-plugin,
feature-maven-plugin, kar-maven-pl
Hi all,
Right now, our itests are always run when you build with a simple mvn
clean install.
I would like to propose:
- create a itests profile in itests and tooling (renaming of
ci-build-profile as it's not related to ci only)
- enable the run-it profile on Jenkins by default
- document the
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
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
co
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é :
> Rethinki
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-mav
It makes sense to "spread" the plugin per module (instead of having all
in tooling).
I do the changes on my branch and come back with a proposal.
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 dif
28 matches
Mail list logo
