this sure has gotten long :-) Lets see if I can summarize... maybe we can double the length...
First, the features.xml generation and kar assembly are done in separate mojos, and the feature packaging stops after feature generation whereas the kar packaging generates the features.xml and then assembles a kar. Features generation: I think we all agree that the output from features generation should express pretty much all the options available in a features.xml. Some of these are going to be easy to derive from pom dependencies and other native pom information, some are going to be easy to derive from maven plugin configuration, and some are going to be easier to express in a source features.xml that is modified. The one thing that the current features generation doesn't do is include more than one feature in a generated features.xml. I'm not sure how important this is. One option should we decide to support it would be to have a plugin configuration option that includes the features from maven dependencies that are features. In other words, in a features or kar project A, if one of the maven dependencies B is a features packaging project, we would include the features from B's feature.xml in the generated features.xml for A. kar assembly: I think there's supposed to be way of controlling whether a dependency gets included in the kar, I'm not sure if that's implemented yet. We might want more flexibility about where resources get unpacked on installation. validation: I think this is the main area of controversy. There are two aspects: 1. should we validate that dependencies mentioned in the preexisting features.xml are also (transitive) maven dependencies of the project 2. should we include dependencies mentioned in the preexisting features.xml that are not known to maven in a kar. My answer to these are 1 yes, 2 no. (2 is only relevant if you answer 1 no). 2: if maven doesn't know about a dependency, then you need a way outside maven to find the dependency in order to include it in the kar. I guess this would involve configuring the pax-mvn-url stuff. But this duplicates maven configuration. This is just a bad idea and pretty much guarantees a non-portable build. 1. I think this is usually a good idea, but essential for kar packaging. I'd be OK with having an option to turn it off for standalone feature packaging, especially for non-mvn url dependencies. ------------- We might start needing some more concrete examples to focus the discussion. For instance seeing what Adrian means by "ergonomic" might be useful and insteresting. And as a side note.... karaf 3 is java 6 so it should be OK now to move the jaxb classes from tooling into the feature deployer runtime? thanks david jencks
