You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@felix.apache.org by Göktürk Gezer <go...@apache.org> on 2012/04/04 16:06:58 UTC

IPojo manipulated bundle not synched with project folder contents

Hi Everyone,

We're using IPojo inside some Eclipse Plugin project for Eclipse itself.

Problem is:

IPojo manipulates the classes and generate new MANIFEST.MF file with
IPojo-Components contents. No problem with generated bundle but while
debugging, Eclipse picks the MANIFEST.MF in [PROJECT]/META-INF/ directory
and also loads the classes in [PROJECT]/target/classes which is default
behaviour. So clearly the problem is, these two aspects are not synched
with the manipulated bundle, thus, wrong MANIFEST.MF and nonmanipulated
classes are loaded into Equinox.

I have to manually change those things for our plugins to work correctly
inside Eclipse, which is not an acceptable solution. I would like to know
if there is some sophisticated method to handle these issues.

Regards,
Gokturk

Re: IPojo manipulated bundle not synched with project folder contents

Posted by "Guillaume Sauthier (Objectweb)" <gu...@objectweb.org>.

What about using the ipojo-bnd-plugin (there is a recent thread on
users@felix with configuration details) ?
It directly executes iPOJO manipulation inside the maven-bundle-plugin, so
it follow the behavior dictated by the bnd configuration.

--G

2012/4/11 Göktürk Gezer <go...@gmail.com>

> 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 ...
>
> From my favorite to less favorite:  1 - 3 - 2.
>
>
> > Regards,
> >
> > Clement
> >
> >
>

Re: IPojo manipulated bundle not synched with project folder contents

Posted by Göktürk Gezer <go...@apache.org>.

Sorry for late reply !

On Thu, Apr 12, 2012 at 5:20 PM, Guillaume Sauthier (OW2/GMail) <
guillaume.ow2@gmail.com> 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 <go...@gmail.com>
>
> > On Thu, Apr 12, 2012 at 12:28 PM, Guillaume Sauthier (Objectweb) <
> > guillaume.sauthier@objectweb.org> wrote:
> >
> > > 2012/4/12 Göktürk Gezer <go...@gmail.com>
> > >
> > > > Hi,
> > > >
> > > > On Thu, Apr 12, 2012 at 11:50 AM, Guillaume Sauthier (Objectweb) <
> > > > guillaume.sauthier@objectweb.org> 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 <cl...@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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>