Hi Jeremy,
> 1) Port my plugin to Rife allowing for users to configure the plugin
> to "manage" multiple Rife instances.
I'm a bit fuzzy about what you mean with 'manage' in this case.
> 2) Create a Server Launch Configuration like Web Tools does for web
> projects so that when you run/debug that application, it will
> seamlessly fire up the server instance hosting that application,
> deploy it and initialize it.
>
> These are two totally different things. Here are my thoughts on
> these:
>
> 1) This would be cool if we wanted to be able to have a user point to
> a live/existing Rife installation and work against it. With this
> setup, we would also be able to provide deploy-time visualization of
> the Rife components (Elements and such) within the Eclipse gui all as
> one view, similar to how WebLogic visualizes the different deployment
> types in my plugin. We would also be able to build around this with
> the other tooling ideas from the rest of the team.
As I see it, such a management tool is for a large part tied to the
actual servlet container in which RIFE is running. Other management of
deployed RIFE instances would be very useful eventually, but I see this
as another focus, maybe a second or third stage of the project. This
would be handy when RIFE has an extensive JMX interface (people can help
out with this if they want to).
This would allow things like this:
* clear out all template classes from memory
* provide new template classes / source files while the application is
running, even from a packaged jar
* changing configuration values in a running application
* injecting new or updated properties in a running application
* providing new site, sub-site, element declarations in a running
application, this would contains an extensive verification before being
actually put live so make sure that the running application doesn't break
* providing new localization property files in a running application
* manage any caching you have setup (this would need the caching API I
plan to add)
* ... any other ideas ...
If someone is interested by this, adding JMX support is a nicely
isolated task that you could undertake to contribute something to RIFE.
We can discuss this further in this new mail thread or on the wiki.
> 2) This would be the least obtrusive requiring no configuration by
> the end user. The user would create a Rife project and then would
> run/debug their Rife project without any visualization of the project
> and no ties to an external Rife instance. The user would be able to
> configure different Launch Types, so that each type could have
> different environments like JVM and such. We could still build all
> features around this approach as well.
>
> Summary:
>
> Neither offer any edge over the other as far as the ability to deliver
> features to the end user. One it built around the developer but also
> provides an administrative portion to the plugin (Option 1) while the
> other is solely developer centric. It is really up to the community
> as to how to build this effectively but I do think that either
> solution will work with the outcome being the same.
I personally think that in this is the best initial approach, make it as
easy as possible for the developer to develop RIFE applications. The
framework tried to do this with the design and the API, the IDE plugin
can bring this to another level in terms of actual coding comfort.
Having this plugin will certainly attract a lot of new users
(developers). We can then start working on the management part, since
more people actually will need it and there will be more people to help
out / contribute.
Best regards,
Geert
--
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
