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
