I have 2 things to say to that - I agree with all the pain points you've identified (experienced them myself) - I'd prefer to fix things instead of claim them useless due to malfunctioning
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. Best, Milen On Thu, Oct 13, 2016 at 11:07 AM, Guillaume Nodet <[email protected]> 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: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > -- http://about.me/milen
