Share global libraries between developers?

I'm trying to work out the easiest way to share global library definitions
between developers. I can set a path variable to make the location of the
library files themselves "developer agnostic", but that's not the problem
(we'd probably put all the shared libraries on a common network drive anyway).

The sticking point seems to be working out how to share applicationLibraries.xml.
I can understand why the difficulty; IDEA no doubt caches that info on startup
and doesn't like applicationLibraries.xml being changed behind it's back,
so sharing the file between multiple IDEA instances is a no-no. But there
must be a better way than having every developer maintain their own version
of applicationLibraries.xml. Storing it in VCS only goes part of the way
to solving the problem; there's still problems like the need to stop IDEA,
check out a new version (& perhaps copy it to the .IntelliJIdea70/config/options
directory), then restart IDEA.

I seem to remember older versions of IDEA used to write a separate file for
each global library that was declared, so creating new libraries into a shared
directory would work well. Obviously changing existing libraries might be
more of a problem but if the files were version controlled/read only, it
should work well for the most part.

Does anyone have any suggestions on the best approach? Is it possible to
write a plugin that intercepts the reading/writing of applicationLibraries.xml
so it can take care of the concurrency issues?


5 comments
Comment actions Permalink

Chris,
I can share my experience: we don't use global libraries feature of Idea
at all.
That's what we do:
- we store libraries in Perforce, in the libraries depot
- if the project, or module requires a library, we use integration
feature of Perforce. Integration allows to keep the single copy of the
library.
- libraries are integrated into project (or module) into project's (or
module) directory tree
- local checkout from Perforce creates local copy of libraries
- check-in (submit) does not create another copy of the library
- we define only module or project libraries

We tried in the past to use Path Variables, but it was causing too many
problems, especially when moving projects between Windows and Linux.
With the current setup, we can check-in project on Windows, checkout on
Linux, and everything works (all libraries are contained within project
tree).

0
Comment actions Permalink

Hi Tom,

Interesting, thanks for the information. We're currently migrating over to
Perforce from CVS so I will investigate this further. How do you deal with
the librarys' source code and javadocs though? I'd like that to be accessible
to IDEA too so we can navigate into library source, debug it, view external
javadocs etc.

Chris,
I can share my experience: we don't use global libraries feature of
Idea
at all.
That's what we do:
- we store libraries in Perforce, in the libraries depot
- if the project, or module requires a library, we use integration
feature of Perforce. Integration allows to keep the single copy of the
library.
- libraries are integrated into project (or module) into project's (or
module) directory tree
- local checkout from Perforce creates local copy of libraries
- check-in (submit) does not create another copy of the library
- we define only module or project libraries
We tried in the past to use Path Variables, but it was causing too
many problems, especially when moving projects between Windows and
Linux. With the current setup, we can check-in project on Windows,
checkout on Linux, and everything works (all libraries are contained
within project tree).



0
Comment actions Permalink

Chris,
Actually we store entire external packages in Perforce.
If project needs only .jar file(s), but not javadoc, we integrate only
jars: usually javadoc can be viewed online anyway.
Nothing prevents us from integrating entire external package (including
javadoc and/or source code) into the project tree.
The cool feature of Perforce is, that integration doesn't create another
copy of this package on the server. It only indicates, that project
checkout should include this package.

0
Comment actions Permalink

Thanks Tom. It's good that there's only one copy in Perforce but I'm more
worried about all the copies we'll end up with on the clients. Or do I misunderstand
something? We have lots of projects and modules, often sharing the same libraries.
Ideally we'd have source and javadocs available from all of them. Also, I'm
not sure I like the dependency on our source control system.

Has anyone got a workable solution for IDEA that I can compare the Perforce
approach against?

Chris,
Actually we store entire external packages in Perforce.
If project needs only .jar file(s), but not javadoc, we integrate only
jars: usually javadoc can be viewed online anyway.
Nothing prevents us from integrating entire external package
(including
javadoc and/or source code) into the project tree.
The cool feature of Perforce is, that integration doesn't create
another
copy of this package on the server. It only indicates, that project
checkout should include this package.



0
Comment actions Permalink

Chris,
Yes, that's true that you will end up with multiple copies on clients, I
don't see a problem here.
If I work on more than one project, I will have multiple copies of
libraries. Again not a problem, everything is in Perforce, so I can
safely delete one project.
The biggest advantage for us is that project created on Windows can be
checked out on Linux, and it will compile/run on Linux.
Your experience may vary, but this model works really well for us.
Good luck.

0

Please sign in to leave a comment.