Community
Participate
Working Groups
Create a plugin project with the source directory as a link to a directory outside of the workspace. Create a "build.properties" file in which the linked directory is the source from which the jar file is to be built. The sources will not be found when you export the plugin as a "Deployable Plug-ins and Fragments". If you create an "Ant" script, build.xml, you'll see that it is referencing the linked directory, instead of the directory that is the target of the link. Note: this problem exists in 3.0RC1
Was it working in 2.1.3 or in 3.0 M8? If I'm correct this has never been supported because PDE Build does use the workspace to find resources. This allows it to work outside of eclipse.
I don't know if it worked in earlier versions. I didn't try it until 3.0M9. It should not be a difficult problem to fix. When generating the "build.xml" take not of a source "directory" that is actually a link, and replace the reference to the target directory. Then it should work fine.
If you really think what you wrote in the previous comment, feel free to provide a patch :-).
Of course, what I meant is "it shouldn't be a difficult problem to fix for one who is familiar with the PDE code that creates the 'build.xml' file". I don't qualify. :-)
The point I made in comment #1 was actually to say that it is not trivial since PDE Build does not know about your workspace as a workspace, nor does it compile the java files directly. The compilation is done by the javac ant task which does not know about eclipse workspaces and just compile folders that it is being told to. This design choice has been one since day one and changing that is far from trivial. However this decoupling as the advantage to allow you to be able in a releng-style mode, build eclipse without eclipse, etc. To be honest it is unlikely to be fixed in a near future. The only workaround that could possibly work in your case would be to put the target of the link in the build.properties.
*** Bug 68965 has been marked as a duplicate of this bug. ***
I wonder how this bug can be deferred. For me it is a show stopper and in that a very serious problem, because we have all our source folders linked to our version control system folders. Currently I have to fully duplicate the whole source structure in a local folder tree to be able to export a plug-in. This is not just a little problem. I also agree that putting the resolved folders into the Ant script should do the job. I assume there is a temporary Ant script generated for the export, right? I tried to manually adjust the folders in the build.xml file but this produced other problems in Eclipse. To sum up: linked folders are a great concept, also for merging different libraries in one Eclipse project, but its implementation seems to have stopped half on the way.
*** Bug 76413 has been marked as a duplicate of this bug. ***
*** Bug 82412 has been marked as a duplicate of this bug. ***
*** Bug 99350 has been marked as a duplicate of this bug. ***
*** Bug 99743 has been marked as a duplicate of this bug. ***
Here is a workaround for this problem: On Windows 2k and XP with NTFS you can use socalled junction points, which allow a mapping of one folder into another folder. This works very much like symbolic links in Unix and is transparent to the OS, so it really looks like the mapped folder is physically located in the target folder, while it is actually only a phantom. You need a special tool to create a junction point, either from the Win resource kit or from Sysinternals: http://www.sysinternals.com/Utilities/Junction.html. Another good point of these junction points is that it is a set-and-forget feature. Once set it stays until you delete the mapping, no need to modify the registry or set an auto start entry etc. The biggest advantage (it's absolute transparency to the OS) is also the biggest disadvantage: using the command line or Explorer you cannot tell which folder is true and which is a mapping. You need the junction point tools to find the mapped folders. So it is easily possible that you delete files in the mapped folder without realizing that the files in the physical folder will also be deleted. So one should not overuse junction points. Apart from that I have used junction points for several months now and they work great for me.
Apart from the fact that the workaround is platform-dependent and the main source of the problem is the way Import sets up projects with linked content. Somebody just tell me how I can import these projects without causing this problem - will copying the source do it? - and I'll go away. Otherwise, the response to this bug so far is to say the least unproductive.
Bob, the bug is clearly marked as for Windows XP, so my workaround might indeed help people with this particular problem. For copying the sources: have you read all comments here? I wrote in my comment from last year that the only solution I found is to copy the source code and use existing instead linked folders. However I agree that the entire handling of this particular bug is a bit disappointing, particularly when you see how many times it was reported (see the duplicates) and how easy a solution seems to be.
*** Bug 101020 has been marked as a duplicate of this bug. ***
*** Bug 113704 has been marked as a duplicate of this bug. ***
for our rich client application we are using a lot of jar files built on the server and binary included in some plugins in the client. therefore this bug is very boring for us, because we have to copy the jar files into the plugin projekts otherwise we would be able to link to the one central file and version. but maybe we can fix it in an releng build script manually.
See comment #5 in bug 99743. This has effects that are more annoying than the build problems. When you link your source code to plug-in projects and try to connect them by exporting a package from one and importing classes int that package in a dependent project you get compile errors of the type: import com.foo.bar.example.trial.Try; ^^^^^^^^^^^^^^^^^^^ (package com.foo.bar.example cannot be resolved. This is a bogus error. In fact the class is compiled. However, it is clearly not helpful, and vastly reduces productivity as well as any down-stream problems it will cause. It doesn't happen if you put the source code for a plug-in in the project directory.
Karl, I suspec that you are adding the libraries directly on the classpath or something like that which would likely create problems.
(In reply to comment #14) > Bob, the bug is clearly marked as for Windows XP, This very same bug also occurs under Mac OSX 10.4.7 using Eclipse 3.2 Please offer a workaround!
> Please offer a workaround! 1) Create a normal source folder /src 2) Add a special ant builder that copies the required files into /src on clean, build, etc You can set your preference. Ant skips if no changes are detected Have Ant mark the copied files as read-only and derived so they don't go into CVS and you don't edit them DON'T NAME YOUR ANT FILE build.xml !! Then the feature build will wipe it out! 3) Go back to developing, all happens automagic...
*** Bug 161434 has been marked as a duplicate of this bug. ***
Hello, I'm using maven 2 to build some project together with a eclipse plugin project. The maven-eclipse-plugin produce the .project and .classpath and include dependencies as linked resources in .project in place of duplicate the library in the project, so I think it's a good way to do. The plugin run without problem inside eclipse PDE, in debug to. But the export wizard don't use the real location of dependency so it's impossible to build plugin. I agree with the idea that it should be fixed.
A fix for bug 101241 would also solve this problem.
My two cents are that the fix Andrew proposes in bug 168365 would be the best, e.g. making marteen's work around part of the generated ant build, or perhaps as a helper build. I would argue against simply using the linked resource directly as this then makes a build dependent on access to that non-workspace resource. Or as I suggest half-seriously in bug 101241, simply dissallow linked resources in PDE builds. <ducking/>
(In reply to comment #24) > A fix for bug 101241 would also solve this problem. > Well, bug 101241 is now fixed, but I still cannot export a plugin that I have that has a linked directory. I am trying to convert an older project over, and the linked directory is to the build tree of native build.
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.
