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é <[email protected]> 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é <[email protected]> >> 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é <[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 >>>> >>> >> >> -- >> 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
