Community
Participate
Working Groups
This piece of code is a library folder classpath container. It adds all jars/zips in a folder (subfolders can be turned on or off) to te classpath There are a few things left to do: -short cut for browse -refactor to another package -the container only supports folders from the current project, I don't know if others would like to be able to choose folders from other projects, but I didn't.. But if anybody wants that, let me know
Created attachment 5262 [details] Sourcecode for the container Someone should refactor the code to another package (org.eclipse.jdt / ui for the pref page)
Created attachment 5263 [details] Sourcecode for the container
I like this feature but would like to see it expanded to include library container management. In MyEclipse we have a concept known as a LibrarySet which is a user managed library container. We have not fully generalized the concept but it allow a user to add/remove Jars to the container and reorder the contents. The path of container elements can use classpath variables.
I think we should add this to core and ui. Fredric, let's do it, I can integrate the UI part. Wayne, can you give more details about what you have in MyEclipse. How are these LibrarySet's manages. On a preference page? Do you allow sharing in a team? Would MyEclipse be interested to contribute that code?
Joris, We're actually interested with your proposal, but we still need to discuss how and where (perhaps not in jdt-core) we want to finalize this feature. I let you inform of progress on this task.
Ok Frédéric, thanks for letting me know. It's kind of frustrating submitting something many people like, and not hearing anything.. I'll upload the updated sourcecode today or tomorrow. There was one thing I found while coding this thing: I had to do a kind of hackery thing to set parameters to the library: <classpathentry kind="con" path="com.insomniq.eclipse.jdt.LIB_CONTAINER/flat/projectname/docroot/WEB- INF/lib"/> I could not find anything about adding a new xml element.. What I'd like to see is something like: <classpathentry kind="con" path="com.insomniq.eclipse.jdt.LIB_CONTAINER> <property name="recursive">false</property> <property name="libraryfolder">/projectname/docroot/WEB-INF/lib</property> </classpathentry> something like that, if anyone has any suggestions, let me know
I was the developer of the MyEclipse libarySet concept, i.e., a user managed classpathContainer. In MyEclipse we needed a way for users to define a collection of jar/zips that could easily be added to a project's classpath. Specifically, we needed a way to bundle J2EE libraries that could be added to the classpath of MyEclipse J2EE projects as a single unit. Along the way we discovered that the concept could be generally useful. When we added the feature to automatically add files from the WEB-INF/lib folder to a project's classpath we started thinking about a generalization similar to Joris work (Joris very good idea). Presently, MyEclipse only supports 2 predefined librarySets (classpathContainers), 1 for J2EE 1.2 projects and 1 for J2EE 1.3 projects. Additionally, these libraries are available to add to any Java project's build path. This later capability led me to use 1 of the librarysets for hosting lots of common libraries that I'm always using and bundling for client projects. This allowed me to eliminate a common's project that I had maintained just hosting libs to be used by other projects (there is still a CVS issue to discuss). Here's how they work in MyEclipse. Since the librarySets are fixed at this time there are no Create/Delete functions for a librarySet. From a preference page a user is able to add, remove, and reorder the libs of a classpathContainer. The "Add Library" use-case allows the user to provide a relative path using Classpath Variables. For simplicity, a library is stored in the plugin's preference store. Also, from the Java project properties the librarysets are available as libraries to add to any Java project. Recently, I was planning to extend the implementation to a much more generalized model but thought I would coordinate the effort with this group and see how our model matches up with Joris approach. Wayne
IMO this feature would greatly improve multi platform development in Eclipse. For example from time to time I need to switch my target platform (J2EE 1.2/1.3, JBoss, WebSphere, Weblogic,...) or in more general the spec level of a set of 3rdparty libs. I like Joris approach but it is a bit to coarse grained yet. And please don't forget to allow source and api doc attachments for library set entries as it is possible when defining JRE system libraries. BTW a colleague of mine uses Fake JRE system libraries to define his library sets. This is kind of misuse but it works ;-)
What I see are two different containers: 1) My approach, which adds a folder's jars, no apidocs / source whatever, and project specific 2) The LibrarySet approach, which is handy for common used jars. For J2EE and frameworks like struts/jsf/hibernate, which are shared between projects. I haven't thought about the apidocs / sourcelocations yet, but that's important too. I think these two features should be implemented seperately. The only thing they share is that they are ClasspathContainers.
Created attachment 6476 [details] Sourcecode updated for use of folders outside of current project This version will allow folders of other projects to be used as containers.
I tried the attachment today; It is still only allowing library folders that are part of the project. I checked the source code in the attachement for 2003-10-19, it is unchanged from the attachment for 2003-06-21. The .class files are dated 2003-06-21 but the .java files are dated 2003-06-?? It seems Joris' finger slipped in his enthusiasm.
Created attachment 6676 [details] Source I've had a harddisk crash, and I thought I had the latest source at home. This should be the most recent version. date/time also matches..
Created attachment 6708 [details] Added support for external file system folders aswell - Added support for external file system folders - Fixed copy 'n paste errors in folder selection dialogs.
Here are some additional ideas for the containers. Currently, there is a severe problem when you share projects between different OSs, like Linux and Windows, when the JARs between these systems differ (like when you use SWT or JAI). Proposed solution: The container should be stored in an external file, preferrably in ANT-compatible syntax, so the very same file can be used in ant. These options should contain the following information: - A name for the container (users should be able to select it by this name in the UI and in ANT). - A set of JARs. It should be possible to use variables in the paths to these JARs and paths relative to the project/workspace. For each JAR, there should be an option to set the path to the source and to the JavaDoc. - A set of Java VM options to use when a program is run which uses this container (especially extensions to java.library.path!) As for the switch between the OSs, I see these solutions: 1. One can include all containers for each OS in the project. Users will then have to copy those they need to a place where eclipse will look for them. More simple to implement but confusing, especially when the container in the project changes and users forget to update their copy. 2. The OS for which this container is valid is specified in the file. Eclipse only considers containers for the OS on which it runs. 3. A container could be split into "common" and "OS specific" parts. This leaves the question how to handle different OS versions. There might be containers which contain different files for Win95 and Win2000. The goal of this enhancement should be to allow to create projects which compile with little or no user changes on different OSs. It should especially be possible to commit the .classpath and .project files to a shared repository. If the format of this extenal file would be compatible with ANT (using <classpath> elements), then these could be shared between Eclipse and ANT, solving the many requests to be able to share the classpath between ANT and Eclipse.
The project "User Libraries" on http://www.javango.net/eclipse/userlib.html implements part of the functionality which I proposed. JBuilder can do something similar. There, you can define libraries on the level of the system (all projects on this host), user (searches $HOME) and the project (in the projects' files)
added user libraries as described in bug 50461, comment 3. > 20040307 Currently all in jdt.ui. It is planed to move the classpath container infrastructure down to jdt.core *** This bug has been marked as a duplicate of 50461 ***
This bug is marked resolved, but the original feature requested (adding all jars in a folder to the classpath) is still not addressed as of Eclipse 3.3. See bug 166556 for a new RFE requesting this feature.
bug 39198, bug 50461, bug 166556 I published a new version of 'Library Folder ClasspathContainer' with an agreement with the original author, Joris. Library Folder ClasspathContainer marks a folder and adds all jars and zips on the folder. When a member of the jars or zips is removed, this plugin automatically follows the changes. I modified the original plugin for eclipse 3.2 and 3.3. Maybe available on 3.0 and 3.1. Please visit and try it. http://libcontainer.sourceforge.net/updates/
