Re: [Stripes-users] plugin strategies?
Hi folks, The main advantage of integrating the extensions to the main build is to centralize everything : you build the framework, you build the extensions. We benefit of our C.I. infrastructure etc. I can't see what the problem is. Look at other frameworks, that's how they do it (Spring, Hibernate etc). Btw I think you concur actually : you give a very good example with the Spring integration, layouts etc. If you had to do this from scratch, you'd probably move the Spring extension sources under a submodule of your agregator project (not in the core module), and you'd probably have all sources in the same tree. That's exactly what I'm talking about :) For official extensions, I've always used double quotes for that :P I guess official means approved by the community (the ones you've cited are good examples). As for Ivy, I've never used it but I think you'll still need to configure a repository of some kind to back it. I guess maven integration comes free, but then you'll still need to build what you depend on with maven... pretty useless then. To be honest I don't understand the reluctancy for switching to maven. If you guys have a better alternative, please speak up. I think switching to maven was a good move, it brought lots of benefits, the main one being central repository sync. Now, it can handle our multi module issue very easily. We don't need to hack anything, it's a feature of the build tool. So what ? What's the issue in having a consistent, standard build that works and is easy to maintain/understand, with central sync for free, loads of tooling etc. ? Morten, you said [Ivy] can be altered to work for us : that's precisely it. Maven need no alteration : it already works out of the box and is backed by a (very) large community. I don't want to alter anything : I prefer stuff that already works. And btw we already have a maven build, all I'm talking about is to drop ant definitively and have one and single build system, that can handle the extensions easily, and doesn't require any work. It must be around half a day work to refactor the maven Stripes build, and have the extensions tossed in submodules, integrated to our C.I. and deployed in the maven repo. Really. Simple, and effective. For the plugin system now, I think tooling is very nice (shell scripts etc, a la Grails) but we have absolutely no idea of what it would look like for now. I suggest (again) using maven to kick start the process because : 1/ it would be consistent with the rest of the build 2/ it handles dependencies 3/ it can even handle war overlay, for plugins that bundle JSPs In short, using maven would make it really easy to write extensions (inherit a parent pom) and use them (depend on the extension's pom(s)). Ok, it's not much compared to rails-style command line tools etc, but it's a start. Doesn't have to be fancy, all we ask for a first step is that it works and is easy to use. The original problem is to enable easier integration of extensions, centralization of the info etc. Sugar comes after IMHO. Again, if you guys have a simpler solution, I'm ready to change my mind. But to be honest, maven really shines for multi-module projects, and that's what we're moving towards... For the switch to github, again, I'd like to see this happen as well, but it's another story I think. We can discuss this in a separate thread maybe ? Cheers Remi 2011/4/19 Morten Matras morten.mat...@gmail.com Hi folks For plugin management I've seen that grails uses Apache Ivy. This works with Maven and can be altered to work for us I think. Moving to maven - I'm not sure that really gives much benefit. When we start building a system with plugins we need a dependency management system (Ivy og Maven). Since we are using ant now - going for the ant based solution (Apache Ivy) sounds like a good idea for me. Please comment. Morten 2011/4/19 Samuel Santos sama...@gmail.com Hi Remi and all, I'm not a huge fan of integrating extensions into the main build, de facto standard is somewhat subjective. I believe we should first think about a better plugin system (as Morten pointed out on Stripes LinkedIn Group). What I would like to see in Stripes: 1. Full Maven build; 2. Validate what belongs to core and what doesn't, I do believe that: 1. Spring integration should be moved from core to a plugin (Java EE users will probably never use/need this feature); 2. Stripes Layout Tags should be moved from core to a plugin (Sitemesh users will probably never use/need this feature); 3. Stripes Security should be moved from plugin to core (Security and JAAS integration is a fundamental feature in any Java web framework). 3. Move Stripes source code to GitHub: 1. Create a Stripes organization; 2. Create Stripes Core project under Stripes organization (developers can fork it, fix issues and add new features, that can later be pulled into the
Re: [Stripes-users] plugin strategies?
Hi Samuel, 2. Validate what belongs to core and what doesn't, I do believe that: 3. Stripes Security should be moved from plugin to core (Security and JAAS integration is a fundamental feature in any Java web framework). I disagree with that. By your logic of not having Spring integration nor layouts in the core because people can use alternative solutions, Stripes Security, as much as I like it, should not be in the core because people who use Spring Security or Apache Shiro will probably never use/need this feature. Also, while I disagree that layouts should not be in the core, I don't feel strongly about it; but you have to agree that layouts are a fundamental feature in any Java web framework! However, I'm not sure that we should do any change before Stripes 1.6. I miss ObjectPostProcessor so much that I rather prefer to release 1.6 first and then make the changes. Oh yes, absolutely agree on that one! :) Cheers, Freddy -- 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?
Hi Freddy, On Tue, Apr 19, 2011 at 1:40 PM, Freddy Daoud xf2...@fastmail.fm wrote: Hi Samuel, 2. Validate what belongs to core and what doesn't, I do believe that: 3. Stripes Security should be moved from plugin to core (Security and JAAS integration is a fundamental feature in any Java web framework). I disagree with that. By your logic of not having Spring integration nor layouts in the core because people can use alternative solutions, Stripes Security, as much as I like it, should not be in the core because people who use Spring Security or Apache Shiro will probably never use/need this feature. Also, while I disagree that layouts should not be in the core, I don't feel strongly about it; but you have to agree that layouts are a fundamental feature in any Java web framework! I don't feel strongly about it neither, it's just a matter of opinion. I'm OK with whatever the majority of the Stripes community decision is. However, I'm not sure that we should do any change before Stripes 1.6. I miss ObjectPostProcessor so much that I rather prefer to release 1.6 first and then make the changes. Oh yes, absolutely agree on that one! :) Of course you do :) Cheers, Freddy -- 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 -- Samuel Santos http://www.samaxes.com/ -- 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?
Moren, Clearly we all agree that Ant alone isn't going to cut it and as such we should focus on removing it. The debate as to whether to go to Maven or Ivy or something else also is really not a big debate IMHO as we have partial Maven build capabilities build into the project today! Moreover, I too have to admit to not having used Ivy but the one BIG plus with Maven is the ability to get releases out to Maven central for simple dependency download into developer projects. Can Ivy do similar or better in this regard? I say we have partial Maven build because like Stripes... Maven shines with Convention over Configuration and considering the Ant roots of Stripes... it isn't surprising that some refactoring of the existing project would be in order for Maven to really shine i.e. the ability to have parent and child project capabilities, deploy your project to web / test containers, etc... as Remi points out in his e-mail... and has offered to refactor for us on his accord (so it isn't like we need to find someone to do this). The question to ask ourselves is with Legacy Ant today useful to a handful of maintainters not enchanted by Maven, and partial Maven build capabilities serving many in the community well, what do we gain by going with Ivy or Ant Hill or any other build tool besides full on Maven? I hear that Ivy can support things and can be altered to work for us I think. That doesn't sound encouraging. Maven is in use today in Stripes, is used by many in the Stripes User and Stripes Developer community and can handle 100% of our needs going forward. I also think we all agree that only 1 build system should be in use especially considering we have 2 today and some don't even know that Maven is offering real benefits to the User community! Remi's e-mail and efforts to get Maven already functional and used by Stripes today and others to setup the Sonatype repo can not simply be discarded b/c some don't use Maven. If you don't use Maven then you probably get your jar from a web page and couldn't care what build system was in use. As such I think the path is clear... 100% Maven build... remove Ant... and lets move on to more pressing things unless someone could tell the community where Maven will fail us and Ivy or Ant Hill can save us all! Cheers, --Nikolaos Morten Matras wrote: Hi folks For plugin management I've seen that grails uses Apache Ivy. This works with Maven and can be altered to work for us I think. Moving to maven - I'm not sure that really gives much benefit. When we start building a system with plugins we need a dependency management system (Ivy og Maven). Since we are using ant now - going for the ant based solution (Apache Ivy) sounds like a good idea for me. Please comment. Morten 2011/4/19 Samuel Santos sama...@gmail.com mailto:sama...@gmail.com Hi Remi and all, I'm not a huge fan of integrating extensions into the main build, de facto standard is somewhat subjective. I believe we should first think about a better plugin system (as Morten pointed out on Stripes LinkedIn Group). What I would like to see in Stripes: 1. Full Maven build; 2. Validate what belongs to core and what doesn't, I do believe that: 1. Spring integration should be moved from core to a plugin (Java EE users will probably never use/need this feature); 2. Stripes Layout Tags should be moved from core to a plugin (Sitemesh users will probably never use/need this feature); 3. Stripes Security should be moved from plugin to core (Security and JAAS integration is a fundamental feature in any Java web framework). 3. Move Stripes source code to GitHub: 1. Create a Stripes organization; 2. Create Stripes Core project under Stripes organization (developers can fork it, fix issues and add new features, that can later be pulled into the master branch); 3. Allow developers to create plugins / extensions under Stripes organization or fork their plugins. However, I'm not sure that we should do any change before Stripes 1.6. I miss ObjectPostProcessor so much that I rather prefer to release 1.6 first and then make the changes. What do you think? Cheers, -- Samuel Santos http://www.samaxes.com/ On Mon, Apr 18, 2011 at 10:47 PM, VANKEISBELCK Remi r...@rvkb.com mailto:r...@rvkb.com wrote: Hey Ben, First things first, what about : 1/ full maven build (yeah, drop ant for good), with refactoring of the source folders etc. 2/ integrate all extensions to the main build (as submodules) - Stripersist / Stripes security for starters 3/ ask plugin devs to submit doc for their
Re: [Stripes-users] plugin strategies?
Hi there, +1 for Maven. It simplifies development and build process - especially for different IDE's and developer machines. Plus it enables me to checkout and build the trunk within 5 minutes. Hudson/Jenkins configuration will also be simplified. This would also enable us to make use of plugins like emma/cobertura, sonar, and don't forget the Chuck Norris plugin ;-) Let me know if you need a helping hand, Richard Maybe On Tue, Apr 19, 2011 at 9:41 PM, Nikolaos Giannopoulos nikol...@brightminds.org wrote: Moren, Clearly we all agree that Ant alone isn't going to cut it and as such we should focus on removing it. The debate as to whether to go to Maven or Ivy or something else also is really not a big debate IMHO as we have partial Maven build capabilities build into the project today! Moreover, I too have to admit to not having used Ivy but the one BIG plus with Maven is the ability to get releases out to Maven central for simple dependency download into developer projects. Can Ivy do similar or better in this regard? I say we have partial Maven build because like Stripes... Maven shines with Convention over Configuration and considering the Ant roots of Stripes... it isn't surprising that some refactoring of the existing project would be in order for Maven to really shine i.e. the ability to have parent and child project capabilities, deploy your project to web / test containers, etc... as Remi points out in his e-mail... and has offered to refactor for us on his accord (so it isn't like we need to find someone to do this). The question to ask ourselves is with Legacy Ant today useful to a handful of maintainters not enchanted by Maven, and partial Maven build capabilities serving many in the community well, what do we gain by going with Ivy or Ant Hill or any other build tool besides full on Maven? I hear that Ivy can support things and can be altered to work for us I think. That doesn't sound encouraging. Maven is in use today in Stripes, is used by many in the Stripes User and Stripes Developer community and can handle 100% of our needs going forward. I also think we all agree that only 1 build system should be in use especially considering we have 2 today and some don't even know that Maven is offering real benefits to the User community! Remi's e-mail and efforts to get Maven already functional and used by Stripes today and others to setup the Sonatype repo can not simply be discarded b/c some don't use Maven. If you don't use Maven then you probably get your jar from a web page and couldn't care what build system was in use. As such I think the path is clear... 100% Maven build... remove Ant... and lets move on to more pressing things unless someone could tell the community where Maven will fail us and Ivy or Ant Hill can save us all! Cheers, --Nikolaos Morten Matras wrote: Hi folks For plugin management I've seen that grails uses Apache Ivy. This works with Maven and can be altered to work for us I think. Moving to maven - I'm not sure that really gives much benefit. When we start building a system with plugins we need a dependency management system (Ivy og Maven). Since we are using ant now - going for the ant based solution (Apache Ivy) sounds like a good idea for me. Please comment. Morten 2011/4/19 Samuel Santos sama...@gmail.com Hi Remi and all, I'm not a huge fan of integrating extensions into the main build, de facto standard is somewhat subjective. I believe we should first think about a better plugin system (as Morten pointed out on Stripes LinkedIn Group). What I would like to see in Stripes: Full Maven build; Validate what belongs to core and what doesn't, I do believe that: Spring integration should be moved from core to a plugin (Java EE users will probably never use/need this feature); Stripes Layout Tags should be moved from core to a plugin (Sitemesh users will probably never use/need this feature); Stripes Security should be moved from plugin to core (Security and JAAS integration is a fundamental feature in any Java web framework). Move Stripes source code to GitHub: Create a Stripes organization; Create Stripes Core project under Stripes organization (developers can fork it, fix issues and add new features, that can later be pulled into the master branch); Allow developers to create plugins / extensions under Stripes organization or fork their plugins. However, I'm not sure that we should do any change before Stripes 1.6. I miss ObjectPostProcessor so much that I rather prefer to release 1.6 first and then make the changes. What do you think? Cheers, -- Samuel Santos http://www.samaxes.com/ On Mon, Apr 18, 2011 at 10:47 PM, VANKEISBELCK Remi r...@rvkb.com wrote: Hey Ben, First things first, what about : 1/ full maven build (yeah, drop ant for good), with refactoring of the source folders etc. 2/ integrate all extensions to the main build (as submodules) -
Re: [Stripes-users] plugin strategies?
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 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. If you'd like to contribute to anything, then do so. There's no reason to repaint the whole thing or re-engineer it from the ground up just to contribute. Stripes has a gazillion extensibility points. If Stripes isn't extensible in a place you think it should be, bring it up, add a Jira, and come up with a potential solution. Those are the kinds of changes that need to go in to Stripes core. Changes to make it easier for folks to do the stuff they want. There's always stuff to do. Leverage the processes in place, and when they're exercised more, then we'll have more data to apply towards other changes. But right now, there's really not a lot of data. Lots of chatter, but no real data. So use the system and share your experiences with it. 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 ___
