Thanks, Michael. I think it's important to support existing workflows,
such as checking out projects as we do today. My point is that we should
extend the current set of wizards and framework so that users can do
team operations without having to deal with setting up projects. I've
seen a number of cases where users are forced to set up their
environments outside of Eclipse using the command-line version of CVS
since the Eclipse CVS integration doesn't support the way their
command-line peers have set up the repository.
And it doesn't need to be a native client. I'm not suggesting we throw
away the CVS client we have in Eclipse. We may need to extend it to
support these operations. But users expect these clients to work to the
same level as their command-line counterparts. One of the things that
bugs me about the ClearCase Remote Client is that it doesn't implement
all the operations I need, like reqmaster, and I do have to go to the
command-line at times to do my work.
And it seems to me to be a prerequisite if you are to take advantage of
the flexible resources that you have the source set up in the file
system first. The root tends not to be a project so you need to be able
to check out a CVS module, for example, to somewhere on the user's file
system and then have the projects created based on what he checked out.
But, of course, we also need to support the existing environments were
these integrations work fine as is.
Doug.
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael Valenta
Sent: Thursday, October 02, 2008 8:50 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Straw man proposal
Doug,
I don't agree with the statement that Team providers should use
a native tool to bootstrap your Eclipse workspace (i.e. you used the
phrase "how team systems should work"). I think that the user should
have the option to use the native tool if they so choose but I think
that many users appreciate being able to setup their Eclipse workspaces
using checkout (load, etc) wizards integrated in Eclipse (i.e. I can't
imagine what life would be like if I had to use the CVS or SVN command
line clients to checkout projects from those repositories and then
import them into Eclipse).
Or were you describing this from the standpoint of a desirable
architecture for a repository provider implementation were a native
client is used for the operations on the local file system and the
integration in Eclipse is handled through a layer on top of that that
makes any changes on the local file system known to the Project layer so
it can be passed on to the application layer? I know this is done in
many cases but does have drawbacks, mostly related to responsiveness of
the UI during long operations (e.g. progress reporting, cancellation,
resource deltas).
Michael
On Thu, Oct 2, 2008 at 8:18 PM, Schaefer, Doug
<[EMAIL PROTECTED]> wrote:
Hey gang,
To feed the discussion for tomorrow's resource meeting,
I have put together a straw man proposal for the e4 resource system
architecture. I'm sure it has a lot of holes and I'm hoping you'll help
me fill them. I could also be totally on the wrong track and maybe
there's better answers we can put on the table. But let's discuss.
The proposal is here:
http://wiki.eclipse.org/E4/Resources/Strawman
<http://wiki.eclipse.org/E4/Resources/Strawman>
Also at tomorrow's meeting we should discuss if we want
to continue our discussions on the platform-core-dev list, or move them
to the e4-dev list. My opinion is changing on this. I'd like to get
concensus from the team on how we want to do this.
Cheers,
Doug.
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
