[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?

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