Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » PDE Builder and project registered builders
PDE Builder and project registered builders [message #45410] Thu, 05 February 2009 15:37 Go to next message
Laurent Petit is currently offline Laurent PetitFriend
Messages: 35
Registered: July 2009
Member
Hello,

I have a plugin project that uses jibx.
jibx does bytecode enhancement to existing classes. It also creates new classes based on information it finds in classes it enhances.

I installed jibx eclipse plugin that adds a jibx nature and a jibx builder to the project.

So everything works well in the modify/save/auto-build/launch development cycle.

But when I try to use the "export" functionality, either directly, or indirectly via the build of a feature via the build of the eclipse update sites, it does not work.


It's as if the export functionality does not leverage the project registered builders.


Is there a solution to this ? Is it a problem in jibx eclipse plugin not correctly doing something to be used via the export functionality ?
Is this a current problem with the eclipse PDE builder ?


I came up with 2 solutions currently, each of which has some cons :

- custom builder. I tell plugin.xml that I will use a custom builder. Ask PDE to create the build.xml file. Tweak the build.xml file. It's not very interesting, because it seems that a lot of things
are hardwired. The generated build.xml file seems to not have been thought to be usable in the long term (lack of factorization, ...).

- play with plugin.xml options : the idea here is to not make PDE compile the classes at all, and prefer instructing him to use the same classes than those compiled via the
modify/save/auto-build/launch/test cycle :
- "runtime" tab : add to the classpath the folder(s) where classes are compiled in the classic development cycle (generally speaking : 'bin' folder)
- "build" tab : "runtime information section" : delete the library named '.' (since we already get all by directly adding 'bin' in the classpath)
- "build" tab : "binary build section" : add folder 'bin' if not already added

I can just see one drawback to this : if the developer's worskpace is not in auto-build, or if the developer has not triggered a build before trying to export, then the 'bin' directory of the
generated plugin jar/folder will be empty.

Do you see other drawbacks to the second solution I may encounter in the long run ?
Re: PDE Builder and project registered builders [message #45505 is a reply to message #45410] Thu, 05 February 2009 19:29 Go to previous messageGo to next message
Andrew Niefer is currently offline Andrew NieferFriend
Messages: 990
Registered: July 2009
Senior Member
Laurent Petit wrote:
>
> It's as if the export functionality does not leverage the project
> registered builders.
>

Yes, this is exactly true.

You have 2 options:
1) Starting in 3.5 (I think M4) there is an option in the export wizard
to reuse .class files from the workspace. This should just pick up the
files after jibx has done its thing.

2) Use custom build callbacks to run custom ant code on your .class
files after they are compiled during export (See
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.pde.doc.user/tasks/pde_custom_callbacks.htm)

From your eclipse install, copy
org.eclipse.pde.build_<version>\templates\plugins\customBuildCallbacks.xml
into your project. In your project's build.properties add
"customBuildCallbacks=true).

In this file edit the post.compile.@dot task to call jibx. I don't know
anything about jibx, so I don't know what this would look like.
${source.folder1}, ${source.folder2}, etc will be properties pointing to
the source files (generally there is only one source folder)
${target.folder} is where the .class files will be
${@dot.classpath} is a reference to the classpath structure that was
used to compile everything.

If you have other libraries, the target will be post.compile.<library>

-Andrew



> Hello,
>
> I have a plugin project that uses jibx.
> jibx does bytecode enhancement to existing classes. It also creates new
> classes based on information it finds in classes it enhances.
>
> I installed jibx eclipse plugin that adds a jibx nature and a jibx
> builder to the project.
>
> So everything works well in the modify/save/auto-build/launch
> development cycle.
>
> But when I try to use the "export" functionality, either directly, or
> indirectly via the build of a feature via the build of the eclipse
> update sites, it does not work.
>
>
> It's as if the export functionality does not leverage the project
> registered builders.
>
>
> Is there a solution to this ? Is it a problem in jibx eclipse plugin not
> correctly doing something to be used via the export functionality ?
> Is this a current problem with the eclipse PDE builder ?
>
>
> I came up with 2 solutions currently, each of which has some cons :
>
> - custom builder. I tell plugin.xml that I will use a custom builder.
> Ask PDE to create the build.xml file. Tweak the build.xml file. It's not
> very interesting, because it seems that a lot of things are hardwired.
> The generated build.xml file seems to not have been thought to be usable
> in the long term (lack of factorization, ...).
>
> - play with plugin.xml options : the idea here is to not make PDE
> compile the classes at all, and prefer instructing him to use the same
> classes than those compiled via the modify/save/auto-build/launch/test
> cycle :
> - "runtime" tab : add to the classpath the folder(s) where classes
> are compiled in the classic development cycle (generally speaking :
> 'bin' folder)
> - "build" tab : "runtime information section" : delete the library
> named '.' (since we already get all by directly adding 'bin' in the
> classpath)
> - "build" tab : "binary build section" : add folder 'bin' if not
> already added
>
> I can just see one drawback to this : if the developer's worskpace is
> not in auto-build, or if the developer has not triggered a build before
> trying to export, then the 'bin' directory of the generated plugin
> jar/folder will be empty.
>
> Do you see other drawbacks to the second solution I may encounter in the
> long run ?
Re: PDE Builder and project registered builders [message #45534 is a reply to message #45505] Fri, 06 February 2009 08:57 Go to previous message
Laurent Petit is currently offline Laurent PetitFriend
Messages: 35
Registered: July 2009
Member
Many thanks !

I'll try this ASAP,

--
Laurent

Andrew Niefer wrote:
> Laurent Petit wrote:
> >
> > It's as if the export functionality does not leverage the project
> > registered builders.
> >
>
> Yes, this is exactly true.
>
> You have 2 options:
> 1) Starting in 3.5 (I think M4) there is an option in the export wizard
> to reuse .class files from the workspace. This should just pick up the
> files after jibx has done its thing.
>
> 2) Use custom build callbacks to run custom ant code on your .class
> files after they are compiled during export (See
> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.pde.doc.user/tasks/pde_custom_callbacks.htm)
>
>
> From your eclipse install, copy
> org.eclipse.pde.build_<version>\templates\plugins\customBuildCallbacks.xml
> into your project. In your project's build.properties add
> "customBuildCallbacks=true).
>
> In this file edit the post.compile.@dot task to call jibx. I don't know
> anything about jibx, so I don't know what this would look like.
> ${source.folder1}, ${source.folder2}, etc will be properties pointing to
> the source files (generally there is only one source folder)
> ${target.folder} is where the .class files will be
> ${@dot.classpath} is a reference to the classpath structure that was
> used to compile everything.
>
> If you have other libraries, the target will be post.compile.<library>
>
> -Andrew
>
>
>
>> Hello,
>>
>> I have a plugin project that uses jibx.
>> jibx does bytecode enhancement to existing classes. It also creates
>> new classes based on information it finds in classes it enhances.
>>
>> I installed jibx eclipse plugin that adds a jibx nature and a jibx
>> builder to the project.
>>
>> So everything works well in the modify/save/auto-build/launch
>> development cycle.
>>
>> But when I try to use the "export" functionality, either directly, or
>> indirectly via the build of a feature via the build of the eclipse
>> update sites, it does not work.
>>
>>
>> It's as if the export functionality does not leverage the project
>> registered builders.
>>
>>
>> Is there a solution to this ? Is it a problem in jibx eclipse plugin
>> not correctly doing something to be used via the export functionality ?
>> Is this a current problem with the eclipse PDE builder ?
>>
>>
>> I came up with 2 solutions currently, each of which has some cons :
>>
>> - custom builder. I tell plugin.xml that I will use a custom builder.
>> Ask PDE to create the build.xml file. Tweak the build.xml file. It's
>> not very interesting, because it seems that a lot of things are
>> hardwired. The generated build.xml file seems to not have been thought
>> to be usable in the long term (lack of factorization, ...).
>>
>> - play with plugin.xml options : the idea here is to not make PDE
>> compile the classes at all, and prefer instructing him to use the same
>> classes than those compiled via the modify/save/auto-build/launch/test
>> cycle :
>> - "runtime" tab : add to the classpath the folder(s) where classes
>> are compiled in the classic development cycle (generally speaking :
>> 'bin' folder)
>> - "build" tab : "runtime information section" : delete the library
>> named '.' (since we already get all by directly adding 'bin' in the
>> classpath)
>> - "build" tab : "binary build section" : add folder 'bin' if not
>> already added
>>
>> I can just see one drawback to this : if the developer's worskpace is
>> not in auto-build, or if the developer has not triggered a build
>> before trying to export, then the 'bin' directory of the generated
>> plugin jar/folder will be empty.
>>
>> Do you see other drawbacks to the second solution I may encounter in
>> the long run ?
Re: PDE Builder and project registered builders [message #591535 is a reply to message #45410] Thu, 05 February 2009 19:29 Go to previous message
Andrew Niefer is currently offline Andrew NieferFriend
Messages: 990
Registered: July 2009
Senior Member
Laurent Petit wrote:
>
> It's as if the export functionality does not leverage the project
> registered builders.
>

Yes, this is exactly true.

You have 2 options:
1) Starting in 3.5 (I think M4) there is an option in the export wizard
to reuse .class files from the workspace. This should just pick up the
files after jibx has done its thing.

2) Use custom build callbacks to run custom ant code on your .class
files after they are compiled during export (See
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.pde.doc.user/tasks/pde_custom_callbacks.htm)

From your eclipse install, copy
org.eclipse.pde.build_<version>\templates\plugins\customBuildCallbacks.xml
into your project. In your project's build.properties add
"customBuildCallbacks=true).

In this file edit the post.compile.@dot task to call jibx. I don't know
anything about jibx, so I don't know what this would look like.
${source.folder1}, ${source.folder2}, etc will be properties pointing to
the source files (generally there is only one source folder)
${target.folder} is where the .class files will be
${@dot.classpath} is a reference to the classpath structure that was
used to compile everything.

If you have other libraries, the target will be post.compile.<library>

-Andrew



> Hello,
>
> I have a plugin project that uses jibx.
> jibx does bytecode enhancement to existing classes. It also creates new
> classes based on information it finds in classes it enhances.
>
> I installed jibx eclipse plugin that adds a jibx nature and a jibx
> builder to the project.
>
> So everything works well in the modify/save/auto-build/launch
> development cycle.
>
> But when I try to use the "export" functionality, either directly, or
> indirectly via the build of a feature via the build of the eclipse
> update sites, it does not work.
>
>
> It's as if the export functionality does not leverage the project
> registered builders.
>
>
> Is there a solution to this ? Is it a problem in jibx eclipse plugin not
> correctly doing something to be used via the export functionality ?
> Is this a current problem with the eclipse PDE builder ?
>
>
> I came up with 2 solutions currently, each of which has some cons :
>
> - custom builder. I tell plugin.xml that I will use a custom builder.
> Ask PDE to create the build.xml file. Tweak the build.xml file. It's not
> very interesting, because it seems that a lot of things are hardwired.
> The generated build.xml file seems to not have been thought to be usable
> in the long term (lack of factorization, ...).
>
> - play with plugin.xml options : the idea here is to not make PDE
> compile the classes at all, and prefer instructing him to use the same
> classes than those compiled via the modify/save/auto-build/launch/test
> cycle :
> - "runtime" tab : add to the classpath the folder(s) where classes
> are compiled in the classic development cycle (generally speaking :
> 'bin' folder)
> - "build" tab : "runtime information section" : delete the library
> named '.' (since we already get all by directly adding 'bin' in the
> classpath)
> - "build" tab : "binary build section" : add folder 'bin' if not
> already added
>
> I can just see one drawback to this : if the developer's worskpace is
> not in auto-build, or if the developer has not triggered a build before
> trying to export, then the 'bin' directory of the generated plugin
> jar/folder will be empty.
>
> Do you see other drawbacks to the second solution I may encounter in the
> long run ?
Re: PDE Builder and project registered builders [message #591546 is a reply to message #45505] Fri, 06 February 2009 08:57 Go to previous message
Laurent Petit is currently offline Laurent PetitFriend
Messages: 35
Registered: July 2009
Member
Many thanks !

I'll try this ASAP,

--
Laurent

Andrew Niefer wrote:
> Laurent Petit wrote:
> >
> > It's as if the export functionality does not leverage the project
> > registered builders.
> >
>
> Yes, this is exactly true.
>
> You have 2 options:
> 1) Starting in 3.5 (I think M4) there is an option in the export wizard
> to reuse .class files from the workspace. This should just pick up the
> files after jibx has done its thing.
>
> 2) Use custom build callbacks to run custom ant code on your .class
> files after they are compiled during export (See
> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.pde.doc.user/tasks/pde_custom_callbacks.htm)
>
>
> From your eclipse install, copy
> org.eclipse.pde.build_<version>\templates\plugins\customBuildCallbacks.xml
> into your project. In your project's build.properties add
> "customBuildCallbacks=true).
>
> In this file edit the post.compile.@dot task to call jibx. I don't know
> anything about jibx, so I don't know what this would look like.
> ${source.folder1}, ${source.folder2}, etc will be properties pointing to
> the source files (generally there is only one source folder)
> ${target.folder} is where the .class files will be
> ${@dot.classpath} is a reference to the classpath structure that was
> used to compile everything.
>
> If you have other libraries, the target will be post.compile.<library>
>
> -Andrew
>
>
>
>> Hello,
>>
>> I have a plugin project that uses jibx.
>> jibx does bytecode enhancement to existing classes. It also creates
>> new classes based on information it finds in classes it enhances.
>>
>> I installed jibx eclipse plugin that adds a jibx nature and a jibx
>> builder to the project.
>>
>> So everything works well in the modify/save/auto-build/launch
>> development cycle.
>>
>> But when I try to use the "export" functionality, either directly, or
>> indirectly via the build of a feature via the build of the eclipse
>> update sites, it does not work.
>>
>>
>> It's as if the export functionality does not leverage the project
>> registered builders.
>>
>>
>> Is there a solution to this ? Is it a problem in jibx eclipse plugin
>> not correctly doing something to be used via the export functionality ?
>> Is this a current problem with the eclipse PDE builder ?
>>
>>
>> I came up with 2 solutions currently, each of which has some cons :
>>
>> - custom builder. I tell plugin.xml that I will use a custom builder.
>> Ask PDE to create the build.xml file. Tweak the build.xml file. It's
>> not very interesting, because it seems that a lot of things are
>> hardwired. The generated build.xml file seems to not have been thought
>> to be usable in the long term (lack of factorization, ...).
>>
>> - play with plugin.xml options : the idea here is to not make PDE
>> compile the classes at all, and prefer instructing him to use the same
>> classes than those compiled via the modify/save/auto-build/launch/test
>> cycle :
>> - "runtime" tab : add to the classpath the folder(s) where classes
>> are compiled in the classic development cycle (generally speaking :
>> 'bin' folder)
>> - "build" tab : "runtime information section" : delete the library
>> named '.' (since we already get all by directly adding 'bin' in the
>> classpath)
>> - "build" tab : "binary build section" : add folder 'bin' if not
>> already added
>>
>> I can just see one drawback to this : if the developer's worskpace is
>> not in auto-build, or if the developer has not triggered a build
>> before trying to export, then the 'bin' directory of the generated
>> plugin jar/folder will be empty.
>>
>> Do you see other drawbacks to the second solution I may encounter in
>> the long run ?
Previous Topic:How to create config.ini file to accept any eclipse plugins in my rcp
Next Topic:headless compilation: equinox launcher version
Goto Forum:
  


Current Time: Tue Mar 19 11:19:13 GMT 2024

Powered by FUDForum. Page generated in 0.03109 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top