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 >
