Community
Participate
Working Groups
Curretnly User Libraries are defined only as containing JARs from the file system with absolute locations. It would be nice if User Libraries could define JARs located as extension to classpath variables and/or workspace folders. Adding Class Folders as library elements would be nice too. A related issue would be defining a project specific libraries. This would improve the organization in the Package Explorer view of projects with many JAR dependencies and would allow the sharing of that library information. Currently one could export/import the library definitions but as they use local file system specific paths, they are not much useful for sharing.
This is the single most problematic issue we have with Eclipse. In every project I have worked on we have had libraries that exist outside the project folder at the same level. Relative paths where you can specify a parent folder like ../otherproject would solve this for us. Absolute paths cause problems because then you can not check out to another machine without configuring. It seems the Eclipse runtime settings recently added the ability to have relative paths, now we need it in the build settings. Relative paths also would be helpful for build results output we don't always want to put our build results in the same folder as the project subfolder.
I've been thinking about this same problem for the last few days. There's an issue to consider when referencing libraries in other projects by project name: the user may have checked out the foreign library by another name (when working on multiple branches of a project, for example.) It's a thorny problem. I wholeheartedly endorse the idea of project-specific libraries. We include about 60 jar files in one project and the cluttering of the package explorer pain is very unpleasant. I've resorted to creating a stub project, importing the jar files from the original project into the stub project, then re-exporting the entire stub project into the original project's classpath. This approach has the unpalatable attribute of being dependent on the absolute project name. A user library might serve the same purpose but it can't be propagated to other users. It would also be nice if libraries in the classpath were not shown at the top level of the project explorer pane, but were instead shown inside a collapsible Libraries folder (the same way that collections of libraries are displayed for a user-defined library.) I'm filing this suggestion as a separate feature request, #71101.
It would be nice to add jars to a user library using classpath variables. MAVEN_REPO anyone. We use this a hell of a lot in our projects. It would be nice to, say, create a hibernate-2.16 user library and add the jars relative to the MAVEN_REPO variable. This would be advisable as each of our developers has the Maven repository stored in a diff location on disk.
Deferring post 3.1
Reopen to close bug 133191 as a dup
*** This bug has been marked as a duplicate of 133191 ***
Reopen. 133191 is a dup of this bug.
*** Bug 133191 has been marked as a duplicate of this bug. ***
I can see that this issue has priority P3, but even though it is not a show stopper this issue causes teams to spend a lot of (unnecessary) time on setting up projects for each team memeber (including the headaches when people don't have the right JAR files in their library path).
We have a similar problem like others. We have a lot of external jars, and this situation makes package exploler useless. So, we tried to use user libraries, but it is not flexible enough. Relative path, workspace relatives, user defined classpath variables... we can't use any of them to define user libraries. So every person of us have to configure user libaries by own, or we have to use unconfortable regulations, standards.
We are considering relaxing some of the classpath rules for 3.3. This one looks like a good candidate.
*** Bug 93061 has been marked as a duplicate of this bug. ***
Note that bug 93061 contains a patch that we might consider.
Unfortunately, we did lack time to implement this enhancement and so have to defer it...
Defered again? We need it!
I wrote a script that helps till they have this - you may be able to modify it for your needs if you can't use something like ivy or mave to accomplish the same: http://simplygenius.com/geekblog/2006/06/05/auto-generating-eclipse-user-libraries/
This also stops me developing using the same user libraries cross-platform. For example, on Windows... c:\workspace\libs\ourlib.jar might be the path On OS X: ~/workspace/libs/ourlib.jar is probably the path. I need to be able to checkout between platforms and work on the same code, so the probable best solution would be... ${project_loc:libs}/ourlib.jar I'm viewing this as critical for cross-platform development using user libraries. Without it, I can't make use of the user library feature.
*** Bug 83208 has been marked as a duplicate of this bug. ***
*** Bug 185256 has been marked as a duplicate of this bug. ***
It would be really good to get a fix for this - as it is at the moment we're still using the individual jar file approach as it's the only way we can switch paths easily between various systems.
Fixing this would be huge for us. The advantages of User Libraries are significant but obviated by the need to redefine the jar path names each time the project is checked out to a new location.
This is also a problem for our environment. We currently use User Libraries, but do to a different bug (that I was searching to see if anyone had opened as an issue when I happend across this one) we're currently looking to implement Maven or Ivy.
Since Eclipse 3.3.x it's possible to choose paths relative to the workspace for the libraries JavaDoc archives, and this brought me the inspiration: libraries with paths relative to the workspace _might_ be working too, but the Eclipse UI is not ready yet? Journal of my steps to prove it (freshly downloaded Eclipse 3.3.1.1 Build id: M20071023-1652): - create new workspace and two test projects: 'LibJEE' + 'P'; - put JEE JARs into '/LibJEE/lib', e.g. 'servlet-api.jar', 'mail.jar', etc.; - create Eclipse User Library 'JEE_LIBS' and add those JARs from to this . library (still absolute paths); - add JEE_LIBS to build path of project P; - create test class T with main method, e.g. . "System.out.println("hi: " + new SendFailedException("dummy"));" - run T.main(), expected output: "hi: javax.mail.SendFailedException: dummy" - go to Eclipse Preferences and _export_ the Eclipse user library! - edit that export file and _remove_ the prefix of absolute paths => transform . them to a paths relative to the workspace: . D:/workspace/LibJEE/lib/mail.jar => /LibJEE/lib/mail.jar - return to Eclipse Preferences and _import_ back the library definition! - clean + build the workspace; - run again test class: works! Test 1: - remove project LibJEE from workspace (but not the files); - move project directory somewhere outside of the workspace; - import project LibJEE back to workspace from the new location; - clean, build and run test class: works! Test 2: - new blank Eclipse installation; - create new blank workspace; - copy directories of LibJEE + T projects somewhere else, different locations; =============================================================================== - import those projects LibJEE + T to the workspace; - import the library definition to the workspace; - clean, build and run test class: works! Summary: it seems to me that only the UI is missing. Of course, tests have to be performed to ensure there are no corner cases.
(In reply to comment #23) Victor, you are right that the underlying infrastructure (in JDT/Core) supports workspace root relative jars in user libraries. And you are right that the UI doesn't allow to select a jar in the workspace. However this bug asks for more. It asks to be able to add jars relatively to a classpath variable, or relatively to a workspace folder. This is currently not supported by JDT/Core. So you should enter a separate bug report against JDT/UI to ask to be able to select a jar relatively to the workspace root. (Please add the bug number to this bug for future reference).
(In reply to comment #24) Jerome, thanks for your reply. I will follow your suggestion and will request to reopen bug 133191, but for JDT/UI instead of JDT/Core.
Hi all, now that JDT/UI bug was solved, is there and work undergoing to fix also this one? You know, sharing a workspace within the team and with the automatic build machine is a pain in the ***. Of course the REAL and useful solution for team-wide development will be only when bug 139132 will be solved as well, but by judging by the number of votes it's got we can wait like forever...
(In reply to comment #26) Mario, I believe the only remaining issue is to be able to add a jar to the User library relatively to a classpath variable. Is this what you are asking for? Or do you need more? (Note you can already add a jar that is inside the workspace and it will be stored relatively to the workspace folder.)
As I understand the proposal is for all the jars in a User Library to be specified with paths relative to any common root, not necessarily the file system root. I suggest that when the user adds a User Library with relative paths to a Project, the system should prompt the user to select an existing Classpath element or to add a new one to serve as the root for that Project.
(In reply to comment #0) > Adding Class Folders as library elements would be nice too. See bug 115097. > A related issue would be defining a project specific libraries. See bug 139132.
(In reply to comment #28) > As I understand the proposal is for all the jars in a User Library to be > specified with paths relative to any common root, not necessarily the file > system root. > > I suggest that when the user adds a User Library with relative paths to a > Project, the system should prompt the user to select an existing Classpath > element or to add a new one to serve as the root for that Project. > I think using a classpath variable to define this common root would be what you want. The UI part can be discussed later (i.e. how do you specify the value of the classpath variable when you import the User Library).
(In reply to comment #27) Yes, I think adding the variables is a real step forward. The other feats I'd love belong already to other entries as you underlined.
we'd like to have this fixed very, very much; we have a lot of small eclipse projects (apps) and lot of contractors, outside team members and us who must move around, changing machines, and having to keep libraries consistent and well organized across projects and yet allow for different local directory structures is a huge struggle for us. It would really help us out a lot to be able to export user libraries with path(s) relative to customizable variable(s).
Keeping dependencies out of version control is ideal. We use Ivy to manage our project's dependencies and place them all under one folder: [project_home]/lib. Eclipse should provide an easy and flexible way to add any and all jars from that folder to the classpath. For now, all our developers are forced to create custom user libraries where the only difference is the absolute path to their project home directory.
So much time passed, but you still didn't fix it. It is unbelievable!!!!11
I will take a look.
Disclaimer: I'm a newbie. Sorry for all the things newbies tend to do wrong :) I've made a patch that allows to add workspace relative JARs. That was the easy part. Now for all the administrative stuff: @Jayaprakash: I assumed You are not working on this. Correct? @All committers: Who wants to give me a helping hand for stupid questions and the like? Most important one: which patch format?
(In reply to comment #36) > @Jayaprakash: I assumed You are not working on this. Correct? No, not yet. > @All committers: > Who wants to give me a helping hand for stupid questions and the like? Most > important one: which patch format? I am assuming you have checked out the eclipse projects from CVS. If you are using eclipse, just generate the CVS patch from your Team Synchronizing perspective.
Created attachment 197492 [details] Patch for eclipse bug 70417 Please review the patch. It should be pretty obvious what I did. Otherwise feel free to ask.
Sorry, I didn't realize the changes you were talking about are on the UI-side. Hence, I am requesting Markus to take a look at it. Markus, what do you think of this approach?
Since bug 133191, user libraries can also contain JARs in the workspace. It looks like the UI to select a JAR from the workspace is the only thing missing, see bug 300542 for that. I quickly looked at the patch, and it contained too many unnecessary changes in the .properties file. Also most of the changes to the UserLibraryPreferencePage.IDX_* are not necessary (just choose a free idx for the new button). Please attach a new patch with only the necessary changes to bug 300542, and I can take a look for 3.8 (not right now, since we're concentrating on Java 7). This bug also seems to contain more requests, e.g. bug 270733 and bug 115097.
(In reply to comment #40) > Please attach a new patch with only the necessary changes to bug 300542, and I > can take a look for 3.8 (not right now, since we're concentrating on Java 7). Thomas, any update on the new patch?
(In reply to comment #41) > (In reply to comment #40) > > Please attach a new patch with only the necessary changes to bug 300542, and I > > can take a look for 3.8 (not right now, since we're concentrating on Java 7). > > Thomas, any update on the new patch? The patch from 2011-06-07 is the correct one. There was a misunderstanding between Markus Keller and me, hence comment #40 (Markus, can you please confirm this? See your email from 2011-06-15).
(In reply to comment #42) > The patch from 2011-06-07 is the correct one. There was a misunderstanding > between Markus Keller and me, hence comment #40 (Markus, can you please confirm > this? See your email from 2011-06-15). Markus, do you expect to be able to look at this for 3.8? Thanks.
Comment on attachment 197492 [details] Patch for eclipse bug 70417 Sorry for the long delay. I'll look at the new patch in bug 300542 for M7. (In reply to comment #40) > This bug also seems to contain more requests, e.g. bug 270733 and bug 115097. This bug can cover the remaining requests.
This looks to be only JDT/UI bug. Hence, moving it.
> This looks to be only JDT/UI bug. Hence, moving it. Nope. Bug 300542 was the open UI bug for internal JARs, but this is fixed now. Bug 115097 is a similar UI request to support class folders in user libraries. The remaining open issue for this bug is that user libraries should allow classpath variables. Comment 13 says bug 93061 has a patch, but that needs to be tested to make sure e.g. bug 93061 comment 4 is addressed and updates to classpath variables are properly propagated to the user library container. The patch also misses Javadoc updates, e.g. in IClasspathContainer and IClasspathContainer#getClasspathEntries(). There is also bug 139132 (and bug 270733) which seems to ask for "sharable" user libraries (stored in a workspace file). See my position on that in bug 139132 comment 7.
(In reply to comment #46) Markus, Thanks for summary of the state. My mistake of not reading the comments thoroughly :( I had a quick glance at the patch in bug 93061 comment 13. I believe there will be some substantial work to be done before we could release. Hence not targetting for 3.8.
As there is no activity since 2012 (which is 6 years back in time) I would like to ask why the code Markus Keller (see comment provided given on 2012-04-25 10:09:29) did not make it into a release. The bug (actually it is a feature request) is still labeled "NEW". A feature that allows to provide classpath entries (or project entries) that are defined relative to workspace paths would facilitate cross platform development (in my case Linux and Windows). The problem is that the paths in the above mentioned files is hardcoded and full, meaning that allow most of the path is identical, the windows path contains drive letters that are unknown in Unix (and therefore in Linux). Maybe Markus Keller and Satyam Kandula share the status of the proposed changes and highlight exactly why the implementation is that problematic (as it seemed to be in 2012). kind regards Franz Gotsis (Munich Germany)
Would it be possible to have at least a minimal viable solution here after more than 15(!) years and more than 70 votes? I'm currently working on support for User Libraries in tycho and absolute path are of course a no-go for such use-case. I think the absolute minimal enhancement would be: - I create a Userlib with absolute path - I export it to a file - I can replace absolute references with a classpath variable - If I import it the classpath variable is resolved (don't mind about updates) and remains its variable nature as long as I don't edit it (e.g. is exported as a variable, re-resolved on restart of eclipse...) Here is an example: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <eclipse-userlibraries version="2"> <library name="Mockito" systemlibrary="false"> <archive path="$M2_REPO/org/mockito/mockito-core/3.8.0/mockito-core-3.8.0.jar"/> </library> </eclipse-userlibraries> $M2_REPO is a Eclipse-Classpath variable. https://bugs.eclipse.org/bugs/show_bug.cgi?id=93061 contains patches to add support for class-path variables but it seems to be outdated but maybe a JDT maintainer can pick them up and apply to the current source accordingly?
