felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Sauthier (Objectweb)" <guillaume.sauth...@objectweb.org>
Subject Re: IPojo manipulated bundle not synched with project folder contents
Date Thu, 12 Apr 2012 08:50:47 GMT
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 tried that on a simple example, and I obtained a manipulated manifest in
the defined directory...

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


2012/4/12 Clement Escoffier <clement.escoffier@gmail.com>

> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

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