sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: [Sling Feature Model] Expanded requirements
Date Wed, 21 Feb 2018 09:42:58 GMT
Hi Ioan,

Yes, there are indeed similarities with the Karaf feature functionality and
actually also similarities with the OSGi Subsystem specification [0]. The
interesting thing is that even though that there is an OSGi specification
in this area, there seems to be a need for something a little bit
different. This can also be seen by the recent contribution to Apache Felix
of the Bundle Archive installer [1].

The requirements here are really aiming to provide a 'next generation' of
the Sling Provisioning model that has already existed for quite some time.

These are all technologies that have some overlap but were still developed
because what was there just didn't quite fit the use cases. I think that
once we are a little further along the implementation of the Sling Feature
Model we could try to see if a common set of requirements can be extracted
that can then be proposed as an RFP for a new OSGi specification. One great
benefit of having such an independent spec would be that tooling would work
with all the implementations, as you say. But obviously the spec needs to
work for all different users so there is definitely a lot of work needed
there.

Best regards,

David

PS @Carsten I guess you're right - maybe this time would be a bit too early
to move it out of the whiteboard.

[0] https://osgi.org/specification/osgi.cmpn/7.0.0/service.subsystem.html
[1] https://www.mail-archive.com/dev@felix.apache.org/msg45002.html

On 21 February 2018 at 07:45, Ioan Eugen Stan <ieugen@netdava.com> wrote:

> Hi,
>
> I've looked on the specification and I've noticed that it also overlaps
> with the Karaf Feature functionality.
>
> Is there any relation between the two? Is there collaboration between
> the projects?
>
> As a user/consumer of technology I enjoy when technologies are
> compatible and the tooling support is great.
>
> I believe collaboration in this area is beneficial. I would like to be
> able to provision Sling features in Karaf and Karaf features in Sling
> with ease.
>
> If you put the spec side by side they share a LOT of things, but there
> are also some minor differences, like file format. Karaf uses XML which
> has much better tooling support IMO, but this is a persistence format
> and can be easily changed.
>
>
> p.s. I like the spec, I imagine it took quite some time to write. Kudos !
>
> Regards,
>
> [1] https://karaf.apache.org/manual/latest/provisioning
>
>
>
> On 21.02.2018 09:10, Carsten Ziegeler wrote:
> > Thanks David
> >
> > We're neither 100% clear on the requirements nor on the structure,
> > meaning we don't know how many and what modules this will be. As we're
> > following the one module per git repo rule, it's currently impossible to
> > create the correct git repositories. And I guess it doesn't make sense
> > to rename them or remove them every now and then.
> >
> > As the collaboration with the whiteboard is the same as with separate
> > modules, I don't think there is anything wrong with having this in the
> > whiteboard for now. Moving it out now creates more problems than it
> solves.
> >
> > Regards
> >
> > Carsten
> >
> >
> > David Bosschaert wrote
> >> Hi all,
> >>
> >> Over the recent past some additions have been made to the requirements
> of
> >> the Sling Feature Model. The updated requirements can be found here:
> >> https://github.com/apache/sling-whiteboard/blob/master/featu
> remodel/readme.md
> >>
> >> Any additional requirements, let us know!
> >>
> >> I'm hoping to start contributing to the implementation of some of these
> in
> >> the near term and was wondering - is there a reason why the feature
> model
> >> still in the sling-whiteboard? Or would it make sense to put it in its
> own
> >> Sling git repo or repos?
> >>
> >> Best regards,
> >>
> >> David
> >>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message