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
