Hi all,
1. As long as the paths are on the classpath when Jetty/RIFE starts, then we should be good to go right? As for adding/removing/reordering participants, will this be necessary with the Jumpstart or should that be part of the bigger rife-ide plugin and the functionality for this plugin only allows for quick/easy RIFE development?
I think this should not be part of the first version. We should think about an easy editor for this and a consistent way to handle the configs. It`s more than one file. 2. I think we'll extend the Java Project type.
Best way so far. They can use the Spring Tools then with adding the Spring Nature to the created project. 3. Really depends on question 1 and since deployment is handled by RIFE, there is no need to use the Server Type if we do not have reason. 4. This plugin will not extend any part of WTP if we decide not to create a Server Type. That being said, this plugin will not affect WTP in any way.
To 3. and 4. we can ommit to use this Feature of the WTP but we should think about the people that will develop for WebSphere, Bea and Tomcat and want to test on this plattforms. How can we easily deploy / test on these plattforms ? I think the concensus is to create our own approach for handling RIFE in Eclipse instead of creating a WTP Server Type. I'll start a new thread on the new questions that follow with the new approach unless we change our mind.
Yes, IMHO it`s the best way for the first version. Jetty is the quickest for the development at this moment.
For me in the first Version it should provide a Wizard that: 1. asks me for the project name 2. ask if i want to have the jumpstart app there or only some template files 3. then create the initial structure. 4. create the Jetty instance as provided by the jumpstart package.
Anything missing ?
btw. is there a IRC Plugin for Eclipse ? We can connect them directly to the channel as step 5 ;)
cu odo Take care,
Jeremy
On 1/24/06, Geert Bevin <[EMAIL PROTECTED]> wrote: 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
> > Rife-users@uwyn.com
> > http://lists.uwyn.com/mailman/listinfo/rife-users
> --
> JR Boyens <[EMAIL PROTECTED] >
>
> _______________________________________________
> Rife-users mailing list
> Rife-users@uwyn.com
> http://lists.uwyn.com/mailman/listinfo/rife-users
>
> _______________________________________________
> Rife-users mailing list
> Rife-users@uwyn.com
> 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
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________ Rife-users mailing list |
PGP.sig