Hi Guillaume, I looked further into it and, unfortunately it is not manipulating the classes. But it is a more polished approach.
I'll look into ipojo-bnd-plugin to see if its possible. More pointers are welcomed. Regards, Gokturk On Thu, Apr 12, 2012 at 12:02 PM, Göktürk Gezer <[email protected]>wrote: > Hi, > > On Thu, Apr 12, 2012 at 11:50 AM, Guillaume Sauthier (Objectweb) < > [email protected]> wrote: > >> Yes, the DirectoryResourceStore is extensible. >> I'm just wondering if we cannot achieve the same goal in an easier way. >> >> What do you think of executing the maven-bundle-plugin's "manifest" goal >> with the ipojo-bnd-plugin activated ? >> > I didn't have a look at the ipojo-bnd-plugin yet. But definetely it should > be considered. I just focused on maven-ipojo-plugin first. > >> I tried that on a simple example, and I obtained a manipulated manifest in >> the defined directory... >> > Is this also manipulated the classes? > >> >> here is my plugin configuration: >> >> <plugin> >> <groupId>org.apache.felix</groupId> >> <artifactId>maven-bundle-plugin</artifactId> >> <version>2.3.7</version> >> <extensions>true</extensions> >> <executions> >> <execution> >> <id>generate-bundle-manifest</id> >> <goals> >> <goal>manifest</goal> >> </goals> >> <configuration> >> <instructions> >> >> >> >> <_plugin>org.apache.felix.ipojo.bnd.PojoizationPlugin;use-local-schemas=true</_plugin> >> </instructions> >> <manifestLocation>target/manifest</manifestLocation> >> </configuration> >> </execution> >> </executions> >> <dependencies> >> <dependency> >> <groupId>org.apache.felix</groupId> >> <artifactId>bnd-ipojo-plugin</artifactId> >> <version>1.8.4</version> >> </dependency> >> </dependencies> >> </plugin> >> >> >> Hope that helps >> --G >> > Regards, > Gokturk > >> >> >> 2012/4/12 Clement Escoffier <[email protected]> >> >> > Hi, >> > >> > On 11.04.2012, at 18:31, Göktürk Gezer wrote: >> > >> > > 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 >> > > way: >> > > >> > > *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 >> > > directoryManipulation(); >> > > >> > > In my experiments, manipulated contents and MANIFEST work just fine >> after >> > > maven-bundle-plugin:bundle without maven-ipojo-plugin:ipojo-bundle >> after >> > > packaging. >> > > >> > > 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 … >> > >> > The DirectoryResourceStore is definitely extendible. Guillaume has >> > probably a better idea about it. But anyway, it looks really cool ! >> > >> > Regards, >> > >> > Clement >> > >> > >> > > >> > > From my favorite to less favorite: 1 - 3 - 2. >> > > >> > > >> > >> Regards, >> > >> >> > >> Clement >> > >> >> > >> >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> > >
