You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/05/04 10:25:44 UTC

[DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

@jb If people think Cellar may potentially grow into something bigger,
we should definitely make it a subproject asap.  It will be much less
pain than doing that later.

@achim that could be a good idea.   I remember jb talked about an OBR
repository and maybe the a webserver (ready to use web container based
on karaf and pax-web plus all the good stuff you wrote recently) could
definitely make sense to me.   It may also help keeping the core clean
and lean.

On Wed, May 4, 2011 at 09:43, Achim Nierbeck <bc...@googlemail.com> wrote:
> Hi,
>
> +1 for cellar being a subproject.
>
> btw. we might need to take a look on different other "core" features
> that might be considered to be a worthy "subproject".
> just my 2 cents :-)
>
> regards, Achim
>
> 2011/5/4 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> Hi Guillaume,
>>
>> thanks for the update.
>>
>> I would prefer to have Cellar directly on Karaf trunk. Like this, it allows
>> to define Cellar feature into the Karaf features descriptors.
>> But your remark is right and it could make sense to have Cellar as a Karaf
>> edge project.
>> @others: WDYT ?
>>
>> For the projects dependencies (SMX, CXF, etc), it's just an idea, and I'm
>> not sure it's a good one :). For now, Cellar is **only** a Karaf cluster
>> implementation. So it makes sense to be in Karaf. If later, it evolves to
>> something different, we will think about moving into a new project (as we
>> made for Karaf, from ServiceMix Kernel, to Felix Karaf and finally Karaf
>> :)).
>>
>> Thanks again
>> Regards
>> JB
>>
>> On 05/04/2011 09:32 AM, Guillaume Nodet wrote:
>>>
>>> +0  as I don't plan to work on that code base in the near future
>>>
>>> A few comments though:
>>>   * I do think it would be better to import cellar into its own
>>> subproject at http://svn.apache.org/repos/asf/karaf/cellar/trunk
>>>      so that it can have independant releases and won't affect the 3.0
>>> schedule
>>>   * if you think of cellar as providing features for servicemix, cxf
>>> or camel, I think Karaf is not the right place for cellar
>>>      and I would start in the incubator so that cellar can have the
>>> broader scope it deserve
>>>
>>>
>>> On Tue, May 3, 2011 at 19:41, Jean-Baptiste Onofré<jb...@nanthrax.net>
>>>  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> following our discussion about Karaf clustering and Cellar, I would like
>>>> to
>>>> launch a vote to add Cellar into Karaf trunk.
>>>>
>>>> This addition covers the following topics:
>>>>
>>>> 1/ Source code
>>>> Currently, Cellar source code is on github. It will be added into Karaf
>>>> trunk, on a cellar maven module.
>>>> All package will be named to org.apache.karaf.cellar and all resources
>>>> (java, properties, etc) will include Apache header.
>>>>
>>>> 2/ Provided features
>>>> Before inclusion, Ioannis and I would include a new feature which allow
>>>> you
>>>> to choose the node discovery mechanism:
>>>> - static list
>>>> - unicast
>>>> - multicast
>>>> - etc
>>>> I started to work on it this afternoon, it should be available soon.
>>>>
>>>> 3/ Documentation resources
>>>> The Karaf user and developers manuals will contain Cellar installation
>>>> and
>>>> user guide. First step is to complete the Karaf cluster wiki page, and
>>>> refactore the Ioannis' blog content into user and developers manuals.
>>>>
>>>> Depending of the result of the vote, I will raise the corresponding Jira
>>>> and
>>>> I will work on it.
>>>>
>>>> I have a couple of Karaf Cellar related topics:
>>>> - I launched a discussion on Apache ACE mailing list. As ACE supports
>>>> cloud
>>>> environment (using jclouds), I would like to avoid overlap between ACE
>>>> and
>>>> Karaf. The first ACE team feedbacks are good as we consider ACE as a pure
>>>> provisioning platform. I will keep you posted about this discussion. On
>>>> the
>>>> same area (relationship with others Apache projects), I think that we
>>>> have
>>>> to discuss with Camel, ServiceMix, CXF, ActiveMQ, and others about we can
>>>> improve Karaf Cellar to provide services for these projects.
>>>> - I submitted a talk for the next ApacheCon 2011 (Vancouver, 5th-11th
>>>> November) about Karaf in an enterprise environment. It will include Karaf
>>>> 3.0.0 new features presentation and of course Karaf Cellar introduction.
>>>> I
>>>> also plan to make a demo using Karaf, Cellar, and ACE to show how Karaf
>>>> is a
>>>> powerful OSGi runtime/container in an high value enterprise environment.
>>>>
>>>> Regarding these topics, I submit the addition of Cellar into Karaf to
>>>> your
>>>> vote:
>>>>
>>>> [ ] +1 Approve the addition of Cellar into Karaf trunk
>>>> [ ] -1 Veto the addition (please provide specific comments)
>>>>
>>>> This vote will be open for 72 hours.
>>>>
>>>> I'm available if you need deeper explanations about Cellar.
>>>>
>>>> Thanks,
>>>> Regards
>>>> JB
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> --
> *Achim Nierbeck*
>
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.

You're right James, I forgot this point :)

Regards
JB

On 05/04/2011 12:07 PM, James Strachan wrote:
> On 4 May 2011 10:51, Jean-Baptiste Onofré<jb...@nanthrax.net>  wrote:
>> It makes sense to have sub-projects in Karaf:
>> - WebContainer (using Pax Web)
>> - EnterpriseContainer (using Aries, OpenJPA)
>> - OBR (using Felix BundleRepository, home mage stuff)
>> - Cluster (using Cellar/Hazelcast)
>>
>> In that case, Karaf itself will be a very lightweight container.
>>
>> Pro:
>> - Karaf itself is more clean and light
>> - Karaf dependencies are more easy to manage (the dependencies management
>> move to subproject)
>
> Its also easier to manage release lifecycles with more granular
> projects. e.g. Cellar is going to be under a state of flux and active
> development for some time; whereas Karaf is much more stable&  already
> used in lots of projects.
>
> We learnt the hard way on the ServiceMix project that separating out
> the Kernel release from features-above-the-kernel makes things much
> easier for folks managing their dependencies&  release schedules.
> (e.g. you might want to use Cellar in 2.x and 3.x versions of Karaf
> for some time yet).
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by James Strachan <ja...@gmail.com>.

On 4 May 2011 11:23, Christian Schneider <ch...@die-schneider.net> wrote:
> Yes .. it is a tradeoff for the flexibility you gain. I just wanted to
> mention the effort needed to do this.

Having courser grained projects also adds work to each release as you
have to test everything is working in every release, rather than the
smaller feature you're hacking on.

Given OSGi is all about modularity; it seems churlish to not have
modular projects & releases too.

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

Yes .. it is a tradeoff for the flexibility you gain. I just wanted to 
mention the effort needed to do this.

Christian


Am 04.05.2011 12:14, schrieb James Strachan:
> On 4 May 2011 11:11, Christian Schneider<ch...@die-schneider.net>  wrote:
>> Good point .. but this also makes things harder to test as each release of
>> Karaf has to be tested with several versions of cellar as well as each
>> release of cellar has to be tested against several versions of Karaf.
> Cellar just needs to be tested against one or more Karaf releases;
> just like ServiceMix components are frequently tested against
> different ServiceMix releases. Its no biggie really.
>
> Given the modular nature of OSGi you probably want to test any OSGi
> component against a number of different containers anyway.
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by James Strachan <ja...@fusesource.com>.

On 4 May 2011 11:11, Christian Schneider <ch...@die-schneider.net> wrote:
> Good point .. but this also makes things harder to test as each release of
> Karaf has to be tested with several versions of cellar as well as each
> release of cellar has to be tested against several versions of Karaf.

Cellar just needs to be tested against one or more Karaf releases;
just like ServiceMix components are frequently tested against
different ServiceMix releases. Its no biggie really.

Given the modular nature of OSGi you probably want to test any OSGi
component against a number of different containers anyway.

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

Good point .. but this also makes things harder to test as each release 
of Karaf has to be tested with several versions of cellar as well as 
each release of cellar has to be tested against several versions of Karaf.

Christian


Am 04.05.2011 12:07, schrieb James Strachan:
> On 4 May 2011 10:51, Jean-Baptiste Onofré<jb...@nanthrax.net>  wrote:
>> It makes sense to have sub-projects in Karaf:
>> - WebContainer (using Pax Web)
>> - EnterpriseContainer (using Aries, OpenJPA)
>> - OBR (using Felix BundleRepository, home mage stuff)
>> - Cluster (using Cellar/Hazelcast)
>>
>> In that case, Karaf itself will be a very lightweight container.
>>
>> Pro:
>> - Karaf itself is more clean and light
>> - Karaf dependencies are more easy to manage (the dependencies management
>> move to subproject)
> Its also easier to manage release lifecycles with more granular
> projects. e.g. Cellar is going to be under a state of flux and active
> development for some time; whereas Karaf is much more stable&  already
> used in lots of projects.
>
> We learnt the hard way on the ServiceMix project that separating out
> the Kernel release from features-above-the-kernel makes things much
> easier for folks managing their dependencies&  release schedules.
> (e.g. you might want to use Cellar in 2.x and 3.x versions of Karaf
> for some time yet).
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

Yes .. I would also rather like to keep it on karaf trunk. When it gets 
bigger and more independent we can still make it a real subproject with 
independent release history. I also like to keep things simple if possible.

Christian

Am 04.05.2011 12:58, schrieb Charles Moulliard:
> Yes. What you call a karaf subprojet will be part of karaf trunk under 
> maven project features/cellar and available for karaf as a feature 
> file like we do now for Karaf Enterprise features (Aries, JPA, ...).
>
> Keep things simple and understandable by the community of users and 
> clients
>
> On 04/05/11 12:42, Ioannis Canellos wrote:
>> So what do you suggest? Add Cellar as a Karaf subproject and provide a
>> Cellar feature in core Karaf?
>>
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Charles Moulliard <cm...@gmail.com>.

Yes. What you call a karaf subprojet will be part of karaf trunk under 
maven project features/cellar and available for karaf as a feature file 
like we do now for Karaf Enterprise features (Aries, JPA, ...).

Keep things simple and understandable by the community of users and clients

On 04/05/11 12:42, Ioannis Canellos wrote:
> So what do you suggest? Add Cellar as a Karaf subproject and provide a
> Cellar feature in core Karaf?
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Andreas Pieber <an...@gmail.com>.

Just reading your response Guillaume; I'm not so sure if we really
should create various distributions here. Instead I think this have to
go hand-in-hand with a "feature-repository" where all subfeatures
could be registered. That way we can update the submodules independent
from the core Karaf container and require only our three distributions
as they are now. The user downloads either a minimal, standard or full
distribution (while I think standard and full are the same with the
difference that you scale the standard distribution "up" and the full
"down (as discussed in another thread by Mike and David)) and can
install cellar, web or anything else via the feature repository. I
don't think that we should differ here between a "clustering" and
"non-clustering" solution in any other way.

Kind regards,
Andreas

On Wed, May 4, 2011 at 12:50 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I think cellar could have irs own distribution of Karaf. That should
> be easy to do using the plugin David is working on.  But it would
> always be very easy to install in a plain karaf using xml features.
> Just like we have with web.
> Downstream projects such as Geronimo may not be interested in
> clustering or web apps, so it would make sense to have the code in a
> separate subproject.
>
> On Wednesday, May 4, 2011, Ioannis Canellos <io...@gmail.com> wrote:
>> So what do you suggest? Add Cellar as a Karaf subproject and provide a
>> Cellar feature in core Karaf?
>>
>> --
>> *Ioannis Canellos*
>> *
>>  http://iocanel.blogspot.com
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> Apache ServiceMix <http://servicemix.apache.org/>  Committer
>> *
>>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com/
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

I think cellar could have irs own distribution of Karaf. That should
be easy to do using the plugin David is working on.  But it would
always be very easy to install in a plain karaf using xml features.
Just like we have with web.
Downstream projects such as Geronimo may not be interested in
clustering or web apps, so it would make sense to have the code in a
separate subproject.

On Wednesday, May 4, 2011, Ioannis Canellos <io...@gmail.com> wrote:
> So what do you suggest? Add Cellar as a Karaf subproject and provide a
> Cellar feature in core Karaf?
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

I will have to look into what we have in 3.0 for this. Perhaps it does 
already what I wanted.

Christian


Am 04.05.2011 13:07, schrieb Guillaume Nodet:
> I think that's what we are working on already as part of 3.0, so not
> sure if I really understand what you mean here.
>
> On Wed, May 4, 2011 at 13:06, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> I think we can not provide a distribution for everything people want anyway.
>> So instead of having more distributions I think we should concentrate on
>> providing a really simple way for users to create their own distros.
>>
>> Christian

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Achim Nierbeck <bc...@googlemail.com>.

+1 on the idea of Ioannis,

I really want to see the clustering being part of the enterprise
features, and again I think it is a good way of
keeping the standard Karaf lean to put the clustering solution in a
subproject, with all given pros and cons.
I personally think the pros still override the cons.

just my 2 cents, Achim :-)

2011/5/4 Ioannis Canellos <io...@gmail.com>:
> Guys, we are getting off topic.
>
> Even though I like Guillaume's ideas about central repository etc, it is
> still hypothetical since the mechanism is not implemented yet and thus we
> can't base our decisions on that.
>
> What we currently have is standard/enterprise features descriptor. What I am
> saying is that clustering should be part of the enterprise features
> descriptor *(and probably hosted as subproject)*. Once we implement the
> central repository mechanism we can move it there.
>
> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> I think you misundertand me.
>> When camel 2.8.1 would be released, we'd just add the url to the global
>> file at
>>   http://karaf.apache.org/features/repository.xml
>>
>> Users could then install the updated feature as it would be
>> automatically available.
>>
>> On Wed, May 4, 2011 at 13:42, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>> > The problem with listing all versions is that you can not work with newer
>> > version of e.g. camel. Imagine you have karaf working with camel 2.8.0.
>> Then
>> > you have a bug which is fixed in camel 2.8.1. Then you will want to
>> easily
>> > use camel 2.8.1 without waiting for a new karaf release.
>> >
>> > I think it would be better to scan for available versions on the maven
>> repo
>> > and warn if the user tries to install a version that was not tested. And
>> > honestly we will not be able to test all those combinations anyway.
>> >
>> > Christian
>> >
>> >
>> > Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>> >>
>> >> In that central xml, we can refer to multiple versions of the same
>> >> feature descriptor:
>> >>
>> >> <features>
>> >>
>> >>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>> >>
>> >>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>> >>  ...
>> >> </features>
>> >>
>> >> I think we'd need a descriptor for each minor version of Karaf so that
>> >> we can make sure only features that have been tested on a given karaf
>> >> version are available.
>> >>
>> >> On Wed, May 4, 2011 at 13:28, Christian Schneider
>> >> <ch...@die-schneider.net>  wrote:
>> >>>
>> >>> I also think a small karaf with the easy possibility to create custom
>> >>> distros is the way to go.
>> >>> A central list of pointers to repository files makes sense. But we have
>> >>> to
>> >>> do this a bit different than the current feature files. Currently a url
>> >>> to a
>> >>> feature file always points to a certain version of that file. For a
>> >>> central
>> >>> list this does not make sense.
>> >>>
>> >>> So I think we rather need a list of the base urls without version and
>> >>> then
>> >>> an easy way for users to install a feature file with a certain version.
>> >>> So
>> >>> for example to install the feature url for camel the user should be
>> able
>> >>> to
>> >>> write something like:
>> >>> features:addurl camel 2.7.0
>> >>>
>> >>> Do we already have support for this or something similar? Or do we have
>> >>> an
>> >>> issue for it? If not I can create one.
>> >>>
>> >>> Christian
>> >>>
>> >>>
>> >>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>> >>>>
>> >>>> I think we need a way to enable user to install other features easily
>> >>>> without having to release karaf for that.
>> >>>> It just does not scale if we have to release Karaf because Camel as
>> >>>> released a new version for example.
>> >>>> We've already discussed that some time ago and I think we need to find
>> >>>> a good technical solution for that.
>> >>>> Maybe having a xml feature descriptor referenced at
>> >>>> http://karaf.apache.org/features/repository.xml which would point to
>> >>>> various other repositories (such as camel, cxf, servicemix, web,
>> >>>> aries, etc...) is more scalable as we would not have to release a new
>> >>>> karaf container each time one of those things change.  People may want
>> >>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>> >>>> things in Karaf trunk as this would create unnecessary ties between
>> >>>> the projects and Karaf.
>> >>>>
>> >>>> Once we have that, we should keep Karaf main distribution clean and
>> >>>> lean and provide all the optional bits using this way.   Combined with
>> >>>> an easy way to create custom distribution, I do think that's the way
>> >>>> to go.
>> >>>>
>> >>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
>> >>>>  wrote:
>> >>>>>>
>> >>>>>> I think that's what we are working on already as part of 3.0, so not
>> >>>>>> sure if I really understand what you mean here.
>> >>>>>>
>> >>>>> I see clustering to be part of the core karaf distribution. By that I
>> >>>>> mean
>> >>>>> that the clustering solution should be provided as a feature inside
>> the
>> >>>>> standard feature repository.
>> >>>>>
>> >>>>> --
>> >>>>> *Ioannis Canellos*
>> >>>>> *
>> >>>>>  http://iocanel.blogspot.com
>> >>>>>
>> >>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>> >>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>> >>>>> *
>> >>>>>
>> >>>>
>> >>> --
>> >>> ----
>> >>> http://www.liquid-reality.de
>> >>>
>> >>>
>> >>
>> >>
>> >
>> > --
>> > ----
>> > http://www.liquid-reality.de
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> Connect at CamelOne May 24-26
>> The Open Source Integration Conference
>> http://camelone.com/
>>
>
>
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>



-- 
--
*Achim Nierbeck*


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.

Hi guys,

a lot of message to read just after lunch :)

Agree with Andreas. It spins a previous discussion about an OBR/EBR for 
Karaf.

FYI, I launched a discussion on Archiva to see if the guys are 
interested to make enhancements to Archiva to turn it as an EBR:
http://www.mail-archive.com/dev@archiva.apache.org/msg01296.html

Anyway, Guillaume already worked on RemoteOBR which could be interesting 
also.

Regards
JB

On 05/04/2011 02:17 PM, Andreas Pieber wrote:
> Absolutely; in addition I think we should make the "central repository
> feature" a must have for 3.x
>
> Kind regards,
> Andreas
>
> On Wed, May 4, 2011 at 2:09 PM, Achim Nierbeck<bc...@googlemail.com>  wrote:
>> 2011/5/4 Guillaume Nodet<gn...@gmail.com>:
>>> On Wed, May 4, 2011 at 14:01, Ioannis Canellos<io...@gmail.com>  wrote:
>>>> Guys, we are getting off topic.
>>>>
>>>> Even though I like Guillaume's ideas about central repository etc, it is
>>>> still hypothetical since the mechanism is not implemented yet and thus we
>>>> can't base our decisions on that.
>>>
>>> I think we already have everything.  It's just a matter of writing
>>> those xml descriptors and managing those.
>>> I think we should get that in place for 3.0 if possible.
>>
>> yep, let's get 2.2.1 out fast and get into that one :)
>>
>>>
>>>> What we currently have is standard/enterprise features descriptor. What I am
>>>> saying is that clustering should be part of the enterprise features
>>>> descriptor *(and probably hosted as subproject)*. Once we implement the
>>>> central repository mechanism we can move it there.
>>>
>>> I think the enterprise descriptor should be pushed back to Aries
>>> actually.  It's a more natural home for it imho.
>>
>>
>>>
>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>>>>
>>>>> I think you misundertand me.
>>>>> When camel 2.8.1 would be released, we'd just add the url to the global
>>>>> file at
>>>>>    http://karaf.apache.org/features/repository.xml
>>>>>
>>>>> Users could then install the updated feature as it would be
>>>>> automatically available.
>>>>>
>>>>> On Wed, May 4, 2011 at 13:42, Christian Schneider
>>>>> <ch...@die-schneider.net>  wrote:
>>>>>> The problem with listing all versions is that you can not work with newer
>>>>>> version of e.g. camel. Imagine you have karaf working with camel 2.8.0.
>>>>> Then
>>>>>> you have a bug which is fixed in camel 2.8.1. Then you will want to
>>>>> easily
>>>>>> use camel 2.8.1 without waiting for a new karaf release.
>>>>>>
>>>>>> I think it would be better to scan for available versions on the maven
>>>>> repo
>>>>>> and warn if the user tries to install a version that was not tested. And
>>>>>> honestly we will not be able to test all those combinations anyway.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>>>>>>>
>>>>>>> In that central xml, we can refer to multiple versions of the same
>>>>>>> feature descriptor:
>>>>>>>
>>>>>>> <features>
>>>>>>>
>>>>>>>
>>>>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>>>>>>>
>>>>>>>
>>>>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>>>>>>>   ...
>>>>>>> </features>
>>>>>>>
>>>>>>> I think we'd need a descriptor for each minor version of Karaf so that
>>>>>>> we can make sure only features that have been tested on a given karaf
>>>>>>> version are available.
>>>>>>>
>>>>>>> On Wed, May 4, 2011 at 13:28, Christian Schneider
>>>>>>> <ch...@die-schneider.net>    wrote:
>>>>>>>>
>>>>>>>> I also think a small karaf with the easy possibility to create custom
>>>>>>>> distros is the way to go.
>>>>>>>> A central list of pointers to repository files makes sense. But we have
>>>>>>>> to
>>>>>>>> do this a bit different than the current feature files. Currently a url
>>>>>>>> to a
>>>>>>>> feature file always points to a certain version of that file. For a
>>>>>>>> central
>>>>>>>> list this does not make sense.
>>>>>>>>
>>>>>>>> So I think we rather need a list of the base urls without version and
>>>>>>>> then
>>>>>>>> an easy way for users to install a feature file with a certain version.
>>>>>>>> So
>>>>>>>> for example to install the feature url for camel the user should be
>>>>> able
>>>>>>>> to
>>>>>>>> write something like:
>>>>>>>> features:addurl camel 2.7.0
>>>>>>>>
>>>>>>>> Do we already have support for this or something similar? Or do we have
>>>>>>>> an
>>>>>>>> issue for it? If not I can create one.
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>>>>>>>>
>>>>>>>>> I think we need a way to enable user to install other features easily
>>>>>>>>> without having to release karaf for that.
>>>>>>>>> It just does not scale if we have to release Karaf because Camel as
>>>>>>>>> released a new version for example.
>>>>>>>>> We've already discussed that some time ago and I think we need to find
>>>>>>>>> a good technical solution for that.
>>>>>>>>> Maybe having a xml feature descriptor referenced at
>>>>>>>>> http://karaf.apache.org/features/repository.xml which would point to
>>>>>>>>> various other repositories (such as camel, cxf, servicemix, web,
>>>>>>>>> aries, etc...) is more scalable as we would not have to release a new
>>>>>>>>> karaf container each time one of those things change.  People may want
>>>>>>>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>>>>>>>>> things in Karaf trunk as this would create unnecessary ties between
>>>>>>>>> the projects and Karaf.
>>>>>>>>>
>>>>>>>>> Once we have that, we should keep Karaf main distribution clean and
>>>>>>>>> lean and provide all the optional bits using this way.   Combined with
>>>>>>>>> an easy way to create custom distribution, I do think that's the way
>>>>>>>>> to go.
>>>>>>>>>
>>>>>>>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
>>>>>>>>>   wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think that's what we are working on already as part of 3.0, so not
>>>>>>>>>>> sure if I really understand what you mean here.
>>>>>>>>>>>
>>>>>>>>>> I see clustering to be part of the core karaf distribution. By that I
>>>>>>>>>> mean
>>>>>>>>>> that the clustering solution should be provided as a feature inside
>>>>> the
>>>>>>>>>> standard feature repository.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Ioannis Canellos*
>>>>>>>>>> *
>>>>>>>>>>   http://iocanel.blogspot.com
>>>>>>>>>>
>>>>>>>>>> Apache Karaf<http://karaf.apache.org/>      Committer&      PMC
>>>>>>>>>> Apache ServiceMix<http://servicemix.apache.org/>        Committer
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> ----
>>>>>>>> http://www.liquid-reality.de
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ----
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>> Connect at CamelOne May 24-26
>>>>> The Open Source Integration Conference
>>>>> http://camelone.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Ioannis Canellos*
>>>> *
>>>>   http://iocanel.blogspot.com
>>>>
>>>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>>>> Apache ServiceMix<http://servicemix.apache.org/>    Committer
>>>> *
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>> Connect at CamelOne May 24-26
>>> The Open Source Integration Conference
>>> http://camelone.com/
>>>
>>
>>
>>
>> --
>> --
>> *Achim Nierbeck*
>>
>>
>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>> OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer&  Project Lead
>>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Andreas Pieber <an...@gmail.com>.

Absolutely; in addition I think we should make the "central repository
feature" a must have for 3.x

Kind regards,
Andreas

On Wed, May 4, 2011 at 2:09 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> 2011/5/4 Guillaume Nodet <gn...@gmail.com>:
>> On Wed, May 4, 2011 at 14:01, Ioannis Canellos <io...@gmail.com> wrote:
>>> Guys, we are getting off topic.
>>>
>>> Even though I like Guillaume's ideas about central repository etc, it is
>>> still hypothetical since the mechanism is not implemented yet and thus we
>>> can't base our decisions on that.
>>
>> I think we already have everything.  It's just a matter of writing
>> those xml descriptors and managing those.
>> I think we should get that in place for 3.0 if possible.
>
> yep, let's get 2.2.1 out fast and get into that one :)
>
>>
>>> What we currently have is standard/enterprise features descriptor. What I am
>>> saying is that clustering should be part of the enterprise features
>>> descriptor *(and probably hosted as subproject)*. Once we implement the
>>> central repository mechanism we can move it there.
>>
>> I think the enterprise descriptor should be pushed back to Aries
>> actually.  It's a more natural home for it imho.
>
>
>>
>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>>> I think you misundertand me.
>>>> When camel 2.8.1 would be released, we'd just add the url to the global
>>>> file at
>>>>   http://karaf.apache.org/features/repository.xml
>>>>
>>>> Users could then install the updated feature as it would be
>>>> automatically available.
>>>>
>>>> On Wed, May 4, 2011 at 13:42, Christian Schneider
>>>> <ch...@die-schneider.net> wrote:
>>>> > The problem with listing all versions is that you can not work with newer
>>>> > version of e.g. camel. Imagine you have karaf working with camel 2.8.0.
>>>> Then
>>>> > you have a bug which is fixed in camel 2.8.1. Then you will want to
>>>> easily
>>>> > use camel 2.8.1 without waiting for a new karaf release.
>>>> >
>>>> > I think it would be better to scan for available versions on the maven
>>>> repo
>>>> > and warn if the user tries to install a version that was not tested. And
>>>> > honestly we will not be able to test all those combinations anyway.
>>>> >
>>>> > Christian
>>>> >
>>>> >
>>>> > Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>>>> >>
>>>> >> In that central xml, we can refer to multiple versions of the same
>>>> >> feature descriptor:
>>>> >>
>>>> >> <features>
>>>> >>
>>>> >>
>>>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>>>> >>
>>>> >>
>>>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>>>> >>  ...
>>>> >> </features>
>>>> >>
>>>> >> I think we'd need a descriptor for each minor version of Karaf so that
>>>> >> we can make sure only features that have been tested on a given karaf
>>>> >> version are available.
>>>> >>
>>>> >> On Wed, May 4, 2011 at 13:28, Christian Schneider
>>>> >> <ch...@die-schneider.net>  wrote:
>>>> >>>
>>>> >>> I also think a small karaf with the easy possibility to create custom
>>>> >>> distros is the way to go.
>>>> >>> A central list of pointers to repository files makes sense. But we have
>>>> >>> to
>>>> >>> do this a bit different than the current feature files. Currently a url
>>>> >>> to a
>>>> >>> feature file always points to a certain version of that file. For a
>>>> >>> central
>>>> >>> list this does not make sense.
>>>> >>>
>>>> >>> So I think we rather need a list of the base urls without version and
>>>> >>> then
>>>> >>> an easy way for users to install a feature file with a certain version.
>>>> >>> So
>>>> >>> for example to install the feature url for camel the user should be
>>>> able
>>>> >>> to
>>>> >>> write something like:
>>>> >>> features:addurl camel 2.7.0
>>>> >>>
>>>> >>> Do we already have support for this or something similar? Or do we have
>>>> >>> an
>>>> >>> issue for it? If not I can create one.
>>>> >>>
>>>> >>> Christian
>>>> >>>
>>>> >>>
>>>> >>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>>> >>>>
>>>> >>>> I think we need a way to enable user to install other features easily
>>>> >>>> without having to release karaf for that.
>>>> >>>> It just does not scale if we have to release Karaf because Camel as
>>>> >>>> released a new version for example.
>>>> >>>> We've already discussed that some time ago and I think we need to find
>>>> >>>> a good technical solution for that.
>>>> >>>> Maybe having a xml feature descriptor referenced at
>>>> >>>> http://karaf.apache.org/features/repository.xml which would point to
>>>> >>>> various other repositories (such as camel, cxf, servicemix, web,
>>>> >>>> aries, etc...) is more scalable as we would not have to release a new
>>>> >>>> karaf container each time one of those things change.  People may want
>>>> >>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>>>> >>>> things in Karaf trunk as this would create unnecessary ties between
>>>> >>>> the projects and Karaf.
>>>> >>>>
>>>> >>>> Once we have that, we should keep Karaf main distribution clean and
>>>> >>>> lean and provide all the optional bits using this way.   Combined with
>>>> >>>> an easy way to create custom distribution, I do think that's the way
>>>> >>>> to go.
>>>> >>>>
>>>> >>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
>>>> >>>>  wrote:
>>>> >>>>>>
>>>> >>>>>> I think that's what we are working on already as part of 3.0, so not
>>>> >>>>>> sure if I really understand what you mean here.
>>>> >>>>>>
>>>> >>>>> I see clustering to be part of the core karaf distribution. By that I
>>>> >>>>> mean
>>>> >>>>> that the clustering solution should be provided as a feature inside
>>>> the
>>>> >>>>> standard feature repository.
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> *Ioannis Canellos*
>>>> >>>>> *
>>>> >>>>>  http://iocanel.blogspot.com
>>>> >>>>>
>>>> >>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>>>> >>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>>>> >>>>> *
>>>> >>>>>
>>>> >>>>
>>>> >>> --
>>>> >>> ----
>>>> >>> http://www.liquid-reality.de
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>> > --
>>>> > ----
>>>> > http://www.liquid-reality.de
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>> Connect at CamelOne May 24-26
>>>> The Open Source Integration Conference
>>>> http://camelone.com/
>>>>
>>>
>>>
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>>  http://iocanel.blogspot.com
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> Apache ServiceMix <http://servicemix.apache.org/>  Committer
>>> *
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> Connect at CamelOne May 24-26
>> The Open Source Integration Conference
>> http://camelone.com/
>>
>
>
>
> --
> --
> *Achim Nierbeck*
>
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Achim Nierbeck <bc...@googlemail.com>.

2011/5/4 Guillaume Nodet <gn...@gmail.com>:
> On Wed, May 4, 2011 at 14:01, Ioannis Canellos <io...@gmail.com> wrote:
>> Guys, we are getting off topic.
>>
>> Even though I like Guillaume's ideas about central repository etc, it is
>> still hypothetical since the mechanism is not implemented yet and thus we
>> can't base our decisions on that.
>
> I think we already have everything.  It's just a matter of writing
> those xml descriptors and managing those.
> I think we should get that in place for 3.0 if possible.

yep, let's get 2.2.1 out fast and get into that one :)

>
>> What we currently have is standard/enterprise features descriptor. What I am
>> saying is that clustering should be part of the enterprise features
>> descriptor *(and probably hosted as subproject)*. Once we implement the
>> central repository mechanism we can move it there.
>
> I think the enterprise descriptor should be pushed back to Aries
> actually.  It's a more natural home for it imho.


>
>> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>
>>> I think you misundertand me.
>>> When camel 2.8.1 would be released, we'd just add the url to the global
>>> file at
>>>   http://karaf.apache.org/features/repository.xml
>>>
>>> Users could then install the updated feature as it would be
>>> automatically available.
>>>
>>> On Wed, May 4, 2011 at 13:42, Christian Schneider
>>> <ch...@die-schneider.net> wrote:
>>> > The problem with listing all versions is that you can not work with newer
>>> > version of e.g. camel. Imagine you have karaf working with camel 2.8.0.
>>> Then
>>> > you have a bug which is fixed in camel 2.8.1. Then you will want to
>>> easily
>>> > use camel 2.8.1 without waiting for a new karaf release.
>>> >
>>> > I think it would be better to scan for available versions on the maven
>>> repo
>>> > and warn if the user tries to install a version that was not tested. And
>>> > honestly we will not be able to test all those combinations anyway.
>>> >
>>> > Christian
>>> >
>>> >
>>> > Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>>> >>
>>> >> In that central xml, we can refer to multiple versions of the same
>>> >> feature descriptor:
>>> >>
>>> >> <features>
>>> >>
>>> >>
>>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>>> >>
>>> >>
>>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>>> >>  ...
>>> >> </features>
>>> >>
>>> >> I think we'd need a descriptor for each minor version of Karaf so that
>>> >> we can make sure only features that have been tested on a given karaf
>>> >> version are available.
>>> >>
>>> >> On Wed, May 4, 2011 at 13:28, Christian Schneider
>>> >> <ch...@die-schneider.net>  wrote:
>>> >>>
>>> >>> I also think a small karaf with the easy possibility to create custom
>>> >>> distros is the way to go.
>>> >>> A central list of pointers to repository files makes sense. But we have
>>> >>> to
>>> >>> do this a bit different than the current feature files. Currently a url
>>> >>> to a
>>> >>> feature file always points to a certain version of that file. For a
>>> >>> central
>>> >>> list this does not make sense.
>>> >>>
>>> >>> So I think we rather need a list of the base urls without version and
>>> >>> then
>>> >>> an easy way for users to install a feature file with a certain version.
>>> >>> So
>>> >>> for example to install the feature url for camel the user should be
>>> able
>>> >>> to
>>> >>> write something like:
>>> >>> features:addurl camel 2.7.0
>>> >>>
>>> >>> Do we already have support for this or something similar? Or do we have
>>> >>> an
>>> >>> issue for it? If not I can create one.
>>> >>>
>>> >>> Christian
>>> >>>
>>> >>>
>>> >>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>> >>>>
>>> >>>> I think we need a way to enable user to install other features easily
>>> >>>> without having to release karaf for that.
>>> >>>> It just does not scale if we have to release Karaf because Camel as
>>> >>>> released a new version for example.
>>> >>>> We've already discussed that some time ago and I think we need to find
>>> >>>> a good technical solution for that.
>>> >>>> Maybe having a xml feature descriptor referenced at
>>> >>>> http://karaf.apache.org/features/repository.xml which would point to
>>> >>>> various other repositories (such as camel, cxf, servicemix, web,
>>> >>>> aries, etc...) is more scalable as we would not have to release a new
>>> >>>> karaf container each time one of those things change.  People may want
>>> >>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>>> >>>> things in Karaf trunk as this would create unnecessary ties between
>>> >>>> the projects and Karaf.
>>> >>>>
>>> >>>> Once we have that, we should keep Karaf main distribution clean and
>>> >>>> lean and provide all the optional bits using this way.   Combined with
>>> >>>> an easy way to create custom distribution, I do think that's the way
>>> >>>> to go.
>>> >>>>
>>> >>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
>>> >>>>  wrote:
>>> >>>>>>
>>> >>>>>> I think that's what we are working on already as part of 3.0, so not
>>> >>>>>> sure if I really understand what you mean here.
>>> >>>>>>
>>> >>>>> I see clustering to be part of the core karaf distribution. By that I
>>> >>>>> mean
>>> >>>>> that the clustering solution should be provided as a feature inside
>>> the
>>> >>>>> standard feature repository.
>>> >>>>>
>>> >>>>> --
>>> >>>>> *Ioannis Canellos*
>>> >>>>> *
>>> >>>>>  http://iocanel.blogspot.com
>>> >>>>>
>>> >>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>>> >>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>>> >>>>> *
>>> >>>>>
>>> >>>>
>>> >>> --
>>> >>> ----
>>> >>> http://www.liquid-reality.de
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> > --
>>> > ----
>>> > http://www.liquid-reality.de
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>> Connect at CamelOne May 24-26
>>> The Open Source Integration Conference
>>> http://camelone.com/
>>>
>>
>>
>>
>> --
>> *Ioannis Canellos*
>> *
>>  http://iocanel.blogspot.com
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> Apache ServiceMix <http://servicemix.apache.org/>  Committer
>> *
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com/
>



-- 
--
*Achim Nierbeck*


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

Ok, then we can have it to the standard features descriptor.

On Wed, May 4, 2011 at 3:06 PM, Guillaume Nodet <gn...@gmail.com> wrote:

> On Wed, May 4, 2011 at 14:01, Ioannis Canellos <io...@gmail.com> wrote:
> > Guys, we are getting off topic.
> >
> > Even though I like Guillaume's ideas about central repository etc, it is
> > still hypothetical since the mechanism is not implemented yet and thus we
> > can't base our decisions on that.
>
> I think we already have everything.  It's just a matter of writing
> those xml descriptors and managing those.
> I think we should get that in place for 3.0 if possible.
>
> > What we currently have is standard/enterprise features descriptor. What I
> am
> > saying is that clustering should be part of the enterprise features
> > descriptor *(and probably hosted as subproject)*. Once we implement the
> > central repository mechanism we can move it there.
>
> I think the enterprise descriptor should be pushed back to Aries
> actually.  It's a more natural home for it imho.
>
> > On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> >
> >> I think you misundertand me.
> >> When camel 2.8.1 would be released, we'd just add the url to the global
> >> file at
> >>   http://karaf.apache.org/features/repository.xml
> >>
> >> Users could then install the updated feature as it would be
> >> automatically available.
> >>
> >> On Wed, May 4, 2011 at 13:42, Christian Schneider
> >> <ch...@die-schneider.net> wrote:
> >> > The problem with listing all versions is that you can not work with
> newer
> >> > version of e.g. camel. Imagine you have karaf working with camel
> 2.8.0.
> >> Then
> >> > you have a bug which is fixed in camel 2.8.1. Then you will want to
> >> easily
> >> > use camel 2.8.1 without waiting for a new karaf release.
> >> >
> >> > I think it would be better to scan for available versions on the maven
> >> repo
> >> > and warn if the user tries to install a version that was not tested.
> And
> >> > honestly we will not be able to test all those combinations anyway.
> >> >
> >> > Christian
> >> >
> >> >
> >> > Am 04.05.2011 13:34, schrieb Guillaume Nodet:
> >> >>
> >> >> In that central xml, we can refer to multiple versions of the same
> >> >> feature descriptor:
> >> >>
> >> >> <features>
> >> >>
> >> >>
> >>
> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
> >> >>
> >> >>
> >>
> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
> >> >>  ...
> >> >> </features>
> >> >>
> >> >> I think we'd need a descriptor for each minor version of Karaf so
> that
> >> >> we can make sure only features that have been tested on a given karaf
> >> >> version are available.
> >> >>
> >> >> On Wed, May 4, 2011 at 13:28, Christian Schneider
> >> >> <ch...@die-schneider.net>  wrote:
> >> >>>
> >> >>> I also think a small karaf with the easy possibility to create
> custom
> >> >>> distros is the way to go.
> >> >>> A central list of pointers to repository files makes sense. But we
> have
> >> >>> to
> >> >>> do this a bit different than the current feature files. Currently a
> url
> >> >>> to a
> >> >>> feature file always points to a certain version of that file. For a
> >> >>> central
> >> >>> list this does not make sense.
> >> >>>
> >> >>> So I think we rather need a list of the base urls without version
> and
> >> >>> then
> >> >>> an easy way for users to install a feature file with a certain
> version.
> >> >>> So
> >> >>> for example to install the feature url for camel the user should be
> >> able
> >> >>> to
> >> >>> write something like:
> >> >>> features:addurl camel 2.7.0
> >> >>>
> >> >>> Do we already have support for this or something similar? Or do we
> have
> >> >>> an
> >> >>> issue for it? If not I can create one.
> >> >>>
> >> >>> Christian
> >> >>>
> >> >>>
> >> >>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
> >> >>>>
> >> >>>> I think we need a way to enable user to install other features
> easily
> >> >>>> without having to release karaf for that.
> >> >>>> It just does not scale if we have to release Karaf because Camel as
> >> >>>> released a new version for example.
> >> >>>> We've already discussed that some time ago and I think we need to
> find
> >> >>>> a good technical solution for that.
> >> >>>> Maybe having a xml feature descriptor referenced at
> >> >>>> http://karaf.apache.org/features/repository.xml which would point
> to
> >> >>>> various other repositories (such as camel, cxf, servicemix, web,
> >> >>>> aries, etc...) is more scalable as we would not have to release a
> new
> >> >>>> karaf container each time one of those things change.  People may
> want
> >> >>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all
> those
> >> >>>> things in Karaf trunk as this would create unnecessary ties between
> >> >>>> the projects and Karaf.
> >> >>>>
> >> >>>> Once we have that, we should keep Karaf main distribution clean and
> >> >>>> lean and provide all the optional bits using this way.   Combined
> with
> >> >>>> an easy way to create custom distribution, I do think that's the
> way
> >> >>>> to go.
> >> >>>>
> >> >>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
> >> >>>>  wrote:
> >> >>>>>>
> >> >>>>>> I think that's what we are working on already as part of 3.0, so
> not
> >> >>>>>> sure if I really understand what you mean here.
> >> >>>>>>
> >> >>>>> I see clustering to be part of the core karaf distribution. By
> that I
> >> >>>>> mean
> >> >>>>> that the clustering solution should be provided as a feature
> inside
> >> the
> >> >>>>> standard feature repository.
> >> >>>>>
> >> >>>>> --
> >> >>>>> *Ioannis Canellos*
> >> >>>>> *
> >> >>>>>  http://iocanel.blogspot.com
> >> >>>>>
> >> >>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
> >> >>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
> >> >>>>> *
> >> >>>>>
> >> >>>>
> >> >>> --
> >> >>> ----
> >> >>> http://www.liquid-reality.de
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> > --
> >> > ----
> >> > http://www.liquid-reality.de
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >> Connect at CamelOne May 24-26
> >> The Open Source Integration Conference
> >> http://camelone.com/
> >>
> >
> >
> >
> > --
> > *Ioannis Canellos*
> > *
> >  http://iocanel.blogspot.com
> >
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > Apache ServiceMix <http://servicemix.apache.org/>  Committer
> > *
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com/
>



-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

On Wed, May 4, 2011 at 14:01, Ioannis Canellos <io...@gmail.com> wrote:
> Guys, we are getting off topic.
>
> Even though I like Guillaume's ideas about central repository etc, it is
> still hypothetical since the mechanism is not implemented yet and thus we
> can't base our decisions on that.

I think we already have everything.  It's just a matter of writing
those xml descriptors and managing those.
I think we should get that in place for 3.0 if possible.

> What we currently have is standard/enterprise features descriptor. What I am
> saying is that clustering should be part of the enterprise features
> descriptor *(and probably hosted as subproject)*. Once we implement the
> central repository mechanism we can move it there.

I think the enterprise descriptor should be pushed back to Aries
actually.  It's a more natural home for it imho.

> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> I think you misundertand me.
>> When camel 2.8.1 would be released, we'd just add the url to the global
>> file at
>>   http://karaf.apache.org/features/repository.xml
>>
>> Users could then install the updated feature as it would be
>> automatically available.
>>
>> On Wed, May 4, 2011 at 13:42, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>> > The problem with listing all versions is that you can not work with newer
>> > version of e.g. camel. Imagine you have karaf working with camel 2.8.0.
>> Then
>> > you have a bug which is fixed in camel 2.8.1. Then you will want to
>> easily
>> > use camel 2.8.1 without waiting for a new karaf release.
>> >
>> > I think it would be better to scan for available versions on the maven
>> repo
>> > and warn if the user tries to install a version that was not tested. And
>> > honestly we will not be able to test all those combinations anyway.
>> >
>> > Christian
>> >
>> >
>> > Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>> >>
>> >> In that central xml, we can refer to multiple versions of the same
>> >> feature descriptor:
>> >>
>> >> <features>
>> >>
>> >>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>> >>
>> >>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>> >>  ...
>> >> </features>
>> >>
>> >> I think we'd need a descriptor for each minor version of Karaf so that
>> >> we can make sure only features that have been tested on a given karaf
>> >> version are available.
>> >>
>> >> On Wed, May 4, 2011 at 13:28, Christian Schneider
>> >> <ch...@die-schneider.net>  wrote:
>> >>>
>> >>> I also think a small karaf with the easy possibility to create custom
>> >>> distros is the way to go.
>> >>> A central list of pointers to repository files makes sense. But we have
>> >>> to
>> >>> do this a bit different than the current feature files. Currently a url
>> >>> to a
>> >>> feature file always points to a certain version of that file. For a
>> >>> central
>> >>> list this does not make sense.
>> >>>
>> >>> So I think we rather need a list of the base urls without version and
>> >>> then
>> >>> an easy way for users to install a feature file with a certain version.
>> >>> So
>> >>> for example to install the feature url for camel the user should be
>> able
>> >>> to
>> >>> write something like:
>> >>> features:addurl camel 2.7.0
>> >>>
>> >>> Do we already have support for this or something similar? Or do we have
>> >>> an
>> >>> issue for it? If not I can create one.
>> >>>
>> >>> Christian
>> >>>
>> >>>
>> >>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>> >>>>
>> >>>> I think we need a way to enable user to install other features easily
>> >>>> without having to release karaf for that.
>> >>>> It just does not scale if we have to release Karaf because Camel as
>> >>>> released a new version for example.
>> >>>> We've already discussed that some time ago and I think we need to find
>> >>>> a good technical solution for that.
>> >>>> Maybe having a xml feature descriptor referenced at
>> >>>> http://karaf.apache.org/features/repository.xml which would point to
>> >>>> various other repositories (such as camel, cxf, servicemix, web,
>> >>>> aries, etc...) is more scalable as we would not have to release a new
>> >>>> karaf container each time one of those things change.  People may want
>> >>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>> >>>> things in Karaf trunk as this would create unnecessary ties between
>> >>>> the projects and Karaf.
>> >>>>
>> >>>> Once we have that, we should keep Karaf main distribution clean and
>> >>>> lean and provide all the optional bits using this way.   Combined with
>> >>>> an easy way to create custom distribution, I do think that's the way
>> >>>> to go.
>> >>>>
>> >>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
>> >>>>  wrote:
>> >>>>>>
>> >>>>>> I think that's what we are working on already as part of 3.0, so not
>> >>>>>> sure if I really understand what you mean here.
>> >>>>>>
>> >>>>> I see clustering to be part of the core karaf distribution. By that I
>> >>>>> mean
>> >>>>> that the clustering solution should be provided as a feature inside
>> the
>> >>>>> standard feature repository.
>> >>>>>
>> >>>>> --
>> >>>>> *Ioannis Canellos*
>> >>>>> *
>> >>>>>  http://iocanel.blogspot.com
>> >>>>>
>> >>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>> >>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>> >>>>> *
>> >>>>>
>> >>>>
>> >>> --
>> >>> ----
>> >>> http://www.liquid-reality.de
>> >>>
>> >>>
>> >>
>> >>
>> >
>> > --
>> > ----
>> > http://www.liquid-reality.de
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> Connect at CamelOne May 24-26
>> The Open Source Integration Conference
>> http://camelone.com/
>>
>
>
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by mikevan <mv...@comcast.net>.

Andreas Pieber wrote:
> 
> In fact I think we should take a look how far we really want to break
> down the various components. What really should be extracted. Although
> there are various possibilities to split Karaf I would roughly suggest
> something like: management, web, clustering, spring (to finally get
> the spring things out of the "real" core :)). Since there are 13 PMCs
> (if Jamie stays at releasing karaf-core there are still 12 remaining)
> I think it should be possible to find 4 PMCs willing to take over the
> release process for those components. I have no problem taking one
> myself (which means 3 remaining :))...
> 
> Kind regards,
> Andreas
> 
> On Wed, May 4, 2011 at 6:30 PM, Jamie G. &lt;jamie.goodyear@gmail.com&gt;
> wrote:
>> The website just requires committer status.
>>
>> According to this a PMC is 'preferred', as the PMCs are responsible
>> for their projects distribution directory at Apache.
>> http://www.apache.org/dev/release.html#what-must-every-release-contain
>>
>>
>> Cheers,
>> Jamie
>>
>> On Wed, May 4, 2011 at 1:49 PM, mikevan &lt;mvangeertruy@comcast.net&gt;
>> wrote:
>>>
>>> jgoodyear wrote:
>>>>
>>>> As a reminder our release process is posted here:
>>>> http://karaf.apache.org/index/developers/release-guide.html
>>>>
>>>> To my knowledge those instructions should be sufficient to allow
>>>> anyone the ability to perform a Karaf release, the only caveat I
>>>> believe is that they have committer status as its required to perform
>>>> tags & uploads (not sure if PMC is required or not when it comes to
>>>> nexus).
>>>>
>>>> Cheers,
>>>> Jamie
>>>>
>>>> On Wed, May 4, 2011 at 1:13 PM, Jamie G.
>>>> &lt;jamie.goodyear@gmail.com&gt;
>>>> wrote:
>>>>> Very true Mike. I've been picking up release duties as required. I
>>>>> have no claim at all to doing them other than if/when I'm actively
>>>>> assigned and working upon a particular release Jira task.
>>>>>
>>>>> Cheers,
>>>>> Jamie
>>>>>
>>>>> On Wed, May 4, 2011 at 1:04 PM, mikevan
>>>>> &lt;mvangeertruy@comcast.net&gt;
>>>>> wrote:
>>>>>>
>>>>>> Christian Schneider wrote:
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I think clustering is important enough to be part of the enterprise
>>>>>>> features.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>>>>>>> Guys, we are getting off topic.
>>>>>>>>
>>>>>>>> Even though I like Guillaume's ideas about central repository etc,
>>>>>>>> it
>>>>>>>> is
>>>>>>>> still hypothetical since the mechanism is not implemented yet and
>>>>>>>> thus
>>>>>>>> we
>>>>>>>> can't base our decisions on that.
>>>>>>>>
>>>>>>>> What we currently have is standard/enterprise features descriptor.
>>>>>>>> What I
>>>>>>>> am
>>>>>>>> saying is that clustering should be part of the enterprise features
>>>>>>>> descriptor *(and probably hosted as subproject)*. Once we implement
>>>>>>>> the
>>>>>>>> central repository mechanism we can move it there.
>>>>>>>>
>>>>>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume
>>>>>>>> Nodet&lt;gnodet@gmail.com&gt;
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ----
>>>>>>> http://www.liquid-reality.de
>>>>>>>
>>>>>>
>>>>>> Subprojects sounds like a good idea on the face, but it really comes
>>>>>> down to
>>>>>> a management issue.  Who is going to be responsible for each
>>>>>> sub-project?
>>>>>> Right now we have a few folks who are working on Karaf in addition to
>>>>>> other
>>>>>> open-source projects.  IMHO, we should not have a sub-project unless
>>>>>> we
>>>>>> have
>>>>>> someone willing to be responsible for it.  I also don't think Jamie
>>>>>> should
>>>>>> be that one person for all sub-projects.  However, if we can get
>>>>>> folks
>>>>>> to
>>>>>> accept responsiblity for them, I think its a great idea.
>>>>>>
>>>>>> -----
>>>>>> Mike Van (aka karafman)
>>>>>> Karaf Team (Contributor)
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
>>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>
>>> Hmm.. I thought PMC was required for a release, or is that just for the
>>> site?
>>>
>>> -----
>>> Mike Van (aka karafman)
>>> Karaf Team (Contributor)
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899495.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
> 

Is this different than what Guillaume originally suggested?  The original
suggestion seemed aimed more at creating customer distributions of Karaf,
and this seems like breaking up optional functionality into subprojects... 
I'm a tad confused.

-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899744.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by mikevan <mv...@comcast.net>.

iocanel wrote:
> 
> I guess I could take on clustering.
> 
> 
> -- 
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
> 
> Apache Karaf &lt;http://karaf.apache.org/&gt; Committer & PMC
> Apache ServiceMix &lt;http://servicemix.apache.org/&gt;  Committer
> *
> 

I'm always ready to help verify the releases!  :-)

-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899734.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

I guess I could take on clustering.


-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Andreas Pieber <an...@gmail.com>.

In fact I think we should take a look how far we really want to break
down the various components. What really should be extracted. Although
there are various possibilities to split Karaf I would roughly suggest
something like: management, web, clustering, spring (to finally get
the spring things out of the "real" core :)). Since there are 13 PMCs
(if Jamie stays at releasing karaf-core there are still 12 remaining)
I think it should be possible to find 4 PMCs willing to take over the
release process for those components. I have no problem taking one
myself (which means 3 remaining :))...

Kind regards,
Andreas

On Wed, May 4, 2011 at 6:30 PM, Jamie G. <ja...@gmail.com> wrote:
> The website just requires committer status.
>
> According to this a PMC is 'preferred', as the PMCs are responsible
> for their projects distribution directory at Apache.
> http://www.apache.org/dev/release.html#what-must-every-release-contain
>
>
> Cheers,
> Jamie
>
> On Wed, May 4, 2011 at 1:49 PM, mikevan <mv...@comcast.net> wrote:
>>
>> jgoodyear wrote:
>>>
>>> As a reminder our release process is posted here:
>>> http://karaf.apache.org/index/developers/release-guide.html
>>>
>>> To my knowledge those instructions should be sufficient to allow
>>> anyone the ability to perform a Karaf release, the only caveat I
>>> believe is that they have committer status as its required to perform
>>> tags & uploads (not sure if PMC is required or not when it comes to
>>> nexus).
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Wed, May 4, 2011 at 1:13 PM, Jamie G. &lt;jamie.goodyear@gmail.com&gt;
>>> wrote:
>>>> Very true Mike. I've been picking up release duties as required. I
>>>> have no claim at all to doing them other than if/when I'm actively
>>>> assigned and working upon a particular release Jira task.
>>>>
>>>> Cheers,
>>>> Jamie
>>>>
>>>> On Wed, May 4, 2011 at 1:04 PM, mikevan &lt;mvangeertruy@comcast.net&gt;
>>>> wrote:
>>>>>
>>>>> Christian Schneider wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> I think clustering is important enough to be part of the enterprise
>>>>>> features.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>>>>>> Guys, we are getting off topic.
>>>>>>>
>>>>>>> Even though I like Guillaume's ideas about central repository etc, it
>>>>>>> is
>>>>>>> still hypothetical since the mechanism is not implemented yet and thus
>>>>>>> we
>>>>>>> can't base our decisions on that.
>>>>>>>
>>>>>>> What we currently have is standard/enterprise features descriptor.
>>>>>>> What I
>>>>>>> am
>>>>>>> saying is that clustering should be part of the enterprise features
>>>>>>> descriptor *(and probably hosted as subproject)*. Once we implement
>>>>>>> the
>>>>>>> central repository mechanism we can move it there.
>>>>>>>
>>>>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume
>>>>>>> Nodet&lt;gnodet@gmail.com&gt;
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ----
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>
>>>>> Subprojects sounds like a good idea on the face, but it really comes
>>>>> down to
>>>>> a management issue.  Who is going to be responsible for each
>>>>> sub-project?
>>>>> Right now we have a few folks who are working on Karaf in addition to
>>>>> other
>>>>> open-source projects.  IMHO, we should not have a sub-project unless we
>>>>> have
>>>>> someone willing to be responsible for it.  I also don't think Jamie
>>>>> should
>>>>> be that one person for all sub-projects.  However, if we can get folks
>>>>> to
>>>>> accept responsiblity for them, I think its a great idea.
>>>>>
>>>>> -----
>>>>> Mike Van (aka karafman)
>>>>> Karaf Team (Contributor)
>>>>> --
>>>>> View this message in context:
>>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>
>> Hmm.. I thought PMC was required for a release, or is that just for the
>> site?
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899495.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by "Jamie G." <ja...@gmail.com>.

The website just requires committer status.

According to this a PMC is 'preferred', as the PMCs are responsible
for their projects distribution directory at Apache.
http://www.apache.org/dev/release.html#what-must-every-release-contain


Cheers,
Jamie

On Wed, May 4, 2011 at 1:49 PM, mikevan <mv...@comcast.net> wrote:
>
> jgoodyear wrote:
>>
>> As a reminder our release process is posted here:
>> http://karaf.apache.org/index/developers/release-guide.html
>>
>> To my knowledge those instructions should be sufficient to allow
>> anyone the ability to perform a Karaf release, the only caveat I
>> believe is that they have committer status as its required to perform
>> tags & uploads (not sure if PMC is required or not when it comes to
>> nexus).
>>
>> Cheers,
>> Jamie
>>
>> On Wed, May 4, 2011 at 1:13 PM, Jamie G. &lt;jamie.goodyear@gmail.com&gt;
>> wrote:
>>> Very true Mike. I've been picking up release duties as required. I
>>> have no claim at all to doing them other than if/when I'm actively
>>> assigned and working upon a particular release Jira task.
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Wed, May 4, 2011 at 1:04 PM, mikevan &lt;mvangeertruy@comcast.net&gt;
>>> wrote:
>>>>
>>>> Christian Schneider wrote:
>>>>>
>>>>> +1
>>>>>
>>>>> I think clustering is important enough to be part of the enterprise
>>>>> features.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>>>>> Guys, we are getting off topic.
>>>>>>
>>>>>> Even though I like Guillaume's ideas about central repository etc, it
>>>>>> is
>>>>>> still hypothetical since the mechanism is not implemented yet and thus
>>>>>> we
>>>>>> can't base our decisions on that.
>>>>>>
>>>>>> What we currently have is standard/enterprise features descriptor.
>>>>>> What I
>>>>>> am
>>>>>> saying is that clustering should be part of the enterprise features
>>>>>> descriptor *(and probably hosted as subproject)*. Once we implement
>>>>>> the
>>>>>> central repository mechanism we can move it there.
>>>>>>
>>>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume
>>>>>> Nodet&lt;gnodet@gmail.com&gt;
>>>>>> wrote:
>>>>>>
>>>>>
>>>>> --
>>>>> ----
>>>>> http://www.liquid-reality.de
>>>>>
>>>>
>>>> Subprojects sounds like a good idea on the face, but it really comes
>>>> down to
>>>> a management issue.  Who is going to be responsible for each
>>>> sub-project?
>>>> Right now we have a few folks who are working on Karaf in addition to
>>>> other
>>>> open-source projects.  IMHO, we should not have a sub-project unless we
>>>> have
>>>> someone willing to be responsible for it.  I also don't think Jamie
>>>> should
>>>> be that one person for all sub-projects.  However, if we can get folks
>>>> to
>>>> accept responsiblity for them, I think its a great idea.
>>>>
>>>> -----
>>>> Mike Van (aka karafman)
>>>> Karaf Team (Contributor)
>>>> --
>>>> View this message in context:
>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>
> Hmm.. I thought PMC was required for a release, or is that just for the
> site?
>
> -----
> Mike Van (aka karafman)
> Karaf Team (Contributor)
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899495.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by mikevan <mv...@comcast.net>.

jgoodyear wrote:
> 
> As a reminder our release process is posted here:
> http://karaf.apache.org/index/developers/release-guide.html
> 
> To my knowledge those instructions should be sufficient to allow
> anyone the ability to perform a Karaf release, the only caveat I
> believe is that they have committer status as its required to perform
> tags & uploads (not sure if PMC is required or not when it comes to
> nexus).
> 
> Cheers,
> Jamie
> 
> On Wed, May 4, 2011 at 1:13 PM, Jamie G. &lt;jamie.goodyear@gmail.com&gt;
> wrote:
>> Very true Mike. I've been picking up release duties as required. I
>> have no claim at all to doing them other than if/when I'm actively
>> assigned and working upon a particular release Jira task.
>>
>> Cheers,
>> Jamie
>>
>> On Wed, May 4, 2011 at 1:04 PM, mikevan &lt;mvangeertruy@comcast.net&gt;
>> wrote:
>>>
>>> Christian Schneider wrote:
>>>>
>>>> +1
>>>>
>>>> I think clustering is important enough to be part of the enterprise
>>>> features.
>>>>
>>>> Christian
>>>>
>>>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>>>> Guys, we are getting off topic.
>>>>>
>>>>> Even though I like Guillaume's ideas about central repository etc, it
>>>>> is
>>>>> still hypothetical since the mechanism is not implemented yet and thus
>>>>> we
>>>>> can't base our decisions on that.
>>>>>
>>>>> What we currently have is standard/enterprise features descriptor.
>>>>> What I
>>>>> am
>>>>> saying is that clustering should be part of the enterprise features
>>>>> descriptor *(and probably hosted as subproject)*. Once we implement
>>>>> the
>>>>> central repository mechanism we can move it there.
>>>>>
>>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume
>>>>> Nodet&lt;gnodet@gmail.com&gt;
>>>>> wrote:
>>>>>
>>>>
>>>> --
>>>> ----
>>>> http://www.liquid-reality.de
>>>>
>>>
>>> Subprojects sounds like a good idea on the face, but it really comes
>>> down to
>>> a management issue.  Who is going to be responsible for each
>>> sub-project?
>>> Right now we have a few folks who are working on Karaf in addition to
>>> other
>>> open-source projects.  IMHO, we should not have a sub-project unless we
>>> have
>>> someone willing to be responsible for it.  I also don't think Jamie
>>> should
>>> be that one person for all sub-projects.  However, if we can get folks
>>> to
>>> accept responsiblity for them, I think its a great idea.
>>>
>>> -----
>>> Mike Van (aka karafman)
>>> Karaf Team (Contributor)
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
> 
Hmm.. I thought PMC was required for a release, or is that just for the
site?

-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899495.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by "Jamie G." <ja...@gmail.com>.

As a reminder our release process is posted here:
http://karaf.apache.org/index/developers/release-guide.html

To my knowledge those instructions should be sufficient to allow
anyone the ability to perform a Karaf release, the only caveat I
believe is that they have committer status as its required to perform
tags & uploads (not sure if PMC is required or not when it comes to
nexus).

Cheers,
Jamie

On Wed, May 4, 2011 at 1:13 PM, Jamie G. <ja...@gmail.com> wrote:
> Very true Mike. I've been picking up release duties as required. I
> have no claim at all to doing them other than if/when I'm actively
> assigned and working upon a particular release Jira task.
>
> Cheers,
> Jamie
>
> On Wed, May 4, 2011 at 1:04 PM, mikevan <mv...@comcast.net> wrote:
>>
>> Christian Schneider wrote:
>>>
>>> +1
>>>
>>> I think clustering is important enough to be part of the enterprise
>>> features.
>>>
>>> Christian
>>>
>>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>>> Guys, we are getting off topic.
>>>>
>>>> Even though I like Guillaume's ideas about central repository etc, it is
>>>> still hypothetical since the mechanism is not implemented yet and thus we
>>>> can't base our decisions on that.
>>>>
>>>> What we currently have is standard/enterprise features descriptor. What I
>>>> am
>>>> saying is that clustering should be part of the enterprise features
>>>> descriptor *(and probably hosted as subproject)*. Once we implement the
>>>> central repository mechanism we can move it there.
>>>>
>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet&lt;gnodet@gmail.com&gt;
>>>> wrote:
>>>>
>>>
>>> --
>>> ----
>>> http://www.liquid-reality.de
>>>
>>
>> Subprojects sounds like a good idea on the face, but it really comes down to
>> a management issue.  Who is going to be responsible for each sub-project?
>> Right now we have a few folks who are working on Karaf in addition to other
>> open-source projects.  IMHO, we should not have a sub-project unless we have
>> someone willing to be responsible for it.  I also don't think Jamie should
>> be that one person for all sub-projects.  However, if we can get folks to
>> accept responsiblity for them, I think its a great idea.
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by "Jamie G." <ja...@gmail.com>.

Very true Mike. I've been picking up release duties as required. I
have no claim at all to doing them other than if/when I'm actively
assigned and working upon a particular release Jira task.

Cheers,
Jamie

On Wed, May 4, 2011 at 1:04 PM, mikevan <mv...@comcast.net> wrote:
>
> Christian Schneider wrote:
>>
>> +1
>>
>> I think clustering is important enough to be part of the enterprise
>> features.
>>
>> Christian
>>
>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>> Guys, we are getting off topic.
>>>
>>> Even though I like Guillaume's ideas about central repository etc, it is
>>> still hypothetical since the mechanism is not implemented yet and thus we
>>> can't base our decisions on that.
>>>
>>> What we currently have is standard/enterprise features descriptor. What I
>>> am
>>> saying is that clustering should be part of the enterprise features
>>> descriptor *(and probably hosted as subproject)*. Once we implement the
>>> central repository mechanism we can move it there.
>>>
>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet&lt;gnodet@gmail.com&gt;
>>> wrote:
>>>
>>
>> --
>> ----
>> http://www.liquid-reality.de
>>
>
> Subprojects sounds like a good idea on the face, but it really comes down to
> a management issue.  Who is going to be responsible for each sub-project?
> Right now we have a few folks who are working on Karaf in addition to other
> open-source projects.  IMHO, we should not have a sub-project unless we have
> someone willing to be responsible for it.  I also don't think Jamie should
> be that one person for all sub-projects.  However, if we can get folks to
> accept responsiblity for them, I think its a great idea.
>
> -----
> Mike Van (aka karafman)
> Karaf Team (Contributor)
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by mikevan <mv...@comcast.net>.

Christian Schneider wrote:
> 
> +1
> 
> I think clustering is important enough to be part of the enterprise 
> features.
> 
> Christian
> 
> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>> Guys, we are getting off topic.
>>
>> Even though I like Guillaume's ideas about central repository etc, it is
>> still hypothetical since the mechanism is not implemented yet and thus we
>> can't base our decisions on that.
>>
>> What we currently have is standard/enterprise features descriptor. What I
>> am
>> saying is that clustering should be part of the enterprise features
>> descriptor *(and probably hosted as subproject)*. Once we implement the
>> central repository mechanism we can move it there.
>>
>> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet&lt;gnodet@gmail.com&gt; 
>> wrote:
>>
> 
> -- 
> ----
> http://www.liquid-reality.de
> 

Subprojects sounds like a good idea on the face, but it really comes down to
a management issue.  Who is going to be responsible for each sub-project? 
Right now we have a few folks who are working on Karaf in addition to other
open-source projects.  IMHO, we should not have a sub-project unless we have
someone willing to be responsible for it.  I also don't think Jamie should
be that one person for all sub-projects.  However, if we can get folks to
accept responsiblity for them, I think its a great idea.

-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

+1

I think clustering is important enough to be part of the enterprise 
features.

Christian

Am 04.05.2011 14:01, schrieb Ioannis Canellos:
> Guys, we are getting off topic.
>
> Even though I like Guillaume's ideas about central repository etc, it is
> still hypothetical since the mechanism is not implemented yet and thus we
> can't base our decisions on that.
>
> What we currently have is standard/enterprise features descriptor. What I am
> saying is that clustering should be part of the enterprise features
> descriptor *(and probably hosted as subproject)*. Once we implement the
> central repository mechanism we can move it there.
>
> On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

Guys, we are getting off topic.

Even though I like Guillaume's ideas about central repository etc, it is
still hypothetical since the mechanism is not implemented yet and thus we
can't base our decisions on that.

What we currently have is standard/enterprise features descriptor. What I am
saying is that clustering should be part of the enterprise features
descriptor *(and probably hosted as subproject)*. Once we implement the
central repository mechanism we can move it there.

On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <gn...@gmail.com> wrote:

> I think you misundertand me.
> When camel 2.8.1 would be released, we'd just add the url to the global
> file at
>   http://karaf.apache.org/features/repository.xml
>
> Users could then install the updated feature as it would be
> automatically available.
>
> On Wed, May 4, 2011 at 13:42, Christian Schneider
> <ch...@die-schneider.net> wrote:
> > The problem with listing all versions is that you can not work with newer
> > version of e.g. camel. Imagine you have karaf working with camel 2.8.0.
> Then
> > you have a bug which is fixed in camel 2.8.1. Then you will want to
> easily
> > use camel 2.8.1 without waiting for a new karaf release.
> >
> > I think it would be better to scan for available versions on the maven
> repo
> > and warn if the user tries to install a version that was not tested. And
> > honestly we will not be able to test all those combinations anyway.
> >
> > Christian
> >
> >
> > Am 04.05.2011 13:34, schrieb Guillaume Nodet:
> >>
> >> In that central xml, we can refer to multiple versions of the same
> >> feature descriptor:
> >>
> >> <features>
> >>
> >>
> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
> >>
> >>
> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
> >>  ...
> >> </features>
> >>
> >> I think we'd need a descriptor for each minor version of Karaf so that
> >> we can make sure only features that have been tested on a given karaf
> >> version are available.
> >>
> >> On Wed, May 4, 2011 at 13:28, Christian Schneider
> >> <ch...@die-schneider.net>  wrote:
> >>>
> >>> I also think a small karaf with the easy possibility to create custom
> >>> distros is the way to go.
> >>> A central list of pointers to repository files makes sense. But we have
> >>> to
> >>> do this a bit different than the current feature files. Currently a url
> >>> to a
> >>> feature file always points to a certain version of that file. For a
> >>> central
> >>> list this does not make sense.
> >>>
> >>> So I think we rather need a list of the base urls without version and
> >>> then
> >>> an easy way for users to install a feature file with a certain version.
> >>> So
> >>> for example to install the feature url for camel the user should be
> able
> >>> to
> >>> write something like:
> >>> features:addurl camel 2.7.0
> >>>
> >>> Do we already have support for this or something similar? Or do we have
> >>> an
> >>> issue for it? If not I can create one.
> >>>
> >>> Christian
> >>>
> >>>
> >>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
> >>>>
> >>>> I think we need a way to enable user to install other features easily
> >>>> without having to release karaf for that.
> >>>> It just does not scale if we have to release Karaf because Camel as
> >>>> released a new version for example.
> >>>> We've already discussed that some time ago and I think we need to find
> >>>> a good technical solution for that.
> >>>> Maybe having a xml feature descriptor referenced at
> >>>> http://karaf.apache.org/features/repository.xml which would point to
> >>>> various other repositories (such as camel, cxf, servicemix, web,
> >>>> aries, etc...) is more scalable as we would not have to release a new
> >>>> karaf container each time one of those things change.  People may want
> >>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
> >>>> things in Karaf trunk as this would create unnecessary ties between
> >>>> the projects and Karaf.
> >>>>
> >>>> Once we have that, we should keep Karaf main distribution clean and
> >>>> lean and provide all the optional bits using this way.   Combined with
> >>>> an easy way to create custom distribution, I do think that's the way
> >>>> to go.
> >>>>
> >>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
> >>>>  wrote:
> >>>>>>
> >>>>>> I think that's what we are working on already as part of 3.0, so not
> >>>>>> sure if I really understand what you mean here.
> >>>>>>
> >>>>> I see clustering to be part of the core karaf distribution. By that I
> >>>>> mean
> >>>>> that the clustering solution should be provided as a feature inside
> the
> >>>>> standard feature repository.
> >>>>>
> >>>>> --
> >>>>> *Ioannis Canellos*
> >>>>> *
> >>>>>  http://iocanel.blogspot.com
> >>>>>
> >>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
> >>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
> >>>>> *
> >>>>>
> >>>>
> >>> --
> >>> ----
> >>> http://www.liquid-reality.de
> >>>
> >>>
> >>
> >>
> >
> > --
> > ----
> > http://www.liquid-reality.de
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com/
>



-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

I think you misundertand me.
When camel 2.8.1 would be released, we'd just add the url to the global file at
  http://karaf.apache.org/features/repository.xml

Users could then install the updated feature as it would be
automatically available.

On Wed, May 4, 2011 at 13:42, Christian Schneider
<ch...@die-schneider.net> wrote:
> The problem with listing all versions is that you can not work with newer
> version of e.g. camel. Imagine you have karaf working with camel 2.8.0. Then
> you have a bug which is fixed in camel 2.8.1. Then you will want to easily
> use camel 2.8.1 without waiting for a new karaf release.
>
> I think it would be better to scan for available versions on the maven repo
> and warn if the user tries to install a version that was not tested. And
> honestly we will not be able to test all those combinations anyway.
>
> Christian
>
>
> Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>>
>> In that central xml, we can refer to multiple versions of the same
>> feature descriptor:
>>
>> <features>
>>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>>  ...
>> </features>
>>
>> I think we'd need a descriptor for each minor version of Karaf so that
>> we can make sure only features that have been tested on a given karaf
>> version are available.
>>
>> On Wed, May 4, 2011 at 13:28, Christian Schneider
>> <ch...@die-schneider.net>  wrote:
>>>
>>> I also think a small karaf with the easy possibility to create custom
>>> distros is the way to go.
>>> A central list of pointers to repository files makes sense. But we have
>>> to
>>> do this a bit different than the current feature files. Currently a url
>>> to a
>>> feature file always points to a certain version of that file. For a
>>> central
>>> list this does not make sense.
>>>
>>> So I think we rather need a list of the base urls without version and
>>> then
>>> an easy way for users to install a feature file with a certain version.
>>> So
>>> for example to install the feature url for camel the user should be able
>>> to
>>> write something like:
>>> features:addurl camel 2.7.0
>>>
>>> Do we already have support for this or something similar? Or do we have
>>> an
>>> issue for it? If not I can create one.
>>>
>>> Christian
>>>
>>>
>>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>>>
>>>> I think we need a way to enable user to install other features easily
>>>> without having to release karaf for that.
>>>> It just does not scale if we have to release Karaf because Camel as
>>>> released a new version for example.
>>>> We've already discussed that some time ago and I think we need to find
>>>> a good technical solution for that.
>>>> Maybe having a xml feature descriptor referenced at
>>>> http://karaf.apache.org/features/repository.xml which would point to
>>>> various other repositories (such as camel, cxf, servicemix, web,
>>>> aries, etc...) is more scalable as we would not have to release a new
>>>> karaf container each time one of those things change.  People may want
>>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>>>> things in Karaf trunk as this would create unnecessary ties between
>>>> the projects and Karaf.
>>>>
>>>> Once we have that, we should keep Karaf main distribution clean and
>>>> lean and provide all the optional bits using this way.   Combined with
>>>> an easy way to create custom distribution, I do think that's the way
>>>> to go.
>>>>
>>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>
>>>>  wrote:
>>>>>>
>>>>>> I think that's what we are working on already as part of 3.0, so not
>>>>>> sure if I really understand what you mean here.
>>>>>>
>>>>> I see clustering to be part of the core karaf distribution. By that I
>>>>> mean
>>>>> that the clustering solution should be provided as a feature inside the
>>>>> standard feature repository.
>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> *
>>>>>  http://iocanel.blogspot.com
>>>>>
>>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>>>>> *
>>>>>
>>>>
>>> --
>>> ----
>>> http://www.liquid-reality.de
>>>
>>>
>>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

The problem with listing all versions is that you can not work with 
newer version of e.g. camel. Imagine you have karaf working with camel 
2.8.0. Then you have a bug which is fixed in camel 2.8.1. Then you will 
want to easily use camel 2.8.1 without waiting for a new karaf release.

I think it would be better to scan for available versions on the maven 
repo and warn if the user tries to install a version that was not 
tested. And honestly we will not be able to test all those combinations 
anyway.

Christian


Am 04.05.2011 13:34, schrieb Guillaume Nodet:
> In that central xml, we can refer to multiple versions of the same
> feature descriptor:
>
> <features>
>    <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>    <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>   ...
> </features>
>
> I think we'd need a descriptor for each minor version of Karaf so that
> we can make sure only features that have been tested on a given karaf
> version are available.
>
> On Wed, May 4, 2011 at 13:28, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> I also think a small karaf with the easy possibility to create custom
>> distros is the way to go.
>> A central list of pointers to repository files makes sense. But we have to
>> do this a bit different than the current feature files. Currently a url to a
>> feature file always points to a certain version of that file. For a central
>> list this does not make sense.
>>
>> So I think we rather need a list of the base urls without version and then
>> an easy way for users to install a feature file with a certain version. So
>> for example to install the feature url for camel the user should be able to
>> write something like:
>> features:addurl camel 2.7.0
>>
>> Do we already have support for this or something similar? Or do we have an
>> issue for it? If not I can create one.
>>
>> Christian
>>
>>
>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>> I think we need a way to enable user to install other features easily
>>> without having to release karaf for that.
>>> It just does not scale if we have to release Karaf because Camel as
>>> released a new version for example.
>>> We've already discussed that some time ago and I think we need to find
>>> a good technical solution for that.
>>> Maybe having a xml feature descriptor referenced at
>>> http://karaf.apache.org/features/repository.xml which would point to
>>> various other repositories (such as camel, cxf, servicemix, web,
>>> aries, etc...) is more scalable as we would not have to release a new
>>> karaf container each time one of those things change.  People may want
>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>>> things in Karaf trunk as this would create unnecessary ties between
>>> the projects and Karaf.
>>>
>>> Once we have that, we should keep Karaf main distribution clean and
>>> lean and provide all the optional bits using this way.   Combined with
>>> an easy way to create custom distribution, I do think that's the way
>>> to go.
>>>
>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>    wrote:
>>>>> I think that's what we are working on already as part of 3.0, so not
>>>>> sure if I really understand what you mean here.
>>>>>
>>>> I see clustering to be part of the core karaf distribution. By that I
>>>> mean
>>>> that the clustering solution should be provided as a feature inside the
>>>> standard feature repository.
>>>>
>>>> --
>>>> *Ioannis Canellos*
>>>> *
>>>>   http://iocanel.blogspot.com
>>>>
>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>>>> *
>>>>
>>>
>> --
>> ----
>> http://www.liquid-reality.de
>>
>>
>
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

In that central xml, we can refer to multiple versions of the same
feature descriptor:

<features>
  <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
  <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
 ...
</features>

I think we'd need a descriptor for each minor version of Karaf so that
we can make sure only features that have been tested on a given karaf
version are available.

On Wed, May 4, 2011 at 13:28, Christian Schneider
<ch...@die-schneider.net> wrote:
> I also think a small karaf with the easy possibility to create custom
> distros is the way to go.
> A central list of pointers to repository files makes sense. But we have to
> do this a bit different than the current feature files. Currently a url to a
> feature file always points to a certain version of that file. For a central
> list this does not make sense.
>
> So I think we rather need a list of the base urls without version and then
> an easy way for users to install a feature file with a certain version. So
> for example to install the feature url for camel the user should be able to
> write something like:
> features:addurl camel 2.7.0
>
> Do we already have support for this or something similar? Or do we have an
> issue for it? If not I can create one.
>
> Christian
>
>
> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>
>> I think we need a way to enable user to install other features easily
>> without having to release karaf for that.
>> It just does not scale if we have to release Karaf because Camel as
>> released a new version for example.
>> We've already discussed that some time ago and I think we need to find
>> a good technical solution for that.
>> Maybe having a xml feature descriptor referenced at
>> http://karaf.apache.org/features/repository.xml which would point to
>> various other repositories (such as camel, cxf, servicemix, web,
>> aries, etc...) is more scalable as we would not have to release a new
>> karaf container each time one of those things change.  People may want
>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>> things in Karaf trunk as this would create unnecessary ties between
>> the projects and Karaf.
>>
>> Once we have that, we should keep Karaf main distribution clean and
>> lean and provide all the optional bits using this way.   Combined with
>> an easy way to create custom distribution, I do think that's the way
>> to go.
>>
>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>  wrote:
>>>>
>>>> I think that's what we are working on already as part of 3.0, so not
>>>> sure if I really understand what you mean here.
>>>>
>>> I see clustering to be part of the core karaf distribution. By that I
>>> mean
>>> that the clustering solution should be provided as a feature inside the
>>> standard feature repository.
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>>  http://iocanel.blogspot.com
>>>
>>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>>> Apache ServiceMix<http://servicemix.apache.org/>    Committer
>>> *
>>>
>>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by "Jamie G." <ja...@gmail.com>.

To my view of things, Cellar becomes part of the core features of
Karaf as its clustering solution. I do not believe that a separate
distribution is required  (ie. Apache-Karaf-Cellar.tar.gz) as
clustering is something that the user should just need to install as a
feature to enable. To the question of should Cellar be on trunk or as
a sub project, at this time I think in trunk makes sense.

Cheers,
Jamie

On Wed, May 4, 2011 at 8:58 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I also think a small karaf with the easy possibility to create custom
> distros is the way to go.
> A central list of pointers to repository files makes sense. But we have to
> do this a bit different than the current feature files. Currently a url to a
> feature file always points to a certain version of that file. For a central
> list this does not make sense.
>
> So I think we rather need a list of the base urls without version and then
> an easy way for users to install a feature file with a certain version. So
> for example to install the feature url for camel the user should be able to
> write something like:
> features:addurl camel 2.7.0
>
> Do we already have support for this or something similar? Or do we have an
> issue for it? If not I can create one.
>
> Christian
>
>
> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>
>> I think we need a way to enable user to install other features easily
>> without having to release karaf for that.
>> It just does not scale if we have to release Karaf because Camel as
>> released a new version for example.
>> We've already discussed that some time ago and I think we need to find
>> a good technical solution for that.
>> Maybe having a xml feature descriptor referenced at
>> http://karaf.apache.org/features/repository.xml which would point to
>> various other repositories (such as camel, cxf, servicemix, web,
>> aries, etc...) is more scalable as we would not have to release a new
>> karaf container each time one of those things change.  People may want
>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>> things in Karaf trunk as this would create unnecessary ties between
>> the projects and Karaf.
>>
>> Once we have that, we should keep Karaf main distribution clean and
>> lean and provide all the optional bits using this way.   Combined with
>> an easy way to create custom distribution, I do think that's the way
>> to go.
>>
>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>  wrote:
>>>>
>>>> I think that's what we are working on already as part of 3.0, so not
>>>> sure if I really understand what you mean here.
>>>>
>>> I see clustering to be part of the core karaf distribution. By that I
>>> mean
>>> that the clustering solution should be provided as a feature inside the
>>> standard feature repository.
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>>  http://iocanel.blogspot.com
>>>
>>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>>> Apache ServiceMix<http://servicemix.apache.org/>    Committer
>>> *
>>>
>>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

I also think a small karaf with the easy possibility to create custom 
distros is the way to go.
A central list of pointers to repository files makes sense. But we have 
to do this a bit different than the current feature files. Currently a 
url to a feature file always points to a certain version of that file. 
For a central list this does not make sense.

So I think we rather need a list of the base urls without version and 
then an easy way for users to install a feature file with a certain 
version. So for example to install the feature url for camel the user 
should be able to write something like:
features:addurl camel 2.7.0

Do we already have support for this or something similar? Or do we have 
an issue for it? If not I can create one.

Christian


Am 04.05.2011 13:21, schrieb Guillaume Nodet:
> I think we need a way to enable user to install other features easily
> without having to release karaf for that.
> It just does not scale if we have to release Karaf because Camel as
> released a new version for example.
> We've already discussed that some time ago and I think we need to find
> a good technical solution for that.
> Maybe having a xml feature descriptor referenced at
> http://karaf.apache.org/features/repository.xml which would point to
> various other repositories (such as camel, cxf, servicemix, web,
> aries, etc...) is more scalable as we would not have to release a new
> karaf container each time one of those things change.  People may want
> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
> things in Karaf trunk as this would create unnecessary ties between
> the projects and Karaf.
>
> Once we have that, we should keep Karaf main distribution clean and
> lean and provide all the optional bits using this way.   Combined with
> an easy way to create custom distribution, I do think that's the way
> to go.
>
> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<io...@gmail.com>  wrote:
>>> I think that's what we are working on already as part of 3.0, so not
>>> sure if I really understand what you mean here.
>>>
>> I see clustering to be part of the core karaf distribution. By that I mean
>> that the clustering solution should be provided as a feature inside the
>> standard feature repository.
>>
>> --
>> *Ioannis Canellos*
>> *
>>   http://iocanel.blogspot.com
>>
>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>> Apache ServiceMix<http://servicemix.apache.org/>    Committer
>> *
>>
>
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

I think we need a way to enable user to install other features easily
without having to release karaf for that.
It just does not scale if we have to release Karaf because Camel as
released a new version for example.
We've already discussed that some time ago and I think we need to find
a good technical solution for that.
Maybe having a xml feature descriptor referenced at
http://karaf.apache.org/features/repository.xml which would point to
various other repositories (such as camel, cxf, servicemix, web,
aries, etc...) is more scalable as we would not have to release a new
karaf container each time one of those things change.  People may want
Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
things in Karaf trunk as this would create unnecessary ties between
the projects and Karaf.

Once we have that, we should keep Karaf main distribution clean and
lean and provide all the optional bits using this way.   Combined with
an easy way to create custom distribution, I do think that's the way
to go.

On Wed, May 4, 2011 at 13:12, Ioannis Canellos <io...@gmail.com> wrote:
>>
>> I think that's what we are working on already as part of 3.0, so not
>> sure if I really understand what you mean here.
>>
>
> I see clustering to be part of the core karaf distribution. By that I mean
> that the clustering solution should be provided as a feature inside the
> standard feature repository.
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

>
> I think that's what we are working on already as part of 3.0, so not
> sure if I really understand what you mean here.
>

I see clustering to be part of the core karaf distribution. By that I mean
that the clustering solution should be provided as a feature inside the
standard feature repository.

-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

I think that's what we are working on already as part of 3.0, so not
sure if I really understand what you mean here.

On Wed, May 4, 2011 at 13:06, Christian Schneider
<ch...@die-schneider.net> wrote:
> I think we can not provide a distribution for everything people want anyway.
> So instead of having more distributions I think we should concentrate on
> providing a really simple way for users to create their own distros.
>
> Christian
>
>
> Am 04.05.2011 13:00, schrieb Ioannis Canellos:
>>
>> I don't mind hosting it as a subproject.
>>
>> I disagree on having a separate distribution. Currently we have the
>> minimal
>> distribution and everyone who wants a minimalistic Karaf can build on top
>> of
>> that. I don't see any added value in having multiple distributions.
>>
>> Till this day, I didn't see any anyone complain about enterprise features
>> (tx, jpa), nor did we create a distribution for them.
>>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

I think we can not provide a distribution for everything people want 
anyway. So instead of having more distributions I think we should 
concentrate on providing a really simple way for users to create their 
own distros.

Christian


Am 04.05.2011 13:00, schrieb Ioannis Canellos:
> I don't mind hosting it as a subproject.
>
> I disagree on having a separate distribution. Currently we have the minimal
> distribution and everyone who wants a minimalistic Karaf can build on top of
> that. I don't see any added value in having multiple distributions.
>
> Till this day, I didn't see any anyone complain about enterprise features
> (tx, jpa), nor did we create a distribution for them.
>
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

I'm not sure to understand your objections.  Having a tar/gz with
karaf + cellar already installed makes things easier to consume for
end users.  Same for karaf + web, which gives you a ready to use web
container.

On Wed, May 4, 2011 at 13:00, Ioannis Canellos <io...@gmail.com> wrote:
> I don't mind hosting it as a subproject.
>
> I disagree on having a separate distribution. Currently we have the minimal
> distribution and everyone who wants a minimalistic Karaf can build on top of
> that. I don't see any added value in having multiple distributions.
>
> Till this day, I didn't see any anyone complain about enterprise features
> (tx, jpa), nor did we create a distribution for them.
>
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

I don't mind hosting it as a subproject.

I disagree on having a separate distribution. Currently we have the minimal
distribution and everyone who wants a minimalistic Karaf can build on top of
that. I don't see any added value in having multiple distributions.

Till this day, I didn't see any anyone complain about enterprise features
(tx, jpa), nor did we create a distribution for them.


-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Andreas Pieber <an...@gmail.com>.

Yeah, that's what I'm also thinking of. THB I really like JB's
proposal about having:

- WebContainer (using Pax Web)
- EnterpriseContainer (using Aries, OpenJPA)
- OBR (using Felix BundleRepository, home mage stuff)
- Cluster (using Cellar/Hazelcast)

I'm with JB about the pros but not completely about the cons; at least
not about

- it requires more knowledges for the users to create custom
distribution with exactly what they want (Karaf is less integrated but
provide all required to create custom distro)

If we finish the .kar model in a good way in 3.x (what I really
believe we can) it won't be any difference for an end-user (from my
point of view at least).

So +1 for subprojects directly in Karaf (similar to Felix).

Kind regards,
Andreas

On Wed, May 4, 2011 at 12:42 PM, Ioannis Canellos <io...@gmail.com> wrote:
> So what do you suggest? Add Cellar as a Karaf subproject and provide a
> Cellar feature in core Karaf?
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

So what do you suggest? Add Cellar as a Karaf subproject and provide a
Cellar feature in core Karaf?

-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.

Hi Charles,

We are talking about Karaf sub-projects, not Apache one.
All these projects will be under the Karaf repository.

Regards
JB

On 05/04/2011 12:28 PM, Charles Moulliard wrote:
> Do we really need to create Apache sub-projects for cellar, pax-web,
> OBR, .... ? I don't think so. We can follow the approach adopted by
> ServiceMix where by examples the bundles are packaged into a deliverable
> link to a ServiceMix version.
>
> On 04/05/11 12:07, James Strachan wrote:
>> On 4 May 2011 10:51, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>>> It makes sense to have sub-projects in Karaf:
>>> - WebContainer (using Pax Web)
>>> - EnterpriseContainer (using Aries, OpenJPA)
>>> - OBR (using Felix BundleRepository, home mage stuff)
>>> - Cluster (using Cellar/Hazelcast)
>>>
>>> In that case, Karaf itself will be a very lightweight container.
>>>
>>> Pro:
>>> - Karaf itself is more clean and light
>>> - Karaf dependencies are more easy to manage (the dependencies
>>> management
>>> move to subproject)
>> Its also easier to manage release lifecycles with more granular
>> projects. e.g. Cellar is going to be under a state of flux and active
>> development for some time; whereas Karaf is much more stable& already
>> used in lots of projects.
>>
>> We learnt the hard way on the ServiceMix project that separating out
>> the Kernel release from features-above-the-kernel makes things much
>> easier for folks managing their dependencies& release schedules.
>> (e.g. you might want to use Cellar in 2.x and 3.x versions of Karaf
>> for some time yet).
>>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Charles Moulliard <cm...@gmail.com>.

Do we really need to create Apache sub-projects for cellar, pax-web, 
OBR, .... ? I don't think so. We can follow the approach adopted by 
ServiceMix where by examples the bundles are packaged into a deliverable 
link to a ServiceMix version.

On 04/05/11 12:07, James Strachan wrote:
> On 4 May 2011 10:51, Jean-Baptiste Onofré<jb...@nanthrax.net>  wrote:
>> It makes sense to have sub-projects in Karaf:
>> - WebContainer (using Pax Web)
>> - EnterpriseContainer (using Aries, OpenJPA)
>> - OBR (using Felix BundleRepository, home mage stuff)
>> - Cluster (using Cellar/Hazelcast)
>>
>> In that case, Karaf itself will be a very lightweight container.
>>
>> Pro:
>> - Karaf itself is more clean and light
>> - Karaf dependencies are more easy to manage (the dependencies management
>> move to subproject)
> Its also easier to manage release lifecycles with more granular
> projects. e.g. Cellar is going to be under a state of flux and active
> development for some time; whereas Karaf is much more stable&  already
> used in lots of projects.
>
> We learnt the hard way on the ServiceMix project that separating out
> the Kernel release from features-above-the-kernel makes things much
> easier for folks managing their dependencies&  release schedules.
> (e.g. you might want to use Cellar in 2.x and 3.x versions of Karaf
> for some time yet).
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by James Strachan <ja...@gmail.com>.

On 4 May 2011 10:51, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> It makes sense to have sub-projects in Karaf:
> - WebContainer (using Pax Web)
> - EnterpriseContainer (using Aries, OpenJPA)
> - OBR (using Felix BundleRepository, home mage stuff)
> - Cluster (using Cellar/Hazelcast)
>
> In that case, Karaf itself will be a very lightweight container.
>
> Pro:
> - Karaf itself is more clean and light
> - Karaf dependencies are more easy to manage (the dependencies management
> move to subproject)

Its also easier to manage release lifecycles with more granular
projects. e.g. Cellar is going to be under a state of flux and active
development for some time; whereas Karaf is much more stable & already
used in lots of projects.

We learnt the hard way on the ServiceMix project that separating out
the Kernel release from features-above-the-kernel makes things much
easier for folks managing their dependencies & release schedules.
(e.g. you might want to use Cellar in 2.x and 3.x versions of Karaf
for some time yet).

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.

It makes sense to have sub-projects in Karaf:
- WebContainer (using Pax Web)
- EnterpriseContainer (using Aries, OpenJPA)
- OBR (using Felix BundleRepository, home mage stuff)
- Cluster (using Cellar/Hazelcast)

In that case, Karaf itself will be a very lightweight container.

Pro:
- Karaf itself is more clean and light
- Karaf dependencies are more easy to manage (the dependencies 
management move to subproject)

Cons:
- multiple projects is not easy to understand for the end-users. See the 
Felix case: I think that a lot of users are lost about Felix, with a lot 
of misunderstanding between Felix Framework and others projects
- it requires more community "interactions": more votes, more releases, etc
- it requires more knowledges for the users to create custom 
distribution with exactly what they want (Karaf is less integrated but 
provide all required to create custom distro)

Regards
JB

On 05/04/2011 10:25 AM, Guillaume Nodet wrote:
> @jb If people think Cellar may potentially grow into something bigger,
> we should definitely make it a subproject asap.  It will be much less
> pain than doing that later.
>
> @achim that could be a good idea.   I remember jb talked about an OBR
> repository and maybe the a webserver (ready to use web container based
> on karaf and pax-web plus all the good stuff you wrote recently) could
> definitely make sense to me.   It may also help keeping the core clean
> and lean.
>
> On Wed, May 4, 2011 at 09:43, Achim Nierbeck<bc...@googlemail.com>  wrote:
>> Hi,
>>
>> +1 for cellar being a subproject.
>>
>> btw. we might need to take a look on different other "core" features
>> that might be considered to be a worthy "subproject".
>> just my 2 cents :-)
>>
>> regards, Achim
>>
>> 2011/5/4 Jean-Baptiste Onofré<jb...@nanthrax.net>:
>>> Hi Guillaume,
>>>
>>> thanks for the update.
>>>
>>> I would prefer to have Cellar directly on Karaf trunk. Like this, it allows
>>> to define Cellar feature into the Karaf features descriptors.
>>> But your remark is right and it could make sense to have Cellar as a Karaf
>>> edge project.
>>> @others: WDYT ?
>>>
>>> For the projects dependencies (SMX, CXF, etc), it's just an idea, and I'm
>>> not sure it's a good one :). For now, Cellar is **only** a Karaf cluster
>>> implementation. So it makes sense to be in Karaf. If later, it evolves to
>>> something different, we will think about moving into a new project (as we
>>> made for Karaf, from ServiceMix Kernel, to Felix Karaf and finally Karaf
>>> :)).
>>>
>>> Thanks again
>>> Regards
>>> JB
>>>
>>> On 05/04/2011 09:32 AM, Guillaume Nodet wrote:
>>>>
>>>> +0  as I don't plan to work on that code base in the near future
>>>>
>>>> A few comments though:
>>>>    * I do think it would be better to import cellar into its own
>>>> subproject at http://svn.apache.org/repos/asf/karaf/cellar/trunk
>>>>       so that it can have independant releases and won't affect the 3.0
>>>> schedule
>>>>    * if you think of cellar as providing features for servicemix, cxf
>>>> or camel, I think Karaf is not the right place for cellar
>>>>       and I would start in the incubator so that cellar can have the
>>>> broader scope it deserve
>>>>
>>>>
>>>> On Tue, May 3, 2011 at 19:41, Jean-Baptiste Onofré<jb...@nanthrax.net>
>>>>   wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> following our discussion about Karaf clustering and Cellar, I would like
>>>>> to
>>>>> launch a vote to add Cellar into Karaf trunk.
>>>>>
>>>>> This addition covers the following topics:
>>>>>
>>>>> 1/ Source code
>>>>> Currently, Cellar source code is on github. It will be added into Karaf
>>>>> trunk, on a cellar maven module.
>>>>> All package will be named to org.apache.karaf.cellar and all resources
>>>>> (java, properties, etc) will include Apache header.
>>>>>
>>>>> 2/ Provided features
>>>>> Before inclusion, Ioannis and I would include a new feature which allow
>>>>> you
>>>>> to choose the node discovery mechanism:
>>>>> - static list
>>>>> - unicast
>>>>> - multicast
>>>>> - etc
>>>>> I started to work on it this afternoon, it should be available soon.
>>>>>
>>>>> 3/ Documentation resources
>>>>> The Karaf user and developers manuals will contain Cellar installation
>>>>> and
>>>>> user guide. First step is to complete the Karaf cluster wiki page, and
>>>>> refactore the Ioannis' blog content into user and developers manuals.
>>>>>
>>>>> Depending of the result of the vote, I will raise the corresponding Jira
>>>>> and
>>>>> I will work on it.
>>>>>
>>>>> I have a couple of Karaf Cellar related topics:
>>>>> - I launched a discussion on Apache ACE mailing list. As ACE supports
>>>>> cloud
>>>>> environment (using jclouds), I would like to avoid overlap between ACE
>>>>> and
>>>>> Karaf. The first ACE team feedbacks are good as we consider ACE as a pure
>>>>> provisioning platform. I will keep you posted about this discussion. On
>>>>> the
>>>>> same area (relationship with others Apache projects), I think that we
>>>>> have
>>>>> to discuss with Camel, ServiceMix, CXF, ActiveMQ, and others about we can
>>>>> improve Karaf Cellar to provide services for these projects.
>>>>> - I submitted a talk for the next ApacheCon 2011 (Vancouver, 5th-11th
>>>>> November) about Karaf in an enterprise environment. It will include Karaf
>>>>> 3.0.0 new features presentation and of course Karaf Cellar introduction.
>>>>> I
>>>>> also plan to make a demo using Karaf, Cellar, and ACE to show how Karaf
>>>>> is a
>>>>> powerful OSGi runtime/container in an high value enterprise environment.
>>>>>
>>>>> Regarding these topics, I submit the addition of Cellar into Karaf to
>>>>> your
>>>>> vote:
>>>>>
>>>>> [ ] +1 Approve the addition of Cellar into Karaf trunk
>>>>> [ ] -1 Veto the addition (please provide specific comments)
>>>>>
>>>>> This vote will be open for 72 hours.
>>>>>
>>>>> I'm available if you need deeper explanations about Cellar.
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> --
>> *Achim Nierbeck*
>>
>>
>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>> OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer&  Project Lead
>>
>
>
>

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Guillaume Nodet <gn...@gmail.com>.

Yes, and I think it would make sense to have a subproject dedicated to
having a ready to use webserver, such as tomcat, jetty or gemini.
We can't really talk about Karaf as a web server, that's not what it
is.

For OBR, I'm not talking about just the obr bundle, that would not
make any sense, but Jean-Baptiste talked some time ago about having an
distribution of Karaf targetet at having an OBR server with the help
of RemoteOBR (see http://gnodet.blogspot.com/2010/09/remoteobr.html).

I think the same apply to cellar.  As soon as we want to give a
personality to karaf, i.e. something build on top of Karaf, it makes
more sense to have a subproject for that.

Over the past months, I've expressed myself a number of time to make
sure Karaf does not become a dumping ground for any OSGi stuff.  For
sure, other features should be able to be installed very easily using
features xml descriptors, but that doesn't mean we should not provide
specific distributions in other subprojects.

On Wed, May 4, 2011 at 11:21, Ioannis Canellos <io...@gmail.com> wrote:
> Cellar is a feature, just like HTTP, OBR etc. I don't see any reason
> treating it differently than the existing features (*which are optional but
> provided*) in the core distribution.
>
> I am not against having it as a subproject, I just want it to be treat same
> as the rest of the features (*which are optional but provided*).
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Christian Schneider <ch...@die-schneider.net>.

I would like Cellar to be integrated into Karaf for the moment. When it 
supports more then Karaf then this is the right time to make it more 
independent.

Always remember that for subprojects you also have to call votes for the 
releases. So this would mean some extra  overhead.

Christian


Am 04.05.2011 11:21, schrieb Ioannis Canellos:
> Cellar is a feature, just like HTTP, OBR etc. I don't see any reason
> treating it differently than the existing features (*which are optional but
> provided*) in the core distribution.
>
> I am not against having it as a subproject, I just want it to be treat same
> as the rest of the features (*which are optional but provided*).
>

-- 
----
http://www.liquid-reality.de

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Ioannis Canellos <io...@gmail.com>.

Cellar is a feature, just like HTTP, OBR etc. I don't see any reason
treating it differently than the existing features (*which are optional but
provided*) in the core distribution.

I am not against having it as a subproject, I just want it to be treat same
as the rest of the features (*which are optional but provided*).

-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by Freeman Fang <fr...@gmail.com>.

Yeah, If we decide to add Cellar into Karaf, make it as a subject is  
better so that we can keep Karaf core as small as possible, I believe  
this is also how the original "KERNEL" means.
Also +1 to put pax-web related stuff as subject.

Freeman
On 2011-5-4, at 下午4:25, Guillaume Nodet wrote:

> @jb If people think Cellar may potentially grow into something bigger,
> we should definitely make it a subproject asap.  It will be much less
> pain than doing that later.
>
> @achim that could be a good idea.   I remember jb talked about an OBR
> repository and maybe the a webserver (ready to use web container based
> on karaf and pax-web plus all the good stuff you wrote recently) could
> definitely make sense to me.   It may also help keeping the core clean
> and lean.
>
> On Wed, May 4, 2011 at 09:43, Achim Nierbeck  
> <bc...@googlemail.com> wrote:
>> Hi,
>>
>> +1 for cellar being a subproject.
>>
>> btw. we might need to take a look on different other "core" features
>> that might be considered to be a worthy "subproject".
>> just my 2 cents :-)
>>
>> regards, Achim
>>
>> 2011/5/4 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>> Hi Guillaume,
>>>
>>> thanks for the update.
>>>
>>> I would prefer to have Cellar directly on Karaf trunk. Like this,  
>>> it allows
>>> to define Cellar feature into the Karaf features descriptors.
>>> But your remark is right and it could make sense to have Cellar as  
>>> a Karaf
>>> edge project.
>>> @others: WDYT ?
>>>
>>> For the projects dependencies (SMX, CXF, etc), it's just an idea,  
>>> and I'm
>>> not sure it's a good one :). For now, Cellar is **only** a Karaf  
>>> cluster
>>> implementation. So it makes sense to be in Karaf. If later, it  
>>> evolves to
>>> something different, we will think about moving into a new project  
>>> (as we
>>> made for Karaf, from ServiceMix Kernel, to Felix Karaf and finally  
>>> Karaf
>>> :)).
>>>
>>> Thanks again
>>> Regards
>>> JB
>>>
>>> On 05/04/2011 09:32 AM, Guillaume Nodet wrote:
>>>>
>>>> +0  as I don't plan to work on that code base in the near future
>>>>
>>>> A few comments though:
>>>>   * I do think it would be better to import cellar into its own
>>>> subproject at http://svn.apache.org/repos/asf/karaf/cellar/trunk
>>>>      so that it can have independant releases and won't affect  
>>>> the 3.0
>>>> schedule
>>>>   * if you think of cellar as providing features for servicemix,  
>>>> cxf
>>>> or camel, I think Karaf is not the right place for cellar
>>>>      and I would start in the incubator so that cellar can have the
>>>> broader scope it deserve
>>>>
>>>>
>>>> On Tue, May 3, 2011 at 19:41, Jean-Baptiste  
>>>> Onofré<jb...@nanthrax.net>
>>>>  wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> following our discussion about Karaf clustering and Cellar, I  
>>>>> would like
>>>>> to
>>>>> launch a vote to add Cellar into Karaf trunk.
>>>>>
>>>>> This addition covers the following topics:
>>>>>
>>>>> 1/ Source code
>>>>> Currently, Cellar source code is on github. It will be added  
>>>>> into Karaf
>>>>> trunk, on a cellar maven module.
>>>>> All package will be named to org.apache.karaf.cellar and all  
>>>>> resources
>>>>> (java, properties, etc) will include Apache header.
>>>>>
>>>>> 2/ Provided features
>>>>> Before inclusion, Ioannis and I would include a new feature  
>>>>> which allow
>>>>> you
>>>>> to choose the node discovery mechanism:
>>>>> - static list
>>>>> - unicast
>>>>> - multicast
>>>>> - etc
>>>>> I started to work on it this afternoon, it should be available  
>>>>> soon.
>>>>>
>>>>> 3/ Documentation resources
>>>>> The Karaf user and developers manuals will contain Cellar  
>>>>> installation
>>>>> and
>>>>> user guide. First step is to complete the Karaf cluster wiki  
>>>>> page, and
>>>>> refactore the Ioannis' blog content into user and developers  
>>>>> manuals.
>>>>>
>>>>> Depending of the result of the vote, I will raise the  
>>>>> corresponding Jira
>>>>> and
>>>>> I will work on it.
>>>>>
>>>>> I have a couple of Karaf Cellar related topics:
>>>>> - I launched a discussion on Apache ACE mailing list. As ACE  
>>>>> supports
>>>>> cloud
>>>>> environment (using jclouds), I would like to avoid overlap  
>>>>> between ACE
>>>>> and
>>>>> Karaf. The first ACE team feedbacks are good as we consider ACE  
>>>>> as a pure
>>>>> provisioning platform. I will keep you posted about this  
>>>>> discussion. On
>>>>> the
>>>>> same area (relationship with others Apache projects), I think  
>>>>> that we
>>>>> have
>>>>> to discuss with Camel, ServiceMix, CXF, ActiveMQ, and others  
>>>>> about we can
>>>>> improve Karaf Cellar to provide services for these projects.
>>>>> - I submitted a talk for the next ApacheCon 2011 (Vancouver,  
>>>>> 5th-11th
>>>>> November) about Karaf in an enterprise environment. It will  
>>>>> include Karaf
>>>>> 3.0.0 new features presentation and of course Karaf Cellar  
>>>>> introduction.
>>>>> I
>>>>> also plan to make a demo using Karaf, Cellar, and ACE to show  
>>>>> how Karaf
>>>>> is a
>>>>> powerful OSGi runtime/container in an high value enterprise  
>>>>> environment.
>>>>>
>>>>> Regarding these topics, I submit the addition of Cellar into  
>>>>> Karaf to
>>>>> your
>>>>> vote:
>>>>>
>>>>> [ ] +1 Approve the addition of Cellar into Karaf trunk
>>>>> [ ] -1 Veto the addition (please provide specific comments)
>>>>>
>>>>> This vote will be open for 72 hours.
>>>>>
>>>>> I'm available if you need deeper explanations about Cellar.
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> --
>> *Achim Nierbeck*
>>
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com/

---------------------------------------------
Freeman Fang

FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference

Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)

Posted by mikevan <mv...@comcast.net>.

Andreas Pieber wrote:
> 
> In fact i proposed two things :-) one to cut down the number of
> distributions into online and offline depending on the number of packages
> they contain and virtually any number of distributions based on features
> making them visible during the startup. The second one is to split the
> "non-core" parts out of karaf to keep a sleek karaf core.
> 
> It is neither exactly what Guillaume proposed, nor anybody else, but
> rather
> a mixture ;-)
> 
> So I think this some up my ideas explained in more detail quite well. I am
> currently on my mobile phone. I can write this down in more detail once I
> am
> back to my PC if required.
> 
> Kind regards Andreas
> On May 4, 2011 7:15 PM, "mikevan" &lt;mvangeertruy@comcast.net&gt; wrote:
>>
>> Andreas Pieber wrote:
>>>
>>> In fact I think we should take a look how far we really want to break
>>> down the various components. What really should be extracted. Although
>>> there are various possibilities to split Karaf I would roughly suggest
>>> something like: management, web, clustering, spring (to finally get
>>> the spring things out of the "real" core :)). Since there are 13 PMCs
>>> (if Jamie stays at releasing karaf-core there are still 12 remaining)
>>> I think it should be possible to find 4 PMCs willing to take over the
>>> release process for those components. I have no problem taking one
>>> myself (which means 3 remaining :))...
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Wed, May 4, 2011 at 6:30 PM, Jamie G.
>>> &lt;jamie.goodyear@gmail.com&gt;
>>> wrote:
>>>> The website just requires committer status.
>>>>
>>>> According to this a PMC is 'preferred', as the PMCs are responsible
>>>> for their projects distribution directory at Apache.
>>>> http://www.apache.org/dev/release.html#what-must-every-release-contain
>>>>
>>>>
>>>> Cheers,
>>>> Jamie
>>>>
>>>> On Wed, May 4, 2011 at 1:49 PM, mikevan
>>>> &lt;mvangeertruy@comcast.net&gt;
>>>> wrote:
>>>>>
>>>>> jgoodyear wrote:
>>>>>>
>>>>>> As a reminder our release process is posted here:
>>>>>> http://karaf.apache.org/index/developers/release-guide.html
>>>>>>
>>>>>> To my knowledge those instructions should be sufficient to allow
>>>>>> anyone the ability to perform a Karaf release, the only caveat I
>>>>>> believe is that they have committer status as its required to perform
>>>>>> tags & uploads (not sure if PMC is required or not when it comes to
>>>>>> nexus).
>>>>>>
>>>>>> Cheers,
>>>>>> Jamie
>>>>>>
>>>>>> On Wed, May 4, 2011 at 1:13 PM, Jamie G.
>>>>>> &lt;jamie.goodyear@gmail.com&gt;
>>>>>> wrote:
>>>>>>> Very true Mike. I've been picking up release duties as required. I
>>>>>>> have no claim at all to doing them other than if/when I'm actively
>>>>>>> assigned and working upon a particular release Jira task.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jamie
>>>>>>>
>>>>>>> On Wed, May 4, 2011 at 1:04 PM, mikevan
>>>>>>> &lt;mvangeertruy@comcast.net&gt;
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Christian Schneider wrote:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> I think clustering is important enough to be part of the
>>>>>>>>> enterprise
>>>>>>>>> features.
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> Am 04.05.2011 14:01, schrieb Ioannis Canellos:
>>>>>>>>>> Guys, we are getting off topic.
>>>>>>>>>>
>>>>>>>>>> Even though I like Guillaume's ideas about central repository
>>>>>>>>>> etc,
>>>>>>>>>> it
>>>>>>>>>> is
>>>>>>>>>> still hypothetical since the mechanism is not implemented yet and
>>>>>>>>>> thus
>>>>>>>>>> we
>>>>>>>>>> can't base our decisions on that.
>>>>>>>>>>
>>>>>>>>>> What we currently have is standard/enterprise features
>>>>>>>>>> descriptor.
>>>>>>>>>> What I
>>>>>>>>>> am
>>>>>>>>>> saying is that clustering should be part of the enterprise
> features
>>>>>>>>>> descriptor *(and probably hosted as subproject)*. Once we
> implement
>>>>>>>>>> the
>>>>>>>>>> central repository mechanism we can move it there.
>>>>>>>>>>
>>>>>>>>>> On Wed, May 4, 2011 at 2:52 PM, Guillaume
>>>>>>>>>> Nodet&lt;gnodet@gmail.com&gt;
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ----
>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>
>>>>>>>>
>>>>>>>> Subprojects sounds like a good idea on the face, but it really
>>>>>>>> comes
>>>>>>>> down to
>>>>>>>> a management issue.  Who is going to be responsible for each
>>>>>>>> sub-project?
>>>>>>>> Right now we have a few folks who are working on Karaf in addition
> to
>>>>>>>> other
>>>>>>>> open-source projects.  IMHO, we should not have a sub-project
>>>>>>>> unless
>>>>>>>> we
>>>>>>>> have
>>>>>>>> someone willing to be responsible for it.  I also don't think Jamie
>>>>>>>> should
>>>>>>>> be that one person for all sub-projects.  However, if we can get
>>>>>>>> folks
>>>>>>>> to
>>>>>>>> accept responsiblity for them, I think its a great idea.
>>>>>>>>
>>>>>>>> -----
>>>>>>>> Mike Van (aka karafman)
>>>>>>>> Karaf Team (Contributor)
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899307.html
>>>>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> Hmm.. I thought PMC was required for a release, or is that just for
>>>>> the
>>>>> site?
>>>>>
>>>>> -----
>>>>> Mike Van (aka karafman)
>>>>> Karaf Team (Contributor)
>>>>> --
>>>>> View this message in context:
>>>>>
> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899495.html
>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>
>>
>> Is this different than what Guillaume originally suggested? The original
>> suggestion seemed aimed more at creating customer distributions of Karaf,
>> and this seems like breaking up optional functionality into
>> subprojects...
> 
>> I'm a tad confused.
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context:
> http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899744.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> 


I like this approach, Andreas.

-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Subprojects-was-VOTE-Add-Cellar-into-Karaf-trunk-tp2897884p2899862.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.