felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject Re: IPojo manipulated bundle not synched with project folder contents
Date Wed, 11 Apr 2012 16:31:11 GMT
Hi Clement,

> > Question is, in which shape we should integrate that facility into maven
> > build:
> > * A new goal for directoryManipulation for use in 'compile' phase
> > * A new boolean property for ipojo-bundle goal to unpack manipulated
> > content into project folder
> > * Modification of current mojo to also accept directory paths as
> > manipulation candidate
> > * Or combination of above approaches,
> >
> So, I will eliminate 2 because of the overhead. I would be in favor of 1
> because you don't actually have to package the bundle to get it to work,
> however it requires the manifest to be updated too. I'm not sure that this
> is actually possible.
I reconsidered the option-1 today and yeah, it seems non-trivial just
inside maven-ipojo-plugin. But i've managed to implement the option-1 that

*Created a new goal "ipojo-manipulate" in "process-classes" phase, which
extends maven-bundle-plugin's "manifest" goal. Plugin property propagation
is managed by maven-inherit-plugin added to parent pom.
*As i see maven-ipojo-plugin is beeing used with maven-bundle-plugin
generally. So i read the maven-bundle-plugin configuration in pom.xml
inside "ipojo-manipulate" mojo to issue a MANIFEST file generation.
If pom.xml does not contain maven-bundle-plugin instructions then MANIFEST
is generated with default values by bnd.
*Then manipulate the class contents and MANIFEST file using

In my experiments, manipulated contents and MANIFEST work just fine after
maven-bundle-plugin:bundle without maven-ipojo-plugin:ipojo-bundle after

When configured correctly with m2e plugin, i believe that this new goal can
replace ipojo-ant task inside eclipse. But i don't know it for sure, didn't
tried it yet, since i don't know how m2e's MavenBuilder works internally.

One problem with the implementation comes from
DirectoryResourceStore.open() method, since it is writing manipulated
MANIFEST to a fixed location rather then altering given MANIFEST. So i
added a additional field to DirectoryResourceStore to keep MANIFEST file's
path, then used it. However i don't know if i'm breaking some intended
behavior here?

Please let me know WDYT about that approach in theory ...

>From my favorite to less favorite:  1 - 3 - 2.

> Regards,
> Clement

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message