Non binding and I too think EOL of 2.1 is okay. Its a bit fast though
for a project that is just 1 year old.
+1 for option 1.
There may be Camel and SMX users who are on Karaf 2.1. And they don't
migrate to new releases so often.
But I guess we can find out to help them if a critical issues is
di
Just to remind you that the purpose of this thread was to disucss -->
[PROPOSAL] Towards Karaf 3.0.0
On Wed, Jul 13, 2011 at 1:26 AM, David Jencks wrote:
> if you are talking about spifly I'd rather avoid that since it perverts the
> semantics of ServiceLoader.
>
> In Geronimo we have something
+1 for option 1.
On Wed, Jul 13, 2011 at 3:22 AM, Johan Edstrom 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,
>>>
>>> A
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
+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, wi
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
The issue is less the impl version than it is the api version. The API
version is just "2.1", not 2.1.13. What happens if the system is exported as
2.1 and we then add a "real" osgi engabled version that is also 2.1? The
API's are exactly the same, is just the "FactoryFinder" class that i
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,\
> ...
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
+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 outstan
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
I don`t really understand why it should not work to export the system
package as the version it really is.
So if the jdk 1.6 exports 2.1.0 for example we should export it as that.
Then a bundle could still require the version 2.1.13 and it should then
take a separate version from outside the jd
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 u
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
0.0.
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 2.1 api and
> implementation shipped with jav
On Tuesday, July 12, 2011 10:59:09 PM Achim Nierbeck wrote:
> I think the jaxb stuff is a very specific problem we have
> and I ran into that one quite a lot :-)
>
> my best practice has been to version the crucial part of the
> jre.properties.
> For example I did a versioning for jaxb like the fo
Sounds good to me.
On Tue, Jul 12, 2011 at 22:49, Achim Nierbeck wrote:
> 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 anyt
I think the jaxb stuff is a very specific problem we have
and I ran into that one quite a lot :-)
my best practice has been to version the crucial part of the
jre.properties.
For example I did a versioning for jaxb like the following in the
jre.properties:
javax.xml.bind;version=2.1, \
This way
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 keep
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 sno
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
+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.
Andre
> 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 2.
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 options;
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é
> Hi Bengt,
>
> Thanks for your reminder and your feedback about your Karaf usage.
>
> I also use Karaf as a pure container (used in
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
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
pac
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 CX
On Tue, Jul 12, 2011 at 1:42 PM, 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
>> features file. To make it ru
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 it run you have to modify the jre.properties
> and the bootdeleg
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 enhancement
Just a little input from a humble user of Karaf...
Karaf is not only used by other "projects" like ServiceMix and Geronimo. It
is also used by end users like me. For me, Karaf is a deployment container I
use to implement my products. I find it very hard to customize a Karaf
server for the purposes
32 matches
Mail list logo
