| Project local classpath [message #247654] |
Mon, 04 February 2008 12:30  |
Eclipse User |
|
|
|
Hi,
I'm trying to set up a classpath for several versions of the same project.
I have tried using classpath variables, but these seem to by global rather
than per project.
The problem I have is that I might have several versions of the same
project mounted on different drives (actually clearcase views) so I want
to be able to set the classpath differently for each version of the same
project. Other users may also be using versions of the project, but
mounted on different drives.
I'd like the classpath file to be under source control and so common to
all versions of the project, but not have it tied to a particular mount
point.
I'd also like to be able to have different versions of the project mounted
on different mount points. So a single classpath variable would not work
across all versions of the project.
Can anyone help?
Thanks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Project local classpath [message #248261 is a reply to message #248243] |
Thu, 07 February 2008 11:29  |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:fof8bs$1tg$1@build.eclipse.org...
> Andy Ling wrote:
> > Eric Rizzo wrote:
> >> 2) Why not make the tomcat directory into a project and then the other
> >> projects can depend on it instead of having to point to its physical
> >> file-system location. Project references are always relative to the
> >> workspace so there would be no classpath issues.
> >
> > We want tomcat to stay with the project so that if we pick a particular
> > version of a project it gets the version of tomcat that goes with it.
> >
> > Dave's suggestion of different classpath variables in each project
> > will probably help. But it doesn't fix the problem if we have
> > two versions of the same project in the same workspace.
>
> I see. What I usually do for projects that have important dependencies
> (that is, almost every project I work on) is to include the dependencies
> in the project itself. For JARs that just means a lib/ directory; for
> Tomcat it might mean slightly more (as it does for Jetty, which I've
> used more often); but the principal is the same - include everything
> that is needed to build and run the application either in the one
> project or have several projects that must be synchronized together.
> Since you are trying to have several versions in one workspace,
> embedding Tomcat in the main project would meet that goal, if there is
> nothing else preventing you from doing it.
>
ClearCase actually can help with this. I should have thought of it sooner.
You can create a ClearCase symbolic link that points to an element within a
ClearCase vob. For example, most of our projects have a lib folder that
contains symbolic links to jar files that the project depends on. ClearCase
uses the config spec rules to pick the version of the jar file that is
available in a given view. This way, you may not need to use a ClassPath
variable. If you create the library folder under your project, you can just
use the Add Jar option.
This might solve your problem. Different projects would reference the Tomcat
version based on the projects config spec. Different versions of the same
project would each reference the version specific to them.
I would still recomend against having multiple versions of a project in the
same workspace. It's too easy to loose track of which version you are
working on and change the wrong version by mistake. If you have the
ClearCase plugin installed, you can use the compare with previous or version
tree menu options to compare changes between versions.
>
> > I think we've probably done this to death now. The simple answer is
> > there isn't a way to do what I want. So I'll have to cahnge the way we
> > work until I can persuade someone to implement per project variables :-)
>
> Please file an enhancement request in Bugzilla for project classpath
> variables - at least someone will either take up the work to implement
> it, shoot down the idea, or ask you to commit a patch for it ;-)
>
> Eric
|
|
|
|
| Re: Project local classpath [message #248354 is a reply to message #248261] |
Fri, 08 February 2008 05:41 |
| Eclipse User |
|
|
|
Dave Wegener wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:fof8bs$1tg$1@build.eclipse.org...
>> Andy Ling wrote:
>> > Eric Rizzo wrote:
>> >> 2) Why not make the tomcat directory into a project and then the other
>> >> projects can depend on it instead of having to point to its physical
>> >> file-system location. Project references are always relative to the
>> >> workspace so there would be no classpath issues.
>> >
>> > We want tomcat to stay with the project so that if we pick a particular
>> > version of a project it gets the version of tomcat that goes with it.
>> >
>> > Dave's suggestion of different classpath variables in each project
>> > will probably help. But it doesn't fix the problem if we have
>> > two versions of the same project in the same workspace.
>>
>> I see. What I usually do for projects that have important dependencies
>> (that is, almost every project I work on) is to include the dependencies
>> in the project itself. For JARs that just means a lib/ directory; for
>> Tomcat it might mean slightly more (as it does for Jetty, which I've
>> used more often); but the principal is the same - include everything
>> that is needed to build and run the application either in the one
>> project or have several projects that must be synchronized together.
>> Since you are trying to have several versions in one workspace,
>> embedding Tomcat in the main project would meet that goal, if there is
>> nothing else preventing you from doing it.
>>
> ClearCase actually can help with this. I should have thought of it sooner.
> You can create a ClearCase symbolic link that points to an element within a
> ClearCase vob. For example, most of our projects have a lib folder that
> contains symbolic links to jar files that the project depends on. ClearCase
> uses the config spec rules to pick the version of the jar file that is
> available in a given view. This way, you may not need to use a ClassPath
> variable. If you create the library folder under your project, you can just
> use the Add Jar option.
Yes, we use symbolic links and this does go some way to helping.
To some extent this example is slightly artificial to try and describe
what I wanted.
I would have liked a single classpath variable in every project e.g. ROOT
that everyone knew about and was defined to point to the name of the
clearcase view. It looks like we have to have p1-root, p2-root etc.
> This might solve your problem. Different projects would reference the Tomcat
> version based on the projects config spec. Different versions of the same
> project would each reference the version specific to them.
> I would still recomend against having multiple versions of a project in the
> same workspace. It's too easy to loose track of which version you are
> working on and change the wrong version by mistake.
I hear what you are saying. In practice, what I have is several version
of the same project "available" in a workspace, but only one open
at any given time. I just find this an easier way of working
rather than keep switching workspace. Switching workspace involves
restarting eclipse and there are issues with keeping preferences
common between workspaces. (Particularly as being a fairly novice
user I'm still tweaking things :-)
Thanks for all the help
Andy
|
|
|
Powered by
FUDForum. Page generated in 0.10353 seconds
Home