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 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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<tel:%28%2B45%29%2036%2096%2007%2006>
W: www.blobcom.com <http://www.blobcom.com>
E: morten.mat...@gmail.com
<mailto: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
<mailto: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
<mailto: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
<mailto: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 <http://www.blobcom.com>
E: morten.mat...@gmail.com <mailto: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
