Struts2 stuff

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Struts2 stuff

Alan D. Cabrera
Has anyone had any time to look at it?  I'm also going to write some documentation.  Can I do it this weekend or do we want to wait for a release?


Regards,
Alan

Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

Les Hazlewood-2
I haven't had a chance yet.  Given that I have a bit of breathing room
due to the holiday, I'll take a peek this weekend.

But part of my delay is equally related to me thinking about how we
manage our 'support' modules.  With struts2 and wicket and maybe
others, it seems like we should discuss how we handle this stuff in
general and what (if any) our policy should be.

Regards,

Les
Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

kaosko
On Thu, Nov 25, 2010 at 9:27 AM, Les Hazlewood <[hidden email]> wrote:
> But part of my delay is equally related to me thinking about how we
> manage our 'support' modules.  With struts2 and wicket and maybe
> others, it seems like we should discuss how we handle this stuff in
> general and what (if any) our policy should be.

I doubt we can make a clear-cut decision. It depends on the value of
the particular support module to Shiro core (you could argue that
maintaining Spring support has more value than struts2, wicket, etc.)
and committers' interest in maintaining the support module. It's
extremely difficult to convince committers to maintain support modules
for web frameworks they don't use themselves (been there, done that).
The safe bet is to put the new support modules on github or elsewhere.
They can always be migrated later to become part of Shiro.

Kalle
Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

Alan D. Cabrera

On Nov 25, 2010, at 9:54 AM, Kalle Korhonen wrote:

> On Thu, Nov 25, 2010 at 9:27 AM, Les Hazlewood <[hidden email]> wrote:
>> But part of my delay is equally related to me thinking about how we
>> manage our 'support' modules.  With struts2 and wicket and maybe
>> others, it seems like we should discuss how we handle this stuff in
>> general and what (if any) our policy should be.
>
> I doubt we can make a clear-cut decision. It depends on the value of
> the particular support module to Shiro core (you could argue that
> maintaining Spring support has more value than struts2, wicket, etc.)
> and committers' interest in maintaining the support module. It's
> extremely difficult to convince committers to maintain support modules
> for web frameworks they don't use themselves (been there, done that).
> The safe bet is to put the new support modules on github or elsewhere.
> They can always be migrated later to become part of Shiro.

Unless there is some kind of licensing issue there is no reason, from the ASF standpoint, to put new support modules on github or elsewhere.


Regards,
Alan
Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

Les Hazlewood-2
I think Kalle's comments don't reflect a licensing issue, but rather
one of maintenance and longevity: Shiro developers (or any open source
development team for that matter) will maintain things that 1) has
high perceived value for the community or 2) the developers use very
frequently themselves in their own real-world projects.

The idea is that while it's nice to see that a new support module is
being written (I think it's great!), there may not be enough evidence
that the module will be regularly maintained and kept up to date,
which would inevitably cause more headaches and maintenance time for
the team, which would in turn would reflect negatively on the
project's perceived health.

So, one approach is to start up the support module on an external
hosting site (e.g. similar to 'wicketstuff') and see how much traction
it gets.  If it gains and maintains momentum, then the community would
clearly benefit from it being in the core project.  Kind of like a
mini incubator of sorts.

I think though, Alan, you might be saying that such a 'proving ground'
could be the Shiro project itself - perhaps a different part of our
SVN repo.  The only issue I can see with that is one of committer
rights.  Wicket stuff and external hosting providers offer a much
lower barrier to 'committer entry' than a normal ASF project, so it
might be worth seeing how it fares there before taking it on as part
of the core.

I tend to prefer the lowest barrier to committership possible, as I
feel it helps the community more than the risk of any 'questionable'
code it might introduce.  I really believe most people that write code
for an open source project and would like it to see adopted are good
citizens in general and do their best to write good quality code and
help the project.

Les

On Mon, Nov 29, 2010 at 12:37 PM, Alan D. Cabrera <[hidden email]> wrote:

>
> On Nov 25, 2010, at 9:54 AM, Kalle Korhonen wrote:
>
>> On Thu, Nov 25, 2010 at 9:27 AM, Les Hazlewood <[hidden email]> wrote:
>>> But part of my delay is equally related to me thinking about how we
>>> manage our 'support' modules.  With struts2 and wicket and maybe
>>> others, it seems like we should discuss how we handle this stuff in
>>> general and what (if any) our policy should be.
>>
>> I doubt we can make a clear-cut decision. It depends on the value of
>> the particular support module to Shiro core (you could argue that
>> maintaining Spring support has more value than struts2, wicket, etc.)
>> and committers' interest in maintaining the support module. It's
>> extremely difficult to convince committers to maintain support modules
>> for web frameworks they don't use themselves (been there, done that).
>> The safe bet is to put the new support modules on github or elsewhere.
>> They can always be migrated later to become part of Shiro.
>
> Unless there is some kind of licensing issue there is no reason, from the ASF standpoint, to put new support modules on github or elsewhere.
>
>
> Regards,
> Alan
Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

Alan D. Cabrera

On Nov 29, 2010, at 1:37 PM, Les Hazlewood wrote:

> I think Kalle's comments don't reflect a licensing issue, but rather
> one of maintenance and longevity: Shiro developers (or any open source
> development team for that matter) will maintain things that 1) has
> high perceived value for the community or 2) the developers use very
> frequently themselves in their own real-world projects.
>
> The idea is that while it's nice to see that a new support module is
> being written (I think it's great!), there may not be enough evidence
> that the module will be regularly maintained and kept up to date,
> which would inevitably cause more headaches and maintenance time for
> the team, which would in turn would reflect negatively on the
> project's perceived health.
>
> So, one approach is to start up the support module on an external
> hosting site (e.g. similar to 'wicketstuff') and see how much traction
> it gets.  If it gains and maintains momentum, then the community would
> clearly benefit from it being in the core project.  Kind of like a
> mini incubator of sorts.

I've never seen contributions handled in this manner at ASF.  It doesn't mean that they do not exist but I would like to see proof that this "vetting" procedure is kosher with respect to foundation projects.


Regards,
Alan



Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

Les Hazlewood
Administrator
Wicketstuff exists, so that's one definitive example at least.  And
I'm not stating that this is indeed the best solution - just merely
stating that it seems to work well enough for the Wicket project and
it *might* be something we want to look in to.

Cheers,

Les
Reply | Threaded
Open this post in threaded view
|

Re: Struts2 stuff

Alan D. Cabrera

On Nov 29, 2010, at 2:33 PM, Les Hazlewood wrote:

> Wicketstuff exists, so that's one definitive example at least.  And
> I'm not stating that this is indeed the best solution - just merely
> stating that it seems to work well enough for the Wicket project and
> it *might* be something we want to look in to.

Pretty cool.

The trick is to have *all* the components and realms put into this hub.  That way there's no perception of favoritism.


Regards,
Alan