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 >
