Hey, On Thu, Mar 24, 2011 at 6:34 AM, David Jencks <[email protected]> wrote: > > On Mar 22, 2011, at 5:24 PM, Jean-Baptiste Onofré wrote: > >> Thanks for the update David. >> >> AFAIR, the ValidateFeaturesMojo allow you: >> - check if the features descriptor is valid regarding the XSD (introduced in >> Karaf 2.2.0) >> - check if there's not missing features or bundles in the features descriptor >> >> +1 to remove "old" Mojos. >> >> On my side, I would like to work on KARAF-402 to gather all goals in one >> main Karaf maven plugin. >> Do you prefer that you have finished your changes before starting this ? > > I think KARAF-402 consists of moving the cmdhelp package to the > features-maven-plugin src/main/java/org/apache/karaf/tooling and changing the > project name for features-maven-plugin to karaf-maven-plugin?
Yep, that's KARAF-402 :) > If this is all there is perhaps I could do it when I have a spare minute and > time to update all the local projects I have that are using the plugin. WDYT? Since you've invested more time than we together into this plugin in the last weeks I think this is a good idea. So +1 from my side to go ahead. > I could also try to come up with a command packaging that includes generating > the cmdhelp. Also +1 here. I think this would make sense since (AFAIK) the cmdhelp is only required in this specific context --> including it in an own packaging would make perfect sense. Kind regards, Andreas > > thanks > david jencks > >> >> Regards >> JB >> >> On 03/23/2011 12:00 AM, David Jencks wrote: >>> I've been working on the features-maven-plugin some more. I added a sample >>> assemblies-apache-karaf-minimal assembly to show some of what it can do >>> (this is the same as the archive-server packaging but not using the >>> packaging itself). >>> >>> I rewrote the dependency tree analysis in the GenerateFeatureXml2 mojo to >>> use aether. Possibly it could be even simpler but this seems ok for now. >>> >>> The InstallKars mojo now can install both kars and features. By default >>> bundles listed in features.xml are put into startup.properties. After >>> completing startup.properties, it uses aether to install all the (missing) >>> bundles into system. >>> >>> I don't understand the philosophy differentiating stuff put into system and >>> started from startup.properties and stuff put into local-repo and started >>> by other means. IIUC if you do a clean start you will have to reconstruct >>> everything you installed not listed in startup.properties, is this correct? >>> >>> I'm considering making compile scoped features and kars get installed into >>> system and startup.properties and runtime scoped features and kars >>> installed into local-repo and the features cfg file (so at least the server >>> will still know about them after a clean). Is this reasonable? >>> >>> Note that the sample apache-karaf-minimal assembly is much much faster than >>> the apache-karar assembly. I would prefer to use the new method. AFAIK >>> the missing piece is the source assembly. Is this actually useful? the >>> release plugin produces a source archive that seems more than adequate to >>> me. >>> >>> What else needs to be implemented before we can remove some of the old >>> mojos? >>> I think we can remove these: >>> GenerateFeaturesFileMojo >>> GenerateFeaturesXmlMojo (use feature or kar packaging) >>> AddFeaturesToRepoMojo (use archive-server packaging) >>> >>> I don't understand what this does, can someone explain? >>> ValidateFeaturesMojo >>> >>> thanks >>> david jencks >>> > >
