On Thu, Apr 12, 2012 at 12:28 PM, Guillaume Sauthier (Objectweb) < [email protected]> wrote:
> 2012/4/12 Göktürk Gezer <[email protected]> > > > 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. > > > > For me, modifying the Store for a new usage of maven-ipojo-plugin when the > same goal could be achieved with a combination of existing > maven-bundle-plugin + ipojo-bnd-plugin is some kind of duplicate effort ... > It is just an option. So much like an experiment. However they are not doing the same thing. Main point was to manipulate the classes and generate the MANIFEST correctly at "compile" time, and it does that. If the same thing could be achieved with ipojo_bnd_plugin in bundle@manifest goal, that would be a better solution for sure. > > > > > > I tried that on a simple example, and I obtained a manipulated manifest > > in > > > the defined directory... > > > > > Is this also manipulated the classes? > > > > maven-bundle-plugin@manifest only generates the manifest in a dedicated > directory. > The bnd-plugin manipulates the component's classes, but this goal is > designed not to produce any bytecode, so no manipulated bytecode here... > > Anyway, if you use the maven-bundle-plugin@bundle goal, with the > "manifestLocation" configuration, you get both the manipulated bundle > content AND the manipulated MANIFEST written in the location of your > choice. > Yes i confirm, above usage with <unpackBundle> works to update project folder after packaging. > --G > > > > > > > > > > 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] > > > > > > > > > > > > > >
