On Thu, Apr 12, 2012 at 2:17 PM, Guillaume Sauthier (Objectweb) < [email protected]> wrote:
> If you want the classes of the bundle to be placed in the target/classes > directory, you have to use the <unpackBundle> configuration option. > That should do the trick for you, right ? > Yeah it should have and i tried it already, but it didn't work for some reason. Maybe i'm doing something wrong ! > --G > > 2012/4/12 Göktürk Gezer <[email protected]> > > > 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] > > >> > > > >> > > > >> > > > > > > > > >
