hi-
Thanks for all your replies. Here's a short todo list summarizing what i've
read (in no particular order) :
jelly script editor
-> edit maven.xml
-> edit plugin.jelly
maven nature
-> standard projects
-> web/j2ee projects
project editor/synchronizer
-> dependencies change tracking
build/launch
-> eclipse incremental builder vs maven java goal
-> manage default goals
-> launch on double-click
i gonna start it very soon, versionning locally for now. i'll put it on
sf.net when i'll get some results.
-- gd
----- Original Message -----
From: "Lester Ward" <[EMAIL PROTECTED]>
To: "'Turbine Maven Users List'" <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 5:02 PM
Subject: RE: eclipse plugin
> > i want to write an eclipse plugin in order to integrate maven
> > into eclipse ide.
>
> First thing, as a note to people reading this: he is .not. talking about
> Maven's existing plugin to support Eclipse. He is talking about a plugin
for
> Eclipse to support Maven.
>
> > im new to maven and so i dont know yet all
> > what we can get from it. that's why i'd appreciate if you could
> > tell me what functionnalities you would like to see in that
> > plugin.
>
> First of all, check out the project on SourceForge dedicated to this
already
> (http://sourceforge.net/projects/mevenide). It hasn't really started in
> earnest yet.
>
> > some ideas after quick thinking and quick discussion with mvdb :
> > * add a maven project nature
>
> Yes. Make sure that there are "types" of projects, including one for web
> applications (e.g. WEB-INF directory, etc.).
>
> One thing to worry about as well: in a Maven eclipse project, do you want
> the project's compile system to use Eclipse's compile system or .always.
use
> Maven to build? I've found that Maven is distractingly slow when doing
> debug-fix-debug type work, so I tend to use both Eclipse's main build
system
> as well as Maven, just not for the same things. (My setup would be perfect
> it Eclipse allowed build targets to be outside of the project directory,
so
> I could build directly into the application server's deploy directory when
> debugging, but that's another issue.)
>
> > * edit project.xml
>
> Less important to me. The XML editor works fine for this.
>
> > * specify and run goals (like tasks in ant plugin)
>
> This is the most important thing. I think the way Ant is currently
> integrated is the perfect model for how the UI should work with one
> exception*. While you can invoke Maven via Ant already in eclipse, the
> output doesn't work correctly (it doesn't output while the script is
> running, but rather dumps the entire output when the script is complete).
>
> Also, it would be .very. nice if Maven could be preloaded or something to
> make its long startup time (about 10 to 15 seconds at the moment) less
> irritating. (The real fix to this, really, should be in Maven itself, but
> that's another topic.)
>
> > * manage dependencies (is not that already done with maven
> > eclipse plugin ?)
>
> This is already done with Maven's Eclipse plugin, but it doesn't work that
> well. It is great for initially generating the file, but if you make
changes
> to the project file (by, say, adding an External Tools Builder to invoke a
> maven task) or the .classpath file (by, say, changing the target away from
> the Maven's Eclipse plugin's stupid, unchangable default), you're stuck
> because the Maven's Eclipse plugin will blow away those changes if re-run.
>
> So, incremental management of these files would be helpful. For example,
> detection if the project.xml file changed and automatic adjustment of the
> project file would be exremely cool.
>
> One other thing: One of the issues with Maven is that it gives you almost
> too many build goals by default. For example, if you run Maven's Eclipse
> plugin goal to generate external tools, you get this huge list, most of
> which you don't want. Figuring out a way to make this more managable would
> be good.
>
> Wordman
>
> *One thing I liked about the way Forte integrated Ant is that when
> double-clicking an Ant file, rather than opening the file, the default
> target of the Ant file would be executed. This was really useful, as once
a
> project gets going, you want to run Ant files more than edit them.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
