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." 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
We have faced the same issue in Camel before.
As you know we don't want Camel feature have the dependency on the specific
version of Karaf.
We don't specify the version of karaf feature which we want to use, and leave
it to Karaf container to pickup.
In this way we just leverage all the features
>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
wrote:
> What if it was first prototyped with Spring? Deployer, f
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,
Hi Charles, JB
I know there are issues with JSF, though myfaces should still work.
All the itests in Pax-Web for JSF do work, so myfaces itself should
still be an option.
For Pax-Web 3.0 we added special handlers for CDI which should also
improve working with JSF.
Still this is not optimal working
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
f
Hi Charles,
for Pax-Web there will be 3.0.0 which is capable of CDI, it depends on
Pax-CDI which will work with any CDI (weld, openbeans) framework.
regards, Achim
2012/10/18 Jean-Baptiste Onofré :
> Hi Charles,
>
> it sounds good to me, and it could be related to the other discussion about
> Ka
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
in
As a Karaf user I like the idea that JB proposes although I understand that
it might be hard to implement. I think that in order to externalize the
feature descriptors the feature mechanism must be stable in itself. I think
that is a requirement even for other projects to provide Karaf feature
desc
Yeah, I'm with Guillaume and Ioannis here.
-
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/
Yeah, that's also my fear. If we need to have a separate definition for
each karaf version, I'm not really sure there's a huge win in externalizing
those from the karaf branches.
Maybe that's not too much the case between 2.2 and 2.3, but I kinda fear
2.3 / 3.0 need a lot of changes, even in some
Hi Ioannis,
about the Spring deployer, it doesn't depend to the Spring features itself.
For instance, in 2.3.0, you can see:
karaf@root> la|grep -i spring
[ 16] [Active ] [Created ] [ 28] Apache Karaf :: Deployer ::
Spring (2.3.0)
without the Spring feature installé:
karaf@root>
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.
S
Hi Christoph,
We got an update from David: it should be done at OSGi directly.
Regards
JB
On 10/18/2012 09:13 AM, Christoph Gritschenberger wrote:
Sounds like a good idea.
Wouldn't it also make sense to include the recompiled osgi-4.3-specs
there? JB once said on IRC that the plan was to incl
Sounds like a good idea.
Wouldn't it also make sense to include the recompiled osgi-4.3-specs
there? JB once said on IRC that the plan was to include them in felix,
but until that happens maybe that's a place to put them.
kind regards,
christoph
On 18/10/12 09:09, Charles Moulliard wrote:
> I co
I completely agree with this idea. That could also help us to provide a
kind of "web" repo of the different features available and include more
like Pax Web, KarafEE, Camel, CXf, ActiveMQ, JClouds,
On Thu, Oct 18, 2012 at 9:04 AM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> Currently, Karaf pr
Hi Charles,
it sounds good to me, and it could be related to the other discussion
about Karaf Features sub-project ;)
Regards
JB
On 10/18/2012 09:06 AM, Charles Moulliard wrote:
Hi,
As you probably knows we have working very hard to propose a CDI container
top of Karaf (weld-osgi, openejb,
Hi guys,
in order to identify issues on Karaf Pax-Exam tooling, I created a Jira
component named karaf-exam.
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Hi,
As you probably knows we have working very hard to propose a CDI container
top of Karaf (weld-osgi, openejb, openwbbeans, ...). This is almost done (=
KarafEE) and work will be presented at ApacheCon 2012. I would like to
suggest that we add to the enterprise features of Karaf this capability
Sure, I will.
Regards
JB
On 10/18/2012 09:00 AM, Charles Moulliard wrote:
Hi JB.
Can you put me in the loop when you will talk that with Achim ? I have
created another ticket this morning (http://team.ops4j.org/browse/PAXWEB-434
).
Regards,
Charles
On Thu, Oct 18, 2012 at 8:18 AM, Jean-Bapt
Hi all,
Currently, Karaf provides features that it doesn't use directly and
internally.
For instance, it's the case for:
- enterprise features (leveraging Aries),
- spring features
As those features are provided by Karaf, the features version is coupled
to the Karaf version.
For instance, Ka
Hi JB.
Can you put me in the loop when you will talk that with Achim ? I have
created another ticket this morning (http://team.ops4j.org/browse/PAXWEB-434
).
Regards,
Charles
On Thu, Oct 18, 2012 at 8:18 AM, Jean-Baptiste Onofré wrote:
> Hi Charles,
>
> the issues were in Pax Web. I know that
22 matches
Mail list logo