This content has been marked as final. Show 8 replies
In 11g, when you go to project properties -> Libraries.... -> Add New, you can choose the 'scope' of the library between Project, User and o.jdeveloper (which is system.... folder).
Haven't tried it, but I think if you create a library in Project, it should be created in the project structure which would solve the problem. I don't know if that option is available in 10g.
Thank you, Pedja, this is helpful. In 10g just as in 11g, I can define the library at the Project level. This puts all of the references to library jar files in the project's jpr file, rather than in a .library file in the system directory of JDev home. So it removes the dependency on a particular JDev installation.
However, the references are still relative references, relative to the location of the project on my disk. So I still have a problem if another developer checks out the project to a different place than I have mine, or even if I have a working copy of a branch in a different spot than a working copy of my main trunk development.
One possibility is to edit the .jpr file in an editor outside of JDeveloper, and change the references to absolute locations. I'd have to put my library jar files on a network resource accessible to all developers (which I do anyway) by the same absolute path (like \\servername\resourcename format, or WebDav). But editing jpr files directly is not exactly supported, and I'm not even sure that JDeveloper won't just change it back to relative addressing. I wonder if there is a way to add an entry to a library in a way that forces JDeveloper to use absolute addressing.
Have you tried to put the jar files in the project structure, that way the relative path makes sense.
For example, you put the jar files for the library in /ViewController/public_html/WEB-INF/lib. Then the entry in ViewController.jpr would look something like
Commit the jars, and everything should work with relative paths for all developers.
<list n="libraryDefinitions"> <hash> <list n="classPath"> <url path="public_html/WEB-INF/lib/myJarFile.jar" jar-entry=""/> </list> <value n="description" v="test_lib"/> <value n="id" v="test_lib"/> </hash> </list>
Yeah, I suppose I may have to go the way you suggest - put the jars in a directory within the project. I just found that I CAN'T point at a network file system for the location of the jar files - JDev won't let me. So even if I get absolute addressing to work, every developer will need to put the libraries in the same location on their local disk. But I was hoping not to have to do what you suggest, because several applications may use the same library.
I'll watch this thread for a few more days to see if anyone has a better idea.
So, to summarize:
<li>I'll define my libraries at the project level, which will store the definitions in the .jpr file, not in .library files in the JDeveloper home directory. That will make sure that I won't have to re-define libraries when I change JDeveloper versions.</li>
<li>I'll copy libraries used by a project into a library directory within the project. Even though it may mean duplicate copies of libraries in various places, at least it will mean that any working directory containing the project will also have a copy of the library in the place the project expects it to be.</li>
<li>I'll see what I can do to speed along our upgrade to JDeveloper 11g. When we switch to 11g, we should be able to point at a shared network resource with a fixed location for libraries.</li>
And finally, I need to enter a few enhancement requests:
<li>JDeveloper should not store preferences and other user files like .library files under the JDeveloper home directory. SQL Developer has been storing this stuff under the user's home directory (Documents and Settings\username in Windows XP, /home/username in Linux) for several years now, why not JDeveloper?</li>
<li>The one major thing keeping us on JDeveloper 10g is that 11g doesn't support deployment to OC4J. Our production application servers run OAS 10.1.3, and we don't have time to learn how to run WebLogic. Tomcat might be acceptable, since at least it runs under Apache like OC4J, but I'm seeing conflicting information about certification of deployment on Tomcat.</li>
Welcome to the wonders of Jdeveloper's library management ;-)
I can agree with the described summary.
That's how we always do it at our projects, never a problem. We use maven for our build process and always have the libraries in a local repository, but still we add them to the project because it allows us for a flexible organization of the developer's workstation.
I agree that it's not so nice to store all the libraries in the scm, but ok, it's a small price to pay. The big advantage is that you're sure that everybody is using the same versions.
However, don't count on 11g to handle libraries better, it's only minor. We still include all the libraries in the project and in subversion. I heard some rumors that they are working on improving the library management. I can't wait...