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