Re: [Rife-users] I18n
Geert, I just finished to code a new proposition. I want to write unit tests for methods like public static Translator getTranslator(TranslatorSupport support) where I need TranslatorSupport instance, in fact ElementSupport instance. Where can I find unit tests in rife as exemples? Regards Pierre ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] I18n
Hi Pierre, you can use the out-of-container testing support in RIFE to test element-related things easily. http://rifers.org/wiki/display/RIFE/Out+of+container+testing Best regards, Geert On 24-jan-06, at 16:58, Raoul Pierre wrote: Geert, I just finished to code a new proposition. I want to write unit tests for methods like public static Translator getTranslator(TranslatorSupport support) where I need TranslatorSupport instance, in fact ElementSupport instance. Where can I find unit tests in rife as exemples? Regards Pierre ___ 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 comTel +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] Re: Eclipse Plugin Development Begins
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 deployments4. 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. Take care,JeremyOn 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/EclipseSubversion: 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,JeremyP.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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
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 [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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
Geert, Questions, concerns and clarification: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. Take care,JeremyOn 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 itsparticipants. By default they will be setup for jumpstart webdev, butit should be possible to remove / add any participant and reorder them. Also, something that needs to be configurable somehow is whichdirectories on the classpath that RIFE needs to consider to be partof the web application (if it's outside WEB-INF). This is currentlydone 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 otherapplications too (GUI, ...). So extending the Java Project typeshould 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 adeployment or package task available for when an application has tobe put into production, but I suppose that can be handled with an antbuild 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 WTPshouldn't be used, they would only be cumbersome. It's XMLvalidation, 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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
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. Take care,JeremyOn 1/24/06, Oliver Dohmen [EMAIL PROTECTED] wrote: 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 name2. ask if i want to have the jumpstart app there or only some template files3.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,JeremyOn 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, butit should be possible to remove / add any participant and reorder them. Also, something that needs to be configurable somehow is whichdirectories on the classpath that RIFE needs to consider to be part of the web application (if it's outside WEB-INF). This is currentlydone 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 otherapplications too (GUI, ...). So extending the Java Project typeshould 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 adeployment or package task available for when an application has tobe 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 WTPshouldn't be used, they would only be cumbersome. It's XMLvalidation, 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
Re: [Rife-devel] 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? 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 comTel +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
Re: [Rife-users] Re: Eclipse Plugin Development Begins
Hi Jeremy, 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. Ok, sounds like a good approach. Take care, 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 comTel +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
