Re: [Stripes-users] "plugin" strategies?

[Morten Matras]

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 

> 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

Re: [Stripes-users] "plugin" strategies?

[Ben Gunter]

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 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 
>
>> 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

Re: [Stripes-users] "plugin" strategies?

[VANKEISBELCK Remi]

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 "de facto standard" 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 

> 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 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 
>>
>>> 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

Re: [Stripes-users] "plugin" strategies?

[Samuel Santos]

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  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 
>
>> 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 
>> 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 
>>>
 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
 differe

Re: [Stripes-users] "plugin" strategies?

[Morten Matras]

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 

> 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  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 
>>
>>> 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 
>>> 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 

> 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.  

Re: [Stripes-users] "plugin" strategies?

[VANKEISBELCK Remi]

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 

> 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 
>
>> 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

Re: [Stripes-users] "plugin" strategies?

[Freddy Daoud]

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?

[Samuel Santos]

Hi Freddy,

On Tue, Apr 19, 2011 at 1:40 PM, Freddy Daoud  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?

[Nikolaos Giannopoulos]

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 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 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
inte

Re: [Stripes-users] "plugin" strategies?

[Richard Hauswald]

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
 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 
>>
>> 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  wrote:
>>>
>>> Hey Ben,
>>>
>>> First things first, what about :
>>> 1/ full maven build (yeah, drop ant for 

Re: [Stripes-users] "plugin" strategies?

[Will Hartung]

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
___

Re: [Stripes-users] "plugin" strategies?

[Morten Matras]

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 

> 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 t

Re: [Stripes-users] "plugin" strategies?

[VANKEISBELCK Remi]

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 

> 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, ostensi

Re: [Stripes-users] "plugin" strategies?

[Samuel Santos]

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
ShrinkWrapand
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.

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 .

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  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 
>
>> 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 port

Re: [Stripes-users] "plugin" strategies?

[Will Hartung]

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?

[Will Hartung]

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?

[Will Hartung]

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?

[Janne Jalkanen]

> 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?

[George Clark]

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 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 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?

[VANKEISBELCK Remi]

2011/4/20 Will Hartung 

> 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?

[VANKEISBELCK Remi]

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 

>
> 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 
> 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 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?

[Rusty Wright]

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 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 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 and disaster protection. Learn m

Re: [Stripes-users] "plugin" strategies?

[George Clark]

This is exactly the answer I've been looking for.  Thank you Remi.
Cheers
[Now you can all go back to your debate]


On Wed, Apr 20, 2011 at 2:34 PM, 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 
>
>>
>> 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 > > 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 and disaster protection. Learn more about
>>> boosting
>>> the value of server virtualization. http://p.s