śr., 29 sty 2020 o 08:42 Jean-Baptiste Onofré <j...@nanthrax.net> 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é <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
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
