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) - >>> Stripersist / Stripes security for starters >>> 3/ ask plugin devs to submit doc for their plugins, to be integrated to >>> the main wiki >>> >>> I know you're not a maven freak, but really, 2 separate builds is >>> awkward, and having a standard build would help a lot for third party >>> integration. I really think a small source layout refactoring and dropping >>> all the build.xml stuff wouldn't hurt. >>> >>> I'm ok to do this on 1.5.x and trunk whenever you want. >>> >>> Cheers >>> >>> Remi >>> >>> 2011/4/18 Ben Gunter <gunter...@gmail.com> >>>> >>>> I just chimed in on the LinkedIn discussion, though there's not much to >>>> my response. Basically, I'd like to see a clear plan for what you want to >>>> do. Then we can discuss how to execute the plan. >>>> >>>> On Thu, Apr 14, 2011 at 9:01 PM, Morten Matras <morten.mat...@gmail.com> >>>> wrote: >>>>> >>>>> Hi George >>>>> In the Stripesframework linked in group there is an ongoing discussion >>>>> regarding this topic. >>>>> There seems to be a consensus regarding your ideas. Currently we're >>>>> waiting for Ben / Tim to give their opinion before stepping forward with >>>>> some action. >>>>> Ben? >>>>> Thanks >>>>> Morten >>>>> 2011/4/14 George Clark <gc1...@gmail.com> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I enjoy Stripes in my personal time. Unfortunately, at the office >>>>>> we're using Grails. I'm wondering if any of you have thought about or >>>>>> implemented a grails-type plugin solution in your dev environments? >>>>>> >>>>>> There are a few things I enjoy about Grails and one of them is >>>>>> their plugin strategy. It can be messy at times but I feel we've >>>>>> leveraged >>>>>> it well and it's become pretty valuable. An example might be something >>>>>> off-the-shelf like an Acegi authentication plugin. It can be "installed" >>>>>> through maven, and it's controllers, configuration and WEB-INF resources >>>>>> are >>>>>> merged into the main application. >>>>>> >>>>>> But I suppose the real benefit is if you're in charge of five or >>>>>> six applications in different repositories and want to share more than >>>>>> just >>>>>> taglibs. For instance, we have a system that consumes events from >>>>>> running >>>>>> applications and makes decisions to notify people of said events. We've >>>>>> built a plugin that provides beans to create such events, controllers to >>>>>> act >>>>>> as an interface to the queued data, and controllers that provide views to >>>>>> allow humans to inspect the app directly complete with images, css and >>>>>> javascript. It appears as a complete application structure: >>>>>> controllers/views/jars/assests, etc. >>>>>> >>>>>> Any person creating a new webapp merely adds >>>>>> event-monitoring-plugin in their pom and now they've met the corporate >>>>>> web >>>>>> interface for monitoring and reporting. Occasionally the plugin is >>>>>> upgraded >>>>>> and we can simply change the value in the pom and rebuild the >>>>>> application. >>>>>> I'm feeling like if we were doing this is stripes I would be copying >>>>>> these >>>>>> resources into every application and they would live within that >>>>>> applications resources. >>>>>> >>>>>> I suppose I could do something at build time where I unzip a >>>>>> package over-top of main application code which adds controllers and adds >>>>>> resources to WEB-INF. Maybe I could also make it smart enough to modify >>>>>> the >>>>>> ActionResolver.Packages list. Or, maybe I just need to think about this >>>>>> differently altogether! >>>>>> >>>>>> What kinds of processes/solutions do you use when wanting to share >>>>>> this kind of code? >>>>>> >>>>>> Thanks! >>>>>> George >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Morten Matras >>>>> Consultant >>>>> Blob Communication ApS >>>>> Svendsagervej 42 >>>>> DK-5240 Odense NØ >>>>> P: (+45) 36 96 07 06 >>>>> W: www.blobcom.com >>>>> E: morten.mat...@gmail.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 >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>> >> > > > > -- > Morten Matras > Consultant > Blob Communication ApS > Svendsagervej 42 > DK-5240 Odense NØ > P: (+45) 36 96 07 06 > W: www.blobcom.com > E: morten.mat...@gmail.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 > > > -- > Nikolaos Giannopoulos > Director, Information Technology > BrightMinds Software Inc. > e. nikol...@brightminds.org > w. www.brightminds.org > t. 1.613.822.1700 > c. 1.613.797.0036 > f. 1.613.822.1915 > > ------------------------------------------------------------------------------ > 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 > > -- Richard Hauswald Blog: http://tnfstacc.blogspot.com/ LinkedIn: http://www.linkedin.com/in/richardhauswald Xing: http://www.xing.com/profile/Richard_Hauswald ------------------------------------------------------------------------------ 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
