+1 for that regards Grzegorz Grzybek
czw., 30 sty 2020 o 08:33 Jean-Baptiste Onofré <[email protected]> napisał(a): > 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 >
