Sounds good. I do have to say porting my plugin to Rife would be quick but I don't mind doing that later. We can follow your model and based on user/developer needs, we'll make changes accordingly. To provide what you are looking for, we basically should do the following in Eclipse-speak:
We need a plugin that extends the Java Project but is a Rife Project. This will be similar to how Web Tools does it's thing. This will allow for Eclipse-aware Rife types that we can use later to do Rife things when modified and such. We then need to create Rife templates. Following that we should probably figure out a way to add Rife-aware features like code assist, code templates, infopop help and the likes.
How does this sound?
Take care,
Jeremy
On 1/13/06, Geert Bevin <[EMAIL PROTECTED]> wrote:
Great recap and replies!
I think that the plugin should first focus on making the development of
RIFE applications easier. Managing production installations and stuff
like that would be interesting, but I think that should be left for
later. This would also benefit from adding JMX support to RIFE, which I
plan on doing sometimes in the future.
I think that the first step to take is to make it easy to setup a RIFE
project with Eclipse with all the information that the plugin would
require. This includes the classpath elements, libraries and what is to
be considered part of the web application.
From there onwards we can work our way through the structure of a RIFE
application itself. Adding support for the repository with nice forms
for adding participants (and knowledge of those that ship with RIFE).
Views for setting up the datasources and a configuration manager could
be up next. These should all be aware of RIFE-specific types and names
and not provide generic key-value property editors. I personally always
found those to be awkward.
The next step would then be the site structure itself. There's a lot to
write about that, let's detail it later.
One thing that could be interesting wrt the starting, stopping and
management is adding an easy way to launch RIFE out-of-container tests.
The plugin could maybe extend or reuse the TestNG (or JUnit - yuck -)
plugin and allow you to automatically startup your project without a
servlet container to start running one or several tests. Just an idea.
Let's leave the debugging for a later step, unless someone is really
dedicated to get that working. Having that integrated with the visual
editor would be the nicest. I would concentrate on making the life of
the developer a lot easier to manage the code and run it, afterwards we
can focus on these more advanced features.
Jeremy Whitlock wrote:
> Wow...a lot of stuff going on. Here are my comments:
>
> Geert,
> While the starting/starting of Rife isn't really a function of
> Rife, we will want to be able to start/stop and embedded container, like
> Jetty/Tomcat, to allow us to control the Rife environment. (This would
> also allow for us to debug Rife applications.) That is what would be
> started and stopped. As for your ideas of visualizing a site and it's
> components, that is definately a reality. Working with local/remote
> servers would be available as well as Eclipse supports both.
>
> JR,
> Oliver and I have started discussion on this. The plan is to take
> the features of my WebLogic plugin, porting them to Rife and then
> integrating Oliver's plugin into it.
>
> Oliver,
> Debugging facilities are easy. My plugin already provides them.
> For the modeling of Rife, we just need to know what to model and if we
> want to model the actual breakpoints and visually view the app running
> somehow, the APIs already exist in Eclipse.
>
> All,
> This idea isn't a half baked idea. We have a very powerful and
> extendable IDE at our hands. We also have great developers with
> experience in all technologies involved. I do not see us having a
> problem with coming up with an idea and making it so.
>
> Take care,
>
> Jeremy
>
> On 1/13/06, *Geert Bevin* <[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>> wrote:
>
> >> What I have been dreaming of since several years is to be able to
> >> visually see the site structure and to be able to set
> breakpoints and
> >> watch expressions visually on a running application. Like that
> you can
> >> visually trace what is going on exactly and clearly follow the data
> >> and logic flow. This could be tied to the actual implementations and
> >> declarations and offer some round-trip coding features that can be
> >> reloaded automatically without restarting the server.
> >
> > for this we can try to combine the debug facility and the model
> editor.
> > The will be tricky ! And it takes some time. Maybe we can make
> this in
> > Version 3.0 :)
>
> Yes, that was what I was thinking about too :-)
>
> --
> Geert Bevin Uwyn bvba
> "Use what you need" Avenue de Scailmont 34
> http://www.uwyn.com 7170 Manage, Belgium
> gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
> Public PGP key : available at servers pgp.mit.edu
> <http://pgp.mit.edu>, wwwkeys.pgp.net <http://wwwkeys.pgp.net>
> _______________________________________________
> Rife-users mailing list
> [email protected] <mailto:[email protected]>
> http://www.uwyn.com/mailman/listinfo/rife-users
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rife-users mailing list
> [email protected]
> http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________ Rife-users mailing list [email protected] http://www.uwyn.com/mailman/listinfo/rife-users
