Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 147432

Summary:	[workspace] Better support for building non-Java projects
Product:	[Eclipse Project] PDE	Reporter:	Matt Chapman <mpchapman>
Component:	Build	Assignee:	pde-build-inbox <pde-build-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	aniefer, email, mkempka
Version:	3.2
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Matt Chapman

2006-06-16 09:29:56 EDT

There are a number of assumptions across PDE that a project can be built using a javac ant task, such as the "Create Ant Build File" support, and when driving headless builds. A project may have registered its own builder via the org.eclipse.core.resources.builders extension point, so that the project builds successfully in the workspace. But then this isn't taken into account when creating an ant file to build the project.

This is the situation in AJDT with AspectJ-enabled plug-in projects. In AJDT we have implemented a number of variations on the regular operations, such as "Create Ant Build File with AspectJ support". These generate build.xml files which call the incremental AspectJ compiler (using the "iajc" ant task) instead of javac. Apart from the implementation overhead, this clearly isn't the ideal solution for the user - the project "knows" it's an AspectJ project, so the "Create Ant Build File" operation should be able to just do the right thing, without the user having to choose between the available variants. The situation is even worse when it comes to headless builds - there is no opportunity to select a variant - it's javac all the way. So the headless build capability cannot be used for AspectJ projects.

Comment 1 Matt Chapman

2006-06-16 09:35:39 EDT

See bug 147433 for a suggested enhancement which would allow PDE to ask a project how to build itself from an ant script. Of course, a project may have multiple builders, so PDE would need to query each builder for Ant build commands, and then add them together in the generated build.xml.

Comment 2 Pascal Rapicault

2006-06-16 10:50:45 EDT

This unfortunate situation results from historical decisions on making PDE build be completly workspace unaware so that we could bootstrap eclipse with Ant. Of course this is no excuse, just a bit of background. 
At this time there is no plan to change pde build to be workspace aware.

Comment 3 Matt Chapman

2006-06-16 14:35:47 EDT

Re: comment #2. Thanks for the info, but I don't fully understand - by "workspace aware" do you mean that a running workspace is required when generating the build file, or when executing it? In order to generate the build.xml files currently various properties must be queried, such as the manifest, in order to generate the classpath. So could the project builder(s) not be queried in a similar way, so that they return something like a subclass of AbstractScriptGenerator, which is then used to generate the build.xml, which can then be run outside of eclipse.

Comment 4 Pascal Rapicault

2006-06-18 20:57:10 EDT

PDE Build is not running from a workspace. It is running from the file system.
Therefore it can not query the workspace to retrieve the builders associated to a project. However if it was told about these other builders (let's say by the build.properties), then things like you outline could work, however all plug-ins willing to contribute builders would have to be able to run headless and without IResources (I'm sure there are other constraints that I'm forgetting).

Currently we are exploring to see if Maven could be of any help and I think its plugin model would have the ability to solve something this problem.

Comment 5 Matt Chapman

2006-09-25 11:42:40 EDT

Do you think something could be done for this in time for 3.3? It's quite a big issue for AspectJ. How about if a builder added something to build.properties to indicate an alternative AbstractScriptGenerator class to use instead of ModelBuildScriptGenerator? It would then be optional, only required by those builders that operate instead of the Java builder.

Comment 6 Pascal Rapicault

2006-09-26 11:46:25 EDT

We don't have plan to address that in a 3.3 timeframe. However we could allocate some cycles to help / review code.

Comment 7 Matt Chapman

2006-09-26 12:03:31 EDT

Fair enough. It's important enough for us to try working on it ourselves. We'll try to implement the build.properties approach as above, and attach a patch or ask questions as required.

Comment 8 Andrew Niefer

2010-03-26 13:27:52 EDT


*** This bug has been marked as a duplicate of bug 303960 ***