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:
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.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hey all, 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?
2. How should we handle associating a project with Rife? 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.
b. I also have worries about what artifact types we should allow for WTP deployment if we went this approach like deployments 4. If not using WTP's Server Types, how do we handle one Rife/Jetty instance for all Rife-aware projects?
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.
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:
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.
Re: [Rife-users] Re: Eclipse Plugin Development Begins
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.
2. That is what I was thinking. A RIFE Project that extends Java Project or something like that.
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.
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.
Those are my clarifications. Hopefully this makes sense.
On Tue, 2006-01-24 at 12:02 -0700, Jeremy Whitlock wrote:
> Hey all, > 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 <jcscoobyrs@...> 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
> 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 <jcscoobyrs@... > 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@... > > http://lists.uwyn.com/mailman/listinfo/rife-users > --
> JR Boyens <jboyens@... >
>
> _______________________________________________
> Rife-users mailing list
> Rife-users@... > http://lists.uwyn.com/mailman/listinfo/rife-users >
> _______________________________________________
> Rife-users mailing list
> Rife-users@... > 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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
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?
2. I think we'll extend the Java Project type.
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.
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.
> 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 <jcscoobyrs@... > 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@... > >
http://lists.uwyn.com/mailman/listinfo/rife-users > -- > JR Boyens <jboyens@... > > > _______________________________________________
> Rife-users mailing list > Rife-users@... > http://lists.uwyn.com/mailman/listinfo/rife-users > > _______________________________________________ > Rife-users mailing list > Rife-users@... >
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
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 ;)
> 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 <jcscoobyrs@... > 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@... > > http://lists.uwyn.com/mailman/listinfo/rife-users > -- > JR Boyens <jboyens@... > > > _______________________________________________ > Rife-users mailing list > Rife-users@... > http://lists.uwyn.com/mailman/listinfo/rife-users > > _______________________________________________ > Rife-users mailing list > Rife-users@... > 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
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hey all, I do not know of an IRC plugin for Eclipse but that would be cool. Anyway, it seems as though we are mixing parts of the rife-jumpstart and rife-ide plugins together. I was thinking that the rife-jumpstart was to provide a facility similar to RIFE's own jumpstart that allowed for a controlled RIFE environment for development and debugging. If I am wrong, please let me know and I will tailor my reply.
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 ;)
> 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 <jcscoobyrs@... > 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@... > >
http://lists.uwyn.com/mailman/listinfo/rife-users > -- > JR Boyens <jboyens@... >
-- 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
>> 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.
I agree that the configuration is not needed at the beginning,
however this architecture needs to be in place. The repository is
where everything starts from and if you want to build an intelligent
editor for RIFE, you'll have to start from there. So better include
'support' for it in the core project.
> 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 ?
As long as you can package wars, it should be pretty easy to automate
the deployment if the semantics are known.
>> 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 ?
Sounds good for the most basic possible approach.
> btw. is there a IRC Plugin for Eclipse ? We can connect them
> directly to the channel as step 5 ;)
>
> cu odo
--
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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
> 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?
It's not exactly the same, a servlet container has a hierarchy of
classloaders. RIFE's classloader automatically instruments all the
classes in the web application. It doesn't instrument anything
outside since that would be a needlessly high performance hit. That's
where the rife.webapp.path java property comes into play, to indicate
to RIFE which paths are to be considered part of the webapp when the
classes are not situated in a classic WEB-INF hierarchy.
> 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.
I think we discussed and decided this on IRC now.
> 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.
>
> 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.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
PGP.sig (186 bytes)