Hi Jeremy,
1. I hope there is no configuration but I was thinking that we
might need to allow for changing mabye the Jetty port, to be able
to change if something is already listening on the Jetty port.
I think that you need to be able to manage the repository and its
participants. By default they will be setup for jumpstart webdev, but
it should be possible to remove / add any participant and reorder them.
Also, something that needs to be configurable somehow is which
directories on the classpath that RIFE needs to consider to be part
of the web application (if it's outside WEB-INF). This is currently
done with the rife.webapp.path java property.
2. That is what I was thinking. A RIFE Project that extends Java
Project or something like that.
I would make it as lightweight as possible. Don't restrict the
project type to web applications since RIFE can be used for other
applications too (GUI, ...). So extending the Java Project type
should be good since it's as minimal as you can get I think.
3. There is a lot that goes into creating a Server Type that
really isn't necessary thanks to how RIFE works. No need to have
WTP handle redeploying the changed sources when changed in Eclipse.
Indeed, it's much better to follow the model of the existing
jumpstart, without any deployment. It would be handy to have a
deployment or package task available for when an application has to
be put into production, but I suppose that can be handled with an ant
build file.
4. WTP handles deployment of new source changes to the Server Type
by creating an archive specified by the project type. For example,
creating an ear or a war to deploy the changes to the server.
Well...this isn't necessary with RIFE.
Nope. I'm starting to think that the architectural featured of WTP
shouldn't be used, they would only be cumbersome. It's XML
validation, highlighting and DTD completion, and stuff like that are
handy though. I suppose they will 'just keep working'?
> I have been thinking of how to do the rife-jumpstart plugin
and I
> have a few details we need to iron out:
>
> 1. What configuration, if any, should the user have to do to get
the
> Rife jumpstart working?
As little as possible, at the moment, nothing whatsoever is
needed.
> 2. How should we handle associating a project with Rife?
Project type I would suppose. This flows into question 3.
> 3. Should we try to use WTP's Server Types? (Create a Rife/Jetty
> type)
> a. I have some worries about doing this because of the required
> overhead on the Eclipse side that isn't necessary for Rife.
What kind of overhead?
> b. I also have worries about what artifact types we should
allow
> for WTP deployment if we went this approach like deployments
Artifact types? Historical pieces left by ancestors?
> 4. If not using WTP's Server Types, how do we handle one Rife/Jetty
> instance for all Rife-aware projects?
One Rife/Jetty instance gets hairy. Usually it's best to have one per
project.
>
> These are my preliminary questions/concerns that we need to discuss.
> These were all prompted by my research into duplicating the
Tomcat or
> WebSphere Server Types to create our custom Server Type. I'll
> continue to research and as soon as we get some feedback, we'll
move.
>
> Take care,
>
> Jeremy
>
> On 1/23/06, Jeremy Whitlock <[EMAIL PROTECTED] > wrote:
> Hey all,
> The Eclipse plugin development for Rife has began.
Over
> the last 2 weeks, there has been a lot of conversation on
IRC
> regarding the plans for the Eclipse support for Rife. Now
> that we have initial plans, I have gone ahead and created
the
> most basic Eclipse plugin source bases and checked them into
> Subversion so we could begin working on the plugins. I have
> also create an initial Wiki space for Eclipse. Here we will
> build upon this page to include developer and user
information
> for the Eclipse Rife support. Here are the important URLs:
>
> Wiki: http://rifers.org/wiki/display/RIFE/Eclipse
> Subversion: https://svn.rifers.org/rife-eclipse/trunk/
>
> Now...we need to begin working on outlining and documenting
> the plugin-specific features and approaches. If you are
> interested in getting involved with this initiative, please
> email the mailing list and we will act accordingly.
>
> Take care,
>
> Jeremy
>
> P.S. - To keep in you all up to date, the Wiki and mailing
> list will be constantly updated with progress, questions and
> concerns.
>
> _______________________________________________
> Rife-users mailing list
> [email protected]
> http://lists.uwyn.com/mailman/listinfo/rife-users
--
JR Boyens <[EMAIL PROTECTED] >
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.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://lists.uwyn.com/mailman/listinfo/rife-users
