karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: features-maven-plugin progress and questions
Date Fri, 25 Mar 2011 03:31:33 GMT

On Thu, Mar 24, 2011 at 6:34 AM, David Jencks <david_jencks@yahoo.com> 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
>> - 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

> 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,

> 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

View raw message