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é <[email protected]> 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é <[email protected]>
>> 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é<
>> [email protected]>
>>>> 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é
>>>> [email protected]
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [email protected]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
