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