I have 2 things to say to that
- I agree with all the pain points you've identified (experienced them
- I'd prefer to fix things instead of claim them useless due to
Perhaps a middle ground would be a good starting point? Something like how
bndrun resolution works. I mean:
- developer says - this is what I care to run (perhaps a prototype feature
or something ...)
- feature-generate-descriptor takes it from there and fills in the gaps
- developer can change/fix things by tweaking the prototype if not happy
with what feature-generate-descriptor did
This is just my first thought and I'm pretty sure reality is not that
simple. Just wanted to vote against removing it and suggest to start
looking for better solution instead.
On Thu, Oct 13, 2016 at 11:07 AM, Guillaume Nodet <gno...@apache.org> wrote:
> The feature packaging is a nice thing, as it allows automatic attachment of
> the feature file.
> However, it always use the feature-generate-descriptor, which produces a
> lot of weird results.
> Afaik, the feature packaging is not much used and all projects i've seen,
> such as pax projects, camel, cxf, and even karaf itself (including
> decanter, cellar, karaf container...).
> I think part of the problem comes from the feature descriptor generation,
> which is difficult to control. I have always found much easier to simply
> write the feature manually.
> Although the generation process rewrites the xml entirely, so that any xml
> comments or license header is lost.
> Overall, I'm not sure that it makes our users life really easier.
> So I'd like to propose to get rid of the feature-generate-descriptor from
> inside the feature packaging and replace it with the verify goal to
> validate the hand-written features instead.
> Thoughts ?
> Guillaume Nodet
> Red Hat, Open Source Integration
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/