Agree,
But I would prefer to have feature deployed by default than failure
without documentation.
I would add something like that in the xml-specs-api feature:
mvn:org.apache.camel.karaf/jre/${project.version}/properties
to provide a "preconfigured" jre.properties for Camel (hiding the
On Saturday, December 24, 2011 2:50:00 PM Jean-Baptiste Onofré wrote:
> Hi Dan,
>
> did you see my latest e-mail on this thread ?
>
> I don't see any problem, as camel-hdfs or camel-soap reference
> ServiceMix Specs JAXWS, which reference JAXB 2.2
> (javax.xml.bind*;version=2.2 and not just javax
Hi Dan,
did you see my latest e-mail on this thread ?
I don't see any problem, as camel-hdfs or camel-soap reference
ServiceMix Specs JAXWS, which reference JAXB 2.2
(javax.xml.bind*;version=2.2 and not just javax.xml.bind*).
So it means that without these changes, these features will never
On Saturday, December 24, 2011 4:29:53 PM Willem Jiang wrote:
> -1 for it.
> As it brokes CAMEL-4671 even we don't add the dependency of the
> xml-specs-api feature on the camel-core.
> And it make it wore, the user need to remove lots of xml-specs-api this
> time.
I would recommend backing out th
Today, I could successfully test all the features we had problems with in
Karaf 2.2.4. I will do the same for 2.8, but later today or tomorrow...
I think we could/should start a new release, if nobody has an urgent fix
which should be included.
@Hadrian: Do you have time to do it?
Best,
Christian
FYI,
karaf@root> packages:exports |grep -i bind
0 javax.xml.bind; version=0.0.0
0 javax.xml.bind.annotation; version=0.0.0
0 javax.xml.bind.annotation.adapters; version=0.0.0
0 javax.xml.bind.attachment; version=0.0.0
0 javax.xml.bind.helpers; version=0.0.0
0 javax.x
Really I don't understand.
camel-hdfs and camel-soap features don't work out of the box EVEN using
a JRE 1.6 profile (because the version mismatch): it's exactly the test
that I did on a Karaf 2.2.4, using a JDK 1.6 with jre-1.6 profile.
For me, it's worse to have camel-* features that didn't
Hi Dan,
just saw your revision [1] on ManagedRoute today where you cleaned up the
compiler warnings regarding the deprecated usage of the Route.shutdown()
API. IMHO we should better keep on that compiler warnings until the *right*
moment (3.x.y release) because:
At the time the commiter who inten
Please check out the comments of CAMEL-4671 here.
https://issues.apache.org/jira/browse/CAMEL-4671
On Sat Dec 24 16:26:17 2011, Jean-Baptiste Onofré wrote:
Other question, why it's not the same in Camel 2.9 ?
Regards
JB
On 12/24/2011 09:17 AM, Willem Jiang wrote:
Hi JB,
As the xml-specs-api
-1 for it.
As it brokes CAMEL-4671 even we don't add the dependency of the
xml-specs-api feature on the camel-core.
And it make it wore, the user need to remove lots of xml-specs-api this
time.
If we want to support to install the feature out of box, we may
consider to provide two kind of fea
Other question, why it's not the same in Camel 2.9 ?
Regards
JB
On 12/24/2011 09:17 AM, Willem Jiang wrote:
Hi JB,
As the xml-specs-api is included in the camel-core feature, you don't
need port these kind of patch to the camel-2.8.x branch.
On Sat Dec 24 00:20:23 2011, jbono...@apache.org wr
Hi Willem,
thanks for the udpate, I fix that.
Regards
JB
On 12/24/2011 09:17 AM, Willem Jiang wrote:
Hi JB,
As the xml-specs-api is included in the camel-core feature, you don't
need port these kind of patch to the camel-2.8.x branch.
On Sat Dec 24 00:20:23 2011, jbono...@apache.org wrote:
Hi JB,
As the xml-specs-api is included in the camel-core feature, you don't
need port these kind of patch to the camel-2.8.x branch.
On Sat Dec 24 00:20:23 2011, jbono...@apache.org wrote:
Author: jbonofre
Date: Fri Dec 23 16:20:23 2011
New Revision: 1222723
URL: http://svn.apache.org/viewv
13 matches
Mail list logo
