Home » Eclipse Projects » Eclipse Platform » Eclipse PDE Launch vs Export
Eclipse PDE Launch vs Export [message #331480] |
Tue, 09 September 2008 16:34 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: aiello.barron-associates.com
One of the things I continue to fail to grasp about the Eclipse Plugin Development Environment is the difference between selecting "Launch an Eclipse Application" from my product definition as opposed to "Use the Eclipse Product export wizard...." to build a stand-alone, deployable program.
My project builds an Eclipse RCP Application. It uses a host of plugins (many of which I wrote as subcomponents of the build) to get its job done, as well as 2 plugins that were automagically created by the IDE from JARs (Xerces and Jacob, in my case). Now, being someone fairly anal about warnings, I've spend a lot of time systematically going through my projects and tweaking settings so that warnings (generated by other people's code, like JFreeCharts) don't show up. So, within the IDE, my entire Workspace compiles sans warnings or errors. Which is great. Furthermore, if I select the aforementioned "Launch an Eclipse Application," everything works fine.
But when I attempt to export my product, the build fails spectacularly. Not only do I get errors in code that, within the IDE, is error free, but in compiling the JFreeCharts code (for which I suppressed a host of warnings), I get 2266 warnings.
So what gives? Why is it that completely different compiler settings seem to be used for the in-IDE build leading up to an in-IDE run as opposed to an export for deployment? Perhaps more importantly, why is this viewed as a Good Thing? From my point of view, it's a Very Bad Thing (since it means that my in-IDE build and test is basically useless).... But for it to have persisted into the 4th major release of version 3 of the tool, someone must think it's a Good Thing. I assume, therefore, that I fundamentally don't understand something critical about this whole process.
Apologies if this has been answered (I suspect it has) - I've been utterly unable to unearth anything through Google or searching these forums.
|
|
|
Re: Eclipse PDE Launch vs Export [message #331486 is a reply to message #331480] |
Tue, 09 September 2008 21:00 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Andrew Niefer![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=aniefer%40gmail.com) Messages: 990 Registered: July 2009 |
Senior Member |
|
|
The root of this is that for "real" products, you generally are not
going to ship to your customer something that you compiled manually by
loading all your projects into the IDE.
Generally then, you have some kind of automated headless system that
builds everything over night. In Eclipse, that automated headless sytem
is usually PDE/Build. Export from the UI is essentially a push-button
run of the headless build system to give you something closer to
automated headless build. It glosses over many of the configuration
details that are available.
The fundamental problem is PDE/Build does not know about the workspace
and any builders (including the jdt builder) that may be running there.
This is the source of the disconnect with what you see in the IDE.
PDE/UI does do some synchronization between the workspace and the
headless system, but does not cover everything.
Hope this clarifies things somewhat.
There are open bugs around this that have been open for a while, however
manpower is always at a premium and the PDE/Build team is quite small.
In particular https://bugs.eclipse.org/bugs/show_bug.cgi?id=101241
managed to slip off of both 3.3 and 3.4 schedules.
For your particular issues, consider using the
Bundle-RequiredExecutionEnvironment manifest header and set up
appropriate JREs in your preferences Java->Installed JREs->Execution
Environments. See also
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.pde.doc.user/tasks/pde_compilation_env.htm
Compiler warning options can be set in the plug-in's build.properties
file, see javacWarnings.<library> (<library> is generally '.', or a
nested 'lib.jar') from
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.pde.doc.user/reference/pde_feature_generating_build.htm
-Andrew
M. Anthony Aiello wrote:
> One of the things I continue to fail to grasp about the Eclipse Plugin Development Environment is the difference between selecting "Launch an Eclipse Application" from my product definition as opposed to "Use the Eclipse Product export wizard...." to build a stand-alone, deployable program.
>
> My project builds an Eclipse RCP Application. It uses a host of plugins (many of which I wrote as subcomponents of the build) to get its job done, as well as 2 plugins that were automagically created by the IDE from JARs (Xerces and Jacob, in my case). Now, being someone fairly anal about warnings, I've spend a lot of time systematically going through my projects and tweaking settings so that warnings (generated by other people's code, like JFreeCharts) don't show up. So, within the IDE, my entire Workspace compiles sans warnings or errors. Which is great. Furthermore, if I select the aforementioned "Launch an Eclipse Application," everything works fine.
>
> But when I attempt to export my product, the build fails spectacularly. Not only do I get errors in code that, within the IDE, is error free, but in compiling the JFreeCharts code (for which I suppressed a host of warnings), I get 2266 warnings.
>
> So what gives? Why is it that completely different compiler settings seem to be used for the in-IDE build leading up to an in-IDE run as opposed to an export for deployment? Perhaps more importantly, why is this viewed as a Good Thing? From my point of view, it's a Very Bad Thing (since it means that my in-IDE build and test is basically useless).... But for it to have persisted into the 4th major release of version 3 of the tool, someone must think it's a Good Thing. I assume, therefore, that I fundamentally don't understand something critical about this whole process.
>
> Apologies if this has been answered (I suspect it has) - I've been utterly unable to unearth anything through Google or searching these forums.
|
|
|
Re: Eclipse PDE Launch vs Export [message #331488 is a reply to message #331486] |
Tue, 09 September 2008 21:21 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: aiello.barron-associates.com
Thanks for the clarification.
My particular problem seems more complex than what would be solved by adding the required execution environment (which I had done anyway). Somehow, between 3.3 and 3.4, those plugin projects that were synthesized by the IDE from JARs stopped building correctly. In particular, inside the IDE, the src/ directory is skipped, whereas when the PDE/Build kicks off, it tries to recompile all of that nonsense from sources. I assumed that something was wrong in the build.properties file, but haven't the slightest idea what it might be (especially since I never edited those files - 3.3 just made them and they worked under 3.3). Curiously (or not, perhaps) if I remove the src/ directories from those projects, the build proceeds without a hitch. So the build process is completely needless compiling that directory and I can't seem to prevent that.
Here's the text from my build.properties file from the Xerces plugin project that was synthesized from the 2.9 release of Xerces:
--------------- Code ----------------
source.. = .
output.. = .
bin.includes = META-INF/,\
javax/,\
license/,\
org/
--------------- \Code ---------------
As you can see, it's pretty sparse. I wondered if the "." under source might be causing problems, so I removed that line along with the output line. That appeared to be bad, as my primary plugin (which references the classes exported from the Xerces plugin) suddenly couldn't resolve those imports.
Do you had specific ideas to deal with this?
On a philosophical note, it seems to me that a better approach would be to find a way to perform the PDE/Build step within the IDE rather than without it, so that small-project developers (like myself) and people just starting out with Eclipse would be able to trust that, once they had built and run their product within the IDE, it would also export without problems. For those who need the power, etc. of a manual build, that functionality could be retained as an option that would have to be activated. Thus the simpler, more transparent approach would be the default rather than the complex, more opaque one.
I do, however, appreciate your note that manpower is a limited commodity.
Again, thank you for the clarification. I feel less antipathy toward the tool now that I have an explanation for its underlying philosophy.
Tony
|
|
|
Re: Eclipse PDE Launch vs Export [message #331505 is a reply to message #331488] |
Wed, 10 September 2008 17:52 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Andrew Niefer![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=aniefer%40gmail.com) Messages: 990 Registered: July 2009 |
Senior Member |
|
|
With respect to your Xerces plugin, you might want to take a look at the
Orbit project.
http://www.eclipse.org/orbit/overview.php
http://download.eclipse.org/tools/orbit/downloads/
They are bundling up 3rd party libraries to be reconsumed by eclipse.
Xerces 2.9 is one of the bundles they make. Look at the v2_9_0 branch
of dev.eclipse.org:/cvsroot/tools/org.eclipse.orbit/org.apache. xerces
They have the following in their build.properties:
output.. = .
bin.includes = META-INF/,\
org/,\
about.html,\
about_files/,\
plugin.properties
The source.. property indicates folders containing .java files to be
compiled, since there are none, you can omit that property. The
output.. property indicates folders that other bundles should put in
their classpath when compiling against xerces and it is in the workspace.
-Andrew
M. Anthony Aiello wrote:
> Thanks for the clarification.
>
> My particular problem seems more complex than what would be solved by adding the required execution environment (which I had done anyway). Somehow, between 3.3 and 3.4, those plugin projects that were synthesized by the IDE from JARs stopped building correctly. In particular, inside the IDE, the src/ directory is skipped, whereas when the PDE/Build kicks off, it tries to recompile all of that nonsense from sources. I assumed that something was wrong in the build.properties file, but haven't the slightest idea what it might be (especially since I never edited those files - 3.3 just made them and they worked under 3.3). Curiously (or not, perhaps) if I remove the src/ directories from those projects, the build proceeds without a hitch. So the build process is completely needless compiling that directory and I can't seem to prevent that.
>
> Here's the text from my build.properties file from the Xerces plugin project that was synthesized from the 2.9 release of Xerces:
>
> --------------- Code ----------------
> source.. = .
> output.. = .
> bin.includes = META-INF/,\
> javax/,\
> license/,\
> org/
> --------------- \Code ---------------
>
> As you can see, it's pretty sparse. I wondered if the "." under source might be causing problems, so I removed that line along with the output line. That appeared to be bad, as my primary plugin (which references the classes exported from the Xerces plugin) suddenly couldn't resolve those imports.
>
> Do you had specific ideas to deal with this?
>
> On a philosophical note, it seems to me that a better approach would be to find a way to perform the PDE/Build step within the IDE rather than without it, so that small-project developers (like myself) and people just starting out with Eclipse would be able to trust that, once they had built and run their product within the IDE, it would also export without problems. For those who need the power, etc. of a manual build, that functionality could be retained as an option that would have to be activated. Thus the simpler, more transparent approach would be the default rather than the complex, more opaque one.
>
> I do, however, appreciate your note that manpower is a limited commodity.
>
> Again, thank you for the clarification. I feel less antipathy toward the tool now that I have an explanation for its underlying philosophy.
>
> Tony
|
|
|
Goto Forum:
Current Time: Sat Aug 17 06:48:54 GMT 2024
Powered by FUDForum. Page generated in 0.03507 seconds
|