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 >
