Home » Eclipse Projects » Eclipse Platform » Multiple classpath options?
| Multiple classpath options? [message #300746] |
Thu, 16 March 2006 15:36  |
Eclipse User |
|
|
|
Originally posted by: joezulli.yahoo.comXXXXX
Hi everyone,
I have a pretty interesting problem with classpaths and I'm wondering if
there is a solution available that will allow me to achieve what I want
using Eclipse as is, or if it's possible to write a plugin. Here's my
scenario:
-- The company I work for uses both Eclipse and Maven for development. We
have probably around 20 Eclipse projects with intricate dependencies. Some
projects represent end-applications/web sites, and some represent shared
libraries and utilities.
-- Within the company there are different levels of access rights in the
codebase. Some users have access to all projects, while others
(contractors, for instance) only have access to the end-application
projects. This access is controlled by our SCM tool.
-- In the .classpath files for the end appications, there are no project
dependencies, but rather use referenced jars for the shared libraries.
This allows the users with limited access to compile and run the end
applications with ease.
-- The users with full access are a little less lucky. Since they want to
use dependent projects instead of the jars (for purposes of debugging into
the code and making changes that span into both end applications and
shared components), they have to constantly change the project properties.
This puts the project out of sync with the repository, which is a pain to
say the least. Sometimes these modified .classpath files accidentially get
checked in, which breaks things for the users with limited access. It's a
huge mess!
Essentially, I'm looking for a creative way to solve this problem,
preferrably while writing as little code as possible. One thought (don't
know how feasible this is) is to write some plugin that modifies the
schema of the .classpath so that if both a dependent project and a jar are
specified (and somehow linked together) the dependent project will be used
if and only if it exists in the workspace.
Another possible, though less elegant, solution would be to have multiple
classpath files, one for each level of access, and somehow be able to
tell Eclipse which level of access you have, and therefore, which
classpath to use.
I'm curious what everybody's thoughts are on this topic. Any input would
certainly be greatly appreciated.
Thanks,
Joe
|
|
|
| Re: Multiple classpath options? [message #300754 is a reply to message #300746] |
Thu, 16 March 2006 17:14  |
| Eclipse User |
|
|
|
Originally posted by: kwpeck.mersoft.com
Not sure if this totally applies but let me attempt to explain what we did.
We have a Maven repository. We point the Project -> Java -> Build Class
path to the jars in that repository using a MAVEN_REPO variable so that
directory can be in a unique location on each users machine without
having adjustments to the class path to find them. Obviously this class
path is used during build, to find javadocs and the like but not at runtime.
For each Eclipse project there is a maven.xml file just like we have a
plugin.xml file. We run a Maven command from the workspace root. It
copies required JAR files from the maven repository to the LIB directory
of each project. If a project only needs A.JAR then only A.JAR appears
in its LIB directory. We warn people via IM or email when you need to
rerun the master maven command to update your LIB directory. Maven
copies both the code jar and the source jar so you can trace into things
during debug.
The class path for Manifest file points to the LIB directory.
When we export the product we again use the LIB directory and not the
maven repository as that is what the Manifest is plucking jars from.
All of the maven jar files are built on a server. When you run the Maven
command from the root of the workspace it sucks down the latest built
files from there. If a developer is testing a "master" jar file on their
machine they are not affecting others. When they are happy with the
results the build the file on the server or just copy up the one they
have on their machine and IM / email everyone. Other devs run the maven
command from the workspace root and it sucks down the new one hopefully
without breaking any of your code. You have to select affected projects
in Eclipse and Refresh (F5) them to pick up the new jar file that was
copied to your LIB directory.
This all generally works pretty well. Of course some builds don't go
very easy and people forget to update the maven.xml file when they have
new project requirements but that is a people issue and not a technical
issue.
Again, I am not sure if this is of any help to what you are doing but
maybe it will trigger a thought in a new direction.
Joe Zulli wrote:
> Hi everyone,
> I have a pretty interesting problem with classpaths and I'm wondering if
> there is a solution available that will allow me to achieve what I want
> using Eclipse as is, or if it's possible to write a plugin. Here's my
> scenario:
>
> -- The company I work for uses both Eclipse and Maven for development.
> We have probably around 20 Eclipse projects with intricate dependencies.
> Some projects represent end-applications/web sites, and some represent
> shared libraries and utilities. -- Within the company there are
> different levels of access rights in the codebase. Some users have
> access to all projects, while others (contractors, for instance) only
> have access to the end-application projects. This access is controlled
> by our SCM tool.
> -- In the .classpath files for the end appications, there are no project
> dependencies, but rather use referenced jars for the shared libraries.
> This allows the users with limited access to compile and run the end
> applications with ease.
> -- The users with full access are a little less lucky. Since they want
> to use dependent projects instead of the jars (for purposes of debugging
> into the code and making changes that span into both end applications
> and shared components), they have to constantly change the project
> properties. This puts the project out of sync with the repository, which
> is a pain to say the least. Sometimes these modified .classpath files
> accidentially get checked in, which breaks things for the users with
> limited access. It's a huge mess!
>
> Essentially, I'm looking for a creative way to solve this problem,
> preferrably while writing as little code as possible. One thought (don't
> know how feasible this is) is to write some plugin that modifies the
> schema of the .classpath so that if both a dependent project and a jar
> are specified (and somehow linked together) the dependent project will
> be used if and only if it exists in the workspace.
>
> Another possible, though less elegant, solution would be to have
> multiple classpath files, one for each level of access, and somehow be
> able to tell Eclipse which level of access you have, and therefore,
> which classpath to use.
> I'm curious what everybody's thoughts are on this topic. Any input would
> certainly be greatly appreciated.
> Thanks,
> Joe
>
|
|
|
| Re: Multiple classpath options? [message #300845 is a reply to message #300746] |
Fri, 17 March 2006 11:09 |
| Eclipse User |
|
|
|
Originally posted by: eclipse3.rizzoweb.com
Joe Zulli wrote:
> Hi everyone,
> I have a pretty interesting problem with classpaths and I'm wondering if
> there is a solution available that will allow me to achieve what I want
> using Eclipse as is, or if it's possible to write a plugin. Here's my
> scenario:
>
> -- The company I work for uses both Eclipse and Maven for development.
> We have probably around 20 Eclipse projects with intricate dependencies.
> Some projects represent end-applications/web sites, and some represent
> shared libraries and utilities. -- Within the company there are
> different levels of access rights in the codebase. Some users have
> access to all projects, while others (contractors, for instance) only
> have access to the end-application projects. This access is controlled
> by our SCM tool.
> -- In the .classpath files for the end appications, there are no project
> dependencies, but rather use referenced jars for the shared libraries.
> This allows the users with limited access to compile and run the end
> applications with ease.
> -- The users with full access are a little less lucky. Since they want
> to use dependent projects instead of the jars (for purposes of debugging
> into the code and making changes that span into both end applications
> and shared components), they have to constantly change the project
> properties. This puts the project out of sync with the repository, which
> is a pain to say the least. Sometimes these modified .classpath files
> accidentially get checked in, which breaks things for the users with
> limited access. It's a huge mess!
Hmm, definitely not your run-of-the-mill setup, and a bit challenging.
Here's one idea that I have not actually tried but might work out:
Create a "Dependencies" project that has nothing in it but the shared
library JARs. Set it up with two branches in your SCM; one branch will
have a .classpath that points to the JARs, the other branch points to
the Projects instead. Make sure to set up the Order and Export tab of
Java Build Path for that project.
Then your other projects (applications) can depend on the Dependencies
project; they will either depend on the JARs or the their projects,
depending on which branch of Dependencies you have. Hopefully your SCM
tool can control access to different branches and different users.
Of course this means that updates to the dependencies (like adding a new
library) will have to be done on both branches of Dependencies, but I
doubt that will be much a burden.
Another idea would be to NOT check .classpath in, but rather have
another process for distributing the right version to the right people
(shared file system, email, etc). The drawback there is that whenever it
changes, everyone has to be told to update their copy.
Hope this helps,
Eric
|
|
| | |
Goto Forum:
Current Time: Sat Aug 16 10:35:37 EDT 2025
Powered by FUDForum. Page generated in 0.33310 seconds |
Home