| Workspaces and CVS [message #54798] |
Tue, 19 April 2005 16:31  |
Eclipse User |
|
|
|
Originally posted by: cimmerian76.hotmail.com
I work for a small company that has decided to put its software package
developed with Eclipse 3.0.2 under configuration management and a few
general questions have come up.
The main question is how can someone check out the project's files for the
first time from the repository and be able to maintain any workspace
settings that are/were associated with that project in Eclipse (i.e. debug
options, ANT build scripts, .jar locations, etc.)?
Is it as simple as committing the .metadata folder and .project files along
with the resources so that when a someone checks out the files, the
workspace settings are checked out as well? Or is that unwise? Is it
possible to control which parts of .metadata go into the repository?
Basically, we are trying to make creating a new workspace/sandbox for the
package as painless as possible. We don't want to have to reset all the
workspace preferences every time someone new checks out the project since it
is fairly complex and would be time consuming.
|
|
|
| Re: Workspaces and CVS [message #54852 is a reply to message #54798] |
Tue, 19 April 2005 17:42  |
| Eclipse User |
|
|
|
Originally posted by: duncan.krebsnet.com
Neil, here are some thoughts:
> The main question is how can someone check out the project's files for the
> first time from the repository and be able to maintain any workspace
> settings that are/were associated with that project in Eclipse (i.e. debug
> options, ANT build scripts, .jar locations, etc.)?
We have two methods of sharing eclipse projects. First method is initially
setting up the project in eclipse and on the first commit into the
repository both the .project and .classpath files are committed as well.
Then when another users wants to check out and work with the project they
go into the cvs repository view in eclipse, right click on the module
(after adding the repository in eclipse) and they select "check out as
java project."
This is fast and easy but one of the main issues with this approach is
that you have to deal with references to jars. For example a user might
configure the project to reference an external jar that is specific to
their machine, another user will import the project and it will not build
because eclipse can not find the jar.
Although not perfect the work around we have for this is always adding
referenced jars inside a "lib" folder within the project and then
committing the jars to the repository as well.
Second... there is a project called maven that takes a little time to
learn but solves the jar issues by maintaining a repository of jars for
the organization. It also has a plugin that will generate a .classpath and
project file based on the project information. This way on our maven
projects we don't have to commit the .project, .classpath and referenced
jars into the repository making it cleaner. maven.apache.org
Hope that gives you some ideas.
|
|
|
| Re: Workspaces and CVS [message #55577 is a reply to message #54852] |
Wed, 20 April 2005 13:52 |
| Eclipse User |
|
|
|
Originally posted by: cimmerian76.hotmail.com
Thanks dkrebs, your help has definitely given us some ideas and answers,
which leads me into a couple follow-up questions.
First, is it possible to set up user specific privileges that limits some
people's abilities to check in possible changes to .classpath or .project
files, i.e. perhaps a user changed certain debug preferences that we don't
want carried back into the repository?
One idea we had for getting around that is branching off if someone needs to
make changes to the workspace environment and then merging back once they
finished what they are doing. So the next question, is it possible to merge
..classpath and .project files that have been branched? Is it a good idea to
do so?
|
|
|
| Re: Workspaces and CVS [message #55899 is a reply to message #55577] |
Wed, 20 April 2005 21:51 |
| Eclipse User |
|
|
|
Originally posted by: duncan.krebsnet.com
> First, is it possible to set up user specific privileges that limits some
> people's abilities to check in possible changes to .classpath or .project
> files, i.e. perhaps a user changed certain debug preferences that we don't
> want carried back into the repository?
I'm sure it is but that sounds like something that would have to be
configured inside the CVS server and not in eclipse. For example I'm sure
you could create two cvs logins. One that lets users commit .project and
class files and another account that does not.
> One idea we had for getting around that is branching off if someone needs to
> make changes to the workspace environment and then merging back once they
> finished what they are doing. So the next question, is it possible to merge
> ..classpath and .project files that have been branched? Is it a good idea
to
> do so?
Sounds too messy. I also would not really worry about it too much because
a lot of workspace specific configuration stuff including debugging is
stored in the users local workspace and not in the .classpath and .proejct
files. I'd suggest starting by committing one project to the repository
and have your developers get together and walk through the process of
checking out projects and see what breaks.
|
|
|
Powered by
FUDForum. Page generated in 0.07452 seconds
] 
Search
Help
Register
Login
Home
