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é <j...@nanthrax.net> 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é <j...@nanthrax.net> > 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é< > j...@nanthrax.net> > >> 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é > >> jbono...@apache.org > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > >> > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
