ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: [PATCH] ejb-jar/jonas element again
Date Fri, 28 Dec 2001 12:59:31 GMT
Well, you may be right after all and I was just brainstorming without
just thinking it through.  Still and all, I think I'm going to disagree
with you a little bit that an interface for working in an IDE is a
simpler thing than what we're doing in ant.  I think it's the other way

Interfacing to an IDE involves GUI considerations, the particular IDE's
view of files, and folders, whether to support single or multiple
operations, whose GUI widgets to use, progress meters, (in ant, we don't
need no stinkin progress meter, we've got the log), catering to every
flavor of checkout or checkin supported by the system.  For example, the
StarTeam GUI has an annoying restriction:  If you have selected multiple
files in its interface, it won't let you invoke the "edit" operation
because they didn't conceive of interfacing to an editor that could open
multiple files.  There are lots of gotchas to interfacing with a GUI
that are not present with ant.

The most typical ant use case is still just "pull out everything from
the respository so we can build it."  This can be done with any system
that supports methods for "GiveMeAListOfEverythingInThisFolder()" and
"GetThisFile()".  Now, if not all VC APIs support methods like this, my
idea is surely dead.  But if they do, it might be possible to do it this
way.  It might be that other systems' APIs have higher level methods
that handle the iteration over the tree for you. If they don't also have
the lower level methods, we can forget my idea. But let's not forget
that if vendors are going to do this, they may have more resources than
what their public apis expose.

Of course I'm oversimplifying, of course there are still bells and
whistles that must be supported but it's worth thinking about at least.

Still, thanks for the slap in the face awakening me to reality.  I've
still got work to do on the StarTeam support! 


-----Original Message-----
From:	Stephane Bailliez
Sent:	Fri 12/28/2001 3:48 AM
To:	Ant Developers List
Subject:	RE: [PATCH] ejb-jar/jonas element again
> -----Original Message-----
> From: Steve Cohen []

> Although I confess that I have not even looked at the other 
> version control tasks, I am fairly sure that this or 
> something like it would be generalizable to the point that an 
> Interface could be designed for it that could be implemented 
> not only for Star Team but for other version control systems 
> as well.  

I don't think it is possible *at all*.

The common interface already exists even though it is Microsoft only, it
called SCC.
It is not widely supported by SCM vendors because it fails to address
specific issues of each software of course and each software nearly as
own concept, but some vendors provide a scc dll so that it can
integrates in
some IDEs.

Now assuming you want to do this.

Just keep in mind that it means you must do the same for every tool out
there, like for example - the EJB task for each app. server out there.
- the java compiler
- the C/C++ compiler

Since it is not even standardized, I fail to see how you will be able to
standardize every piece of software out there which you don't even know
deeply and where you have absolutely zero influence. It is just like
for standard parameters in all C/C++ compilers.

For the little story, when I got my hands on Eclipse 1.0, I could not
see at
all how the clearcase model could fit into the eclipse vcm stream model.
Since Rational was involved in Eclipse as a partner, I was intrigued and
asked the question, Kevin McGuire then directed me to the new API that
designed for 2.0 to address this issue. You can find it here:

Now consider that this is just a very simple API, that is intended
for IDE use and that is very much different from what you would be able
do via Ant which is more a deployment thing than a bare
checkin/checkout/move that you do 99% of the time in an IDE.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message