In my previous e-mail, my intention is not to host the feature of others
projects (it's the responsibility of others projects). The purpose is to
host (at least temporary) the projects that don't provide features
descriptor "natively" (spring for instance).
Regards
JB
On 10/19/2012 09:08 AM, Charles Moulliard wrote:
Hi JB,
Maybe we could reduce the scope about what you propose and simply until now
maintain in a page the list of existing features karaf repository, their
location and what they provide as features/components. I agree that
maintaining "external" features repository into karaf project will be
overkill and that should be the responsability of external projects (camel,
pax, activemq, cxf, ....) to maintain them.
Regards,
Charles
On Fri, Oct 19, 2012 at 8:01 AM, Johan Edstrom <[email protected]> wrote:
I think this is getting into a lot of features we never wanted, starting
with spring sounds even worse.
On Oct 18, 2012, at 18:51, "Jamie G." <[email protected]> wrote:
From a high level this sounds good, however i share Ioannis,
Guillaume, and Freeman's concerns as well.
I assume this would be targeting Karaf 2.4.x / 3.1.x?
Cheers,
Jamie
On Thu, Oct 18, 2012 at 6:46 PM, Scott England-Sullivan
<[email protected]> wrote:
What if it was first prototyped with Spring? Deployer, feature, and
all.
Use that as a template then for migrating other non-core modules?
Is this that much different than the karaf-webconsole project?
*Scott England-Sullivan*
*blog*:sully6768.blogspot.com
*twitter*:@sully6768
On Oct 18, 2012, at 6:03 AM, Achim Nierbeck <[email protected]>
wrote:
Hi,
I really like this idea of separate feature files.
And I think we really should at least give it a try.
I fully understand the "fears" of Ioannis, Guillaume and Freeman
cause as I tried to seperate the pax-web features from Karaf
I just stumbled over a couple of constraint I didn't see right
from the beginning.
Like Camel depends on the http feature, this feature also
provides Karaf specific commands and so forth.
I think it can be done and I'll try to work on this as soon as possible,
still I think we will find such shortcomings with other features, too.
But if we stick to the way it is right now, we do get the feedback
it's not modular enough :)
regards, Achim
2012/10/18 Christian Schneider <[email protected]>:
I think the goal to have separate feature files that are independent of
the
karaf version is good.
Like Ioannis I am also unsure if it can be done right now. At least the
recent karaf versions would not have allowed that.
So before really starting this we should make sure we can deliver these
independent feature files.
Christian
On 10/18/2012 09:52 AM, Ioannis Canellos wrote:
The idea seems good at first glance, but there are things that we need
consider.
In many cases a feature descriptor is not portable between major Karaf
versions, and it also happens that it breaks between minor versions.
Even from Karaf 2.2.x to Karaf 2.3.x I've seen third party features
break.
So it may seem that most features could decoupled from the underlying
version of Karaf, but practically this is not always the case.
An example: In the spring feature case, we also have the spring
deployer.
Where will the source of spring deployer will be hosted and which are
going
to be the versions of fileinstall and karaf that the deployer will be
built
against?
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
