Community
Participate
Working Groups
It would be great if the requirement for all the assemble targets in customTargets.xml/allElements.xml could be replaced with a macro, for example: <macrodef name="assemble"> <attribute name="featureId"/> <attribute name="configSpec"/> <sequential> <ant antfile="assemble.@{featureId}.@{configSpec}.xml" dir="${buildDirectory}"/> </sequential> </macrodef> The generated assemble*all.xml script could then call the macro this way: <?xml version="1.0" encoding="UTF-8"?> <project name="Assemble All Config of org.eclipse.platform" default="main"> <import file="${customTargets}" /> <target name="main"> <antcall target="win32.win32.x86" /> </target> <target name="win32.win32.x86"> <assemble featureId="org.eclipse.platform" configSpec="win32.win32.x86"/> </target> <target name="linux.gtk.x86"> <assemble featureId="org.eclipse.platform" configSpec="linux.gtk.x86"/> </target> </project> Each call to the macro would need to be nested in it's own target to avoid Ant property value inheritance between calls to the macros. Separating the featureId and config spec into their own attributes will allow the macro implementor to test on these values to set the archive name.
Sonia would you be able to provide a complete patch for that?
Sure, will do.
We want to remove the requirement for all the assemble targets in the allElements file. However, we should also allow the build to specify those targets if desired to allow custom control over particular configurations. When using the default targets, the build would no longer need a copy of the allElements file (it would just need to provide the top type & id properties in the main build.properties file). There is no real need for a macro, I tested the following using the ant 1.7 we currently ship. The default allElements contains: <target name="defaultAssemble"> <ant antfile="${assembleScriptName}" dir="${buildDirectory}"/> </target> Builders can add optional assemble targets, along with a corresponding property: <property name="assemble.org.eclipse.sdk.win32.win32.x86" value="true"/> <target name="assemble.org.eclipse.sdk.win32.win32.x86"> <!-- do stuff --> <ant antfile="${assembleScriptName}" dir="${buildDirectory}"/> </target> customTargets.xml then has the following: <target name="assembleConfig"> <condition property="customOrDefault" value="assemble.${element}.${config}" else="defaultAssemble"> <isset property="assemble.${element}.${config}" /> </condition> <antcall target="${customOrDefault}" /> </target> The assemble.element.all.xml script then makes calls like: <ant antfile="${customTargets}" target="assembleConfig"> <property name="config" value="win32.wpf.x86"/> <property name="element" value="org.eclipse.sdk"/> <property name="assembleScriptName" value="assemble.org.eclipse.sdk.win32.wpf.x86.xml"/> </ant> The result is that the custom assemble config targets are used if the associated properties are defined, otherwise the default target is used. The build can also edit the default target. The ${config} and ${element} properties are available in the default and custom targets if desired for conditions. Note that some top level property would need to be specified to use these changes in the generated assemble scripts since this is not backward compatible with old customTargets.xml and allElements.xml scripts.
Created attachment 82922 [details] patch First attempt at this change. It is backward compatible with old allElements and customTargets files. This needs more testing before I release it.
Created attachment 83445 [details] updated patch Updated patch with tests. This deserves a final review before release. As well, I will wait for bug 208821 to be completed so as to not throw a wrench into the builder used for M4.
*** Bug 143319 has been marked as a duplicate of this bug. ***
done in HEAD
Currently in HEAD, PDE Build help hasn't been updated to reflect this change (Section "Controlling what will be built: allElements.xml" in the "Building Features" page). It should. :) May a new bug be filed instead of reopening this one?
