Good point and actually I was thinking about improving pax-url-wrap.
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
