[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.tools.jdt] Why does the project export require the project to be shared?
|
- From: Scott Ellsworth <scott@xxxxxxxxxx>
- Date: Thu, 02 Jun 2005 13:36:40 -0700
- Newsgroups: eclipse.tools.jdt
- Organization: EclipseCorner
- User-agent: MT-NewsWatcher/3.4 (PPC Mac OS X)
Hello.
After a long hiatus, I downloaded and installed 3.1RC1, in hopes that it
would let me create a project import form from outside Eclipse.
I note that one can only export a project if it is already a shared CVS
project. I note further that one cannot import a plain old archive file
(created by exporting the project as an archive file) without the
project already existing.
Is there a way around this?
For those wondering why I might want to do this:
At one of my clients, people rarely use Eclipse. They use IDEA,
ant&emacs, JBuilder, and other tools. I believe they might want to use
Eclipse, if the barrier to entry was low enough.
We have over a hundred interdependent projects, whose dependencies
change roughly weekly.
When those dependencies change, or when a new developer comes on, I have
an ant target that uses Velocity to create the hundred some odd xml
files for IDEA, and similar build.xml files. They can thus be up and
running in a few minutes. Similarly, for an existing developer, they
quit their IDE, run the script, and in a few minutes, are back in action
with whatever changes taken into account.
I can do this because ant, NetBeans, and IDEA all have xml files as
their core project and module format. Thus, it is not hard to generate
the needed files.
Because Eclipse uses an opaque binary format for the workspace, I cannot
do the same for them. I can generate valid .classpath and .project
files, but I cannot generate the workspace that binds them together with
the proper dependencies between them. Thus, a change to the
dependencies means developer Hell.
It sure looked like the project list export would do exactly this, but
it requires running against the cvs repository. Since we have had
troubles in the past with IDEs doing exciting things to our repository,
we want developers to be familiar with command line repository access,
even if they usually use an IDE. (We are also moving towards
subversion, which is not directly supported by the team view.)
Hopefully, this makes it clear why we might want such a thing.
Scott