Sorry for late reply ! On Thu, Apr 12, 2012 at 5:20 PM, Guillaume Sauthier (OW2/GMail) < [email protected]> wrote:
> So, the solution with bnd-plugin is OK for you ? > Yeah i guess i can live without it . > It feels easier than modifying the maven-ipojo-plugin ... > That's right. > --G > > 2012/4/12 Göktürk Gezer <[email protected]> > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > >
