Community
Participate
Working Groups
The PDE team has done some exciting work in improving the way target platforms are defined and configured in the IDE (see http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08538.html and http://eclipsesource.com/blogs/2009/02/24/target-platform-changes/) PDE Build (headless) should be able to leverage this, too. It seems of very limited value to have this improved mechanism available in the IDE but not for headless, automated builds. Having to maintain two targets actually makes more work for plugin/product developers and would basically keep us from utilizing the new feature.
There is an issue when sharing with PDE build... PDE build runs without a workspace/without OSGi. The target definition infrastructure currently requires an workspace/OSGi environment.
Build does have OSGi, and works with BundleDescription objects, but we have no access to the resource model.
This issue is more complicated due to the reasons that Darin mentioned (workspace awareness). I don't think we have anytime in 3.5 to do something useful in this area, however, in the future, we should think about linking the way people craft targets to the way PDE Build could use that information to build successfully.
fixed *** This bug has been marked as a duplicate of bug 269122 ***
oops, wrong bug
Andrew, in theory, if you use an IU to build your target platform, can't you use an IU in PDE Build's map file so your .target file and PDE Build would have a target based on the same IU?
(In reply to comment #6) > Andrew, in theory, if you use an IU to build your target platform, can't you > use an IU in PDE Build's map file so your .target file and PDE Build would have > a target based on the same IU? > This does not really address the issue, as that would mean that I would have to track 2 sets of what is essentially same metadata one for IDE and another for build environment. The goal here is to make differences in the build versus development environments as little as possible...
Is the desire for PDE build to use the .target files? what sort of API/sharing do people want here? Some use cases would be helpful to flesh this out.
We have an age old problem where what you do in your workspace is completely different than what happens at build time. There are different artifacts to specify things... in PDE Build there are things like pluginPath and map files that help dictate what is in a target. In PDE UI, we now have the target definition mechanism. The goal here is for people to craft one artifact that they can use in dev and build time.
The target definition file lists "locations" where plugins / features are found (sites, directories, etc...). This is obviously very good from a user point of view, but I wonder if the definition file should also contain the bundles / features (+1 versions) that actually constitute the target. From a user POV nothing would change (I would add http//foo.com as a site), but the definition file would end up listing the bundles that were fetched from this repo. This would have a big advantage in PDE build, since you now know exactly what bundles / feature are needed. If the bundles are available (say in baseLocation) then you don't need to fetch them. If they are not there, then you can fetch them (we have the repo location + bundle + version, so we should be able to do this). I was thinking of something like this <target> <location path="c:/foo/plugins" type="Directory"> <contents> <plugin id="org.eclipse.core.runtime" version="3.5.0.2009..."/> </contents> </location> <location includeAllPlatforms="false" includeMode="planner" type="IU"> <unit id="org.eclipse.mylyn" version="1.0.0"/> <repository id="http://galileo.com"/> <contains> <plugin id ="org.eclipse.mylyn" version="1.0.0"/> <plugin id="org.eclipse.mylyn.core" version="2.0.0"/> </contains> </location> </target> In this case my target has 3 bundles, core.runtime, mylyn and mylyn.core. When you invoke build (and point to this target definition), we now know "exactly" what bundles you need. If (for example) mylyn.core is not available, it gets it from http://galileo.com.
Created attachment 165767 [details] simple target platform resolver for PDE build The issue of integrating target platform resolution right into PDE Build is indeed not quite easy. Some refactoring would be necessary. However, PDE Build already provides some neat capabilities to hook into the build process. The attached plug-in demonstrates this. I've implemented a simple target definition resolver based on the p2 mirror task. This requires to use p2 repositories inside your .target file. But that's my recommendation anyway for true shared target platforms (shared within your team and with your build tooling). The plug-in depends on pde.core and pde.build and can run headless. Resoling a target is as simple as using the following Ant task. <eclipse.target.resolver destination="${repoBaseLocation}/mytarget" targetDefinition="${uri/to/my.target}"/> This can be integrated into any PDE Build process. I attached the plug-in here so that it can be integrated into the base builder, which would allow a better out-of-the box experience.
Created attachment 168703 [details] transformPlatform.xsl The attached XSLT template will convert a target definition into an Ant script containing a target with one p2.mirror per repository referenced from the target defintion. This will only work for referenced p2 repos (as this is the only mode that makes sense, as comment 11 has already noted). There is certainly room for improvement, just posting this in the hope this may be useful to others. Usage from within the preProcessRepos target in customTargets.xml: <xslt style="transformPlatform.xsl" in="${targetPlatform}" out="mirror_base.xml"> <param name="destination" expression="${repoBaseLocation}/mirrored"/> </xslt> <ant antfile="mirror_base.xml" target="mirrorBasePlatform" />
This is a great idea, I was disappointed earlier when I realized target definitions couldn't be used this way. I've done something similar here for some build scripts, used xsl and p2.mirror to derive/resolve dependencies from feature.xml. Not a target definition, but same idea. I ran into a problem were multiple versions of a 3rd party bundle were retrieved from our p2 repository, the one lower versioned one we wanted and a higher versioned one that was resolved as a transient dependency of another required bundle. The lower version meets the version rules/requirements too, but we get both. The higher version is used(resolved?) by pde and breaks our build. (I think this means the 3rd party bundle isn't versioned properly too, but that's a different issue. By the version rules something that builds with 3.2.6 & should build with 3.5.1 right?) The solution(s) above would have a similar problem. Playing with target definitions in the ui, I found that we got what we wanted if we checked the 'Include required software' box. That box toggles between planner and slicer in the target definitions xml. The only way I've found to involve the planner headlessly is to use the p2.director. I'm still in the process of working that out, but it's worked for some preliminary tests I did outside of the actual build processes. I'd like to suggest that this should be considered for this enhancement. BTW, is there any other way to involve the planner for headless p2 tasks?
FYI, as an alternative to the XSL transformation I opened bug 351526 with a patch for pde.core. This patch adds an Ant task to PDE Core which allows to provision (resolve+export) a target platform into a destination directory. It runs without UI and workspace but needs an OSGi/Eclipse environment (as PDE Build does).
There's obviously a lot of good work that's been done here. But ... I think we won't be putting more effort into PDE batch builds so will close as "won't fix". If you disagree and still think a large need, please re-open.
