R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Andrea Cosentino <an...@yahoo.com.INVALID>]

+1 on each point.
I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
So I would go with attic and clearly states to use karaf



Inviato da Yahoo Mail su Android 
 
  Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,

If the ServiceMix project is fairly active for SMX Bundles and Specs, we
clearly have a "slow pace" on distribution releases.

Here, we have two approaches possible:

1. We clearly state on website and codebase that users should better use
Karaf and create their own custom distribution if needed.
2. We begin a regular pace in distribution release.

I think 1 makes more sense and it's worth to be mentioned in the SMX
distribution.

Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
- Update to Karaf 4.2.x
- Update to Camel 3.0.1
- Update on Activity
- Cleanup and improved SMX features
- Add itests in smx for coverage

Another more "important" decision would be to retire ServiceMix to attic
and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
Decanter, Cave, Cellar, ...).

I think it's fair to discuss about that as we don't see lot of activity
on ServiceMix distribution/releases.

Thoughts ?

Regards
JB
-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
  

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Gert,

My proposal about Karaf integration distribution was just to easily
"migrate" users.
If you think it could be addressed with documentation/migration guide,
that's good to me !

Regards
JB

On 30/01/2020 09:55, Gert Vanthienen wrote:
> L.S.,
> 
> Getting back to the original topic of this thread, this proposal makes
> a lot of sense.
> 
> I'm not sure we need a separate Karaf integration distribution, I
> think a migration document or some extra documentation on how to setup
> Karaf as an integration platform might be sufficient, but perhaps we
> better leave that up to the Karaf community? They're the ones that
> would have to support & maintain the extra distribution.
> 
> Apart from that, I agree it's time to move this project to the attic,
> so let's go for it!
> 
> Regards,
> 
> Gert Vanthienen
> 
> 
> On Tue, Jan 28, 2020 at 3:30 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> Hi Andrea,
>>
>> I fully agree with you.
>>
>> My proposal is basically:
>>
>> 1. Move SMX bundles and SMX specs as Karaf subproject
>> 2. Create Karaf Integration distribution at Karaf (as we have standard
>> and minimal distributions already)
>> 3. Provide a migration guide for SMX users
>> 4. Move ServiceMix project to attic
>>
>> Regards
>> JB
>>
>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>> +1 on each point.
>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
>>> So I would go with attic and clearly states to use karaf
>>>
>>>
>>>
>>> Inviato da Yahoo Mail su Android
>>>
>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,
>>>
>>> If the ServiceMix project is fairly active for SMX Bundles and Specs, we
>>> clearly have a "slow pace" on distribution releases.
>>>
>>> Here, we have two approaches possible:
>>>
>>> 1. We clearly state on website and codebase that users should better use
>>> Karaf and create their own custom distribution if needed.
>>> 2. We begin a regular pace in distribution release.
>>>
>>> I think 1 makes more sense and it's worth to be mentioned in the SMX
>>> distribution.
>>>
>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>> - Update to Karaf 4.2.x
>>> - Update to Camel 3.0.1
>>> - Update on Activity
>>> - Cleanup and improved SMX features
>>> - Add itests in smx for coverage
>>>
>>> Another more "important" decision would be to retire ServiceMix to attic
>>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
>>> Decanter, Cave, Cellar, ...).
>>>
>>> I think it's fair to discuss about that as we don't see lot of activity
>>> on ServiceMix distribution/releases.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Gert Vanthienen <ge...@gmail.com>]

L.S.,

Getting back to the original topic of this thread, this proposal makes
a lot of sense.

I'm not sure we need a separate Karaf integration distribution, I
think a migration document or some extra documentation on how to setup
Karaf as an integration platform might be sufficient, but perhaps we
better leave that up to the Karaf community? They're the ones that
would have to support & maintain the extra distribution.

Apart from that, I agree it's time to move this project to the attic,
so let's go for it!

Regards,

Gert Vanthienen


On Tue, Jan 28, 2020 at 3:30 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Andrea,
>
> I fully agree with you.
>
> My proposal is basically:
>
> 1. Move SMX bundles and SMX specs as Karaf subproject
> 2. Create Karaf Integration distribution at Karaf (as we have standard
> and minimal distributions already)
> 3. Provide a migration guide for SMX users
> 4. Move ServiceMix project to attic
>
> Regards
> JB
>
> On 28/01/2020 15:27, Andrea Cosentino wrote:
> > +1 on each point.
> > I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
> > So I would go with attic and clearly states to use karaf
> >
> >
> >
> > Inviato da Yahoo Mail su Android
> >
> >   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,
> >
> > If the ServiceMix project is fairly active for SMX Bundles and Specs, we
> > clearly have a "slow pace" on distribution releases.
> >
> > Here, we have two approaches possible:
> >
> > 1. We clearly state on website and codebase that users should better use
> > Karaf and create their own custom distribution if needed.
> > 2. We begin a regular pace in distribution release.
> >
> > I think 1 makes more sense and it's worth to be mentioned in the SMX
> > distribution.
> >
> > Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> > - Update to Karaf 4.2.x
> > - Update to Camel 3.0.1
> > - Update on Activity
> > - Cleanup and improved SMX features
> > - Add itests in smx for coverage
> >
> > Another more "important" decision would be to retire ServiceMix to attic
> > and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> > Decanter, Cave, Cellar, ...).
> >
> > I think it's fair to discuss about that as we don't see lot of activity
> > on ServiceMix distribution/releases.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Gert Vanthienen <ge...@gmail.com>]

L.S.,

That sounds like a good plan to me. There's quite a bit of overlap
between the currently active committers/PMC members on the ServiceMix
project and the Karaf community anyway.

Regards,

Gert Vanthienen

On Wed, Jan 29, 2020 at 6:55 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Krsysztof,
>
> I guess by community you mean the current committers and PMC members.
>
> What I propose (and we did that already for other Apache projects which
> moved to attic) is a "call to Karaf". Basically, we will ask to any
> committer and PMC member if they want to "follow" the project at Karaf
> and call for a vote at Karaf.
>
> I think it's the best way for two reasons:
> 1. it gives a chance to "active" ServiceMix committers/PMC members to
> still be involved at Karaf
> 2. it will allow to "clean" the list of committers/PMC members which
> currently contains lot of inactive people.
>
> Thoughts ?
>
> Regards
> JB
>
> On 28/01/2020 21:18, Krzysztof Sobkowiak wrote:
> > Hi
> >
> > I was thinking about this a long time last months, but had not too much courage to say this, because
> > I've spent a lot of time to resurect the ServiceMix 5 and work on the further releases. But actually
> > I have not too much time and power to spend so much time as before to work on the new releases. So,
> > it's time to clear the status of ServiceMix. Thanks JB for starting of the theme.
> >
> > As we cannot guarantee to provide new regular releases, I second your opinion not to provide the
> > next releases and move ServiceMix project to attic.
> >
> > I propose to
> > - move the Bundles and Specs to Karaf as subprojects
> > - provide Integration features in Karaf and Karaf Integration distribution as proposed by JB
> > - provide integration documentation in Karaf + migration guide
> > - contribute the Activiti features to Activiti project (can be part of Integration features in Karaf
> > at the beginning)
> > - move the ServiceMix project to attic
> >
> > The open question: what about the active community members? Would they be merged to Karaf community
> > too?
> >
> >
> > Best regards
> > Krzysztof
> >
> > On Tue, 2020-01-28 at 15:30 +0100, Jean-Baptiste Onofré wrote:
> >> Hi Andrea,
> >>
> >> I fully agree with you.
> >>
> >> My proposal is basically:
> >>
> >> 1. Move SMX bundles and SMX specs as Karaf subproject
> >> 2. Create Karaf Integration distribution at Karaf (as we have standard
> >> and minimal distributions already)
> >> 3. Provide a migration guide for SMX users
> >> 4. Move ServiceMix project to attic
> >>
> >> Regards
> >> JB
> >>
> >> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>> +1 on each point.
> >>> I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
> >>> So I would go with attic and clearly states to use karaf
> >>>
> >>>
> >>>
> >>> Inviato da Yahoo Mail su Android
> >>>
> >>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,
> >>>
> >>> If the ServiceMix project is fairly active for SMX Bundles and Specs, we
> >>> clearly have a "slow pace" on distribution releases.
> >>>
> >>> Here, we have two approaches possible:
> >>>
> >>> 1. We clearly state on website and codebase that users should better use
> >>> Karaf and create their own custom distribution if needed.
> >>> 2. We begin a regular pace in distribution release.
> >>>
> >>> I think 1 makes more sense and it's worth to be mentioned in the SMX
> >>> distribution.
> >>>
> >>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>> - Update to Karaf 4.2.x
> >>> - Update to Camel 3.0.1
> >>> - Update on Activity
> >>> - Cleanup and improved SMX features
> >>> - Add itests in smx for coverage
> >>>
> >>> Another more "important" decision would be to retire ServiceMix to attic
> >>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> >>> Decanter, Cave, Cellar, ...).
> >>>
> >>> I think it's fair to discuss about that as we don't see lot of activity
> >>> on ServiceMix distribution/releases.
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Krsysztof,

I guess by community you mean the current committers and PMC members.

What I propose (and we did that already for other Apache projects which
moved to attic) is a "call to Karaf". Basically, we will ask to any
committer and PMC member if they want to "follow" the project at Karaf
and call for a vote at Karaf.

I think it's the best way for two reasons:
1. it gives a chance to "active" ServiceMix committers/PMC members to
still be involved at Karaf
2. it will allow to "clean" the list of committers/PMC members which
currently contains lot of inactive people.

Thoughts ?

Regards
JB

On 28/01/2020 21:18, Krzysztof Sobkowiak wrote:
> Hi
> 
> I was thinking about this a long time last months, but had not too much courage to say this, because
> I've spent a lot of time to resurect the ServiceMix 5 and work on the further releases. But actually
> I have not too much time and power to spend so much time as before to work on the new releases. So,
> it's time to clear the status of ServiceMix. Thanks JB for starting of the theme.
> 
> As we cannot guarantee to provide new regular releases, I second your opinion not to provide the
> next releases and move ServiceMix project to attic.
> 
> I propose to 
> - move the Bundles and Specs to Karaf as subprojects
> - provide Integration features in Karaf and Karaf Integration distribution as proposed by JB
> - provide integration documentation in Karaf + migration guide
> - contribute the Activiti features to Activiti project (can be part of Integration features in Karaf
> at the beginning)
> - move the ServiceMix project to attic
> 
> The open question: what about the active community members? Would they be merged to Karaf community
> too? 
> 
> 
> Best regards
> Krzysztof
> 
> On Tue, 2020-01-28 at 15:30 +0100, Jean-Baptiste Onofré wrote:
>> Hi Andrea,
>>
>> I fully agree with you.
>>
>> My proposal is basically:
>>
>> 1. Move SMX bundles and SMX specs as Karaf subproject
>> 2. Create Karaf Integration distribution at Karaf (as we have standard
>> and minimal distributions already)
>> 3. Provide a migration guide for SMX users
>> 4. Move ServiceMix project to attic
>>
>> Regards
>> JB
>>
>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>> +1 on each point.
>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
>>> So I would go with attic and clearly states to use karaf
>>>
>>>
>>>
>>> Inviato da Yahoo Mail su Android 
>>>  
>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,
>>>
>>> If the ServiceMix project is fairly active for SMX Bundles and Specs, we
>>> clearly have a "slow pace" on distribution releases.
>>>
>>> Here, we have two approaches possible:
>>>
>>> 1. We clearly state on website and codebase that users should better use
>>> Karaf and create their own custom distribution if needed.
>>> 2. We begin a regular pace in distribution release.
>>>
>>> I think 1 makes more sense and it's worth to be mentioned in the SMX
>>> distribution.
>>>
>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>> - Update to Karaf 4.2.x
>>> - Update to Camel 3.0.1
>>> - Update on Activity
>>> - Cleanup and improved SMX features
>>> - Add itests in smx for coverage
>>>
>>> Another more "important" decision would be to retire ServiceMix to attic
>>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
>>> Decanter, Cave, Cellar, ...).
>>>
>>> I think it's fair to discuss about that as we don't see lot of activity
>>> on ServiceMix distribution/releases.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
> 
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Krzysztof Sobkowiak <kr...@gmail.com>]

Hi

I was thinking about this a long time last months, but had not too much courage to say this, because
I've spent a lot of time to resurect the ServiceMix 5 and work on the further releases. But actually
I have not too much time and power to spend so much time as before to work on the new releases. So,
it's time to clear the status of ServiceMix. Thanks JB for starting of the theme.

As we cannot guarantee to provide new regular releases, I second your opinion not to provide the
next releases and move ServiceMix project to attic.

I propose to 
- move the Bundles and Specs to Karaf as subprojects
- provide Integration features in Karaf and Karaf Integration distribution as proposed by JB
- provide integration documentation in Karaf + migration guide
- contribute the Activiti features to Activiti project (can be part of Integration features in Karaf
at the beginning)
- move the ServiceMix project to attic

The open question: what about the active community members? Would they be merged to Karaf community
too? 


Best regards
Krzysztof

On Tue, 2020-01-28 at 15:30 +0100, Jean-Baptiste Onofré wrote:
> Hi Andrea,
> 
> I fully agree with you.
> 
> My proposal is basically:
> 
> 1. Move SMX bundles and SMX specs as Karaf subproject
> 2. Create Karaf Integration distribution at Karaf (as we have standard
> and minimal distributions already)
> 3. Provide a migration guide for SMX users
> 4. Move ServiceMix project to attic
> 
> Regards
> JB
> 
> On 28/01/2020 15:27, Andrea Cosentino wrote:
> > +1 on each point.
> > I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
> > So I would go with attic and clearly states to use karaf
> > 
> > 
> > 
> > Inviato da Yahoo Mail su Android 
> >  
> >   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,
> > 
> > If the ServiceMix project is fairly active for SMX Bundles and Specs, we
> > clearly have a "slow pace" on distribution releases.
> > 
> > Here, we have two approaches possible:
> > 
> > 1. We clearly state on website and codebase that users should better use
> > Karaf and create their own custom distribution if needed.
> > 2. We begin a regular pace in distribution release.
> > 
> > I think 1 makes more sense and it's worth to be mentioned in the SMX
> > distribution.
> > 
> > Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> > - Update to Karaf 4.2.x
> > - Update to Camel 3.0.1
> > - Update on Activity
> > - Cleanup and improved SMX features
> > - Add itests in smx for coverage
> > 
> > Another more "important" decision would be to retire ServiceMix to attic
> > and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> > Decanter, Cave, Cellar, ...).
> > 
> > I think it's fair to discuss about that as we don't see lot of activity
> > on ServiceMix distribution/releases.
> > 
> > Thoughts ?
> > 
> > Regards
> > JB
> > 

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Basically, something like bundle:install desc:mvn:...my-bundle-1.json

and all is in my-bundle-1.json

It's the PoC I started.

Regards
JB

On 30/01/2020 08:07, Jean-Baptiste Onofré wrote:
> Hi,
> 
> It's more than just manifest.
> 
> And I think it's better to only have the descriptor location on the URL
> nothing else.
> All should be described in the descriptor (locations of the jar
> resources, meta/headers, ...).
> 
> Regards
> JB
> 
> On 30/01/2020 08:01, Grzegorz Grzybek wrote:
>> Hello
>>
>> śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
>>
>>> Good point ;)
>>>
>>> What about bundledesc ?
>>>
>>
>> Naming is hard ;) manifest:// maybe?
>>
>> I imagined also this scenario - if this manifest is an XML file (or JSON,
>> or whatever structured doc), it could contain MORE than one manifest. For
>> example a manifest for "tomcat" or for "spring framework" usually sharing
>> groupId. So a manifest could be e.g.,
>> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
>> (or similar) meaning that the bundle description should be fetched from
>> mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
>> particular - from "spring-core" section of this manifest.
>>
>> But that's just an idea.
>>
>> regards
>> Grzegorz Grzybek
>>
>>
>>> Regards
>>> JB
>>>
>>> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
>>>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> napisał(a):
>>>>
>>>>> The descriptor will a URL, so, they can be embedded in Karaf and then we
>>>>> can use file: URL, or available on Karaf website/Maven Central, and then
>>>>> we can use mvn or http URL as well.
>>>>>
>>>>> The bundle generator descriptor will contain the META and the overriding
>>>>> resources locations.
>>>>>
>>>>> For instance:
>>>>>
>>>>> my-bundle-descriptor-1.0.json
>>>>> {
>>>>> "base-location": "mvn:....jar",
>>>>> "Import-Package": "...",
>>>>> "Export-Package": "...",
>>>>> "resources":["mvn...jar","..."]
>>>>> }
>>>>>
>>>>> I already started a PoC like this while ago introducing a new URL
>>>>> handler "bundle:".
>>>>>
>>>>
>>>> This looks cool - exactly what I was thinking about - instead of relying
>>> on
>>>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes bad,
>>>> because sometimes authors of libraries do not know much about OSGi),
>>> have a
>>>> descriptor pointing to a location of (possibly not OSGi-aware) a library.
>>>>
>>>> But I'd use different protocol than "bundle:" which is used by Felix, I
>>>> think.
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>>
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
>>>>>> Hi
>>>>>>
>>>>>> Good idea about not having it as part of featuresService
>>>>> (featuresProcessor
>>>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
>>>>>> keeping some generic descriptors instead of building/voting/releasing
>>> SMX
>>>>>> bundles and generating actual bundles on the fly would be a good idea.
>>>>>>
>>>>>> Where those descriptors could be stored? In some Karaf subdirectory
>>> maybe
>>>>>> (etc/)? Currently I see 413 subdirectories of
>>>>>> github/apache/servicemix-bundles repo, All of those could be in single
>>>>> XML
>>>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
>>> additional
>>>>>> resources, this generic (by default) generator descriptor could be
>>>>> tweaked
>>>>>> to load/shade/repackage additional resources...
>>>>>>
>>>>>> Anyway - I see it can be changed without huge effort.
>>>>>>
>>>>>> regards
>>>>>> Grzegorz Grzybek
>>>>>>
>>>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>> napisał(a):
>>>>>>
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> For bundles, as separate project, I have more the idea of
>>> "descriptor".
>>>>>>>
>>>>>>> It's something I proposed while ago.
>>>>>>>
>>>>>>> Instead of storing the concrete artifacts, I would rather store the
>>>>> meta.
>>>>>>> However, some bundles needs "resources" (like META-INF/foo or code).
>>>>>>>
>>>>>>> So, basically, I agree with a "dynamic" processing, however, I don't
>>>>>>> think it's good to have this in feature.
>>>>>>> I would rather add a "bundle generator" service, generic, that can
>>>>>>> easily be used outside Karaf.
>>>>>>> The bundle generator service can read artifact from Central or any
>>>>>>> repository, than, he reads META descriptor and overriding resources
>>>>>>> (from karaf-bundles repo for instances) and generates a concrete
>>> bundle
>>>>>>> on the fly.
>>>>>>> Big advantage is that it's easy to change the META/bundle on the fly.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> I can't tell much about SMX, but I fully agree about focusing on
>>> Karaf.
>>>>>>>>
>>>>>>>> About specs/bundles - good to have them as separate projects of Karaf
>>>>>>> (but
>>>>>>>> not in the same github/apache/karaf repo!), but for bundles I may
>>> have
>>>>>>>> different proposal... There's
>>>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
>>>>> local
>>>>>>>> implementation. I needed a mechanism to declaratively override
>>> bundle's
>>>>>>>> headers without touching the bundle. Similar to what we have with
>>>>> feature
>>>>>>>> override/blacklisting.
>>>>>>>>
>>>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
>>>>>>> something
>>>>>>>> like this:
>>>>>>>>
>>>>>>>> <bundleProcessing>
>>>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
>>>>>>>>         <add header="Processed-By" value="Karaf Bundle Processor" />
>>>>>>>>         <clause header="Import-Package" name="javax.servlet"
>>>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
>>>>>>>>         <clause header="Import-Package"
>>> name="javax.servlet.annotation"
>>>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>>>>>>>>         <clause header="Import-Package"
>>> name="javax.servlet.descriptor"
>>>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>>>>>>>>         <clause header="Import-Package" name="javax.servlet.http"
>>>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
>>>>>>>>     </bundle>
>>>>>>>> </bundleProcessing>
>>>>>>>>
>>>>>>>> which does exactly what it shows - for all bundles (installed with
>>>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
>>>>> manifest
>>>>>>>> clauses. I didn't need this mechanism after all, because I could make
>>>>>>> Jetty
>>>>>>>> run with Servlet API 4 using "compatibility fragment bundle" that
>>> adds
>>>>>>>> extended exports to javax.servlet:javax.servlet-api.
>>>>>>>>
>>>>>>>> What I was thinking about (even back in 2009
>>>>>>>> <https://www.theserverside.com/discussions/thread/53803.html#305391
>>>> )
>>>>>>> is to
>>>>>>>> maybe extend the above mechanism to get rid of SMX bundles entirely?
>>> I
>>>>>>>> know, I know, there's "wrap:" protocol where you can specify headers
>>> in
>>>>>>> URI
>>>>>>>> itself, but it's not that easy to use. So instead of releasing SMX
>>>>>>> bundles,
>>>>>>>> we can just release the above alteration definitions (somehow).
>>>>>>>> I know there are 10000 things I didn't think about (like what to do
>>> if
>>>>>>> you
>>>>>>>> don't use Karaf features where featuresService can apply the above
>>>>>>>> manipulation), but maybe it's worth trying?
>>>>>>>>
>>>>>>>> regards
>>>>>>>> Grzegorz Grzybek
>>>>>>>>
>>>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>>> napisał(a):
>>>>>>>>
>>>>>>>>> Hi Andrea,
>>>>>>>>>
>>>>>>>>> I fully agree with you.
>>>>>>>>>
>>>>>>>>> My proposal is basically:
>>>>>>>>>
>>>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
>>>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
>>> standard
>>>>>>>>> and minimal distributions already)
>>>>>>>>> 3. Provide a migration guide for SMX users
>>>>>>>>> 4. Move ServiceMix project to attic
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>>>>>>>>> +1 on each point.
>>>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
>>>>>>>>> releases..
>>>>>>>>>> So I would go with attic and clearly states to use karaf
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Inviato da Yahoo Mail su Android
>>>>>>>>>>
>>>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
>>>>>>> jb@nanthrax.net>
>>>>>>>>> ha scritto:   Hi guys,
>>>>>>>>>>
>>>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
>>> Specs,
>>>>>>> we
>>>>>>>>>> clearly have a "slow pace" on distribution releases.
>>>>>>>>>>
>>>>>>>>>> Here, we have two approaches possible:
>>>>>>>>>>
>>>>>>>>>> 1. We clearly state on website and codebase that users should
>>> better
>>>>>>> use
>>>>>>>>>> Karaf and create their own custom distribution if needed.
>>>>>>>>>> 2. We begin a regular pace in distribution release.
>>>>>>>>>>
>>>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in the
>>> SMX
>>>>>>>>>> distribution.
>>>>>>>>>>
>>>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>>>>>>>>> - Update to Karaf 4.2.x
>>>>>>>>>> - Update to Camel 3.0.1
>>>>>>>>>> - Update on Activity
>>>>>>>>>> - Cleanup and improved SMX features
>>>>>>>>>> - Add itests in smx for coverage
>>>>>>>>>>
>>>>>>>>>> Another more "important" decision would be to retire ServiceMix to
>>>>>>> attic
>>>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
>>> Karaf
>>>>>>>>>> Decanter, Cave, Cellar, ...).
>>>>>>>>>>
>>>>>>>>>> I think it's fair to discuss about that as we don't see lot of
>>>>> activity
>>>>>>>>>> on ServiceMix distribution/releases.
>>>>>>>>>>
>>>>>>>>>> Thoughts ?
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

+1 for that

regards
Grzegorz Grzybek

czw., 30 sty 2020 o 08:33 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> Actually, I was thinking about a dedicated module/service in Pax URL.
>
> Something like pax-url-descriptor introducing a dedicated protocol suffix.
>
> Regards
> JB
>
> On 30/01/2020 08:17, Grzegorz Grzybek wrote:
> > czw., 30 sty 2020 o 08:13 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
> >
> >> Good point and actually I was thinking about improving pax-url-wrap.
> >>
> >
> > Great - it could be based on wrap:. But with clear distinction IMO:
> >  - wrap: is using bndlib and the URI parameters are BND instructions
> >  - wrap2: (or desc: or whatever) is NOT using bndlib and everything is
> just
> > in external manifest
> >
> > the external manifest of course could have tooling to generate it, but
> the
> > point should be "generate/write once". wrap: is generating manifest on
> each
> > resolution.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >>
> >>
> >> On 30/01/2020 08:12, Grzegorz Grzybek wrote:
> >>> czw., 30 sty 2020 o 08:07 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi,
> >>>>
> >>>> It's more than just manifest.
> >>>>
> >>>> And I think it's better to only have the descriptor location on the
> URL
> >>>> nothing else.
> >>>> All should be described in the descriptor (locations of the jar
> >>>> resources, meta/headers, ...).
> >>>>
> >>>
> >>> Do you think it can be done at pax-url level? Everything that works is
> >>> great. I think the most important goal is to NOT require an ASF release
> >>> (i.e., SMX bundles with build, repackaging and deployment). THough if
> >> it's
> >>> part of Karaf, we'll need a vote and release anyway. I'll think about
> it
> >> in
> >>> the background ;)
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>>
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 30/01/2020 08:01, Grzegorz Grzybek wrote:
> >>>>> Hello
> >>>>>
> >>>>> śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>> napisał(a):
> >>>>>
> >>>>>> Good point ;)
> >>>>>>
> >>>>>> What about bundledesc ?
> >>>>>>
> >>>>>
> >>>>> Naming is hard ;) manifest:// maybe?
> >>>>>
> >>>>> I imagined also this scenario - if this manifest is an XML file (or
> >> JSON,
> >>>>> or whatever structured doc), it could contain MORE than one manifest.
> >> For
> >>>>> example a manifest for "tomcat" or for "spring framework" usually
> >> sharing
> >>>>> groupId. So a manifest could be e.g.,
> >>>>>
> >>>>
> >>
> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
> >>>>> (or similar) meaning that the bundle description should be fetched
> from
> >>>>> mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
> >>>>> particular - from "spring-core" section of this manifest.
> >>>>>
> >>>>> But that's just an idea.
> >>>>>
> >>>>> regards
> >>>>> Grzegorz Grzybek
> >>>>>
> >>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
> >>>>>>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>>>> napisał(a):
> >>>>>>>
> >>>>>>>> The descriptor will a URL, so, they can be embedded in Karaf and
> >> then
> >>>> we
> >>>>>>>> can use file: URL, or available on Karaf website/Maven Central,
> and
> >>>> then
> >>>>>>>> we can use mvn or http URL as well.
> >>>>>>>>
> >>>>>>>> The bundle generator descriptor will contain the META and the
> >>>> overriding
> >>>>>>>> resources locations.
> >>>>>>>>
> >>>>>>>> For instance:
> >>>>>>>>
> >>>>>>>> my-bundle-descriptor-1.0.json
> >>>>>>>> {
> >>>>>>>> "base-location": "mvn:....jar",
> >>>>>>>> "Import-Package": "...",
> >>>>>>>> "Export-Package": "...",
> >>>>>>>> "resources":["mvn...jar","..."]
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> I already started a PoC like this while ago introducing a new URL
> >>>>>>>> handler "bundle:".
> >>>>>>>>
> >>>>>>>
> >>>>>>> This looks cool - exactly what I was thinking about - instead of
> >>>> relying
> >>>>>> on
> >>>>>>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes
> >>>> bad,
> >>>>>>> because sometimes authors of libraries do not know much about
> OSGi),
> >>>>>> have a
> >>>>>>> descriptor pointing to a location of (possibly not OSGi-aware) a
> >>>> library.
> >>>>>>>
> >>>>>>> But I'd use different protocol than "bundle:" which is used by
> >> Felix, I
> >>>>>>> think.
> >>>>>>>
> >>>>>>> regards
> >>>>>>> Grzegorz Grzybek
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>>
> >>>>>>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>> Good idea about not having it as part of featuresService
> >>>>>>>> (featuresProcessor
> >>>>>>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?).
> >>>> Indeed
> >>>>>>>>> keeping some generic descriptors instead of
> >> building/voting/releasing
> >>>>>> SMX
> >>>>>>>>> bundles and generating actual bundles on the fly would be a good
> >>>> idea.
> >>>>>>>>>
> >>>>>>>>> Where those descriptors could be stored? In some Karaf
> subdirectory
> >>>>>> maybe
> >>>>>>>>> (etc/)? Currently I see 413 subdirectories of
> >>>>>>>>> github/apache/servicemix-bundles repo, All of those could be in
> >>>> single
> >>>>>>>> XML
> >>>>>>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
> >>>>>> additional
> >>>>>>>>> resources, this generic (by default) generator descriptor could
> be
> >>>>>>>> tweaked
> >>>>>>>>> to load/shade/repackage additional resources...
> >>>>>>>>>
> >>>>>>>>> Anyway - I see it can be changed without huge effort.
> >>>>>>>>>
> >>>>>>>>> regards
> >>>>>>>>> Grzegorz Grzybek
> >>>>>>>>>
> >>>>>>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>>>>>> napisał(a):
> >>>>>>>>>
> >>>>>>>>>> Hi Greg,
> >>>>>>>>>>
> >>>>>>>>>> For bundles, as separate project, I have more the idea of
> >>>>>> "descriptor".
> >>>>>>>>>>
> >>>>>>>>>> It's something I proposed while ago.
> >>>>>>>>>>
> >>>>>>>>>> Instead of storing the concrete artifacts, I would rather store
> >> the
> >>>>>>>> meta.
> >>>>>>>>>> However, some bundles needs "resources" (like META-INF/foo or
> >> code).
> >>>>>>>>>>
> >>>>>>>>>> So, basically, I agree with a "dynamic" processing, however, I
> >> don't
> >>>>>>>>>> think it's good to have this in feature.
> >>>>>>>>>> I would rather add a "bundle generator" service, generic, that
> can
> >>>>>>>>>> easily be used outside Karaf.
> >>>>>>>>>> The bundle generator service can read artifact from Central or
> any
> >>>>>>>>>> repository, than, he reads META descriptor and overriding
> >> resources
> >>>>>>>>>> (from karaf-bundles repo for instances) and generates a concrete
> >>>>>> bundle
> >>>>>>>>>> on the fly.
> >>>>>>>>>> Big advantage is that it's easy to change the META/bundle on the
> >>>> fly.
> >>>>>>>>>>
> >>>>>>>>>> Thoughts ?
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> JB
> >>>>>>>>>>
> >>>>>>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> >>>>>>>>>>> Hello
> >>>>>>>>>>>
> >>>>>>>>>>> I can't tell much about SMX, but I fully agree about focusing
> on
> >>>>>> Karaf.
> >>>>>>>>>>>
> >>>>>>>>>>> About specs/bundles - good to have them as separate projects of
> >>>> Karaf
> >>>>>>>>>> (but
> >>>>>>>>>>> not in the same github/apache/karaf repo!), but for bundles I
> may
> >>>>>> have
> >>>>>>>>>>> different proposal... There's
> >>>>>>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I
> >> have
> >>>>>>>> local
> >>>>>>>>>>> implementation. I needed a mechanism to declaratively override
> >>>>>> bundle's
> >>>>>>>>>>> headers without touching the bundle. Similar to what we have
> with
> >>>>>>>> feature
> >>>>>>>>>>> override/blacklisting.
> >>>>>>>>>>>
> >>>>>>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and
> adds
> >>>>>>>>>> something
> >>>>>>>>>>> like this:
> >>>>>>>>>>>
> >>>>>>>>>>> <bundleProcessing>
> >>>>>>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
> >>>>>>>>>>>         <add header="Processed-By" value="Karaf Bundle
> Processor"
> >>>> />
> >>>>>>>>>>>         <clause header="Import-Package" name="javax.servlet"
> >>>>>>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
> >>>>>>>>>>>         <clause header="Import-Package"
> >>>>>> name="javax.servlet.annotation"
> >>>>>>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
> >>>>>>>>>>>         <clause header="Import-Package"
> >>>>>> name="javax.servlet.descriptor"
> >>>>>>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
> >>>>>>>>>>>         <clause header="Import-Package"
> name="javax.servlet.http"
> >>>>>>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
> >>>>>>>>>>>     </bundle>
> >>>>>>>>>>> </bundleProcessing>
> >>>>>>>>>>>
> >>>>>>>>>>> which does exactly what it shows - for all bundles (installed
> >> with
> >>>>>>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
> >>>>>>>> manifest
> >>>>>>>>>>> clauses. I didn't need this mechanism after all, because I
> could
> >>>> make
> >>>>>>>>>> Jetty
> >>>>>>>>>>> run with Servlet API 4 using "compatibility fragment bundle"
> that
> >>>>>> adds
> >>>>>>>>>>> extended exports to javax.servlet:javax.servlet-api.
> >>>>>>>>>>>
> >>>>>>>>>>> What I was thinking about (even back in 2009
> >>>>>>>>>>> <
> >>>> https://www.theserverside.com/discussions/thread/53803.html#305391
> >>>>>>> )
> >>>>>>>>>> is to
> >>>>>>>>>>> maybe extend the above mechanism to get rid of SMX bundles
> >>>> entirely?
> >>>>>> I
> >>>>>>>>>>> know, I know, there's "wrap:" protocol where you can specify
> >>>> headers
> >>>>>> in
> >>>>>>>>>> URI
> >>>>>>>>>>> itself, but it's not that easy to use. So instead of releasing
> >> SMX
> >>>>>>>>>> bundles,
> >>>>>>>>>>> we can just release the above alteration definitions (somehow).
> >>>>>>>>>>> I know there are 10000 things I didn't think about (like what
> to
> >> do
> >>>>>> if
> >>>>>>>>>> you
> >>>>>>>>>>> don't use Karaf features where featuresService can apply the
> >> above
> >>>>>>>>>>> manipulation), but maybe it's worth trying?
> >>>>>>>>>>>
> >>>>>>>>>>> regards
> >>>>>>>>>>> Grzegorz Grzybek
> >>>>>>>>>>>
> >>>>>>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb@nanthrax.net
> >
> >>>>>>>>>> napisał(a):
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Andrea,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I fully agree with you.
> >>>>>>>>>>>>
> >>>>>>>>>>>> My proposal is basically:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
> >>>>>>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
> >>>>>> standard
> >>>>>>>>>>>> and minimal distributions already)
> >>>>>>>>>>>> 3. Provide a migration guide for SMX users
> >>>>>>>>>>>> 4. Move ServiceMix project to attic
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards
> >>>>>>>>>>>> JB
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>>>>>>>>>>>> +1 on each point.
> >>>>>>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee
> >> patch
> >>>>>>>>>>>> releases..
> >>>>>>>>>>>>> So I would go with attic and clearly states to use karaf
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Inviato da Yahoo Mail su Android
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
> >>>>>>>>>> jb@nanthrax.net>
> >>>>>>>>>>>> ha scritto:   Hi guys,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles
> and
> >>>>>> Specs,
> >>>>>>>>>> we
> >>>>>>>>>>>>> clearly have a "slow pace" on distribution releases.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Here, we have two approaches possible:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. We clearly state on website and codebase that users should
> >>>>>> better
> >>>>>>>>>> use
> >>>>>>>>>>>>> Karaf and create their own custom distribution if needed.
> >>>>>>>>>>>>> 2. We begin a regular pace in distribution release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in
> >> the
> >>>>>> SMX
> >>>>>>>>>>>>> distribution.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>>>>>>>>>>>> - Update to Karaf 4.2.x
> >>>>>>>>>>>>> - Update to Camel 3.0.1
> >>>>>>>>>>>>> - Update on Activity
> >>>>>>>>>>>>> - Cleanup and improved SMX features
> >>>>>>>>>>>>> - Add itests in smx for coverage
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Another more "important" decision would be to retire
> ServiceMix
> >>>> to
> >>>>>>>>>> attic
> >>>>>>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we
> have
> >>>>>> Karaf
> >>>>>>>>>>>>> Decanter, Cave, Cellar, ...).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think it's fair to discuss about that as we don't see lot
> of
> >>>>>>>> activity
> >>>>>>>>>>>>> on ServiceMix distribution/releases.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thoughts ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards
> >>>>>>>>>>>>> JB
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Baptiste Onofré
> >>>>>>>> jbonofre@apache.org
> >>>>>>>> http://blog.nanthrax.net
> >>>>>>>> Talend - http://www.talend.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Actually, I was thinking about a dedicated module/service in Pax URL.

Something like pax-url-descriptor introducing a dedicated protocol suffix.

Regards
JB

On 30/01/2020 08:17, Grzegorz Grzybek wrote:
> czw., 30 sty 2020 o 08:13 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 
>> Good point and actually I was thinking about improving pax-url-wrap.
>>
> 
> Great - it could be based on wrap:. But with clear distinction IMO:
>  - wrap: is using bndlib and the URI parameters are BND instructions
>  - wrap2: (or desc: or whatever) is NOT using bndlib and everything is just
> in external manifest
> 
> the external manifest of course could have tooling to generate it, but the
> point should be "generate/write once". wrap: is generating manifest on each
> resolution.
> 
> regards
> Grzegorz Grzybek
> 
> 
>>
>>
>> On 30/01/2020 08:12, Grzegorz Grzybek wrote:
>>> czw., 30 sty 2020 o 08:07 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi,
>>>>
>>>> It's more than just manifest.
>>>>
>>>> And I think it's better to only have the descriptor location on the URL
>>>> nothing else.
>>>> All should be described in the descriptor (locations of the jar
>>>> resources, meta/headers, ...).
>>>>
>>>
>>> Do you think it can be done at pax-url level? Everything that works is
>>> great. I think the most important goal is to NOT require an ASF release
>>> (i.e., SMX bundles with build, repackaging and deployment). THough if
>> it's
>>> part of Karaf, we'll need a vote and release anyway. I'll think about it
>> in
>>> the background ;)
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>>
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 30/01/2020 08:01, Grzegorz Grzybek wrote:
>>>>> Hello
>>>>>
>>>>> śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> Good point ;)
>>>>>>
>>>>>> What about bundledesc ?
>>>>>>
>>>>>
>>>>> Naming is hard ;) manifest:// maybe?
>>>>>
>>>>> I imagined also this scenario - if this manifest is an XML file (or
>> JSON,
>>>>> or whatever structured doc), it could contain MORE than one manifest.
>> For
>>>>> example a manifest for "tomcat" or for "spring framework" usually
>> sharing
>>>>> groupId. So a manifest could be e.g.,
>>>>>
>>>>
>> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
>>>>> (or similar) meaning that the bundle description should be fetched from
>>>>> mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
>>>>> particular - from "spring-core" section of this manifest.
>>>>>
>>>>> But that's just an idea.
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
>>>>>>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>> napisał(a):
>>>>>>>
>>>>>>>> The descriptor will a URL, so, they can be embedded in Karaf and
>> then
>>>> we
>>>>>>>> can use file: URL, or available on Karaf website/Maven Central, and
>>>> then
>>>>>>>> we can use mvn or http URL as well.
>>>>>>>>
>>>>>>>> The bundle generator descriptor will contain the META and the
>>>> overriding
>>>>>>>> resources locations.
>>>>>>>>
>>>>>>>> For instance:
>>>>>>>>
>>>>>>>> my-bundle-descriptor-1.0.json
>>>>>>>> {
>>>>>>>> "base-location": "mvn:....jar",
>>>>>>>> "Import-Package": "...",
>>>>>>>> "Export-Package": "...",
>>>>>>>> "resources":["mvn...jar","..."]
>>>>>>>> }
>>>>>>>>
>>>>>>>> I already started a PoC like this while ago introducing a new URL
>>>>>>>> handler "bundle:".
>>>>>>>>
>>>>>>>
>>>>>>> This looks cool - exactly what I was thinking about - instead of
>>>> relying
>>>>>> on
>>>>>>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes
>>>> bad,
>>>>>>> because sometimes authors of libraries do not know much about OSGi),
>>>>>> have a
>>>>>>> descriptor pointing to a location of (possibly not OSGi-aware) a
>>>> library.
>>>>>>>
>>>>>>> But I'd use different protocol than "bundle:" which is used by
>> Felix, I
>>>>>>> think.
>>>>>>>
>>>>>>> regards
>>>>>>> Grzegorz Grzybek
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Good idea about not having it as part of featuresService
>>>>>>>> (featuresProcessor
>>>>>>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?).
>>>> Indeed
>>>>>>>>> keeping some generic descriptors instead of
>> building/voting/releasing
>>>>>> SMX
>>>>>>>>> bundles and generating actual bundles on the fly would be a good
>>>> idea.
>>>>>>>>>
>>>>>>>>> Where those descriptors could be stored? In some Karaf subdirectory
>>>>>> maybe
>>>>>>>>> (etc/)? Currently I see 413 subdirectories of
>>>>>>>>> github/apache/servicemix-bundles repo, All of those could be in
>>>> single
>>>>>>>> XML
>>>>>>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
>>>>>> additional
>>>>>>>>> resources, this generic (by default) generator descriptor could be
>>>>>>>> tweaked
>>>>>>>>> to load/shade/repackage additional resources...
>>>>>>>>>
>>>>>>>>> Anyway - I see it can be changed without huge effort.
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Grzegorz Grzybek
>>>>>>>>>
>>>>>>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>>>> napisał(a):
>>>>>>>>>
>>>>>>>>>> Hi Greg,
>>>>>>>>>>
>>>>>>>>>> For bundles, as separate project, I have more the idea of
>>>>>> "descriptor".
>>>>>>>>>>
>>>>>>>>>> It's something I proposed while ago.
>>>>>>>>>>
>>>>>>>>>> Instead of storing the concrete artifacts, I would rather store
>> the
>>>>>>>> meta.
>>>>>>>>>> However, some bundles needs "resources" (like META-INF/foo or
>> code).
>>>>>>>>>>
>>>>>>>>>> So, basically, I agree with a "dynamic" processing, however, I
>> don't
>>>>>>>>>> think it's good to have this in feature.
>>>>>>>>>> I would rather add a "bundle generator" service, generic, that can
>>>>>>>>>> easily be used outside Karaf.
>>>>>>>>>> The bundle generator service can read artifact from Central or any
>>>>>>>>>> repository, than, he reads META descriptor and overriding
>> resources
>>>>>>>>>> (from karaf-bundles repo for instances) and generates a concrete
>>>>>> bundle
>>>>>>>>>> on the fly.
>>>>>>>>>> Big advantage is that it's easy to change the META/bundle on the
>>>> fly.
>>>>>>>>>>
>>>>>>>>>> Thoughts ?
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> I can't tell much about SMX, but I fully agree about focusing on
>>>>>> Karaf.
>>>>>>>>>>>
>>>>>>>>>>> About specs/bundles - good to have them as separate projects of
>>>> Karaf
>>>>>>>>>> (but
>>>>>>>>>>> not in the same github/apache/karaf repo!), but for bundles I may
>>>>>> have
>>>>>>>>>>> different proposal... There's
>>>>>>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I
>> have
>>>>>>>> local
>>>>>>>>>>> implementation. I needed a mechanism to declaratively override
>>>>>> bundle's
>>>>>>>>>>> headers without touching the bundle. Similar to what we have with
>>>>>>>> feature
>>>>>>>>>>> override/blacklisting.
>>>>>>>>>>>
>>>>>>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
>>>>>>>>>> something
>>>>>>>>>>> like this:
>>>>>>>>>>>
>>>>>>>>>>> <bundleProcessing>
>>>>>>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
>>>>>>>>>>>         <add header="Processed-By" value="Karaf Bundle Processor"
>>>> />
>>>>>>>>>>>         <clause header="Import-Package" name="javax.servlet"
>>>>>>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
>>>>>>>>>>>         <clause header="Import-Package"
>>>>>> name="javax.servlet.annotation"
>>>>>>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>>>>>>>>>>>         <clause header="Import-Package"
>>>>>> name="javax.servlet.descriptor"
>>>>>>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>>>>>>>>>>>         <clause header="Import-Package" name="javax.servlet.http"
>>>>>>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
>>>>>>>>>>>     </bundle>
>>>>>>>>>>> </bundleProcessing>
>>>>>>>>>>>
>>>>>>>>>>> which does exactly what it shows - for all bundles (installed
>> with
>>>>>>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
>>>>>>>> manifest
>>>>>>>>>>> clauses. I didn't need this mechanism after all, because I could
>>>> make
>>>>>>>>>> Jetty
>>>>>>>>>>> run with Servlet API 4 using "compatibility fragment bundle" that
>>>>>> adds
>>>>>>>>>>> extended exports to javax.servlet:javax.servlet-api.
>>>>>>>>>>>
>>>>>>>>>>> What I was thinking about (even back in 2009
>>>>>>>>>>> <
>>>> https://www.theserverside.com/discussions/thread/53803.html#305391
>>>>>>> )
>>>>>>>>>> is to
>>>>>>>>>>> maybe extend the above mechanism to get rid of SMX bundles
>>>> entirely?
>>>>>> I
>>>>>>>>>>> know, I know, there's "wrap:" protocol where you can specify
>>>> headers
>>>>>> in
>>>>>>>>>> URI
>>>>>>>>>>> itself, but it's not that easy to use. So instead of releasing
>> SMX
>>>>>>>>>> bundles,
>>>>>>>>>>> we can just release the above alteration definitions (somehow).
>>>>>>>>>>> I know there are 10000 things I didn't think about (like what to
>> do
>>>>>> if
>>>>>>>>>> you
>>>>>>>>>>> don't use Karaf features where featuresService can apply the
>> above
>>>>>>>>>>> manipulation), but maybe it's worth trying?
>>>>>>>>>>>
>>>>>>>>>>> regards
>>>>>>>>>>> Grzegorz Grzybek
>>>>>>>>>>>
>>>>>>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>>>>>> napisał(a):
>>>>>>>>>>>
>>>>>>>>>>>> Hi Andrea,
>>>>>>>>>>>>
>>>>>>>>>>>> I fully agree with you.
>>>>>>>>>>>>
>>>>>>>>>>>> My proposal is basically:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
>>>>>>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
>>>>>> standard
>>>>>>>>>>>> and minimal distributions already)
>>>>>>>>>>>> 3. Provide a migration guide for SMX users
>>>>>>>>>>>> 4. Move ServiceMix project to attic
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> JB
>>>>>>>>>>>>
>>>>>>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>>>>>>>>>>>> +1 on each point.
>>>>>>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee
>> patch
>>>>>>>>>>>> releases..
>>>>>>>>>>>>> So I would go with attic and clearly states to use karaf
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Inviato da Yahoo Mail su Android
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
>>>>>>>>>> jb@nanthrax.net>
>>>>>>>>>>>> ha scritto:   Hi guys,
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
>>>>>> Specs,
>>>>>>>>>> we
>>>>>>>>>>>>> clearly have a "slow pace" on distribution releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here, we have two approaches possible:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. We clearly state on website and codebase that users should
>>>>>> better
>>>>>>>>>> use
>>>>>>>>>>>>> Karaf and create their own custom distribution if needed.
>>>>>>>>>>>>> 2. We begin a regular pace in distribution release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in
>> the
>>>>>> SMX
>>>>>>>>>>>>> distribution.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>>>>>>>>>>>> - Update to Karaf 4.2.x
>>>>>>>>>>>>> - Update to Camel 3.0.1
>>>>>>>>>>>>> - Update on Activity
>>>>>>>>>>>>> - Cleanup and improved SMX features
>>>>>>>>>>>>> - Add itests in smx for coverage
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another more "important" decision would be to retire ServiceMix
>>>> to
>>>>>>>>>> attic
>>>>>>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
>>>>>> Karaf
>>>>>>>>>>>>> Decanter, Cave, Cellar, ...).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it's fair to discuss about that as we don't see lot of
>>>>>>>> activity
>>>>>>>>>>>>> on ServiceMix distribution/releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> JB
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

czw., 30 sty 2020 o 08:13 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> Good point and actually I was thinking about improving pax-url-wrap.
>

Great - it could be based on wrap:. But with clear distinction IMO:
 - wrap: is using bndlib and the URI parameters are BND instructions
 - wrap2: (or desc: or whatever) is NOT using bndlib and everything is just
in external manifest

the external manifest of course could have tooling to generate it, but the
point should be "generate/write once". wrap: is generating manifest on each
resolution.

regards
Grzegorz Grzybek


>
>
> On 30/01/2020 08:12, Grzegorz Grzybek wrote:
> > czw., 30 sty 2020 o 08:07 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi,
> >>
> >> It's more than just manifest.
> >>
> >> And I think it's better to only have the descriptor location on the URL
> >> nothing else.
> >> All should be described in the descriptor (locations of the jar
> >> resources, meta/headers, ...).
> >>
> >
> > Do you think it can be done at pax-url level? Everything that works is
> > great. I think the most important goal is to NOT require an ASF release
> > (i.e., SMX bundles with build, repackaging and deployment). THough if
> it's
> > part of Karaf, we'll need a vote and release anyway. I'll think about it
> in
> > the background ;)
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >>
> >> Regards
> >> JB
> >>
> >> On 30/01/2020 08:01, Grzegorz Grzybek wrote:
> >>> Hello
> >>>
> >>> śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Good point ;)
> >>>>
> >>>> What about bundledesc ?
> >>>>
> >>>
> >>> Naming is hard ;) manifest:// maybe?
> >>>
> >>> I imagined also this scenario - if this manifest is an XML file (or
> JSON,
> >>> or whatever structured doc), it could contain MORE than one manifest.
> For
> >>> example a manifest for "tomcat" or for "spring framework" usually
> sharing
> >>> groupId. So a manifest could be e.g.,
> >>>
> >>
> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
> >>> (or similar) meaning that the bundle description should be fetched from
> >>> mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
> >>> particular - from "spring-core" section of this manifest.
> >>>
> >>> But that's just an idea.
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
> >>>>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>> napisał(a):
> >>>>>
> >>>>>> The descriptor will a URL, so, they can be embedded in Karaf and
> then
> >> we
> >>>>>> can use file: URL, or available on Karaf website/Maven Central, and
> >> then
> >>>>>> we can use mvn or http URL as well.
> >>>>>>
> >>>>>> The bundle generator descriptor will contain the META and the
> >> overriding
> >>>>>> resources locations.
> >>>>>>
> >>>>>> For instance:
> >>>>>>
> >>>>>> my-bundle-descriptor-1.0.json
> >>>>>> {
> >>>>>> "base-location": "mvn:....jar",
> >>>>>> "Import-Package": "...",
> >>>>>> "Export-Package": "...",
> >>>>>> "resources":["mvn...jar","..."]
> >>>>>> }
> >>>>>>
> >>>>>> I already started a PoC like this while ago introducing a new URL
> >>>>>> handler "bundle:".
> >>>>>>
> >>>>>
> >>>>> This looks cool - exactly what I was thinking about - instead of
> >> relying
> >>>> on
> >>>>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes
> >> bad,
> >>>>> because sometimes authors of libraries do not know much about OSGi),
> >>>> have a
> >>>>> descriptor pointing to a location of (possibly not OSGi-aware) a
> >> library.
> >>>>>
> >>>>> But I'd use different protocol than "bundle:" which is used by
> Felix, I
> >>>>> think.
> >>>>>
> >>>>> regards
> >>>>> Grzegorz Grzybek
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Good idea about not having it as part of featuresService
> >>>>>> (featuresProcessor
> >>>>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?).
> >> Indeed
> >>>>>>> keeping some generic descriptors instead of
> building/voting/releasing
> >>>> SMX
> >>>>>>> bundles and generating actual bundles on the fly would be a good
> >> idea.
> >>>>>>>
> >>>>>>> Where those descriptors could be stored? In some Karaf subdirectory
> >>>> maybe
> >>>>>>> (etc/)? Currently I see 413 subdirectories of
> >>>>>>> github/apache/servicemix-bundles repo, All of those could be in
> >> single
> >>>>>> XML
> >>>>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
> >>>> additional
> >>>>>>> resources, this generic (by default) generator descriptor could be
> >>>>>> tweaked
> >>>>>>> to load/shade/repackage additional resources...
> >>>>>>>
> >>>>>>> Anyway - I see it can be changed without huge effort.
> >>>>>>>
> >>>>>>> regards
> >>>>>>> Grzegorz Grzybek
> >>>>>>>
> >>>>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>>>> napisał(a):
> >>>>>>>
> >>>>>>>> Hi Greg,
> >>>>>>>>
> >>>>>>>> For bundles, as separate project, I have more the idea of
> >>>> "descriptor".
> >>>>>>>>
> >>>>>>>> It's something I proposed while ago.
> >>>>>>>>
> >>>>>>>> Instead of storing the concrete artifacts, I would rather store
> the
> >>>>>> meta.
> >>>>>>>> However, some bundles needs "resources" (like META-INF/foo or
> code).
> >>>>>>>>
> >>>>>>>> So, basically, I agree with a "dynamic" processing, however, I
> don't
> >>>>>>>> think it's good to have this in feature.
> >>>>>>>> I would rather add a "bundle generator" service, generic, that can
> >>>>>>>> easily be used outside Karaf.
> >>>>>>>> The bundle generator service can read artifact from Central or any
> >>>>>>>> repository, than, he reads META descriptor and overriding
> resources
> >>>>>>>> (from karaf-bundles repo for instances) and generates a concrete
> >>>> bundle
> >>>>>>>> on the fly.
> >>>>>>>> Big advantage is that it's easy to change the META/bundle on the
> >> fly.
> >>>>>>>>
> >>>>>>>> Thoughts ?
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>>
> >>>>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> >>>>>>>>> Hello
> >>>>>>>>>
> >>>>>>>>> I can't tell much about SMX, but I fully agree about focusing on
> >>>> Karaf.
> >>>>>>>>>
> >>>>>>>>> About specs/bundles - good to have them as separate projects of
> >> Karaf
> >>>>>>>> (but
> >>>>>>>>> not in the same github/apache/karaf repo!), but for bundles I may
> >>>> have
> >>>>>>>>> different proposal... There's
> >>>>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I
> have
> >>>>>> local
> >>>>>>>>> implementation. I needed a mechanism to declaratively override
> >>>> bundle's
> >>>>>>>>> headers without touching the bundle. Similar to what we have with
> >>>>>> feature
> >>>>>>>>> override/blacklisting.
> >>>>>>>>>
> >>>>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
> >>>>>>>> something
> >>>>>>>>> like this:
> >>>>>>>>>
> >>>>>>>>> <bundleProcessing>
> >>>>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
> >>>>>>>>>         <add header="Processed-By" value="Karaf Bundle Processor"
> >> />
> >>>>>>>>>         <clause header="Import-Package" name="javax.servlet"
> >>>>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
> >>>>>>>>>         <clause header="Import-Package"
> >>>> name="javax.servlet.annotation"
> >>>>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
> >>>>>>>>>         <clause header="Import-Package"
> >>>> name="javax.servlet.descriptor"
> >>>>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
> >>>>>>>>>         <clause header="Import-Package" name="javax.servlet.http"
> >>>>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
> >>>>>>>>>     </bundle>
> >>>>>>>>> </bundleProcessing>
> >>>>>>>>>
> >>>>>>>>> which does exactly what it shows - for all bundles (installed
> with
> >>>>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
> >>>>>> manifest
> >>>>>>>>> clauses. I didn't need this mechanism after all, because I could
> >> make
> >>>>>>>> Jetty
> >>>>>>>>> run with Servlet API 4 using "compatibility fragment bundle" that
> >>>> adds
> >>>>>>>>> extended exports to javax.servlet:javax.servlet-api.
> >>>>>>>>>
> >>>>>>>>> What I was thinking about (even back in 2009
> >>>>>>>>> <
> >> https://www.theserverside.com/discussions/thread/53803.html#305391
> >>>>> )
> >>>>>>>> is to
> >>>>>>>>> maybe extend the above mechanism to get rid of SMX bundles
> >> entirely?
> >>>> I
> >>>>>>>>> know, I know, there's "wrap:" protocol where you can specify
> >> headers
> >>>> in
> >>>>>>>> URI
> >>>>>>>>> itself, but it's not that easy to use. So instead of releasing
> SMX
> >>>>>>>> bundles,
> >>>>>>>>> we can just release the above alteration definitions (somehow).
> >>>>>>>>> I know there are 10000 things I didn't think about (like what to
> do
> >>>> if
> >>>>>>>> you
> >>>>>>>>> don't use Karaf features where featuresService can apply the
> above
> >>>>>>>>> manipulation), but maybe it's worth trying?
> >>>>>>>>>
> >>>>>>>>> regards
> >>>>>>>>> Grzegorz Grzybek
> >>>>>>>>>
> >>>>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>>>>>> napisał(a):
> >>>>>>>>>
> >>>>>>>>>> Hi Andrea,
> >>>>>>>>>>
> >>>>>>>>>> I fully agree with you.
> >>>>>>>>>>
> >>>>>>>>>> My proposal is basically:
> >>>>>>>>>>
> >>>>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
> >>>>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
> >>>> standard
> >>>>>>>>>> and minimal distributions already)
> >>>>>>>>>> 3. Provide a migration guide for SMX users
> >>>>>>>>>> 4. Move ServiceMix project to attic
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> JB
> >>>>>>>>>>
> >>>>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>>>>>>>>>> +1 on each point.
> >>>>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee
> patch
> >>>>>>>>>> releases..
> >>>>>>>>>>> So I would go with attic and clearly states to use karaf
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Inviato da Yahoo Mail su Android
> >>>>>>>>>>>
> >>>>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
> >>>>>>>> jb@nanthrax.net>
> >>>>>>>>>> ha scritto:   Hi guys,
> >>>>>>>>>>>
> >>>>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
> >>>> Specs,
> >>>>>>>> we
> >>>>>>>>>>> clearly have a "slow pace" on distribution releases.
> >>>>>>>>>>>
> >>>>>>>>>>> Here, we have two approaches possible:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. We clearly state on website and codebase that users should
> >>>> better
> >>>>>>>> use
> >>>>>>>>>>> Karaf and create their own custom distribution if needed.
> >>>>>>>>>>> 2. We begin a regular pace in distribution release.
> >>>>>>>>>>>
> >>>>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in
> the
> >>>> SMX
> >>>>>>>>>>> distribution.
> >>>>>>>>>>>
> >>>>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>>>>>>>>>> - Update to Karaf 4.2.x
> >>>>>>>>>>> - Update to Camel 3.0.1
> >>>>>>>>>>> - Update on Activity
> >>>>>>>>>>> - Cleanup and improved SMX features
> >>>>>>>>>>> - Add itests in smx for coverage
> >>>>>>>>>>>
> >>>>>>>>>>> Another more "important" decision would be to retire ServiceMix
> >> to
> >>>>>>>> attic
> >>>>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
> >>>> Karaf
> >>>>>>>>>>> Decanter, Cave, Cellar, ...).
> >>>>>>>>>>>
> >>>>>>>>>>> I think it's fair to discuss about that as we don't see lot of
> >>>>>> activity
> >>>>>>>>>>> on ServiceMix distribution/releases.
> >>>>>>>>>>>
> >>>>>>>>>>> Thoughts ?
> >>>>>>>>>>>
> >>>>>>>>>>> Regards
> >>>>>>>>>>> JB
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Baptiste Onofré
> >>>>>>>> jbonofre@apache.org
> >>>>>>>> http://blog.nanthrax.net
> >>>>>>>> Talend - http://www.talend.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Good point and actually I was thinking about improving pax-url-wrap.



On 30/01/2020 08:12, Grzegorz Grzybek wrote:
> czw., 30 sty 2020 o 08:07 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 
>> Hi,
>>
>> It's more than just manifest.
>>
>> And I think it's better to only have the descriptor location on the URL
>> nothing else.
>> All should be described in the descriptor (locations of the jar
>> resources, meta/headers, ...).
>>
> 
> Do you think it can be done at pax-url level? Everything that works is
> great. I think the most important goal is to NOT require an ASF release
> (i.e., SMX bundles with build, repackaging and deployment). THough if it's
> part of Karaf, we'll need a vote and release anyway. I'll think about it in
> the background ;)
> 
> regards
> Grzegorz Grzybek
> 
> 
>>
>> Regards
>> JB
>>
>> On 30/01/2020 08:01, Grzegorz Grzybek wrote:
>>> Hello
>>>
>>> śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Good point ;)
>>>>
>>>> What about bundledesc ?
>>>>
>>>
>>> Naming is hard ;) manifest:// maybe?
>>>
>>> I imagined also this scenario - if this manifest is an XML file (or JSON,
>>> or whatever structured doc), it could contain MORE than one manifest. For
>>> example a manifest for "tomcat" or for "spring framework" usually sharing
>>> groupId. So a manifest could be e.g.,
>>>
>> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
>>> (or similar) meaning that the bundle description should be fetched from
>>> mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
>>> particular - from "spring-core" section of this manifest.
>>>
>>> But that's just an idea.
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
>>>>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> The descriptor will a URL, so, they can be embedded in Karaf and then
>> we
>>>>>> can use file: URL, or available on Karaf website/Maven Central, and
>> then
>>>>>> we can use mvn or http URL as well.
>>>>>>
>>>>>> The bundle generator descriptor will contain the META and the
>> overriding
>>>>>> resources locations.
>>>>>>
>>>>>> For instance:
>>>>>>
>>>>>> my-bundle-descriptor-1.0.json
>>>>>> {
>>>>>> "base-location": "mvn:....jar",
>>>>>> "Import-Package": "...",
>>>>>> "Export-Package": "...",
>>>>>> "resources":["mvn...jar","..."]
>>>>>> }
>>>>>>
>>>>>> I already started a PoC like this while ago introducing a new URL
>>>>>> handler "bundle:".
>>>>>>
>>>>>
>>>>> This looks cool - exactly what I was thinking about - instead of
>> relying
>>>> on
>>>>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes
>> bad,
>>>>> because sometimes authors of libraries do not know much about OSGi),
>>>> have a
>>>>> descriptor pointing to a location of (possibly not OSGi-aware) a
>> library.
>>>>>
>>>>> But I'd use different protocol than "bundle:" which is used by Felix, I
>>>>> think.
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Good idea about not having it as part of featuresService
>>>>>> (featuresProcessor
>>>>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?).
>> Indeed
>>>>>>> keeping some generic descriptors instead of building/voting/releasing
>>>> SMX
>>>>>>> bundles and generating actual bundles on the fly would be a good
>> idea.
>>>>>>>
>>>>>>> Where those descriptors could be stored? In some Karaf subdirectory
>>>> maybe
>>>>>>> (etc/)? Currently I see 413 subdirectories of
>>>>>>> github/apache/servicemix-bundles repo, All of those could be in
>> single
>>>>>> XML
>>>>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
>>>> additional
>>>>>>> resources, this generic (by default) generator descriptor could be
>>>>>> tweaked
>>>>>>> to load/shade/repackage additional resources...
>>>>>>>
>>>>>>> Anyway - I see it can be changed without huge effort.
>>>>>>>
>>>>>>> regards
>>>>>>> Grzegorz Grzybek
>>>>>>>
>>>>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>> napisał(a):
>>>>>>>
>>>>>>>> Hi Greg,
>>>>>>>>
>>>>>>>> For bundles, as separate project, I have more the idea of
>>>> "descriptor".
>>>>>>>>
>>>>>>>> It's something I proposed while ago.
>>>>>>>>
>>>>>>>> Instead of storing the concrete artifacts, I would rather store the
>>>>>> meta.
>>>>>>>> However, some bundles needs "resources" (like META-INF/foo or code).
>>>>>>>>
>>>>>>>> So, basically, I agree with a "dynamic" processing, however, I don't
>>>>>>>> think it's good to have this in feature.
>>>>>>>> I would rather add a "bundle generator" service, generic, that can
>>>>>>>> easily be used outside Karaf.
>>>>>>>> The bundle generator service can read artifact from Central or any
>>>>>>>> repository, than, he reads META descriptor and overriding resources
>>>>>>>> (from karaf-bundles repo for instances) and generates a concrete
>>>> bundle
>>>>>>>> on the fly.
>>>>>>>> Big advantage is that it's easy to change the META/bundle on the
>> fly.
>>>>>>>>
>>>>>>>> Thoughts ?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> I can't tell much about SMX, but I fully agree about focusing on
>>>> Karaf.
>>>>>>>>>
>>>>>>>>> About specs/bundles - good to have them as separate projects of
>> Karaf
>>>>>>>> (but
>>>>>>>>> not in the same github/apache/karaf repo!), but for bundles I may
>>>> have
>>>>>>>>> different proposal... There's
>>>>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
>>>>>> local
>>>>>>>>> implementation. I needed a mechanism to declaratively override
>>>> bundle's
>>>>>>>>> headers without touching the bundle. Similar to what we have with
>>>>>> feature
>>>>>>>>> override/blacklisting.
>>>>>>>>>
>>>>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
>>>>>>>> something
>>>>>>>>> like this:
>>>>>>>>>
>>>>>>>>> <bundleProcessing>
>>>>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
>>>>>>>>>         <add header="Processed-By" value="Karaf Bundle Processor"
>> />
>>>>>>>>>         <clause header="Import-Package" name="javax.servlet"
>>>>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
>>>>>>>>>         <clause header="Import-Package"
>>>> name="javax.servlet.annotation"
>>>>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>>>>>>>>>         <clause header="Import-Package"
>>>> name="javax.servlet.descriptor"
>>>>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>>>>>>>>>         <clause header="Import-Package" name="javax.servlet.http"
>>>>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
>>>>>>>>>     </bundle>
>>>>>>>>> </bundleProcessing>
>>>>>>>>>
>>>>>>>>> which does exactly what it shows - for all bundles (installed with
>>>>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
>>>>>> manifest
>>>>>>>>> clauses. I didn't need this mechanism after all, because I could
>> make
>>>>>>>> Jetty
>>>>>>>>> run with Servlet API 4 using "compatibility fragment bundle" that
>>>> adds
>>>>>>>>> extended exports to javax.servlet:javax.servlet-api.
>>>>>>>>>
>>>>>>>>> What I was thinking about (even back in 2009
>>>>>>>>> <
>> https://www.theserverside.com/discussions/thread/53803.html#305391
>>>>> )
>>>>>>>> is to
>>>>>>>>> maybe extend the above mechanism to get rid of SMX bundles
>> entirely?
>>>> I
>>>>>>>>> know, I know, there's "wrap:" protocol where you can specify
>> headers
>>>> in
>>>>>>>> URI
>>>>>>>>> itself, but it's not that easy to use. So instead of releasing SMX
>>>>>>>> bundles,
>>>>>>>>> we can just release the above alteration definitions (somehow).
>>>>>>>>> I know there are 10000 things I didn't think about (like what to do
>>>> if
>>>>>>>> you
>>>>>>>>> don't use Karaf features where featuresService can apply the above
>>>>>>>>> manipulation), but maybe it's worth trying?
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Grzegorz Grzybek
>>>>>>>>>
>>>>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>>>> napisał(a):
>>>>>>>>>
>>>>>>>>>> Hi Andrea,
>>>>>>>>>>
>>>>>>>>>> I fully agree with you.
>>>>>>>>>>
>>>>>>>>>> My proposal is basically:
>>>>>>>>>>
>>>>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
>>>>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
>>>> standard
>>>>>>>>>> and minimal distributions already)
>>>>>>>>>> 3. Provide a migration guide for SMX users
>>>>>>>>>> 4. Move ServiceMix project to attic
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>>>>>>>>>> +1 on each point.
>>>>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
>>>>>>>>>> releases..
>>>>>>>>>>> So I would go with attic and clearly states to use karaf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Inviato da Yahoo Mail su Android
>>>>>>>>>>>
>>>>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
>>>>>>>> jb@nanthrax.net>
>>>>>>>>>> ha scritto:   Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
>>>> Specs,
>>>>>>>> we
>>>>>>>>>>> clearly have a "slow pace" on distribution releases.
>>>>>>>>>>>
>>>>>>>>>>> Here, we have two approaches possible:
>>>>>>>>>>>
>>>>>>>>>>> 1. We clearly state on website and codebase that users should
>>>> better
>>>>>>>> use
>>>>>>>>>>> Karaf and create their own custom distribution if needed.
>>>>>>>>>>> 2. We begin a regular pace in distribution release.
>>>>>>>>>>>
>>>>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in the
>>>> SMX
>>>>>>>>>>> distribution.
>>>>>>>>>>>
>>>>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>>>>>>>>>> - Update to Karaf 4.2.x
>>>>>>>>>>> - Update to Camel 3.0.1
>>>>>>>>>>> - Update on Activity
>>>>>>>>>>> - Cleanup and improved SMX features
>>>>>>>>>>> - Add itests in smx for coverage
>>>>>>>>>>>
>>>>>>>>>>> Another more "important" decision would be to retire ServiceMix
>> to
>>>>>>>> attic
>>>>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
>>>> Karaf
>>>>>>>>>>> Decanter, Cave, Cellar, ...).
>>>>>>>>>>>
>>>>>>>>>>> I think it's fair to discuss about that as we don't see lot of
>>>>>> activity
>>>>>>>>>>> on ServiceMix distribution/releases.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

czw., 30 sty 2020 o 08:07 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> Hi,
>
> It's more than just manifest.
>
> And I think it's better to only have the descriptor location on the URL
> nothing else.
> All should be described in the descriptor (locations of the jar
> resources, meta/headers, ...).
>

Do you think it can be done at pax-url level? Everything that works is
great. I think the most important goal is to NOT require an ASF release
(i.e., SMX bundles with build, repackaging and deployment). THough if it's
part of Karaf, we'll need a vote and release anyway. I'll think about it in
the background ;)

regards
Grzegorz Grzybek


>
> Regards
> JB
>
> On 30/01/2020 08:01, Grzegorz Grzybek wrote:
> > Hello
> >
> > śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
> >
> >> Good point ;)
> >>
> >> What about bundledesc ?
> >>
> >
> > Naming is hard ;) manifest:// maybe?
> >
> > I imagined also this scenario - if this manifest is an XML file (or JSON,
> > or whatever structured doc), it could contain MORE than one manifest. For
> > example a manifest for "tomcat" or for "spring framework" usually sharing
> > groupId. So a manifest could be e.g.,
> >
> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
> > (or similar) meaning that the bundle description should be fetched from
> > mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
> > particular - from "spring-core" section of this manifest.
> >
> > But that's just an idea.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >> Regards
> >> JB
> >>
> >> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
> >>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> The descriptor will a URL, so, they can be embedded in Karaf and then
> we
> >>>> can use file: URL, or available on Karaf website/Maven Central, and
> then
> >>>> we can use mvn or http URL as well.
> >>>>
> >>>> The bundle generator descriptor will contain the META and the
> overriding
> >>>> resources locations.
> >>>>
> >>>> For instance:
> >>>>
> >>>> my-bundle-descriptor-1.0.json
> >>>> {
> >>>> "base-location": "mvn:....jar",
> >>>> "Import-Package": "...",
> >>>> "Export-Package": "...",
> >>>> "resources":["mvn...jar","..."]
> >>>> }
> >>>>
> >>>> I already started a PoC like this while ago introducing a new URL
> >>>> handler "bundle:".
> >>>>
> >>>
> >>> This looks cool - exactly what I was thinking about - instead of
> relying
> >> on
> >>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes
> bad,
> >>> because sometimes authors of libraries do not know much about OSGi),
> >> have a
> >>> descriptor pointing to a location of (possibly not OSGi-aware) a
> library.
> >>>
> >>> But I'd use different protocol than "bundle:" which is used by Felix, I
> >>> think.
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>>
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
> >>>>> Hi
> >>>>>
> >>>>> Good idea about not having it as part of featuresService
> >>>> (featuresProcessor
> >>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?).
> Indeed
> >>>>> keeping some generic descriptors instead of building/voting/releasing
> >> SMX
> >>>>> bundles and generating actual bundles on the fly would be a good
> idea.
> >>>>>
> >>>>> Where those descriptors could be stored? In some Karaf subdirectory
> >> maybe
> >>>>> (etc/)? Currently I see 413 subdirectories of
> >>>>> github/apache/servicemix-bundles repo, All of those could be in
> single
> >>>> XML
> >>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
> >> additional
> >>>>> resources, this generic (by default) generator descriptor could be
> >>>> tweaked
> >>>>> to load/shade/repackage additional resources...
> >>>>>
> >>>>> Anyway - I see it can be changed without huge effort.
> >>>>>
> >>>>> regards
> >>>>> Grzegorz Grzybek
> >>>>>
> >>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>> napisał(a):
> >>>>>
> >>>>>> Hi Greg,
> >>>>>>
> >>>>>> For bundles, as separate project, I have more the idea of
> >> "descriptor".
> >>>>>>
> >>>>>> It's something I proposed while ago.
> >>>>>>
> >>>>>> Instead of storing the concrete artifacts, I would rather store the
> >>>> meta.
> >>>>>> However, some bundles needs "resources" (like META-INF/foo or code).
> >>>>>>
> >>>>>> So, basically, I agree with a "dynamic" processing, however, I don't
> >>>>>> think it's good to have this in feature.
> >>>>>> I would rather add a "bundle generator" service, generic, that can
> >>>>>> easily be used outside Karaf.
> >>>>>> The bundle generator service can read artifact from Central or any
> >>>>>> repository, than, he reads META descriptor and overriding resources
> >>>>>> (from karaf-bundles repo for instances) and generates a concrete
> >> bundle
> >>>>>> on the fly.
> >>>>>> Big advantage is that it's easy to change the META/bundle on the
> fly.
> >>>>>>
> >>>>>> Thoughts ?
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> >>>>>>> Hello
> >>>>>>>
> >>>>>>> I can't tell much about SMX, but I fully agree about focusing on
> >> Karaf.
> >>>>>>>
> >>>>>>> About specs/bundles - good to have them as separate projects of
> Karaf
> >>>>>> (but
> >>>>>>> not in the same github/apache/karaf repo!), but for bundles I may
> >> have
> >>>>>>> different proposal... There's
> >>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
> >>>> local
> >>>>>>> implementation. I needed a mechanism to declaratively override
> >> bundle's
> >>>>>>> headers without touching the bundle. Similar to what we have with
> >>>> feature
> >>>>>>> override/blacklisting.
> >>>>>>>
> >>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
> >>>>>> something
> >>>>>>> like this:
> >>>>>>>
> >>>>>>> <bundleProcessing>
> >>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
> >>>>>>>         <add header="Processed-By" value="Karaf Bundle Processor"
> />
> >>>>>>>         <clause header="Import-Package" name="javax.servlet"
> >>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
> >>>>>>>         <clause header="Import-Package"
> >> name="javax.servlet.annotation"
> >>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
> >>>>>>>         <clause header="Import-Package"
> >> name="javax.servlet.descriptor"
> >>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
> >>>>>>>         <clause header="Import-Package" name="javax.servlet.http"
> >>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
> >>>>>>>     </bundle>
> >>>>>>> </bundleProcessing>
> >>>>>>>
> >>>>>>> which does exactly what it shows - for all bundles (installed with
> >>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
> >>>> manifest
> >>>>>>> clauses. I didn't need this mechanism after all, because I could
> make
> >>>>>> Jetty
> >>>>>>> run with Servlet API 4 using "compatibility fragment bundle" that
> >> adds
> >>>>>>> extended exports to javax.servlet:javax.servlet-api.
> >>>>>>>
> >>>>>>> What I was thinking about (even back in 2009
> >>>>>>> <
> https://www.theserverside.com/discussions/thread/53803.html#305391
> >>> )
> >>>>>> is to
> >>>>>>> maybe extend the above mechanism to get rid of SMX bundles
> entirely?
> >> I
> >>>>>>> know, I know, there's "wrap:" protocol where you can specify
> headers
> >> in
> >>>>>> URI
> >>>>>>> itself, but it's not that easy to use. So instead of releasing SMX
> >>>>>> bundles,
> >>>>>>> we can just release the above alteration definitions (somehow).
> >>>>>>> I know there are 10000 things I didn't think about (like what to do
> >> if
> >>>>>> you
> >>>>>>> don't use Karaf features where featuresService can apply the above
> >>>>>>> manipulation), but maybe it's worth trying?
> >>>>>>>
> >>>>>>> regards
> >>>>>>> Grzegorz Grzybek
> >>>>>>>
> >>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>>>> napisał(a):
> >>>>>>>
> >>>>>>>> Hi Andrea,
> >>>>>>>>
> >>>>>>>> I fully agree with you.
> >>>>>>>>
> >>>>>>>> My proposal is basically:
> >>>>>>>>
> >>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
> >>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
> >> standard
> >>>>>>>> and minimal distributions already)
> >>>>>>>> 3. Provide a migration guide for SMX users
> >>>>>>>> 4. Move ServiceMix project to attic
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>>
> >>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>>>>>>>> +1 on each point.
> >>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
> >>>>>>>> releases..
> >>>>>>>>> So I would go with attic and clearly states to use karaf
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Inviato da Yahoo Mail su Android
> >>>>>>>>>
> >>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
> >>>>>> jb@nanthrax.net>
> >>>>>>>> ha scritto:   Hi guys,
> >>>>>>>>>
> >>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
> >> Specs,
> >>>>>> we
> >>>>>>>>> clearly have a "slow pace" on distribution releases.
> >>>>>>>>>
> >>>>>>>>> Here, we have two approaches possible:
> >>>>>>>>>
> >>>>>>>>> 1. We clearly state on website and codebase that users should
> >> better
> >>>>>> use
> >>>>>>>>> Karaf and create their own custom distribution if needed.
> >>>>>>>>> 2. We begin a regular pace in distribution release.
> >>>>>>>>>
> >>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in the
> >> SMX
> >>>>>>>>> distribution.
> >>>>>>>>>
> >>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>>>>>>>> - Update to Karaf 4.2.x
> >>>>>>>>> - Update to Camel 3.0.1
> >>>>>>>>> - Update on Activity
> >>>>>>>>> - Cleanup and improved SMX features
> >>>>>>>>> - Add itests in smx for coverage
> >>>>>>>>>
> >>>>>>>>> Another more "important" decision would be to retire ServiceMix
> to
> >>>>>> attic
> >>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
> >> Karaf
> >>>>>>>>> Decanter, Cave, Cellar, ...).
> >>>>>>>>>
> >>>>>>>>> I think it's fair to discuss about that as we don't see lot of
> >>>> activity
> >>>>>>>>> on ServiceMix distribution/releases.
> >>>>>>>>>
> >>>>>>>>> Thoughts ?
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> JB
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Baptiste Onofré
> >>>>>>>> jbonofre@apache.org
> >>>>>>>> http://blog.nanthrax.net
> >>>>>>>> Talend - http://www.talend.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

It's more than just manifest.

And I think it's better to only have the descriptor location on the URL
nothing else.
All should be described in the descriptor (locations of the jar
resources, meta/headers, ...).

Regards
JB

On 30/01/2020 08:01, Grzegorz Grzybek wrote:
> Hello
> 
> śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 
>> Good point ;)
>>
>> What about bundledesc ?
>>
> 
> Naming is hard ;) manifest:// maybe?
> 
> I imagined also this scenario - if this manifest is an XML file (or JSON,
> or whatever structured doc), it could contain MORE than one manifest. For
> example a manifest for "tomcat" or for "spring framework" usually sharing
> groupId. So a manifest could be e.g.,
> bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
> (or similar) meaning that the bundle description should be fetched from
> mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
> particular - from "spring-core" section of this manifest.
> 
> But that's just an idea.
> 
> regards
> Grzegorz Grzybek
> 
> 
>> Regards
>> JB
>>
>> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
>>> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> The descriptor will a URL, so, they can be embedded in Karaf and then we
>>>> can use file: URL, or available on Karaf website/Maven Central, and then
>>>> we can use mvn or http URL as well.
>>>>
>>>> The bundle generator descriptor will contain the META and the overriding
>>>> resources locations.
>>>>
>>>> For instance:
>>>>
>>>> my-bundle-descriptor-1.0.json
>>>> {
>>>> "base-location": "mvn:....jar",
>>>> "Import-Package": "...",
>>>> "Export-Package": "...",
>>>> "resources":["mvn...jar","..."]
>>>> }
>>>>
>>>> I already started a PoC like this while ago introducing a new URL
>>>> handler "bundle:".
>>>>
>>>
>>> This looks cool - exactly what I was thinking about - instead of relying
>> on
>>> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes bad,
>>> because sometimes authors of libraries do not know much about OSGi),
>> have a
>>> descriptor pointing to a location of (possibly not OSGi-aware) a library.
>>>
>>> But I'd use different protocol than "bundle:" which is used by Felix, I
>>> think.
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>>
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
>>>>> Hi
>>>>>
>>>>> Good idea about not having it as part of featuresService
>>>> (featuresProcessor
>>>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
>>>>> keeping some generic descriptors instead of building/voting/releasing
>> SMX
>>>>> bundles and generating actual bundles on the fly would be a good idea.
>>>>>
>>>>> Where those descriptors could be stored? In some Karaf subdirectory
>> maybe
>>>>> (etc/)? Currently I see 413 subdirectories of
>>>>> github/apache/servicemix-bundles repo, All of those could be in single
>>>> XML
>>>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
>> additional
>>>>> resources, this generic (by default) generator descriptor could be
>>>> tweaked
>>>>> to load/shade/repackage additional resources...
>>>>>
>>>>> Anyway - I see it can be changed without huge effort.
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> For bundles, as separate project, I have more the idea of
>> "descriptor".
>>>>>>
>>>>>> It's something I proposed while ago.
>>>>>>
>>>>>> Instead of storing the concrete artifacts, I would rather store the
>>>> meta.
>>>>>> However, some bundles needs "resources" (like META-INF/foo or code).
>>>>>>
>>>>>> So, basically, I agree with a "dynamic" processing, however, I don't
>>>>>> think it's good to have this in feature.
>>>>>> I would rather add a "bundle generator" service, generic, that can
>>>>>> easily be used outside Karaf.
>>>>>> The bundle generator service can read artifact from Central or any
>>>>>> repository, than, he reads META descriptor and overriding resources
>>>>>> (from karaf-bundles repo for instances) and generates a concrete
>> bundle
>>>>>> on the fly.
>>>>>> Big advantage is that it's easy to change the META/bundle on the fly.
>>>>>>
>>>>>> Thoughts ?
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> I can't tell much about SMX, but I fully agree about focusing on
>> Karaf.
>>>>>>>
>>>>>>> About specs/bundles - good to have them as separate projects of Karaf
>>>>>> (but
>>>>>>> not in the same github/apache/karaf repo!), but for bundles I may
>> have
>>>>>>> different proposal... There's
>>>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
>>>> local
>>>>>>> implementation. I needed a mechanism to declaratively override
>> bundle's
>>>>>>> headers without touching the bundle. Similar to what we have with
>>>> feature
>>>>>>> override/blacklisting.
>>>>>>>
>>>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
>>>>>> something
>>>>>>> like this:
>>>>>>>
>>>>>>> <bundleProcessing>
>>>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
>>>>>>>         <add header="Processed-By" value="Karaf Bundle Processor" />
>>>>>>>         <clause header="Import-Package" name="javax.servlet"
>>>>>>> value='javax.servlet;version="[3.1.0,5)"' />
>>>>>>>         <clause header="Import-Package"
>> name="javax.servlet.annotation"
>>>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>>>>>>>         <clause header="Import-Package"
>> name="javax.servlet.descriptor"
>>>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>>>>>>>         <clause header="Import-Package" name="javax.servlet.http"
>>>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
>>>>>>>     </bundle>
>>>>>>> </bundleProcessing>
>>>>>>>
>>>>>>> which does exactly what it shows - for all bundles (installed with
>>>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
>>>> manifest
>>>>>>> clauses. I didn't need this mechanism after all, because I could make
>>>>>> Jetty
>>>>>>> run with Servlet API 4 using "compatibility fragment bundle" that
>> adds
>>>>>>> extended exports to javax.servlet:javax.servlet-api.
>>>>>>>
>>>>>>> What I was thinking about (even back in 2009
>>>>>>> <https://www.theserverside.com/discussions/thread/53803.html#305391
>>> )
>>>>>> is to
>>>>>>> maybe extend the above mechanism to get rid of SMX bundles entirely?
>> I
>>>>>>> know, I know, there's "wrap:" protocol where you can specify headers
>> in
>>>>>> URI
>>>>>>> itself, but it's not that easy to use. So instead of releasing SMX
>>>>>> bundles,
>>>>>>> we can just release the above alteration definitions (somehow).
>>>>>>> I know there are 10000 things I didn't think about (like what to do
>> if
>>>>>> you
>>>>>>> don't use Karaf features where featuresService can apply the above
>>>>>>> manipulation), but maybe it's worth trying?
>>>>>>>
>>>>>>> regards
>>>>>>> Grzegorz Grzybek
>>>>>>>
>>>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>> napisał(a):
>>>>>>>
>>>>>>>> Hi Andrea,
>>>>>>>>
>>>>>>>> I fully agree with you.
>>>>>>>>
>>>>>>>> My proposal is basically:
>>>>>>>>
>>>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
>>>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
>> standard
>>>>>>>> and minimal distributions already)
>>>>>>>> 3. Provide a migration guide for SMX users
>>>>>>>> 4. Move ServiceMix project to attic
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>>>>>>>> +1 on each point.
>>>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
>>>>>>>> releases..
>>>>>>>>> So I would go with attic and clearly states to use karaf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Inviato da Yahoo Mail su Android
>>>>>>>>>
>>>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
>>>>>> jb@nanthrax.net>
>>>>>>>> ha scritto:   Hi guys,
>>>>>>>>>
>>>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
>> Specs,
>>>>>> we
>>>>>>>>> clearly have a "slow pace" on distribution releases.
>>>>>>>>>
>>>>>>>>> Here, we have two approaches possible:
>>>>>>>>>
>>>>>>>>> 1. We clearly state on website and codebase that users should
>> better
>>>>>> use
>>>>>>>>> Karaf and create their own custom distribution if needed.
>>>>>>>>> 2. We begin a regular pace in distribution release.
>>>>>>>>>
>>>>>>>>> I think 1 makes more sense and it's worth to be mentioned in the
>> SMX
>>>>>>>>> distribution.
>>>>>>>>>
>>>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>>>>>>>> - Update to Karaf 4.2.x
>>>>>>>>> - Update to Camel 3.0.1
>>>>>>>>> - Update on Activity
>>>>>>>>> - Cleanup and improved SMX features
>>>>>>>>> - Add itests in smx for coverage
>>>>>>>>>
>>>>>>>>> Another more "important" decision would be to retire ServiceMix to
>>>>>> attic
>>>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
>> Karaf
>>>>>>>>> Decanter, Cave, Cellar, ...).
>>>>>>>>>
>>>>>>>>> I think it's fair to discuss about that as we don't see lot of
>>>> activity
>>>>>>>>> on ServiceMix distribution/releases.
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

Hello

śr., 29 sty 2020 o 10:51 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> Good point ;)
>
> What about bundledesc ?
>

Naming is hard ;) manifest:// maybe?

I imagined also this scenario - if this manifest is an XML file (or JSON,
or whatever structured doc), it could contain MORE than one manifest. For
example a manifest for "tomcat" or for "spring framework" usually sharing
groupId. So a manifest could be e.g.,
bundledesc:mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE?id=spring-core
(or similar) meaning that the bundle description should be fetched from
mvn:org.apache.karaf.bundles/spring-framework/5.1.9.RELEASE and in
particular - from "spring-core" section of this manifest.

But that's just an idea.

regards
Grzegorz Grzybek


> Regards
> JB
>
> On 29/01/2020 08:56, Grzegorz Grzybek wrote:
> > śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
> >
> >> The descriptor will a URL, so, they can be embedded in Karaf and then we
> >> can use file: URL, or available on Karaf website/Maven Central, and then
> >> we can use mvn or http URL as well.
> >>
> >> The bundle generator descriptor will contain the META and the overriding
> >> resources locations.
> >>
> >> For instance:
> >>
> >> my-bundle-descriptor-1.0.json
> >> {
> >> "base-location": "mvn:....jar",
> >> "Import-Package": "...",
> >> "Export-Package": "...",
> >> "resources":["mvn...jar","..."]
> >> }
> >>
> >> I already started a PoC like this while ago introducing a new URL
> >> handler "bundle:".
> >>
> >
> > This looks cool - exactly what I was thinking about - instead of relying
> on
> > (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes bad,
> > because sometimes authors of libraries do not know much about OSGi),
> have a
> > descriptor pointing to a location of (possibly not OSGi-aware) a library.
> >
> > But I'd use different protocol than "bundle:" which is used by Felix, I
> > think.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >>
> >> Regards
> >> JB
> >>
> >> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
> >>> Hi
> >>>
> >>> Good idea about not having it as part of featuresService
> >> (featuresProcessor
> >>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
> >>> keeping some generic descriptors instead of building/voting/releasing
> SMX
> >>> bundles and generating actual bundles on the fly would be a good idea.
> >>>
> >>> Where those descriptors could be stored? In some Karaf subdirectory
> maybe
> >>> (etc/)? Currently I see 413 subdirectories of
> >>> github/apache/servicemix-bundles repo, All of those could be in single
> >> XML
> >>> file. If some SMX (and soon Karaf-Bundles?) bundles need some
> additional
> >>> resources, this generic (by default) generator descriptor could be
> >> tweaked
> >>> to load/shade/repackage additional resources...
> >>>
> >>> Anyway - I see it can be changed without huge effort.
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi Greg,
> >>>>
> >>>> For bundles, as separate project, I have more the idea of
> "descriptor".
> >>>>
> >>>> It's something I proposed while ago.
> >>>>
> >>>> Instead of storing the concrete artifacts, I would rather store the
> >> meta.
> >>>> However, some bundles needs "resources" (like META-INF/foo or code).
> >>>>
> >>>> So, basically, I agree with a "dynamic" processing, however, I don't
> >>>> think it's good to have this in feature.
> >>>> I would rather add a "bundle generator" service, generic, that can
> >>>> easily be used outside Karaf.
> >>>> The bundle generator service can read artifact from Central or any
> >>>> repository, than, he reads META descriptor and overriding resources
> >>>> (from karaf-bundles repo for instances) and generates a concrete
> bundle
> >>>> on the fly.
> >>>> Big advantage is that it's easy to change the META/bundle on the fly.
> >>>>
> >>>> Thoughts ?
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> >>>>> Hello
> >>>>>
> >>>>> I can't tell much about SMX, but I fully agree about focusing on
> Karaf.
> >>>>>
> >>>>> About specs/bundles - good to have them as separate projects of Karaf
> >>>> (but
> >>>>> not in the same github/apache/karaf repo!), but for bundles I may
> have
> >>>>> different proposal... There's
> >>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
> >> local
> >>>>> implementation. I needed a mechanism to declaratively override
> bundle's
> >>>>> headers without touching the bundle. Similar to what we have with
> >> feature
> >>>>> override/blacklisting.
> >>>>>
> >>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
> >>>> something
> >>>>> like this:
> >>>>>
> >>>>> <bundleProcessing>
> >>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
> >>>>>         <add header="Processed-By" value="Karaf Bundle Processor" />
> >>>>>         <clause header="Import-Package" name="javax.servlet"
> >>>>> value='javax.servlet;version="[3.1.0,5)"' />
> >>>>>         <clause header="Import-Package"
> name="javax.servlet.annotation"
> >>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
> >>>>>         <clause header="Import-Package"
> name="javax.servlet.descriptor"
> >>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
> >>>>>         <clause header="Import-Package" name="javax.servlet.http"
> >>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
> >>>>>     </bundle>
> >>>>> </bundleProcessing>
> >>>>>
> >>>>> which does exactly what it shows - for all bundles (installed with
> >>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
> >> manifest
> >>>>> clauses. I didn't need this mechanism after all, because I could make
> >>>> Jetty
> >>>>> run with Servlet API 4 using "compatibility fragment bundle" that
> adds
> >>>>> extended exports to javax.servlet:javax.servlet-api.
> >>>>>
> >>>>> What I was thinking about (even back in 2009
> >>>>> <https://www.theserverside.com/discussions/thread/53803.html#305391
> >)
> >>>> is to
> >>>>> maybe extend the above mechanism to get rid of SMX bundles entirely?
> I
> >>>>> know, I know, there's "wrap:" protocol where you can specify headers
> in
> >>>> URI
> >>>>> itself, but it's not that easy to use. So instead of releasing SMX
> >>>> bundles,
> >>>>> we can just release the above alteration definitions (somehow).
> >>>>> I know there are 10000 things I didn't think about (like what to do
> if
> >>>> you
> >>>>> don't use Karaf features where featuresService can apply the above
> >>>>> manipulation), but maybe it's worth trying?
> >>>>>
> >>>>> regards
> >>>>> Grzegorz Grzybek
> >>>>>
> >>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>> napisał(a):
> >>>>>
> >>>>>> Hi Andrea,
> >>>>>>
> >>>>>> I fully agree with you.
> >>>>>>
> >>>>>> My proposal is basically:
> >>>>>>
> >>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
> >>>>>> 2. Create Karaf Integration distribution at Karaf (as we have
> standard
> >>>>>> and minimal distributions already)
> >>>>>> 3. Provide a migration guide for SMX users
> >>>>>> 4. Move ServiceMix project to attic
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>>>>>> +1 on each point.
> >>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
> >>>>>> releases..
> >>>>>>> So I would go with attic and clearly states to use karaf
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Inviato da Yahoo Mail su Android
> >>>>>>>
> >>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
> >>>> jb@nanthrax.net>
> >>>>>> ha scritto:   Hi guys,
> >>>>>>>
> >>>>>>> If the ServiceMix project is fairly active for SMX Bundles and
> Specs,
> >>>> we
> >>>>>>> clearly have a "slow pace" on distribution releases.
> >>>>>>>
> >>>>>>> Here, we have two approaches possible:
> >>>>>>>
> >>>>>>> 1. We clearly state on website and codebase that users should
> better
> >>>> use
> >>>>>>> Karaf and create their own custom distribution if needed.
> >>>>>>> 2. We begin a regular pace in distribution release.
> >>>>>>>
> >>>>>>> I think 1 makes more sense and it's worth to be mentioned in the
> SMX
> >>>>>>> distribution.
> >>>>>>>
> >>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>>>>>> - Update to Karaf 4.2.x
> >>>>>>> - Update to Camel 3.0.1
> >>>>>>> - Update on Activity
> >>>>>>> - Cleanup and improved SMX features
> >>>>>>> - Add itests in smx for coverage
> >>>>>>>
> >>>>>>> Another more "important" decision would be to retire ServiceMix to
> >>>> attic
> >>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have
> Karaf
> >>>>>>> Decanter, Cave, Cellar, ...).
> >>>>>>>
> >>>>>>> I think it's fair to discuss about that as we don't see lot of
> >> activity
> >>>>>>> on ServiceMix distribution/releases.
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Good point ;)

What about bundledesc ?

Regards
JB

On 29/01/2020 08:56, Grzegorz Grzybek wrote:
> śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 
>> The descriptor will a URL, so, they can be embedded in Karaf and then we
>> can use file: URL, or available on Karaf website/Maven Central, and then
>> we can use mvn or http URL as well.
>>
>> The bundle generator descriptor will contain the META and the overriding
>> resources locations.
>>
>> For instance:
>>
>> my-bundle-descriptor-1.0.json
>> {
>> "base-location": "mvn:....jar",
>> "Import-Package": "...",
>> "Export-Package": "...",
>> "resources":["mvn...jar","..."]
>> }
>>
>> I already started a PoC like this while ago introducing a new URL
>> handler "bundle:".
>>
> 
> This looks cool - exactly what I was thinking about - instead of relying on
> (76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes bad,
> because sometimes authors of libraries do not know much about OSGi), have a
> descriptor pointing to a location of (possibly not OSGi-aware) a library.
> 
> But I'd use different protocol than "bundle:" which is used by Felix, I
> think.
> 
> regards
> Grzegorz Grzybek
> 
> 
>>
>> Regards
>> JB
>>
>> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
>>> Hi
>>>
>>> Good idea about not having it as part of featuresService
>> (featuresProcessor
>>> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
>>> keeping some generic descriptors instead of building/voting/releasing SMX
>>> bundles and generating actual bundles on the fly would be a good idea.
>>>
>>> Where those descriptors could be stored? In some Karaf subdirectory maybe
>>> (etc/)? Currently I see 413 subdirectories of
>>> github/apache/servicemix-bundles repo, All of those could be in single
>> XML
>>> file. If some SMX (and soon Karaf-Bundles?) bundles need some additional
>>> resources, this generic (by default) generator descriptor could be
>> tweaked
>>> to load/shade/repackage additional resources...
>>>
>>> Anyway - I see it can be changed without huge effort.
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi Greg,
>>>>
>>>> For bundles, as separate project, I have more the idea of "descriptor".
>>>>
>>>> It's something I proposed while ago.
>>>>
>>>> Instead of storing the concrete artifacts, I would rather store the
>> meta.
>>>> However, some bundles needs "resources" (like META-INF/foo or code).
>>>>
>>>> So, basically, I agree with a "dynamic" processing, however, I don't
>>>> think it's good to have this in feature.
>>>> I would rather add a "bundle generator" service, generic, that can
>>>> easily be used outside Karaf.
>>>> The bundle generator service can read artifact from Central or any
>>>> repository, than, he reads META descriptor and overriding resources
>>>> (from karaf-bundles repo for instances) and generates a concrete bundle
>>>> on the fly.
>>>> Big advantage is that it's easy to change the META/bundle on the fly.
>>>>
>>>> Thoughts ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
>>>>> Hello
>>>>>
>>>>> I can't tell much about SMX, but I fully agree about focusing on Karaf.
>>>>>
>>>>> About specs/bundles - good to have them as separate projects of Karaf
>>>> (but
>>>>> not in the same github/apache/karaf repo!), but for bundles I may have
>>>>> different proposal... There's
>>>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
>> local
>>>>> implementation. I needed a mechanism to declaratively override bundle's
>>>>> headers without touching the bundle. Similar to what we have with
>> feature
>>>>> override/blacklisting.
>>>>>
>>>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
>>>> something
>>>>> like this:
>>>>>
>>>>> <bundleProcessing>
>>>>>     <bundle location="mvn:org.eclipse.jetty*/*">
>>>>>         <add header="Processed-By" value="Karaf Bundle Processor" />
>>>>>         <clause header="Import-Package" name="javax.servlet"
>>>>> value='javax.servlet;version="[3.1.0,5)"' />
>>>>>         <clause header="Import-Package" name="javax.servlet.annotation"
>>>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>>>>>         <clause header="Import-Package" name="javax.servlet.descriptor"
>>>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>>>>>         <clause header="Import-Package" name="javax.servlet.http"
>>>>> value='javax.servlet.http;version="[3.1.0,5)"' />
>>>>>     </bundle>
>>>>> </bundleProcessing>
>>>>>
>>>>> which does exactly what it shows - for all bundles (installed with
>>>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
>> manifest
>>>>> clauses. I didn't need this mechanism after all, because I could make
>>>> Jetty
>>>>> run with Servlet API 4 using "compatibility fragment bundle" that adds
>>>>> extended exports to javax.servlet:javax.servlet-api.
>>>>>
>>>>> What I was thinking about (even back in 2009
>>>>> <https://www.theserverside.com/discussions/thread/53803.html#305391>)
>>>> is to
>>>>> maybe extend the above mechanism to get rid of SMX bundles entirely? I
>>>>> know, I know, there's "wrap:" protocol where you can specify headers in
>>>> URI
>>>>> itself, but it's not that easy to use. So instead of releasing SMX
>>>> bundles,
>>>>> we can just release the above alteration definitions (somehow).
>>>>> I know there are 10000 things I didn't think about (like what to do if
>>>> you
>>>>> don't use Karaf features where featuresService can apply the above
>>>>> manipulation), but maybe it's worth trying?
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> Hi Andrea,
>>>>>>
>>>>>> I fully agree with you.
>>>>>>
>>>>>> My proposal is basically:
>>>>>>
>>>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
>>>>>> 2. Create Karaf Integration distribution at Karaf (as we have standard
>>>>>> and minimal distributions already)
>>>>>> 3. Provide a migration guide for SMX users
>>>>>> 4. Move ServiceMix project to attic
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>>>>>> +1 on each point.
>>>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
>>>>>> releases..
>>>>>>> So I would go with attic and clearly states to use karaf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Inviato da Yahoo Mail su Android
>>>>>>>
>>>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
>>>> jb@nanthrax.net>
>>>>>> ha scritto:   Hi guys,
>>>>>>>
>>>>>>> If the ServiceMix project is fairly active for SMX Bundles and Specs,
>>>> we
>>>>>>> clearly have a "slow pace" on distribution releases.
>>>>>>>
>>>>>>> Here, we have two approaches possible:
>>>>>>>
>>>>>>> 1. We clearly state on website and codebase that users should better
>>>> use
>>>>>>> Karaf and create their own custom distribution if needed.
>>>>>>> 2. We begin a regular pace in distribution release.
>>>>>>>
>>>>>>> I think 1 makes more sense and it's worth to be mentioned in the SMX
>>>>>>> distribution.
>>>>>>>
>>>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>>>>>> - Update to Karaf 4.2.x
>>>>>>> - Update to Camel 3.0.1
>>>>>>> - Update on Activity
>>>>>>> - Cleanup and improved SMX features
>>>>>>> - Add itests in smx for coverage
>>>>>>>
>>>>>>> Another more "important" decision would be to retire ServiceMix to
>>>> attic
>>>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
>>>>>>> Decanter, Cave, Cellar, ...).
>>>>>>>
>>>>>>> I think it's fair to discuss about that as we don't see lot of
>> activity
>>>>>>> on ServiceMix distribution/releases.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> The descriptor will a URL, so, they can be embedded in Karaf and then we
> can use file: URL, or available on Karaf website/Maven Central, and then
> we can use mvn or http URL as well.
>
> The bundle generator descriptor will contain the META and the overriding
> resources locations.
>
> For instance:
>
> my-bundle-descriptor-1.0.json
> {
> "base-location": "mvn:....jar",
> "Import-Package": "...",
> "Export-Package": "...",
> "resources":["mvn...jar","..."]
> }
>
> I already started a PoC like this while ago introducing a new URL
> handler "bundle:".
>

This looks cool - exactly what I was thinking about - instead of relying on
(76 character wide) META-INF/MANIFEST.MF embedded in JAR (sometimes bad,
because sometimes authors of libraries do not know much about OSGi), have a
descriptor pointing to a location of (possibly not OSGi-aware) a library.

But I'd use different protocol than "bundle:" which is used by Felix, I
think.

regards
Grzegorz Grzybek


>
> Regards
> JB
>
> On 29/01/2020 08:32, Grzegorz Grzybek wrote:
> > Hi
> >
> > Good idea about not having it as part of featuresService
> (featuresProcessor
> > in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
> > keeping some generic descriptors instead of building/voting/releasing SMX
> > bundles and generating actual bundles on the fly would be a good idea.
> >
> > Where those descriptors could be stored? In some Karaf subdirectory maybe
> > (etc/)? Currently I see 413 subdirectories of
> > github/apache/servicemix-bundles repo, All of those could be in single
> XML
> > file. If some SMX (and soon Karaf-Bundles?) bundles need some additional
> > resources, this generic (by default) generator descriptor could be
> tweaked
> > to load/shade/repackage additional resources...
> >
> > Anyway - I see it can be changed without huge effort.
> >
> > regards
> > Grzegorz Grzybek
> >
> > śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi Greg,
> >>
> >> For bundles, as separate project, I have more the idea of "descriptor".
> >>
> >> It's something I proposed while ago.
> >>
> >> Instead of storing the concrete artifacts, I would rather store the
> meta.
> >> However, some bundles needs "resources" (like META-INF/foo or code).
> >>
> >> So, basically, I agree with a "dynamic" processing, however, I don't
> >> think it's good to have this in feature.
> >> I would rather add a "bundle generator" service, generic, that can
> >> easily be used outside Karaf.
> >> The bundle generator service can read artifact from Central or any
> >> repository, than, he reads META descriptor and overriding resources
> >> (from karaf-bundles repo for instances) and generates a concrete bundle
> >> on the fly.
> >> Big advantage is that it's easy to change the META/bundle on the fly.
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
> >>
> >> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> >>> Hello
> >>>
> >>> I can't tell much about SMX, but I fully agree about focusing on Karaf.
> >>>
> >>> About specs/bundles - good to have them as separate projects of Karaf
> >> (but
> >>> not in the same github/apache/karaf repo!), but for bundles I may have
> >>> different proposal... There's
> >>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have
> local
> >>> implementation. I needed a mechanism to declaratively override bundle's
> >>> headers without touching the bundle. Similar to what we have with
> feature
> >>> override/blacklisting.
> >>>
> >>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
> >> something
> >>> like this:
> >>>
> >>> <bundleProcessing>
> >>>     <bundle location="mvn:org.eclipse.jetty*/*">
> >>>         <add header="Processed-By" value="Karaf Bundle Processor" />
> >>>         <clause header="Import-Package" name="javax.servlet"
> >>> value='javax.servlet;version="[3.1.0,5)"' />
> >>>         <clause header="Import-Package" name="javax.servlet.annotation"
> >>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
> >>>         <clause header="Import-Package" name="javax.servlet.descriptor"
> >>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
> >>>         <clause header="Import-Package" name="javax.servlet.http"
> >>> value='javax.servlet.http;version="[3.1.0,5)"' />
> >>>     </bundle>
> >>> </bundleProcessing>
> >>>
> >>> which does exactly what it shows - for all bundles (installed with
> >>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter
> manifest
> >>> clauses. I didn't need this mechanism after all, because I could make
> >> Jetty
> >>> run with Servlet API 4 using "compatibility fragment bundle" that adds
> >>> extended exports to javax.servlet:javax.servlet-api.
> >>>
> >>> What I was thinking about (even back in 2009
> >>> <https://www.theserverside.com/discussions/thread/53803.html#305391>)
> >> is to
> >>> maybe extend the above mechanism to get rid of SMX bundles entirely? I
> >>> know, I know, there's "wrap:" protocol where you can specify headers in
> >> URI
> >>> itself, but it's not that easy to use. So instead of releasing SMX
> >> bundles,
> >>> we can just release the above alteration definitions (somehow).
> >>> I know there are 10000 things I didn't think about (like what to do if
> >> you
> >>> don't use Karaf features where featuresService can apply the above
> >>> manipulation), but maybe it's worth trying?
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi Andrea,
> >>>>
> >>>> I fully agree with you.
> >>>>
> >>>> My proposal is basically:
> >>>>
> >>>> 1. Move SMX bundles and SMX specs as Karaf subproject
> >>>> 2. Create Karaf Integration distribution at Karaf (as we have standard
> >>>> and minimal distributions already)
> >>>> 3. Provide a migration guide for SMX users
> >>>> 4. Move ServiceMix project to attic
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>>>> +1 on each point.
> >>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
> >>>> releases..
> >>>>> So I would go with attic and clearly states to use karaf
> >>>>>
> >>>>>
> >>>>>
> >>>>> Inviato da Yahoo Mail su Android
> >>>>>
> >>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
> >> jb@nanthrax.net>
> >>>> ha scritto:   Hi guys,
> >>>>>
> >>>>> If the ServiceMix project is fairly active for SMX Bundles and Specs,
> >> we
> >>>>> clearly have a "slow pace" on distribution releases.
> >>>>>
> >>>>> Here, we have two approaches possible:
> >>>>>
> >>>>> 1. We clearly state on website and codebase that users should better
> >> use
> >>>>> Karaf and create their own custom distribution if needed.
> >>>>> 2. We begin a regular pace in distribution release.
> >>>>>
> >>>>> I think 1 makes more sense and it's worth to be mentioned in the SMX
> >>>>> distribution.
> >>>>>
> >>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>>>> - Update to Karaf 4.2.x
> >>>>> - Update to Camel 3.0.1
> >>>>> - Update on Activity
> >>>>> - Cleanup and improved SMX features
> >>>>> - Add itests in smx for coverage
> >>>>>
> >>>>> Another more "important" decision would be to retire ServiceMix to
> >> attic
> >>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> >>>>> Decanter, Cave, Cellar, ...).
> >>>>>
> >>>>> I think it's fair to discuss about that as we don't see lot of
> activity
> >>>>> on ServiceMix distribution/releases.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

The descriptor will a URL, so, they can be embedded in Karaf and then we
can use file: URL, or available on Karaf website/Maven Central, and then
we can use mvn or http URL as well.

The bundle generator descriptor will contain the META and the overriding
resources locations.

For instance:

my-bundle-descriptor-1.0.json
{
"base-location": "mvn:....jar",
"Import-Package": "...",
"Export-Package": "...",
"resources":["mvn...jar","..."]
}

I already started a PoC like this while ago introducing a new URL
handler "bundle:".

Regards
JB

On 29/01/2020 08:32, Grzegorz Grzybek wrote:
> Hi
> 
> Good idea about not having it as part of featuresService (featuresProcessor
> in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
> keeping some generic descriptors instead of building/voting/releasing SMX
> bundles and generating actual bundles on the fly would be a good idea.
> 
> Where those descriptors could be stored? In some Karaf subdirectory maybe
> (etc/)? Currently I see 413 subdirectories of
> github/apache/servicemix-bundles repo, All of those could be in single XML
> file. If some SMX (and soon Karaf-Bundles?) bundles need some additional
> resources, this generic (by default) generator descriptor could be tweaked
> to load/shade/repackage additional resources...
> 
> Anyway - I see it can be changed without huge effort.
> 
> regards
> Grzegorz Grzybek
> 
> śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 
>> Hi Greg,
>>
>> For bundles, as separate project, I have more the idea of "descriptor".
>>
>> It's something I proposed while ago.
>>
>> Instead of storing the concrete artifacts, I would rather store the meta.
>> However, some bundles needs "resources" (like META-INF/foo or code).
>>
>> So, basically, I agree with a "dynamic" processing, however, I don't
>> think it's good to have this in feature.
>> I would rather add a "bundle generator" service, generic, that can
>> easily be used outside Karaf.
>> The bundle generator service can read artifact from Central or any
>> repository, than, he reads META descriptor and overriding resources
>> (from karaf-bundles repo for instances) and generates a concrete bundle
>> on the fly.
>> Big advantage is that it's easy to change the META/bundle on the fly.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
>>> Hello
>>>
>>> I can't tell much about SMX, but I fully agree about focusing on Karaf.
>>>
>>> About specs/bundles - good to have them as separate projects of Karaf
>> (but
>>> not in the same github/apache/karaf repo!), but for bundles I may have
>>> different proposal... There's
>>> https://issues.apache.org/jira/browse/KARAF-6200 for which I have local
>>> implementation. I needed a mechanism to declaratively override bundle's
>>> headers without touching the bundle. Similar to what we have with feature
>>> override/blacklisting.
>>>
>>> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
>> something
>>> like this:
>>>
>>> <bundleProcessing>
>>>     <bundle location="mvn:org.eclipse.jetty*/*">
>>>         <add header="Processed-By" value="Karaf Bundle Processor" />
>>>         <clause header="Import-Package" name="javax.servlet"
>>> value='javax.servlet;version="[3.1.0,5)"' />
>>>         <clause header="Import-Package" name="javax.servlet.annotation"
>>> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>>>         <clause header="Import-Package" name="javax.servlet.descriptor"
>>> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>>>         <clause header="Import-Package" name="javax.servlet.http"
>>> value='javax.servlet.http;version="[3.1.0,5)"' />
>>>     </bundle>
>>> </bundleProcessing>
>>>
>>> which does exactly what it shows - for all bundles (installed with
>>> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter manifest
>>> clauses. I didn't need this mechanism after all, because I could make
>> Jetty
>>> run with Servlet API 4 using "compatibility fragment bundle" that adds
>>> extended exports to javax.servlet:javax.servlet-api.
>>>
>>> What I was thinking about (even back in 2009
>>> <https://www.theserverside.com/discussions/thread/53803.html#305391>)
>> is to
>>> maybe extend the above mechanism to get rid of SMX bundles entirely? I
>>> know, I know, there's "wrap:" protocol where you can specify headers in
>> URI
>>> itself, but it's not that easy to use. So instead of releasing SMX
>> bundles,
>>> we can just release the above alteration definitions (somehow).
>>> I know there are 10000 things I didn't think about (like what to do if
>> you
>>> don't use Karaf features where featuresService can apply the above
>>> manipulation), but maybe it's worth trying?
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi Andrea,
>>>>
>>>> I fully agree with you.
>>>>
>>>> My proposal is basically:
>>>>
>>>> 1. Move SMX bundles and SMX specs as Karaf subproject
>>>> 2. Create Karaf Integration distribution at Karaf (as we have standard
>>>> and minimal distributions already)
>>>> 3. Provide a migration guide for SMX users
>>>> 4. Move ServiceMix project to attic
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>>>> +1 on each point.
>>>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
>>>> releases..
>>>>> So I would go with attic and clearly states to use karaf
>>>>>
>>>>>
>>>>>
>>>>> Inviato da Yahoo Mail su Android
>>>>>
>>>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
>> jb@nanthrax.net>
>>>> ha scritto:   Hi guys,
>>>>>
>>>>> If the ServiceMix project is fairly active for SMX Bundles and Specs,
>> we
>>>>> clearly have a "slow pace" on distribution releases.
>>>>>
>>>>> Here, we have two approaches possible:
>>>>>
>>>>> 1. We clearly state on website and codebase that users should better
>> use
>>>>> Karaf and create their own custom distribution if needed.
>>>>> 2. We begin a regular pace in distribution release.
>>>>>
>>>>> I think 1 makes more sense and it's worth to be mentioned in the SMX
>>>>> distribution.
>>>>>
>>>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>>>> - Update to Karaf 4.2.x
>>>>> - Update to Camel 3.0.1
>>>>> - Update on Activity
>>>>> - Cleanup and improved SMX features
>>>>> - Add itests in smx for coverage
>>>>>
>>>>> Another more "important" decision would be to retire ServiceMix to
>> attic
>>>>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
>>>>> Decanter, Cave, Cellar, ...).
>>>>>
>>>>> I think it's fair to discuss about that as we don't see lot of activity
>>>>> on ServiceMix distribution/releases.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

Hi

Good idea about not having it as part of featuresService (featuresProcessor
in Kara == Overrides v2). So getting closer to wrap: (wrap2: ?). Indeed
keeping some generic descriptors instead of building/voting/releasing SMX
bundles and generating actual bundles on the fly would be a good idea.

Where those descriptors could be stored? In some Karaf subdirectory maybe
(etc/)? Currently I see 413 subdirectories of
github/apache/servicemix-bundles repo, All of those could be in single XML
file. If some SMX (and soon Karaf-Bundles?) bundles need some additional
resources, this generic (by default) generator descriptor could be tweaked
to load/shade/repackage additional resources...

Anyway - I see it can be changed without huge effort.

regards
Grzegorz Grzybek

śr., 29 sty 2020 o 08:22 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> Hi Greg,
>
> For bundles, as separate project, I have more the idea of "descriptor".
>
> It's something I proposed while ago.
>
> Instead of storing the concrete artifacts, I would rather store the meta.
> However, some bundles needs "resources" (like META-INF/foo or code).
>
> So, basically, I agree with a "dynamic" processing, however, I don't
> think it's good to have this in feature.
> I would rather add a "bundle generator" service, generic, that can
> easily be used outside Karaf.
> The bundle generator service can read artifact from Central or any
> repository, than, he reads META descriptor and overriding resources
> (from karaf-bundles repo for instances) and generates a concrete bundle
> on the fly.
> Big advantage is that it's easy to change the META/bundle on the fly.
>
> Thoughts ?
>
> Regards
> JB
>
> On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> > Hello
> >
> > I can't tell much about SMX, but I fully agree about focusing on Karaf.
> >
> > About specs/bundles - good to have them as separate projects of Karaf
> (but
> > not in the same github/apache/karaf repo!), but for bundles I may have
> > different proposal... There's
> > https://issues.apache.org/jira/browse/KARAF-6200 for which I have local
> > implementation. I needed a mechanism to declaratively override bundle's
> > headers without touching the bundle. Similar to what we have with feature
> > override/blacklisting.
> >
> > KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds
> something
> > like this:
> >
> > <bundleProcessing>
> >     <bundle location="mvn:org.eclipse.jetty*/*">
> >         <add header="Processed-By" value="Karaf Bundle Processor" />
> >         <clause header="Import-Package" name="javax.servlet"
> > value='javax.servlet;version="[3.1.0,5)"' />
> >         <clause header="Import-Package" name="javax.servlet.annotation"
> > value='javax.servlet.annotation;version="[3.1.0,5)"' />
> >         <clause header="Import-Package" name="javax.servlet.descriptor"
> > value='javax.servlet.descriptor;version="[3.1.0,5)"' />
> >         <clause header="Import-Package" name="javax.servlet.http"
> > value='javax.servlet.http;version="[3.1.0,5)"' />
> >     </bundle>
> > </bundleProcessing>
> >
> > which does exactly what it shows - for all bundles (installed with
> > features) with URI matching "mvn:org.eclipse.jetty*/*" we alter manifest
> > clauses. I didn't need this mechanism after all, because I could make
> Jetty
> > run with Servlet API 4 using "compatibility fragment bundle" that adds
> > extended exports to javax.servlet:javax.servlet-api.
> >
> > What I was thinking about (even back in 2009
> > <https://www.theserverside.com/discussions/thread/53803.html#305391>)
> is to
> > maybe extend the above mechanism to get rid of SMX bundles entirely? I
> > know, I know, there's "wrap:" protocol where you can specify headers in
> URI
> > itself, but it's not that easy to use. So instead of releasing SMX
> bundles,
> > we can just release the above alteration definitions (somehow).
> > I know there are 10000 things I didn't think about (like what to do if
> you
> > don't use Karaf features where featuresService can apply the above
> > manipulation), but maybe it's worth trying?
> >
> > regards
> > Grzegorz Grzybek
> >
> > wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi Andrea,
> >>
> >> I fully agree with you.
> >>
> >> My proposal is basically:
> >>
> >> 1. Move SMX bundles and SMX specs as Karaf subproject
> >> 2. Create Karaf Integration distribution at Karaf (as we have standard
> >> and minimal distributions already)
> >> 3. Provide a migration guide for SMX users
> >> 4. Move ServiceMix project to attic
> >>
> >> Regards
> >> JB
> >>
> >> On 28/01/2020 15:27, Andrea Cosentino wrote:
> >>> +1 on each point.
> >>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
> >> releases..
> >>> So I would go with attic and clearly states to use karaf
> >>>
> >>>
> >>>
> >>> Inviato da Yahoo Mail su Android
> >>>
> >>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<
> jb@nanthrax.net>
> >> ha scritto:   Hi guys,
> >>>
> >>> If the ServiceMix project is fairly active for SMX Bundles and Specs,
> we
> >>> clearly have a "slow pace" on distribution releases.
> >>>
> >>> Here, we have two approaches possible:
> >>>
> >>> 1. We clearly state on website and codebase that users should better
> use
> >>> Karaf and create their own custom distribution if needed.
> >>> 2. We begin a regular pace in distribution release.
> >>>
> >>> I think 1 makes more sense and it's worth to be mentioned in the SMX
> >>> distribution.
> >>>
> >>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> >>> - Update to Karaf 4.2.x
> >>> - Update to Camel 3.0.1
> >>> - Update on Activity
> >>> - Cleanup and improved SMX features
> >>> - Add itests in smx for coverage
> >>>
> >>> Another more "important" decision would be to retire ServiceMix to
> attic
> >>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> >>> Decanter, Cave, Cellar, ...).
> >>>
> >>> I think it's fair to discuss about that as we don't see lot of activity
> >>> on ServiceMix distribution/releases.
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Greg,

For bundles, as separate project, I have more the idea of "descriptor".

It's something I proposed while ago.

Instead of storing the concrete artifacts, I would rather store the meta.
However, some bundles needs "resources" (like META-INF/foo or code).

So, basically, I agree with a "dynamic" processing, however, I don't
think it's good to have this in feature.
I would rather add a "bundle generator" service, generic, that can
easily be used outside Karaf.
The bundle generator service can read artifact from Central or any
repository, than, he reads META descriptor and overriding resources
(from karaf-bundles repo for instances) and generates a concrete bundle
on the fly.
Big advantage is that it's easy to change the META/bundle on the fly.

Thoughts ?

Regards
JB

On 29/01/2020 07:59, Grzegorz Grzybek wrote:
> Hello
> 
> I can't tell much about SMX, but I fully agree about focusing on Karaf.
> 
> About specs/bundles - good to have them as separate projects of Karaf (but
> not in the same github/apache/karaf repo!), but for bundles I may have
> different proposal... There's
> https://issues.apache.org/jira/browse/KARAF-6200 for which I have local
> implementation. I needed a mechanism to declaratively override bundle's
> headers without touching the bundle. Similar to what we have with feature
> override/blacklisting.
> 
> KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds something
> like this:
> 
> <bundleProcessing>
>     <bundle location="mvn:org.eclipse.jetty*/*">
>         <add header="Processed-By" value="Karaf Bundle Processor" />
>         <clause header="Import-Package" name="javax.servlet"
> value='javax.servlet;version="[3.1.0,5)"' />
>         <clause header="Import-Package" name="javax.servlet.annotation"
> value='javax.servlet.annotation;version="[3.1.0,5)"' />
>         <clause header="Import-Package" name="javax.servlet.descriptor"
> value='javax.servlet.descriptor;version="[3.1.0,5)"' />
>         <clause header="Import-Package" name="javax.servlet.http"
> value='javax.servlet.http;version="[3.1.0,5)"' />
>     </bundle>
> </bundleProcessing>
> 
> which does exactly what it shows - for all bundles (installed with
> features) with URI matching "mvn:org.eclipse.jetty*/*" we alter manifest
> clauses. I didn't need this mechanism after all, because I could make Jetty
> run with Servlet API 4 using "compatibility fragment bundle" that adds
> extended exports to javax.servlet:javax.servlet-api.
> 
> What I was thinking about (even back in 2009
> <https://www.theserverside.com/discussions/thread/53803.html#305391>) is to
> maybe extend the above mechanism to get rid of SMX bundles entirely? I
> know, I know, there's "wrap:" protocol where you can specify headers in URI
> itself, but it's not that easy to use. So instead of releasing SMX bundles,
> we can just release the above alteration definitions (somehow).
> I know there are 10000 things I didn't think about (like what to do if you
> don't use Karaf features where featuresService can apply the above
> manipulation), but maybe it's worth trying?
> 
> regards
> Grzegorz Grzybek
> 
> wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 
>> Hi Andrea,
>>
>> I fully agree with you.
>>
>> My proposal is basically:
>>
>> 1. Move SMX bundles and SMX specs as Karaf subproject
>> 2. Create Karaf Integration distribution at Karaf (as we have standard
>> and minimal distributions already)
>> 3. Provide a migration guide for SMX users
>> 4. Move ServiceMix project to attic
>>
>> Regards
>> JB
>>
>> On 28/01/2020 15:27, Andrea Cosentino wrote:
>>> +1 on each point.
>>> I wouldn't do an 8.0.0 release, because we can't guarantee patch
>> releases..
>>> So I would go with attic and clearly states to use karaf
>>>
>>>
>>>
>>> Inviato da Yahoo Mail su Android
>>>
>>>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net>
>> ha scritto:   Hi guys,
>>>
>>> If the ServiceMix project is fairly active for SMX Bundles and Specs, we
>>> clearly have a "slow pace" on distribution releases.
>>>
>>> Here, we have two approaches possible:
>>>
>>> 1. We clearly state on website and codebase that users should better use
>>> Karaf and create their own custom distribution if needed.
>>> 2. We begin a regular pace in distribution release.
>>>
>>> I think 1 makes more sense and it's worth to be mentioned in the SMX
>>> distribution.
>>>
>>> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
>>> - Update to Karaf 4.2.x
>>> - Update to Camel 3.0.1
>>> - Update on Activity
>>> - Cleanup and improved SMX features
>>> - Add itests in smx for coverage
>>>
>>> Another more "important" decision would be to retire ServiceMix to attic
>>> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
>>> Decanter, Cave, Cellar, ...).
>>>
>>> I think it's fair to discuss about that as we don't see lot of activity
>>> on ServiceMix distribution/releases.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Grzegorz Grzybek <gr...@gmail.com>]

Hello

I can't tell much about SMX, but I fully agree about focusing on Karaf.

About specs/bundles - good to have them as separate projects of Karaf (but
not in the same github/apache/karaf repo!), but for bundles I may have
different proposal... There's
https://issues.apache.org/jira/browse/KARAF-6200 for which I have local
implementation. I needed a mechanism to declaratively override bundle's
headers without touching the bundle. Similar to what we have with feature
override/blacklisting.

KARAF-6200 reuses etc/org.apache.karaf.feature.xml file and adds something
like this:

<bundleProcessing>
    <bundle location="mvn:org.eclipse.jetty*/*">
        <add header="Processed-By" value="Karaf Bundle Processor" />
        <clause header="Import-Package" name="javax.servlet"
value='javax.servlet;version="[3.1.0,5)"' />
        <clause header="Import-Package" name="javax.servlet.annotation"
value='javax.servlet.annotation;version="[3.1.0,5)"' />
        <clause header="Import-Package" name="javax.servlet.descriptor"
value='javax.servlet.descriptor;version="[3.1.0,5)"' />
        <clause header="Import-Package" name="javax.servlet.http"
value='javax.servlet.http;version="[3.1.0,5)"' />
    </bundle>
</bundleProcessing>

which does exactly what it shows - for all bundles (installed with
features) with URI matching "mvn:org.eclipse.jetty*/*" we alter manifest
clauses. I didn't need this mechanism after all, because I could make Jetty
run with Servlet API 4 using "compatibility fragment bundle" that adds
extended exports to javax.servlet:javax.servlet-api.

What I was thinking about (even back in 2009
<https://www.theserverside.com/discussions/thread/53803.html#305391>) is to
maybe extend the above mechanism to get rid of SMX bundles entirely? I
know, I know, there's "wrap:" protocol where you can specify headers in URI
itself, but it's not that easy to use. So instead of releasing SMX bundles,
we can just release the above alteration definitions (somehow).
I know there are 10000 things I didn't think about (like what to do if you
don't use Karaf features where featuresService can apply the above
manipulation), but maybe it's worth trying?

regards
Grzegorz Grzybek

wt., 28 sty 2020 o 15:30 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):

> Hi Andrea,
>
> I fully agree with you.
>
> My proposal is basically:
>
> 1. Move SMX bundles and SMX specs as Karaf subproject
> 2. Create Karaf Integration distribution at Karaf (as we have standard
> and minimal distributions already)
> 3. Provide a migration guide for SMX users
> 4. Move ServiceMix project to attic
>
> Regards
> JB
>
> On 28/01/2020 15:27, Andrea Cosentino wrote:
> > +1 on each point.
> > I wouldn't do an 8.0.0 release, because we can't guarantee patch
> releases..
> > So I would go with attic and clearly states to use karaf
> >
> >
> >
> > Inviato da Yahoo Mail su Android
> >
> >   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net>
> ha scritto:   Hi guys,
> >
> > If the ServiceMix project is fairly active for SMX Bundles and Specs, we
> > clearly have a "slow pace" on distribution releases.
> >
> > Here, we have two approaches possible:
> >
> > 1. We clearly state on website and codebase that users should better use
> > Karaf and create their own custom distribution if needed.
> > 2. We begin a regular pace in distribution release.
> >
> > I think 1 makes more sense and it's worth to be mentioned in the SMX
> > distribution.
> >
> > Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> > - Update to Karaf 4.2.x
> > - Update to Camel 3.0.1
> > - Update on Activity
> > - Cleanup and improved SMX features
> > - Add itests in smx for coverage
> >
> > Another more "important" decision would be to retire ServiceMix to attic
> > and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> > Decanter, Cave, Cellar, ...).
> >
> > I think it's fair to discuss about that as we don't see lot of activity
> > on ServiceMix distribution/releases.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: R: [PROPOSAL] Preparing Apache ServiceMix 8.0.0+1

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Andrea,

I fully agree with you.

My proposal is basically:

1. Move SMX bundles and SMX specs as Karaf subproject
2. Create Karaf Integration distribution at Karaf (as we have standard
and minimal distributions already)
3. Provide a migration guide for SMX users
4. Move ServiceMix project to attic

Regards
JB

On 28/01/2020 15:27, Andrea Cosentino wrote:
> +1 on each point.
> I wouldn't do an 8.0.0 release, because we can't guarantee patch releases..
> So I would go with attic and clearly states to use karaf
> 
> 
> 
> Inviato da Yahoo Mail su Android 
>  
>   Il mar, 28 gen, 2020 alle 15:01, Jean-Baptiste Onofré<jb...@nanthrax.net> ha scritto:   Hi guys,
> 
> If the ServiceMix project is fairly active for SMX Bundles and Specs, we
> clearly have a "slow pace" on distribution releases.
> 
> Here, we have two approaches possible:
> 
> 1. We clearly state on website and codebase that users should better use
> Karaf and create their own custom distribution if needed.
> 2. We begin a regular pace in distribution release.
> 
> I think 1 makes more sense and it's worth to be mentioned in the SMX
> distribution.
> 
> Regarding 2, I would like to propose a ServiceMix 8.0.0 with:
> - Update to Karaf 4.2.x
> - Update to Camel 3.0.1
> - Update on Activity
> - Cleanup and improved SMX features
> - Add itests in smx for coverage
> 
> Another more "important" decision would be to retire ServiceMix to attic
> and move SMX Bundles and Specs as Karaf subprojects (as we have Karaf
> Decanter, Cave, Cellar, ...).
> 
> I think it's fair to discuss about that as we don't see lot of activity
> on ServiceMix distribution/releases.
> 
> Thoughts ?
> 
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com