Community
Participate
Working Groups
I find myself closing my imported plugins and fragments before doing a product-export, because otherwise the build does not complete normally. Given Bug 166176 in 3.3, this is really a pain. Ben
Ben, I am not sure I understand what you are trying to do nor why it's a problem. For everything related to self-hosting in PDE, workspace projects take precedence over target plug-in counterparts. What is special about this case? and why are workspace plug-ins not desired? and how can we tell which workspace plug-ins you want and which you don't?
Sorry for not being more descriptive, I was very frustrated yesterday... I have the following setup: - Target Platform set to RCP 3.3 M4 - Imported Target Platform Plugins with linked content - Got my own set of plugins which form a RCP application - RCP application is based on features with a product configuration file I was under the impression that this bug was already known to PDE for a while (in fact I have experienced it for a long time but never felt like filing a bug because closing projects worked in 3.2). So, whenever I do a Product Export from the product config file, the export fails if any of the used plugins exists in the workspace as imported with linked content (I am not sure if this problem is related to the "linked" thing or not). With failing I mean that all the RCP plugins end up missing the class-files in their JARs. I have no idea why this is happening at all, but as soon as I close the workspace plugins belonging to RCP, everything goes fine.
> So, whenever I do a Product Export from the product config file, the export > fails if any of the used plugins exists in the workspace as imported with > linked content (I am not sure if this problem is related to the "linked" thing > or not). Is to be read as: So, whenever I do a Product Export from the product config file, the export fails if any of the plugins are open that have been imported from the target platform as "Project with linked content" (I am not sure if this problem is related to the "linked" thing or not).
That's what I figured. PDE/Build has a (known) problem with linked content. I think it's time to get this issue resolved. PDE/UI will be happy to pass in any information pde/build needs to support this scenario.
Andrew, I thought you fixed something to that extent earlier this year? Am I getting confused with something else? Also when I imported ICU as a linked plug-in and then exported it, I got a strange result: all the files listed in project but not the jar. It made me thinking that we may need PDE UI to tell us where is the actual jar when the plugin is jar'ed.
We fixed bug 158589 in M3. It was to do with use incorrectly building the classpath in the case of linked content. Ben, are you using 3.3M3 or later?
I was using M4. But saw this in every milestone of 3.3. bug 158589 is very interesting for me, because it explains why I see different results using 3.2 (build fails with error message) compared to 3.3 (build runs but linked plugins end up missing their jars as Pascal mentions).
Ahh, I expect that we need special handling for this case in the generated assembly/packaging scripts. Such projects would likely be considered binary by pde.build (ie no build.properties file) and are likely just copied straight over. We probably need to explicitly add copy tasks for the linked content.
I think this should be re-investigated and considered in 3.4
*** Bug 206398 has been marked as a duplicate of this bug. ***
This bug is alive a well in 3.5. I'm seeing it in: Version: 3.5.0 Build id: I20090430-2300 Could this finally be fixed for 3.5? It has been hanging around since 3.2 according to this bug report.
3.5 is in the final release candidates and is effectively done. Marking for 3.6 to try and look at the general problem of linked content.
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix.
