struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip Luppens" <philip.lupp...@gmail.com>
Subject Re: Googlecode Maven Repository for External Struts 2 Plugins
Date Tue, 27 Nov 2007 16:47:58 GMT
On 11/27/07, Frank W. Zammetti <fzlists@omnytex.com> wrote:
> The other fairly obvious concern that I thought of after that last reply
> is how to deal with plugin authors... if these third-party plugins are
> hosted at Apache, their authors clearly would need some degree of commit
> priveleges to their own code bases.  There's two ways I could see to deal
> with that.
>
> First, assuming there is infrastructure to do this (which I don't know to
> be the case), is to go ahead and make them commiters for their particular
> plugin only.  This might be a nice way for people to gradually get more
> involved in Struts and Apache in general.  Could actually foster the
> community even more in the long-run.  I'm not aware of any project that's
> a precedent for this, maybe Commons?  But just because something has never
> been done before doesn't mean it shouldn't be tried.

That could mean a lot of work and lots of permissions to keep track
off. Why not simply let a plugin project 'grow' over at googlecode,
and move it to Apache once it's deemed ready ? Yes, I understand that
would mean that the 'golden plugins' problem is real, but then again,
it'll happen anyways if you move some of them over. And then of
course, there's the problem of determining if a project is 'worthy' of
being transferred to Apache.

All in all, I'm more in favor of keeping plugins at googlecode. If you
want/need access to a particular project, then I'm fairly sure you'd
get it pretty easily, and together with Tom's maven repo and the
'official' plugin registry, I'd say that's the fairest/easiest
solution.

My 2 cents, of course,

Phil

>
> Second, only host binaries at Apache and leave source code somewhere else.
>  When an updated plugin is to be released, the author has to go through an
> existing committer to get it into the registry.  This has the benefit of
> not introducing X number of new committers, even if of a limited variety,
> and keeps more control with the existing team.
>
> To be clear, I'm just tossing ideas out here.  Most of you have known me
> for a while and know I have no problem suggesting things that rock the
> boat a bit :)  This all stems from the premise that to be of as much use
> as possible, the plugin registry should look as "official" as possible,
> and I'm just thinking aloud about how that might be accomplished.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
>  (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
>  (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
>  Supplying the wheel, so you don't have to reinvent it!
>
> On Tue, November 27, 2007 11:22 am, Frank W. Zammetti wrote:
> > On Tue, November 27, 2007 11:02 am, Dave Newton wrote:
> >> Licensing?
> >
> > The licensing issue, which Phil mentioned too, could be... I'm not sure
> > what the policy is around that, i.e., can a project hosted at Apache have
> > a non-ASL license?  I'm not at all sure that's insurmountable though even
> > if it's not allowed... how many of the existing third-party plugins
> > currently aren't under the ASL (I'd bet few if any), and of those that
> > aren't, how many of those authors would have an issue with switching to
> > the ASL (also would bet not many)... I wouldn't think it would be too
> > onerous to say, as a policy statement, that if you want your plugin to be
> > in the Apache-hosted registry then you have to be under the ASL (if that's
> > actually a foundation requirement in the first place), and those that
> > don't want to be under that license can host externally but at least still
> > be listed in the Apache-hosted registry (with an asterisk next to it, ala
> > Barry Bonds- LOL).
> >
> >> I don't want to encourage a situation where there's a
> >> perception of "golden" plugins vs. everything else,
> >> and I'd assume (perhaps incorrectly) that projects
> >> hosted under the Apache umbrella would have to be
> >> Apache-licensed.
> >
> > This is my concern too, but I have a hard time believing that won't
> > automatically happen simply by being hosted outside Apache... I mean, how
> > many people, when I released the Ajax-enabled HTML taglib years ago,
> > thought it was second-class simply because it was on the Sourceforge site
> > and not under Apache itself?  Would it have gotten more uptake if it was
> > in some "add-ons" subproject (for lack of a better term) of Struts?  I
> > don't know, but I don't think it's a crazy thought.  I'd hate to see any
> > third-party plugin, mine, yours or anyone's, not get the same sort of
> > attention as those entirely under the Struts umbrella, which it seems
> > everyone agrees with so far.
> >
> > It may be nothing more than a matter of perception and nothing more, but I
> > think externally-hosted projects will automatically have a connotation of
> > not being "golden" as you say, no matter what else is done to say
> > otherwise, as I believe happened with the Sourceforge-hosted items.  I may
> > be wrong, but that's what I believe to be the case.
> >
> >> d.
> >
> > f(rank) :)
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> > AIM/Yahoo: fzammetti
> > MSN: fzammetti@hotmail.com
> > Author of "Practical Ajax Projects With Java Technology"
> >  (2006, Apress, ISBN 1-59059-695-1)
> > and "JavaScript, DOM Scripting and Ajax Projects"
> >  (2007, Apress, ISBN 1-59059-816-4)
> > Java Web Parts - http://javawebparts.sourceforge.net
> >  Supplying the wheel, so you don't have to reinvent it!
> >
> >
> >> --- "Frank W. Zammetti" <fzlists@omnytex.com> wrote:
> >>
> >>> I was involved with the Sourceforge project Ted
> >>> mentioned, as well as
> >>> having a couple of S2 plugins in the registry now...
> >>> my question, which I
> >>> had for the Sourceforge project too, was why not
> >>> host this at Apache and
> >>> have it under Struts itself?  If we're talking about
> >>> CLAs for GC
> >>> contributions now too, I'm not sure I see the
> >>> difference.  If it's a
> >>> question of perception, i.e., if it's external than
> >>> no plugin is
> >>> officially endorsed or anything, that seems to run
> >>> contrary to listing
> >>> developers and all that's being talked about here.
> >>> I can't imagine
> >>> there's infrastructure issues that couldn't be dealt
> >>> with.
> >>>
> >>> Why wouldn't/couldn't/shouldn't/*dn't this be put
> >>> officially under the
> >>> Struts umbrella and hosted alongside Struts itself?
> >>>
> >>> Frank
> >>>
> >>> --
> >>> Frank W. Zammetti
> >>> Founder and Chief Software Architect
> >>> Omnytex Technologies
> >>> http://www.omnytex.com
> >>> AIM/Yahoo: fzammetti
> >>> MSN: fzammetti@hotmail.com
> >>> Author of "Practical Ajax Projects With Java
> >>> Technology"
> >>>  (2006, Apress, ISBN 1-59059-695-1)
> >>> and "JavaScript, DOM Scripting and Ajax Projects"
> >>>  (2007, Apress, ISBN 1-59059-816-4)
> >>> Java Web Parts - http://javawebparts.sourceforge.net
> >>>  Supplying the wheel, so you don't have to reinvent
> >>> it!
> >>>
> >>> On Tue, November 27, 2007 8:48 am, Tom Schneider
> >>> wrote:
> >>> > I think having separate googlecode projects for
> >>> each plugin has worked
> >>> > well up to this point.  Creating a googlecode
> >>> project is quick and
> >>> > easy.  Googlecode seems to be designed to have a
> >>> lot of really small
> >>> > projects, rather than one big projects with many
> >>> subprojects.  The one
> >>> > thing that ties everything together is the plugin
> >>> registry.  If
> >>> > anything, I'd rather see that expanded.  Maybe add
> >>> a list of developers
> >>> > to the plugin registry.  I think the apache
> >>> developers would feel more
> >>> > obligated to maintain something hosted on Apache
> >>> as opposed to something
> >>> > hosted on googlecode.  As you may be able to tell,
> >>> not a lot of the
> >>> > googlecode plugin sites have a ton of content.
> >>> The only reason I
> >>> > created a common maven repository is so that end
> >>> users only have to add
> >>> > one plugin repository to get access to most of the
> >>> plugins.
> >>> >
> >>> > Ted Husted wrote:
> >>> >> Very cool, Tom.
> >>> >>
> >>> >> Has anyone started a shared GoogleCode project
> >>> for Struts 2 plugins yet?
> >>> >>
> >>> >> The notion being that instead of everyone
> >>> starting up one-off
> >>> >> projects, we could have one GC project that
> >>> anyone with a Google ID
> >>> >> could join and use to maintain a "third-party"
> >>> Struts 2 plugin -- a
> >>> >> Struts 2 Plugin Commons.
> >>> >>
> >>> >> Of course, the group could still have a select
> >>> group of owners that
> >>> >> could remove someone who joined and then turned
> >>> out to be a troll.
> >>> >>
> >>> >> -Ted.
> >>> >>
> >>> >> On Nov 25, 2007 10:12 AM, Tom Schneider
> >>> <schneidh@gmail.com> wrote:
> >>> >>
> >>> >>> Hey all,
> >>> >>> I finally figured out a way to host a maven
> >>> repository on googlecode.
> >>> >>> This should greatly simplify using googlecode
> >>> hosted plugins in Struts
> >>> >>> 2.  For me, it's also much nicer to use maven to
> >>> deploy than trying to
> >>> >>> get a jar manually uploaded into the central
> >>> repository.  Instructions
> >>> >>> on how to use this repo for Struts 2 projects
> >>> are at:
> >>> >>>
> >>> http://code.google.com/p/struts2plugin-maven-repo/
> >>> >>>
> >>> >>> Anyone who has a plugin hosted at googlecode can
> >>> use this maven
> >>> >>> repository to host their plugin.  (I've already
> >>> added several
> >>> >>> developers
> >>> >>> that I know of, if your not in the list let me
> >>> know)  I've also already
> >>> >>> added several of my more popular plugins.  I
> >>> plan on adding the rest as
> >>> >>> time permits.  Please look at the scope plugin
> >>> (on googlecode) for an
> >>> >>> example of how to configure maven to deploy to
> >>> this repository.
> >>> >>> Tom
> >>> >>>
> >>> >>
> >>> >>
> >>>
> >> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail:
> >>> dev-unsubscribe@struts.apache.org
> >>> >> For additional commands, e-mail:
> >>> dev-help@struts.apache.org
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>>
> >> ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail:
> >>> dev-unsubscribe@struts.apache.org
> >>> > For additional commands, e-mail:
> >>> dev-help@struts.apache.org
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail:
> >>> dev-help@struts.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
Software Architect - Hydrodesk
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message