Community
Participate
Working Groups
I get errors when exporting a feature whose previous version already exists in the workspace. For instance, I import org.eclipse.rcp from target platform into my workspace and then export it (with a new qualifier and supposedly new/updated plugin content). It appears that BuildTimeSite.findFeature happens upon the version in the target platform before it finds the one in the workspace. Giving preference to workspace-based features addresses the problem.
Created attachment 102170 [details] Proposed patch When collecting feature modesl, put those in the workspace ahead of the external ones.
Proposed patch is on UI. Chris note that the order of features pde.build finds is pluginPath;workingDirectory;baseLocation During export pluginPath = TargetPlatformHelper.getFeaturePaths() workingDirectory = the feature being exported (I think) baseLocation = not set unless bug 233358
Patch is reasonable. Chris, is this worth putting in for RC3?
I need to find out exactly what is going on here. Peter, did this work in 3.3.X? If this is behavior is different in 3.3, than that's scary and may preclude some other bad things.
Chris, I just gave it a quick try using 3.3.2 and I saw the same error reported. Looking at TargetPlatformHelper.getFeaturePaths(), this result is dependent on the order of models returned by PDECore.getDefault().getFeatureModelManager().getModels(). In fact, I managed to reproduce this with one feature but not another (I picked them carefully based on what I saw returned by getModels()).
That sounds right. The order you define your features is important as this correlates directly how PDE Build will build things, right Andrew?
I think it's too risky for RC3 at the moment... it's end game and RC3 is this week. We can consider for 3.5
When asked to build a feature "org.foo" we look it up in our site. Features are kept there in a list the order of which depends on the paths set as per comment #2. The first one we find with matching name is used. We do match on version number, you set it it FeatureExportOperation.setupGenerator . > For instance, I import org.eclipse.rcp from target platform into > my workspace and then export it (with a new qualifier and supposedly > new/updated plugin content). I wonder about this, unless I am missing something, I believe that the qualifier set by export would only be applied to features/plugins whose version ends with .qualifier. If you are importing the feature, I don't think the export will change the version as you expect. Similarly, importing the feature with have specific version numbers for the included plugins which won't be update with new content (that only happens if "0.0.0" is specified.
Created attachment 102497 [details] PSF to reproduce the issue Actually my original problem occurred with projects imported from repository. In trying to reproduce the issue I did import a plugin and a feature from target platform and did not reset version refs to 0.0.0 but rather to 3.4.0.qualifier (so I did change the qualifier). However, the issue is likewise reproducible with projects imported from the repository. Note that I do not always get it to fail -- the paths have to be returned in just the right order for it to fail. But when it does here's what I get: Problems during export Unable to find plug-in: org.eclipse.core.jobs_3.4.0.v20080512. Please check the error log for more details. Unable to find plug-in: org.eclipse.core.jobs_3.4.0.v20080512. Please check the error log for more details.
Wow, this little patch just salvaged me. (I simply couldn't export our features from the IDE any more) FYI: Since this will not be included into a release soon, I put up a little patch feature against pde 3.4RC2 using pde.core v20080530 plus the patch from this issue. It can be installed from http://www.objectteams.org/distrib/patch-updates Although this issue is not a regression in itself, I ran into it because p2 forced me to completely restructure our build and provisioning story. Maybe p2 is the regression at this point. Any way, I would suggest to consider this patch for 3.4.1.
You're not considering the existing patch for 3.4.1? Are there any unresolved issues with it?
ping :) (In reply to comment #7) > I think it's too risky for RC3 at the moment... it's end game and RC3 is this > week. > > We can consider for 3.5 So there's a patch in comment 1, comment 3 states that it is reasonable. Are there any reasons for not releasing the patch? OTOH, I just retried a scenario that used to demonstrate this bug, but today exporting worked flawlessly, even without the patch. Has anything in this direction been changed in 3.4.1? Either way to me this looks like an easy candidate for closing?
Actually it looks like bug 247091 might have fixed it. Andrew?
Yes, this looks to be fixed due to bug 247091. In 3.4.1, there weren't many changes. However, in 3.5, PDE UI is aiming to take advantage of build as much as possible for export related operations to minimize issues.
Yes, I expect that bug 247091 would fix this. That change will not be considered for 3.4.x
It seems this issue is not entirely fixed. I am experiencing a similar issue with Eclipse 3.5.2. I am currently working on (yet another) Eclipse build automation utility (http://ebuilder.sf.net) and during the course of my work I noticed that I still cannot successfully export a feature in the following scenario: - my development workbench is Eclipse 3.5.2 and includes version 1.0.0.r0019 of the com.intuit.teamtrack feature (bug #167670) - the launch configuration for the runtime workbench uses the "plug-ins selected below only" setting; in the Target Platform section all plug-ins that belong to the com.intuit.teamtrack feature are DISABLED - the runtime workspace contains the com.intuit.teamtrack feature project and all its plug-in projects - the feature manifest does not specify individual plug-in versions and uses the version="0.0.0" wildcard for all plug-ins; the individual plug-ins all have "1.0.0.qualifier" as their version number; the feature itself also has version="1.0.0.qualifier" - when I perform a feature export with qualifier replacement string "r0001" I get the following error: Unable to find plug-in: com.intuit.teamtrack_1.0.0.r0019. Please check the error log for more details. What appears to be happening is that even though all com.intuit.teamtrack plug-ins of the target platform are disabled, the feature itself is not disabled and makes it into the runtime workbench. Instead of picking up the feature from the runtime workspace (version="1.0.0.qualifier") PDE build somehow seems to pick up "1.0.0.r0019" and apparently starts specifically looking for plug-ins with an "r0019" qualifier. Notably, the feature export works flawlessly if I use a qualifier of "r0020" instead of "r0001". In that case, apparently, the feature from the workspace wins over the feature that is installed in the runtime workbench because it has a higher version number. This seems to indicate that the PDE feature export still picks the feature with the highest version number rather than giving preference to features in the workspace (as Peter suggested in comment #0). Can someone please confirm this? Thanks! Should we re-open this bug or should I file a separate bug?
