Completely generated features have a number of downsides:
- they require a template to use version ranges, for example for MRI projects
- they end up over-including things, hence they typically never catch anything at compile-time
- more advanced features of feature.xml are simply not available, as they are not expressible in pom.xml
At the end of the day, we are getting to a point where most features have a template anyway. Rather than battling this reality, we should embrace it and take one step back – i.e. use a feature.xml template with version expansion based on pom.xml and test that. We used to have this in Karaf 3, so this is nothing new.
We need to create a plugin which will perform the appropriate transformation – this can be XSLT or pretty much anything – the template is an XML, where we are going to perform a rather trivial substitution:
- we match only <bundle/> tags which contain a maven coordinate (starting with mvn: or wrap:mvn: )
- we match only <feature/> tags with version specification and test content
- within that coordinate we look for mustache-enclosed tag
- we replace the entire contents of mustache
There are only two substitutions we can make, both working on project dependency resolution. Assuming target artifact is resolved to "1.2.3", those are:
<bundle>mvn:org.opendaylight.genius/lockmanager-api/{{versionAsInProject}}</bundle> <feature version="{{semVerRange}}">odl-apache-commons-net</feature>
This would result in:
<bundle>mvn:org.opendaylight.genius/lockmanager-api/1.2.3</bundle> <feature version="[1.2.3,2)">odl-apache-commons-net</feature>
- split from
-
ODLPARENT-65 Use version ranges in generated features
- Resolved