Hi, I like that proposal. +1
2011/3/2 David Jencks <[email protected]>: > 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
