Community
Participate
Working Groups
The ant script seems to fork the pde.exportFeatures task and then continues. If - as in my case - the next task is dependent on the output of the exportFeatures task - this doesn't work too well. <pde.exportFeatures features="${feature}" [ ... ] /> <dependentTask> [ ... ] <!-- this task runs before pde.exportFeatures is done --> </dependentTask> A way to tell pde.exportFeatures to wait until the actual work is done would help.
pde.exportFeatures is a UI Task. When running from a headless environment you would be better using the tasks provided by build. See eclipse.buildScript (http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_feature_generating_antcommandline.htm) and http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_feature_build.htm
I'm confused... If pde.exportFeatures is a UI task, then why would you want to run it from an ant script? I was expecting the same behavior as the reporter of this bug. For me, I thought the whole point of having that ant task was so you can automate feature export in the middle of a build process that you already have implemented in Ant. If it's asynchronous, then why not just click on the export link from the UI?
The pde.exportFeatures and pde.exportPlugins tasks are contributed by the PDE/UI component - they are not actually "UI" tasks, they are part of the pde.core plug-in. However, the tasks can only be run by ant script that is running in the same VM as the Eclipse workspace/OSGi framework. They cannot be used in a PDE headless build (i.e. running without Eclipse workspace/OSGi framework). The code explicitly waits for the export to complete when the "org.eclipse.ant.core.antRunner" application is running - so it does not block when run in the SDK. I am not familiar enough with PDE to know why this is... the comment says: // if running in ant runner, block until job is done. Prevents Exiting before completed // blocking will cause errors if done when running in regular runtime. It does not say what the errors are when running in "regular" runtime.
Wassim, do you know why this task was written to run asynchronously in the SDK? Generally, ant tasks run synchronously, unless they support an explicit "fork" attribute. If this is just to avoid blocking the UI thread during export, it feels like we could just have callers call the task in a non-UI thread/background job (rather than forcing this in the task itself)?
Darin, I was in Romania. Now I am back. this is a dup of bug 58413 The PDE/Export job instantiates an AntRunner to do the work. Therefore, when the job is called from an Ant task in a synchronous manner, you get an error saying you can't have two instances of Ant running. The asynchronous part was a hack to make sure the task exited before the job kicked in. I could not figure out a way to make this work synchronous with the current programmatic way we call pde/build.
Thanks, Wassim. *** This bug has been marked as a duplicate of bug 58413 ***
