Re: [Stripes-users] plugin strategies?
Hi Will and others It seems we're discussing two different things in this thread. 1) Maven / ant for building stripes core. Stripes must as it is now be available in a Maven repository. How it gets in there doesn't really matter 2) Plugin technology: Regarding the plugins - let's just revisit the reasons for discussing it: - Systems like Grails have a vibrant plugin environment with hundreds of plugins - making Grails look much more alive than Stripes. The grails plugin technology includes view unlike Stripes that's a Java - alone plugin technology. We all like Stripes for it's simplicity of use. Adding a plugin strategy to it might just give it the share of the fame needed to keep it alive in the mindset of the people that takes decisions (Managers, Architects etc.) Adding a plugin strategy should be kept away from the development of the Stripes core for the reasons Will states above and maybe that's exactly where we'll have end this discussion - that the Stripes plugin idea is a completely separate project from Stripes core. Our conclusions so far could be: - Stripes core is handled brilliantly by the people and with the technology they choose. No real need to interfere with that! - Stripes could use a better plugin strategy including handling of view parts of the plugins. What do you say - could that be the conclusion? Regards Morten 2011/4/20 Will Hartung redro...@sbcglobal.net I'm not going to copy the entire thread, and I'm not responding to any one in particular. Not being a maven fan, even I can agree with the conversion to Maven. The primary reason is that Maven has become a de facto portable project meta data that all of the IDEs support well, and makes IDE integration reasonably simple. The secondary reason is that someone has gracefully volunteered to undertake the entire process finishing and rounding out the process, and once complete, the ongoing maintenance should be minor and simple to keep up, at least until Maven 4 comes out and they break backward compatibility Yet Again. That said, I don't agree with the plugins concept at all. Stripes is already pretty plugin friendly and whatever burden there is in terms of creating an add on to Stripes is likely minor compared to the work on the add on functionality itself. I don't think folks are saying yea, I'd like to add that to Stripes, but it's just Too Hard. Implementing an interface and adding a line or two to web.xml -- not really arduous. Even I have done it, and if you know anything about my history with Stripes, that's saying something. I see no motivation to make Stripes a plugin framework with some default modules. It's that already, effectively. It's just that this concept doesn't boil to the top when it comes to implementing Stripes. It pretty much works out of the box with minimal configuration. That's a feature. In contrast to something like Spring or JBoss, which is all modules of all kinds and all generic metadata that you have to master to get Hello World running. It's a mostly terrible experience, especially for a new person. I also don't agree with moving the popular Stripes Stuff in to the Stripes source tree. If those are included then, regardless of original intent, users will think that these are first class citizens of Stripes, and that the there is some obligation for the maintainer of Stripes core to maintain these as well. Basically that makes this free code for stripes, but it's free as in free like a puppy. Ben has enough to do just to keep up with bug fixes and such without adding traffic and questions and clutter to the core system stuff that he's not going to be responsible for. There's also the issue of code segregation, IP rights, and commit access. Since each module would, ostensibly, have a different owner and it's easy to see how rights will be different for different people in different parts of the source tree. More bookkeeping, more admin drag, less stuff done to Stripes core. If there is a desire that these projects have more visibility on the web site and wiki, then absolutely. Ask for wiki write access and start linking away and pointing to the assorted projects in their own homes. Perhaps the maintainers of StripesStuff can be more liberal, grant more rights to folks that want to host their project there, and let that be more of a Wild West for, well, Stripe Stuff. Maybe not. But in the end, it doesn't really matter because with an email, wiki rights are pretty easy to get if you want to highlight you favorite project, hosted where you want to host it. As for the GIt conversion, I don't get it. We're not the Linux kernel. There aren't zillions of patches pending to be applied every day. In fact, there are pretty much zero patches. If folks want to make changes, and make a difference, then make or find an issue on Jira, and submit a patch. There's nothing in the toolset holding that up. When Ben throws up the white flag
Re: [Stripes-users] plugin strategies?
Hi Will, folks, That said, I don't agree with the plugins concept at all. To be honest, I also think a clean dependency mechanism + some centralized docs would be enough. Anyway, it's a nice to have, as it allows beginners to have no ramp up. Simply list plugins, install them, it adds the deps, classes and updates your web.xml. Even if many Stripers won't probably use it once they are used to the framerwork, consider it a selling feature. If those are included then, regardless of original intent, users will think that these are first class citizens of Stripes, and that the there is some obligation for the maintainer of Stripes core to maintain these as well. Well, everything is subjective, but clearly some of the extensions will be first class citizens. Think about what's already in the core and will be moved (e.g. Spring integration). Now, I've never said that ALL extensions should be included to the main repo and built along with the framework. I think every extension, once it gets popular, stable etc., turns into a good candidate for integration into the offficial extensions of the framework. There's also the issue of code segregation, IP rights, and commit access. Yep, but on the other hand it ensures that all parts are consistent when new versions are released, that they have the same license, and that they are managed by the same group of developers. Last, it could drag new coders into the framework. And again, it doesn't mean that evey extension has to be there, just the ones that have been approved by the community. You can still write your separate, third party extension if you want, and distribute it the way you want. In short, think about how life would be if Spring's codebase contained only core container, and everything else (JDBC, JMS, ...) was scattered around the web... Different builds, different policies of maven sync, different websites... admin drag you said ? :P That's the way all projects handle scalability of the codebase : they split stuff into modules. I guess Stripes is now at that point, and it's a good sign. There's no reason to repaint the whole thing or re-engineer it from the ground up [...] Not sure you talk about the modularization of the build here. If you do, c'mon... the build already exists, there's nothing to do. I'd say half a day work, not a class file touched, only a few moves... From the ground up ??? There's always stuff to do. Leverage the processes in place [...] That's exactly what I'm trying to do :) Cheers Remi 2011/4/20 Will Hartung redro...@sbcglobal.net I'm not going to copy the entire thread, and I'm not responding to any one in particular. Not being a maven fan, even I can agree with the conversion to Maven. The primary reason is that Maven has become a de facto portable project meta data that all of the IDEs support well, and makes IDE integration reasonably simple. The secondary reason is that someone has gracefully volunteered to undertake the entire process finishing and rounding out the process, and once complete, the ongoing maintenance should be minor and simple to keep up, at least until Maven 4 comes out and they break backward compatibility Yet Again. That said, I don't agree with the plugins concept at all. Stripes is already pretty plugin friendly and whatever burden there is in terms of creating an add on to Stripes is likely minor compared to the work on the add on functionality itself. I don't think folks are saying yea, I'd like to add that to Stripes, but it's just Too Hard. Implementing an interface and adding a line or two to web.xml -- not really arduous. Even I have done it, and if you know anything about my history with Stripes, that's saying something. I see no motivation to make Stripes a plugin framework with some default modules. It's that already, effectively. It's just that this concept doesn't boil to the top when it comes to implementing Stripes. It pretty much works out of the box with minimal configuration. That's a feature. In contrast to something like Spring or JBoss, which is all modules of all kinds and all generic metadata that you have to master to get Hello World running. It's a mostly terrible experience, especially for a new person. I also don't agree with moving the popular Stripes Stuff in to the Stripes source tree. If those are included then, regardless of original intent, users will think that these are first class citizens of Stripes, and that the there is some obligation for the maintainer of Stripes core to maintain these as well. Basically that makes this free code for stripes, but it's free as in free like a puppy. Ben has enough to do just to keep up with bug fixes and such without adding traffic and questions and clutter to the core system stuff that he's not going to be responsible for. There's also the issue of code segregation, IP rights, and commit access. Since each module would, ostensibly, have a different owner and it's easy to
Re: [Stripes-users] plugin strategies?
Hi guys, Again, I totally agree with Will about the plugins strategy and about including them in Stripes source tree. That's why I've suggested GitHub. I believe it can handle what we are trying to achieve here. As for the Git conversion, I don't get it. We're not the Linux kernel. There aren't zillions of patches pending to be applied every day. This is not a valid argument to me. I don't think that the amount of patches submitted is a decisive factor, it's all about organization. Lately, I've been working a lot with ShrinkWraphttps://github.com/shrinkwrap/shrinkwrapand Arquillian https://github.com/arquillian/arquillian from JBoss. It were those two projects that made me move to and started loving GitHub, I've even start to commit code into ShrinkWrap so easy it was. Now, take a look at ShrinkWrap organization https://github.com/shrinkwrap/, it's exactly what we are trying to achieve here. A central place to have a project and its sub-projects or extensions. And plugins don't need to be (or must not be) on the Core project source code tree. Each plugin is maintained by its creator, not the core team. Have its developer lose interest and stop updating it, we can easily fork the project under Stripes organization and continue evolving it to remain compatible with later Stripes versions. I'm not a GitHub guru nor even an advanced user, but I believe it is a better solution than the one we have now and can fix the majority of the issues we are discussing here. Some people have brought it to discussion in this mailing list long before me, not sure why we haven't heard anything from them since then... If your problem is about using Git, don't worry, GitHub also supports Subversion https://github.com/blog/644-subversion-write-support. I will not continue to argue about GitHub if no one, apart from me, sees the advantages in using it, but please think about it for a second before shooting arguments like the one I quoted above. Cheers, -- Samuel Santos http://www.samaxes.com/ On Wed, Apr 20, 2011 at 10:09 AM, VANKEISBELCK Remi r...@rvkb.com wrote: Hi Will, folks, That said, I don't agree with the plugins concept at all. To be honest, I also think a clean dependency mechanism + some centralized docs would be enough. Anyway, it's a nice to have, as it allows beginners to have no ramp up. Simply list plugins, install them, it adds the deps, classes and updates your web.xml. Even if many Stripers won't probably use it once they are used to the framerwork, consider it a selling feature. If those are included then, regardless of original intent, users will think that these are first class citizens of Stripes, and that the there is some obligation for the maintainer of Stripes core to maintain these as well. Well, everything is subjective, but clearly some of the extensions will be first class citizens. Think about what's already in the core and will be moved (e.g. Spring integration). Now, I've never said that ALL extensions should be included to the main repo and built along with the framework. I think every extension, once it gets popular, stable etc., turns into a good candidate for integration into the offficial extensions of the framework. There's also the issue of code segregation, IP rights, and commit access. Yep, but on the other hand it ensures that all parts are consistent when new versions are released, that they have the same license, and that they are managed by the same group of developers. Last, it could drag new coders into the framework. And again, it doesn't mean that evey extension has to be there, just the ones that have been approved by the community. You can still write your separate, third party extension if you want, and distribute it the way you want. In short, think about how life would be if Spring's codebase contained only core container, and everything else (JDBC, JMS, ...) was scattered around the web... Different builds, different policies of maven sync, different websites... admin drag you said ? :P That's the way all projects handle scalability of the codebase : they split stuff into modules. I guess Stripes is now at that point, and it's a good sign. There's no reason to repaint the whole thing or re-engineer it from the ground up [...] Not sure you talk about the modularization of the build here. If you do, c'mon... the build already exists, there's nothing to do. I'd say half a day work, not a class file touched, only a few moves... From the ground up ??? There's always stuff to do. Leverage the processes in place [...] That's exactly what I'm trying to do :) Cheers Remi 2011/4/20 Will Hartung redro...@sbcglobal.net I'm not going to copy the entire thread, and I'm not responding to any one in particular. Not being a maven fan, even I can agree with the conversion to Maven. The primary reason is that Maven has become a de facto portable project meta data that all of the IDEs support well, and
Re: [Stripes-users] plugin strategies?
On Apr 19, 2011, at 11:19 PM, Morten Matras wrote: Our conclusions so far could be: - Stripes core is handled brilliantly by the people and with the technology they choose. No real need to interfere with that! - Stripes could use a better plugin strategy including handling of view parts of the plugins. What do you say - could that be the conclusion? Sure. There's nothing to stop some enterprising person or group from running off and working up some new kind of plugin architecture. I looked at the Grails one, and if you're looking for something of that sophistication, then that may well be a 2.0 kind of thing. But we won't know that until someone starts work on it. But as far as I can tell, there's nothing stopping people from starting work on this right away to better understand what they want from it and how it may, or may not, affect Stripes core. Oh, and speaking of that, I don't want to be (more of) a stick in the mud, but I read the thread on Linked In for the stripes group. It was a nice discussion. My only issue is simply that the community is small enough as is without having the discussions being fragmented. Some of these issue came thundering in to the ML with a lot of unknown history behind it because it was off on the LI forums. I think if you want the input of the community, then the discussion should take place here. Regards, Will Hartung -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] plugin strategies?
On Apr 20, 2011, at 2:09 AM, VANKEISBELCK Remi wrote: If those are included then, regardless of original intent, users will think that these are first class citizens of Stripes, and that the there is some obligation for the maintainer of Stripes core to maintain these as well. Well, everything is subjective, but clearly some of the extensions will be first class citizens. Think about what's already in the core and will be moved (e.g. Spring integration). Now, I've never said that ALL extensions should be included to the main repo and built along with the framework. I think every extension, once it gets popular, stable etc., turns into a good candidate for integration into the offficial extensions of the framework. There's also the issue of code segregation, IP rights, and commit access. Yep, but on the other hand it ensures that all parts are consistent when new versions are released, that they have the same license, and that they are managed by the same group of developers. Last, it could drag new coders into the framework. And again, it doesn't mean that evey extension has to be there, just the ones that have been approved by the community. You can still write your separate, third party extension if you want, and distribute it the way you want. My only concern is that the community can decide whatever it wants, but most of the time its Ben who gets to do the work. And voting to get more puppies for Ben to take care of isn't really fair to him. That's why I resist the inclusion of some of the existing external pieces in to the responsibility of the current maintainer. In short, think about how life would be if Spring's codebase contained only core container, and everything else (JDBC, JMS, ...) was scattered around the web... Different builds, different policies of maven sync, different websites... admin drag you said ? :P It's admin drag on the end users/developers, but not the Stripes dev team. Does it make Stripes harder to use? Perhaps, marginally, but also because there's still really few things to add on. As you mentioned if there is some core mechanism (either in the runtime or in the build) that makes integration of 3rd party modules easier and more consistent, AND those changes are straightforward and suitable for a 1.x release, then that may well be a good plan. That makes Stripes more puppy friendly but without the need to actually take them home. Not sure you talk about the modularization of the build here. If you do, c'mon... the build already exists, there's nothing to do. I'd say half a day work, not a class file touched, only a few moves... From the ground up ??? The maven build is one thing, I've already advocated for that, mostly because you were willing to lend your expertise and time to engineer and see it through to completion, and to train Ben and others how to maintain it. But others are talking a more extensive module system and a project move to Github. Those are more fundamental IMHO than what we're talking about here. Regards, Will Hartung -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] plugin strategies?
On Apr 20, 2011, at 6:15 AM, Samuel Santos wrote: This is not a valid argument to me. I don't think that the amount of patches submitted is a decisive factor, it's all about organization. Lately, I've been working a lot with ShrinkWrap and Arquillian from JBoss. It were those two projects that made me move to and started loving GitHub, I've even start to commit code into ShrinkWrap so easy it was. Now, take a look at ShrinkWrap organization, it's exactly what we are trying to achieve here. A central place to have a project and its sub-projects or extensions. And plugins don't need to be (or must not be) on the Core project source code tree. Each plugin is maintained by its creator, not the core team. Have its developer lose interest and stop updating it, we can easily fork the project under Stripes organization and continue evolving it to remain compatible with later Stripes versions. In my opinion, for the short to mid-term, these concepts can be handled elegantly with the current toolset, perhaps some more process and a bit of wiki work under the current umbrella. I don't see the current patch process as a particularly high threshold to cross for submitting patches and changes. The wiki can be used to organize projects and the maintainers of those projects can submit patches. GitHub lets someone PULL patches, rather than have them pushed. That's sounds like a great feature. But it's not a debilitating show stopper to not have that feature, and I don't believe that the patch process is what keeps people from contributing. The patch process is less elegant and perhaps even more labor intensive than something like GitHub, but since there's are so FEW patches, it's more an issue for the maintainers than it is for the contributor. When that process becomes more painful due to volume, then the time and effort to port over to something like GitHub might well be worthwhile. But I think it's worthwhile to see some activity first than move when the issue really isn't there right now. Regards, Will Hartung -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] plugin strategies?
As for the GIt conversion, I don't get it. We're not the Linux kernel. There aren't zillions of patches pending to be applied every day. In fact, there are pretty much zero patches. If folks want to make changes, and make a difference, then make or find an issue on Jira, and submit a patch. There's nothing in the toolset holding that up. When Ben throws up the white flag because of the crushing load of source patches coming in to core instead of just chatter on the ML, then maybe there's motivation to change to something like Git. I don't really care what Stripes uses (other than I have a deep dislike and fear of Maven, but I'm not the one who has to live with it ;-), but I think this is a misunderstanding of the power of Git. I don't use Git because I expect a lot of contributions. I use Git for all my own projects because of two reasons: 1) Local commits. You don't need IP connectivity to commit anything. This has the advantage that you can keep the workflow even while traveling or when the internet goes bad. 2) Easy branching and merging. It makes a lot of sense to always start a clean branch *from a stable root* when you're hacking on a feature. You can keep committing, tinker at will, and then finally merge the whole thing at the root, or just throw the branch away. This is especially valuable when multiple people work on the same tree (you get to keep the master stable and new features get merged in when they are stable(ish)), but it works really well when you're developing on your own too. I'm a bit ADHD when it comes to development, and I often try out different things. With SVN you need to keep multiple projects open, with Git you just switch between branches, cherry-pick changes, merge and branch. In fact, whenever a project uses SVN, I just usually check it out as a Git project and use Git locally on it... Git has good SVN support, but a native Git project is always better. Just my 2c. /Janne -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] plugin strategies?
I understand this conversation has been going on for a while, and I'm glad to see it spilling over here from the LinkedIn Group, (and I'd love for it to keep going). However, I started this thread with a much more simple question than what this has turned into. So, just to reiterate: Given that Stripes doesn't *currently* have a fancy-schmancy plugin mechanism like Grails- and maybe doesn't need one. What strategies do you use in your personal projects to maximize re-usability? A lot of my little projects are Google AppEngine centric, nothing professional, but I build little billboard type sites for friends businesses, blog type sites for fun, and maybe even a storefront thing for my lousy sister-in-law's creations. So here's an example: To make my life easier I allow the site owners to upload their own images, and content. Therefore, I have a view that displays a form. An ImageUploadAction that handles multi-part uploads, a DAO layer that persists the images to google's datastore, then some views and actions to allow accessing, renaming, deleting, resizing, etc. It works really well, and provides Action mappings to allow accessing images as if they were on the disk in the images directory. The problem is that I've copied and pasted this code 6 times, for 6 separate projects. For each project I have to include the actions, put the view jsp's under the WEB-INF, put any images/css in the project war directory, and modify the web.xml. Then repeat if I fix a bug in it. So, this is where the question is coming from... in your own development environments, what strategies do you use to mitigate this churn? ... today. ;) Thanks! George On Wed, Apr 20, 2011 at 2:00 PM, Janne Jalkanen janne.jalka...@ecyrd.comwrote: As for the GIt conversion, I don't get it. We're not the Linux kernel. There aren't zillions of patches pending to be applied every day. In fact, there are pretty much zero patches. If folks want to make changes, and make a difference, then make or find an issue on Jira, and submit a patch. There's nothing in the toolset holding that up. When Ben throws up the white flag because of the crushing load of source patches coming in to core instead of just chatter on the ML, then maybe there's motivation to change to something like Git. I don't really care what Stripes uses (other than I have a deep dislike and fear of Maven, but I'm not the one who has to live with it ;-), but I think this is a misunderstanding of the power of Git. I don't use Git because I expect a lot of contributions. I use Git for all my own projects because of two reasons: 1) Local commits. You don't need IP connectivity to commit anything. This has the advantage that you can keep the workflow even while traveling or when the internet goes bad. 2) Easy branching and merging. It makes a lot of sense to always start a clean branch *from a stable root* when you're hacking on a feature. You can keep committing, tinker at will, and then finally merge the whole thing at the root, or just throw the branch away. This is especially valuable when multiple people work on the same tree (you get to keep the master stable and new features get merged in when they are stable(ish)), but it works really well when you're developing on your own too. I'm a bit ADHD when it comes to development, and I often try out different things. With SVN you need to keep multiple projects open, with Git you just switch between branches, cherry-pick changes, merge and branch. In fact, whenever a project uses SVN, I just usually check it out as a Git project and use Git locally on it... Git has good SVN support, but a native Git project is always better. Just my 2c. /Janne -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] plugin strategies?
2011/4/20 Will Hartung redro...@sbcglobal.net My only concern is that the community can decide whatever it wants, but most of the time its Ben who gets to do the work. And voting to get more puppies for Ben to take care of isn't really fair to him. That's why I resist the inclusion of some of the existing external pieces in to the responsibility of the current maintainer. Well, I get your point, even if it's a little off topic I think. You raise an issue, but it already exists. Having the official extensions in the codebase won't change the fundamental problem (Ben commiting 99% of the code). And again, I never said that *everything* has to end up in a common source control. I just think that some of the extensions (parts that are in the core and need externalization - e.g. Spring integration, or other stuff likes StripesSecurity) have their place there. Now for new extensions, stuff that is marginal etc, a separate project is fine for me. That's just how it should be. It's admin drag on the end users/developers, but not the Stripes dev team. Does it make Stripes harder to use? Definitly. Some folks I know recently spent half a day setting up Stripes/Hibernate/Security. IMHO, that's 3 and a half hours too much ! This should be as simple as adding a dep to your pom (or if you push it like Morten does, to type a command or two). And that's what approved extensions mean to me : stuff that solves a common problem and has been approved by the community. From then, I see no problem in shipping these extensions along the framework (again, like everybody does). As you mentioned if there is some core mechanism (either in the runtime or in the build) that makes integration of 3rd party modules easier and more consistent, AND those changes are straightforward and suitable for a 1.x release, then that may well be a good plan. That makes Stripes more puppy friendly but without the need to actually take them home. That's exactly my point. As usual, you said it with better words :P Cheers Remi -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] plugin strategies?
Another vote for maven. Here's an interesting thread on a project that recently switched to maven's maven-release-plugin. It demonstrates how when you start using more of maven's features, doing a release largely turns into a one click operation. http://goo.gl/DJBQY On 2011-04-20 12:34, VANKEISBELCK Remi wrote: Maven :) Really : create jar modules for your classes (action beans, interceptors, etc), and war modules for your JSPs, tag files etc. Then, in your final app, just depend on them. I can't explain this in a few lines on the Stripes ML, but I think that's what you need. Look at the maven docs for (transitive) dependency management and war plugin overlay. HTH Remi 2011/4/20 George Clark gc1...@gmail.com mailto:gc1...@gmail.com I understand this conversation has been going on for a while, and I'm glad to see it spilling over here from the LinkedIn Group, (and I'd love for it to keep going). However, I started this thread with a much more simple question than what this has turned into. So, just to reiterate: Given that Stripes doesn't /currently/ have a fancy-schmancy plugin mechanism like Grails- and maybe doesn't need one. What strategies do you use in your personal projects to maximize re-usability? A lot of my little projects are Google AppEngine centric, nothing professional, but I build little billboard type sites for friends businesses, blog type sites for fun, and maybe even a storefront thing for my lousy sister-in-law's creations. So here's an example: To make my life easier I allow the site owners to upload their own images, and content. Therefore, I have a view that displays a form. An ImageUploadAction that handles multi-part uploads, a DAO layer that persists the images to google's datastore, then some views and actions to allow accessing, renaming, deleting, resizing, etc. It works really well, and provides Action mappings to allow accessing images as if they were on the disk in the images directory. The problem is that I've copied and pasted this code 6 times, for 6 separate projects. For each project I have to include the actions, put the view jsp's under the WEB-INF, put any images/css in the project war directory, and modify the web.xml. Then repeat if I fix a bug in it. So, this is where the question is coming from... in your own development environments, what strategies do you use to mitigate this churn? ... today. ;) Thanks! George On Wed, Apr 20, 2011 at 2:00 PM, Janne Jalkanen janne.jalka...@ecyrd.com mailto:janne.jalka...@ecyrd.com wrote: As for the GIt conversion, I don't get it. We're not the Linux kernel. There aren't zillions of patches pending to be applied every day. In fact, there are pretty much zero patches. If folks want to make changes, and make a difference, then make or find an issue on Jira, and submit a patch. There's nothing in the toolset holding that up. When Ben throws up the white flag because of the crushing load of source patches coming in to core instead of just chatter on the ML, then maybe there's motivation to change to something like Git. I don't really care what Stripes uses (other than I have a deep dislike and fear of Maven, but I'm not the one who has to live with it ;-), but I think this is a misunderstanding of the power of Git. I don't use Git because I expect a lot of contributions. I use Git for all my own projects because of two reasons: 1) Local commits. You don't need IP connectivity to commit anything. This has the advantage that you can keep the workflow even while traveling or when the internet goes bad. 2) Easy branching and merging. It makes a lot of sense to always start a clean branch *from a stable root* when you're hacking on a feature. You can keep committing, tinker at will, and then finally merge the whole thing at the root, or just throw the branch away. This is especially valuable when multiple people work on the same tree (you get to keep the master stable and new features get merged in when they are stable(ish)), but it works really well when you're developing on your own too. I'm a bit ADHD when it comes to development, and I often try out different things. With SVN you need to keep multiple projects open, with Git you just switch between branches, cherry-pick changes, merge and branch. In fact, whenever a project uses SVN, I just usually check it out as a Git project and use Git locally on it... Git has good SVN support, but a native Git project is always better. Just my 2c. /Janne -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability
