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 >
