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/[email protected]/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<[email protected]> wrote:
2011/5/4 Guillaume Nodet<[email protected]>:
On Wed, May 4, 2011 at 14:01, Ioannis Canellos<[email protected]> 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<[email protected]> 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
<[email protected]> 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
<[email protected]> 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<[email protected]>
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
