This content has been marked as final. Show 5 replies
First a little update on libraries. Libraries are now divided into two categories;
Internal library definitions are persisted within the project file itself (i.e. .jpr file) and are thus always available to anyone opening that project, but are not sharable among any other projects.
External library definitions are persisted within their own stand-alone library definition file (i.e. .library file). As such, external libraries are now first class citizens that can be checked into source control, referenced by any number of projects, and can be shared among all users in a team environment in the same way that java source files are.
In other words, there is no longer a need for each individual team member to create their own similarly named ambiguous library that may or may not equate to the library defined by his or her team mates.
Since external libraries now have their own unique URL, adding an external library to a project adds that URL to the project (i.e. d:\jdevstudio1013\...\myutils.library), not just an ambiguous name like 'my_utils'.
What this means is that if you created a user library, then that is exactly what it is; a user library, an object relative to your individual user environment. User libraries are not intended to be shared among team members and should not be permanently referenced by a project that is shared among a team. User libraries are convenient for developement and debugging, but should never be left as a reference in a shared project.
If you want to create a library that the project permanently depends upon, then you should create a new library that is to be checked into source control so that the project can reference a constant object sharable by everyone.
Let R = the root of your source control tree (e.g. d:\root)
Let P = a directory within source control where your project is stored (e.g. d:\root\prj)
Let L = a directory within source control where library definitions are stored (e.g. d:\root\lib)
In order for your project (MyProject) located in P to safely refer to a library, you would create a library definition (MyLibrary.library) in L. From that point on, any project could reference your library and all users could safely open your project without the need to create any library definitions of their own.
Whenever possible, references to external libraries within a project are stored as URL values relative to the project itself. So, if including a reference to MyLibrary.library found in L from within MyProject.jpr found in P, then the reference in MyProject.jpr will appear as '..\lib\MyLibrary.library' So long as MyProject.jpr and MyLibray.libary remain in the same relative location within source control, all will be well. This is identical to how all other project content is referenced in the project file.
Putting it all togeather:
- Open the Project Properties dialog for your project
- Select the Libraries panel
- Click the 'Add Library...' button
- Click the 'Load Dir...' button and select the directory within source control in which you want to find/create a library (e.g. L above).
This will load all libraries found in that directory. These libraries are now available for including in your project. If you would like to create a new library in that directory you would just continue with the steps as follows:
- Click the 'New..' button
- Select the location for the new library from the drop list of recognized locations which now includes your library directory L as a result of the Load Dir... functionality.
- Enter the library data and press 'OK'.
The library is now created within source control and is available to all projects and all users. Keep in mind that references within a library definition (both internal and external) are relative to the location of the library. This implies that anything referenced in the classpath/docpath/sourcepath of a library should also be checked into source control to ensure proper path resolution for all users accross an entire organization.
Hope that helps.
Message was edited by:
Message was edited by:
Wow, thanks for that thoughtful explaination.
I can see, however, that our current method of operation is heading for trouble: we don't use any form of repository, just the filesystem. This worked great in previous JDev versions, but from your description of the new library implementation, its not going to work in the new JDev.
Is there any sort of work-around to get that original functionallity back? We have several libraries that we share across many projects and only 3 developers, so the old version user library worked great for us...
Hello again. Thank you both for the kind words.
I'm not entirely clear on how you are able to all look at the same source files, but not at the same library files? The library files can appear in the same file system as the source files. Just consider the .library file as the same as a .java file. If you can each see a .java file from within a project, then you can follow the same approach such that you can each see a .library file from within that same project.
Even if you each worked on complete mirror copies of the source tree on your individual machines, it would just mean that you also each had mirror copies of the libarary files.
The guiding principle is that if the library reference can be resolved relative to the project file, then everything should always be fine (since the URL will be persisted as a relative value). If a fully qualified URL must be used (due to the library not sharing any common directory ancestor with the project file) then yes, you would have problems outside of a source controlled environment. The question that you would have to ask yourself would then be; Why can't you have a library file at least on the same drive as the project file (i.e. bare minimum common root from which a relative URL could be constructed)?
If for some reason unclear to me you really cannot use the feature as intended and absolutely must use the 10.1.2 behavior, you could try the following (ugly but effective) hack:
- Everyone agrees that 'shared' libraries are to be referenced by a subst'ed drive (say drive L:). It does not matter if user A has L: subst'ed to c:\somepath\mylibs and user B has L: subst'ed to d:\temp\libs. (e.g. subst L: c:\temp\libs)
- When adding libraries to the project, load the L:\ directory using the 'Load Dir...' behavior described in my earlier post to select/create the libraries.
Taking the above approach, all library references will appear in the project file as fully qualified URL's referring to the L: drive (e.g. L:\libname.library) since they share no common directory with the project from which to produce a relative URL.
Then, so long as everyone does a subst of L: to point to where they keep their personal version of the 'shared' libraries, the library reference should resolve to the personal copy in the subst'ed location.
Hope that helps.
is it a good idea to load all the big libraries into VCS? And not only the .jars, but sources and docs as well? This will mess up the repository. Mostly, the libraries are much bigger than the project itself.
In our team we've been using the subst hack for long and hope, that no developer will use UNIX...