Hi David,
you made a great work and it would be a shame to not use it :)
The maven plugin refactoring is a great step forward and we have to use it.
We simply have to make a review/test/cleanup in the current trunk assemblies. I
raised Jira about that and I will do it.
Regards
JB
On Tue
Hey David,
On Tue, Jul 12, 2011 at 8:12 AM, David Jencks david_jen...@yahoo.com wrote:
You can include replacement jre.properties and other properties files in a
kar that will overwrite the existing ones. In any case you have to restart
the server to pick up the new files.
However
On Tue, Jul 12, 2011 at 8:23 AM, Charles Moulliard cmoulli...@gmail.com wrote:
Hi Andreas,
I don't think that we will delay the release of Karaf for 2-3 months
if we develop what I suggest. BTW, If we don't do that, our end users
will also have to wait maybe a couple of months also to have
Hi Bengt,
Thanks for your reminder and your feedback about your Karaf usage.
I also use Karaf as a pure container (used in Kalumet/AutoDeploy and
BuildEraser), so I have the same concerns as yours :)
I will plan your Jira on Karaf 3.0.0 as it parts of the
profiles/distributions/KAR
On Tue, Jul 12, 2011 at 1:42 PM, Daniel Kulp dk...@apache.org wrote:
On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote:
Hey David,
The problem isn't during assambling but to install e.g. CXF
afterwards. Please start an empty Karaf 3.x and try to install the CXF
features file. To make
Awesome Dan, very good news :)
Regards
JB
On Tue 12/07/11 13:42 , Daniel Kulp wrote::
On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote:
Hey David,
The problem isn't during assambling but to install e.g. CXF
afterwards. Please start an empty Karaf 3.x and try to install the CXF
I disagree with that. Jaxb, stax and other libraries provided by the JRE
work in OSGi afaik with the JRE implementation. People have complained in
the past that the default karaf behavior did not allow them to leverage
those technologies provided by the JRE, that's why we changed the exported
So it really seems like we need a way to incrementally modify at least
jre.properties and possibly the boot delegation property.
It isn't possible to use a fragment bundle with the framework as host to change
the (effective) jre.properties, is it?
If that won't work maybe we can merge property
Thanks JB - I just wanted to make sure that all use cases (especially mine
of course) are covered.
Looking forward to 3.0!
/Bengt
2011/7/12 Jean-Baptiste Onofré j...@nanthrax.net
Hi Bengt,
Thanks for your reminder and your feedback about your Karaf usage.
I also use Karaf as a pure
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved issued
in JIRA, with no outstanding items on 2.1.6. I would like to propose
two
1) Release 2.1.6 and mark it in JIRA as the EOL (no entry for 2.1.7). Or,
Not so sure about this... You can never know if not somebody jumps up
and provides two critical bug-fixes for 2.1.x because he needs it. On
the other side: is there really and possibility that this happens? If
we remove
+1 to option one. That said, is anything ever really EOL? The reality is
that if someone discovers a critical bug that keeps 2.1.7 from working,
we'll have a hard time saying Upgrade and go away. Its EOL, but with
limitations forced by reality.
+1 to de-allocating the Jenkins profile.
David,
From my experience, the only time I need to use a negation operator in
jre.properties is if I want to explictly show users (folks reading the
jre.properties file) that my implementation of Karaf does not use that
package. If I don't want a package from the jre to be used in my instance
of
I probably didn't explain my idea very well
I was thinking that the base jre.properties might have
javax.xml.bind
in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and
implementation shipped with java 6. If you needed say osgi-friendly jaxb 2.2
api and the separate
nothing else to say, Mike did a nice sum-up on it :-)
+1 for option one
+1 for de-allocating the Jenkins profile
regards, Achim
Am 12.07.2011 21:13, schrieb mikevan:
+1 to option one. That said, is anything ever really EOL? The reality is
that if someone discovers a critical bug that keeps
Sounds good to me.
On Tue, Jul 12, 2011 at 22:49, Achim Nierbeck bcanh...@googlemail.comwrote:
nothing else to say, Mike did a nice sum-up on it :-)
+1 for option one
+1 for de-allocating the Jenkins profile
regards, Achim
Am 12.07.2011 21:13, schrieb mikevan:
+1 to option one. That
Hm,
I'm not sure. For example you set the javax.xml.bind to version 2.1.3
because that is the one used since update 4
you're still able to deploy the 2.1.13 next to it and define your
dependencies to version [2.1.13, 2.2).
This way you are sure you use the one you need. If you leave the jre to
On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote:
On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote:
I probably didn't explain my idea very well
I was thinking that the base jre.properties might have
javax.xml.bind
in the jdk6 entry in it to indicate that it's using the jaxb
Hi Jamie,
1/ sounds good to me.
Regards
JB
On 07/12/2011 08:30 PM, Jamie G. wrote:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved
+1 for Option 1
Am 12.07.2011 20:30, schrieb Jamie G.:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved issued
in JIRA, with no
Another way just comes to my mind. Instead of using the jre.properties
we might just add a fragment bundle
containing only a manifest like the following:
Export-Package: ...
javax.xml.bind;version=2.1.3,\
Fragment-Host: system.bundle; extension:=framework
since it's a framework extension
I kinda like that
On Jul 12, 2011, at 4:14 PM, Achim Nierbeck wrote:
Another way just comes to my mind. Instead of using the jre.properties
we might just add a fragment bundle
containing only a manifest like the following:
Export-Package: ...
javax.xml.bind;version=2.1.3,\
if you are talking about spifly I'd rather avoid that since it perverts the
semantics of ServiceLoader.
In Geronimo we have something that while untested and needing to be added to
the boot class path reimplements ServiceLoader to work with the
ProviderRegistry and make ServiceLoader work with
+1 for option 1.
Freeman
On 2011-7-13, at 上午2:30, Jamie G. wrote:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved issued
in JIRA,
Non binding but I think EOL is great.
+1 for option 1.
/je
On Jul 12, 2011, at 7:18 PM, Freeman Fang wrote:
+1 for option 1.
Freeman
On 2011-7-13, at 上午2:30, Jamie G. wrote:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we
+1 for option 1.
On Wed, Jul 13, 2011 at 3:22 AM, Johan Edstrom seij...@gmail.com wrote:
Non binding but I think EOL is great.
+1 for option 1.
/je
On Jul 12, 2011, at 7:18 PM, Freeman Fang wrote:
+1 for option 1.
Freeman
On 2011-7-13, at 上午2:30, Jamie G. wrote:
Hi All,
As the
26 matches
Mail list logo
