Re: Googlecode Maven Repository for External Struts 2 Plugins
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Ted Husted [EMAIL PROTECTED] 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. By this 'commons' project, do you mean that (some of) these projects should become consolidated (thus giving up their own googlecode page) ? Or would it just be a listing with news and information (=plugin registry), and a global maven repository (Tom's project) ? On a side note: what could be useful would be an overview of all plugin developers and their contact details, so that when a new project gets started, they can be added and/or contacted when required. It could be nice to get an idea of who's interested in helping out developing/maintaining plugins. - Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Nov 27, 2007 4:21 AM, Philip Luppens [EMAIL PROTECTED] wrote: By this 'commons' project, do you mean that (some of) these projects should become consolidated (thus giving up their own googlecode page) ? Or would it just be a listing with news and information (=plugin registry), and a global maven repository (Tom's project) ? I'd say could instead of should, but yes, everyone in the commons project would share the one GoogleCode repository, and, by extension, we'd all have write access to all the code. On a side note: what could be useful would be an overview of all plugin developers and their contact details, so that when a new project gets started, they can be added and/or contacted when required. It could be nice to get an idea of who's interested in helping out developing/maintaining plugins. One effect of a commons would be that the members list would also be a list of some of hte people who have been working on Struts 2 plugins. Another effect would be there would be less need to contact someone, since everyone in that project would have access to the code, in case something needs to be done. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Nov 27, 2007 3:54 AM, Ted Husted [EMAIL PROTECTED] wrote: 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. Better yet, we could use wiki rules and open the GC project to anyone who has filed a CLA with the ASF. In that way, if we later decide to incubate a GC plugin, the paperwork will already be in place. The project would need its own list for commits, but we could defer other support to the Struts lists, to keep it all in one place (and help popularize the plugins). I should mention that we did something similar at SourceForge. The project trailed off after awhile, but I think the plugin model simplifies the notion of a project devoted to contributor extensions with a low bar to admission. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Ted Husted [EMAIL PROTECTED] wrote: On Nov 27, 2007 4:21 AM, Philip Luppens [EMAIL PROTECTED] wrote: By this 'commons' project, do you mean that (some of) these projects should become consolidated (thus giving up their own googlecode page) ? Or would it just be a listing with news and information (=plugin registry), and a global maven repository (Tom's project) ? I'd say could instead of should, but yes, everyone in the commons project would share the one GoogleCode repository, and, by extension, we'd all have write access to all the code. On a side note: what could be useful would be an overview of all plugin developers and their contact details, so that when a new project gets started, they can be added and/or contacted when required. It could be nice to get an idea of who's interested in helping out developing/maintaining plugins. One effect of a commons would be that the members list would also be a list of some of hte people who have been working on Struts 2 plugins. Another effect would be there would be less need to contact someone, since everyone in that project would have access to the code, in case something needs to be done. Sounds ok to me. If people want to keep the control over their plugins, they can just keep their own project page and repository like we're doing now. What would be the name ? struts2-plugins ? struts2-commons ? struts2-extra ? What would happen with the maven repository ? Should it be kept as a seperate project, or also consolidated into the new project ? I can imagine there being plugins that are not in the central repository, so maybe standalone would be better (even if only to have limited access control). - Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Nov 27, 2007 1:21 AM, Philip Luppens [EMAIL PROTECTED] wrote: On a side note: what could be useful would be an overview of all plugin developers and their contact details, so that when a new project gets started, they can be added and/or contacted when required. It could be nice to get an idea of who's interested in helping out developing/maintaining plugins. When a new plugin gets started, an announcement of that on this list should be sufficient. If plugin developers are not tracking the Struts Dev list, their plugins are quite likely to go stale and get out of sync with the rest of the project. -- Martin Cooper - Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
Licensing? 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. d. --- Frank W. Zammetti [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] 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? I assume for the same reason we had to switch datepickers: license issues ? - Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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
Re: Googlecode Maven Repository for External Struts 2 Plugins
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. 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/25/07, Tom Schneider [EMAIL PROTECTED] 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/ On behalf of Maven users everywhere, please consider getting this synced with the central Maven repository. (I think that mostly works via rsync right now, but hopefully something can be arranged to handle svn.) Having to add an additional repository to your settings is a pain, and causes things like archetypes to not Just Work like they're supposed to. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
Marketing is easy - finding the time to do it is the hard part. Maybe someone should write a Developer Works article on Struts Plugins? I say DW because it seems to have the widest reach among online articles. I have connections if anyone is interested in doing this. I'd also like to see Don write an article on the REST plugin - his presentation at ApacheCon was pretty impressive. Matt On Nov 27, 2007 10:15 AM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. Really?!? I'm either the biggest idiot on the face of the planet (which some might say is true regardless, but I digress) or I'm a lot blinder than I thought... I don't see it. It's not out of the realm of possibility that the proxy here at work has an older version of the page cached, I've seen that happen before, but I'm not seeing a big yellow button anywhere on struts.apache.org. What part of the page specifically is it in? - Phil Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
Were you thinking of a roundup, or an article on a specific plugin, or something about to roll your own? I do have an aticle about the SmartURLs plugin pending with TSS. I've also been thinking of trying a JPA plugin of my own. There wouldn't be much to it, so it could also be a how-to. But, yeah, you could put me in touch with someone, Matt. -Ted. On Nov 27, 2007 12:21 PM, Matt Raible [EMAIL PROTECTED] wrote: Marketing is easy - finding the time to do it is the hard part. Maybe someone should write a Developer Works article on Struts Plugins? I say DW because it seems to have the widest reach among online articles. I have connections if anyone is interested in doing this. I'd also like to see Don write an article on the REST plugin - his presentation at ApacheCon was pretty impressive. Matt On Nov 27, 2007 10:15 AM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
Re: Googlecode Maven Repository for External Struts 2 Plugins
If we're focusing on plugins and trying to build a community/ecosystem around them, it's probably best to write an article about how to roll your own. Part of that article could certainly include dissecting an existing plugin. I'll e-mail you privately with my Developer Works contact. Matt On Nov 27, 2007 10:31 AM, Ted Husted [EMAIL PROTECTED] wrote: Were you thinking of a roundup, or an article on a specific plugin, or something about to roll your own? I do have an aticle about the SmartURLs plugin pending with TSS. I've also been thinking of trying a JPA plugin of my own. There wouldn't be much to it, so it could also be a how-to. But, yeah, you could put me in touch with someone, Matt. -Ted. On Nov 27, 2007 12:21 PM, Matt Raible [EMAIL PROTECTED] wrote: Marketing is easy - finding the time to do it is the hard part. Maybe someone should write a Developer Works article on Struts Plugins? I say DW because it seems to have the widest reach among online articles. I have connections if anyone is interested in doing this. I'd also like to see Don write an article on the REST plugin - his presentation at ApacheCon was pretty impressive. Matt On Nov 27, 2007 10:15 AM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Matt Raible [EMAIL PROTECTED] wrote: Marketing is easy - finding the time to do it is the hard part. Maybe someone should write a Developer Works article on Struts Plugins? I say DW because it seems to have the widest reach among online articles. I have connections if anyone is interested in doing this. I'd also like to see Don write an article on the REST plugin - his presentation at ApacheCon was pretty impressive. Voila, that's the kind of thing that we'd need more. Struts 2 must be the most 'quiet' framework I have ever encountered (for such a big mature framework) It's like there never was a hype fase (probably due to the webwork inheritance) - note: hype is used in a positive. And yes, I'm as guilty as the next one for not raving about it more on the internet (probably even more lately). We have quite some plugins, some have been downloaded over a 1000 times, yet it seems unnaturally quiet on the plugin front. Is it indeed due to 'bad marketing' ? Or do users just don't care ? - Phil On Nov 27, 2007 10:15 AM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: Googlecode Maven Repository for External Struts 2 Plugins
On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. Really?!? I'm either the biggest idiot on the face of the planet (which some might say is true regardless, but I digress) or I'm a lot blinder than I thought... I don't see it. It's not out of the realm of possibility that the proxy here at work has an older version of the page cached, I've seen that happen before, but I'm not seeing a big yellow button anywhere on struts.apache.org. What part of the page specifically is it in? It's on the Struts 2 homepage [1], not the struts.apache.org one. [1] http://struts.apache.org/2.x/ - Phil - Phil Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
We do need an article explaining how to write plugins, specially how to create tags in those plugins. People email me a lot asking how to get started with a plugin. musachy On Nov 27, 2007 12:35 PM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Matt Raible [EMAIL PROTECTED] wrote: Marketing is easy - finding the time to do it is the hard part. Maybe someone should write a Developer Works article on Struts Plugins? I say DW because it seems to have the widest reach among online articles. I have connections if anyone is interested in doing this. I'd also like to see Don write an article on the REST plugin - his presentation at ApacheCon was pretty impressive. Voila, that's the kind of thing that we'd need more. Struts 2 must be the most 'quiet' framework I have ever encountered (for such a big mature framework) It's like there never was a hype fase (probably due to the webwork inheritance) - note: hype is used in a positive. And yes, I'm as guilty as the next one for not raving about it more on the internet (probably even more lately). We have quite some plugins, some have been downloaded over a 1000 times, yet it seems unnaturally quiet on the plugin front. Is it indeed due to 'bad marketing' ? Or do users just don't care ? - Phil On Nov 27, 2007 10:15 AM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the standard distribution, mainly because the kids need shoes, and we don't have enough volunteer hours to apply all the patches that people already submit. I would like to encourage a plugin commuity, and a shared external project seemed like one way to do that.
Re: Googlecode Maven Repository for External Struts 2 Plugins
Ok, there appears to be an issue with the site then... when I view it in Macthon, my browser of choice, I don't see the buttons. In FF I see them just fine. I tried in IE7 as well and I see the same thing as Maxthon (which makes sense, since Maxthon is just a wrapper around IE). I fiddled with zoom factors and font size, since that's typically what causes things like this, but even at default font size and zooming, the buttons are not there (I can send a screenshot if anyone would like). It looks like, for whatever reason, the button graphics are not there, all I see is the text in white, so it blends with the background (partially... it slightly overlaps the gray bar there). Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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 12:40 pm, Philip Luppens wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. Really?!? I'm either the biggest idiot on the face of the planet (which some might say is true regardless, but I digress) or I'm a lot blinder than I thought... I don't see it. It's not out of the realm of possibility that the proxy here at work has an older version of the page cached, I've seen that happen before, but I'm not seeing a big yellow button anywhere on struts.apache.org. What part of the page specifically is it in? It's on the Struts 2 homepage [1], not the struts.apache.org one. [1] http://struts.apache.org/2.x/ - Phil - Phil Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
On Nov 27, 2007 12:35 PM, Philip Luppens [EMAIL PROTECTED] wrote: Struts 2 must be the most 'quiet' framework I have ever encountered (for such a big mature framework) It's like there never was a hype fase (probably due to the webwork inheritance) - note: hype is used in a positive. And yes, I'm as guilty as the next one for not raving about it more on the internet (probably even more lately). Historically, we've channeled our effort into helping people on the user list, and quietly promoting third-party resources. In fact, it's probably time to break the other resources section into its own page. * http://struts.apache.org/2.x/docs/home.html#Home-OtherResources For us, the Build! Deploy! Maintain! bit on the S2 home page is radical hype! :) Of course, please remember we come from the Apache HTTPD tradition (http://httpd.apache.org), where what matter is that the system just plain works. People do often tell me things like Struts works great for us. I don't think we've ever found a bug in Struts 1. Or, that the hardest part of Struts 1 development is that, it's so easy, our developers are bored. Out in the blogosphere, people have to hype other frameworks. Otherwise, the only one anyone would ever use is Struts 1. :) We have quite some plugins, some have been downloaded over a 1000 times, yet it seems unnaturally quiet on the plugin front. Is it indeed due to 'bad marketing' ? Or do users just don't care ? Many of the plugins are esoteric and may not have a lot of users yet. Or, they might just work, and don't generate a lot of support request (a al Stripes). We could also use a prettier repository page, and a prettier S2 site in general. People are doing some nice work with the autoexport style sheets these days. Take a tour of http://cwiki.apache.org/. (Though I don't know what's going to happen if we upgrade to Confluence 2.6.x, since the stylesheet support has changed.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
The site looks *horrible* in IE6, at least on my machine. I just never use it, so I had no idea. d. --- Frank W. Zammetti [EMAIL PROTECTED] wrote: Ok, there appears to be an issue with the site then... when I view it in Macthon, my browser of choice, I don't see the buttons. In FF I see them just fine. I tried in IE7 as well and I see the same thing as Maxthon (which makes sense, since Maxthon is just a wrapper around IE). I fiddled with zoom factors and font size, since that's typically what causes things like this, but even at default font size and zooming, the buttons are not there (I can send a screenshot if anyone would like). It looks like, for whatever reason, the button graphics are not there, all I see is the text in white, so it blends with the background (partially... it slightly overlaps the gray bar there). Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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 12:40 pm, Philip Luppens wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, November 27, 2007 12:15 pm, Philip Luppens wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. Really?!? I'm either the biggest idiot on the face of the planet (which some might say is true regardless, but I digress) or I'm a lot blinder than I thought... I don't see it. It's not out of the realm of possibility that the proxy here at work has an older version of the page cached, I've seen that happen before, but I'm not seeing a big yellow button anywhere on struts.apache.org. What part of the page specifically is it in? It's on the Struts 2 homepage [1], not the struts.apache.org one. [1] http://struts.apache.org/2.x/ - Phil - Phil Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugin Article/Pamphlet, was: Re: Googlecode Maven Repository for External Struts 2 Plugins
I'm writing a short (30-40pp) Lulu PDF on creating plugins-with-tags as part of the jQuery tags. d. --- Musachy Barroso [EMAIL PROTECTED] wrote: We do need an article explaining how to write plugins, specially how to create tags in those plugins. People email me a lot asking how to get started with a plugin. musachy On Nov 27, 2007 12:35 PM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Matt Raible [EMAIL PROTECTED] wrote: Marketing is easy - finding the time to do it is the hard part. Maybe someone should write a Developer Works article on Struts Plugins? I say DW because it seems to have the widest reach among online articles. I have connections if anyone is interested in doing this. I'd also like to see Don write an article on the REST plugin - his presentation at ApacheCon was pretty impressive. Voila, that's the kind of thing that we'd need more. Struts 2 must be the most 'quiet' framework I have ever encountered (for such a big mature framework) It's like there never was a hype fase (probably due to the webwork inheritance) - note: hype is used in a positive. And yes, I'm as guilty as the next one for not raving about it more on the internet (probably even more lately). We have quite some plugins, some have been downloaded over a 1000 times, yet it seems unnaturally quiet on the plugin front. Is it indeed due to 'bad marketing' ? Or do users just don't care ? - Phil On Nov 27, 2007 10:15 AM, Philip Luppens [EMAIL PROTECTED] wrote: On 11/27/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I don't disagree with most of what you say here, and what Phillip says in his reply, so let me make a more concrete suggestion: make the plugin registry much more prominent on the Struts home page (that is to say, mention it at all, since I don't see it on the front page anywhere at present). It has a 150px wide button in yellow on the homepage [1] ;-) But I agree that it might need a bit more 'marketing'. - Phil [1] http://struts.apache.org/2.x/ That way, it looks much more official and endorsed, but still retains the benefits you outline here. Again, it's really just a matter of perception in the end, and if this helps make it look like something more than just some outside and yet completely independent entity, as does the Sourceforge project (which is at least mentioned on the home page), then that might be all that's needed to make it work. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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:54 am, Ted Husted wrote: On Nov 27, 2007 11:22 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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. Not all ASF projects are golden, and there are many golden projects that have not joined the ASF. Though, quite a few ASF projects are popular; certainly more than the average open-source startup. One reason is probably the ASF project management style, or the Apache Way. One effect of the Apache Way is that it tends to favor a conservative approach. We need multiple people to agree to an implementation, or at least agree to a release, and forging that agreement can work against innovation. To help promote innovation at the ASF, we even started an Apache Labs project, so that ASF committers could experiment with new code before proposing an actual project. But, the Apache Labs are only open to committers, and sometimes, we want to collaborate on a codebase with someone who isn't a committer (at least, not yet). An important aspect of an external project is that it makes it easier for Struts committers to work with other volunteers, without fussing with the ASF brouhaha. The Apache Way is a great way to manage a mature stable project, but it is not a great way to experiment with new plugins. As an Struts PMC member, I am *very* concerned about plugin proliferation in the
Re: Googlecode Maven Repository for External Struts 2 Plugins
Wendy, I'm all for syncing it with the central repository, it's just a question of how. Googlecode doesn't give shell access so I have no access to cron to sync things up. I could sync it up manually by checking it out and running the rsync on my local machine, but that seems less than ideal. Any suggestions would be greatly appreciated. Tom On Nov 27, 2007 11:04 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/25/07, Tom Schneider [EMAIL PROTECTED] 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/ On behalf of Maven users everywhere, please consider getting this synced with the central Maven repository. (I think that mostly works via rsync right now, but hopefully something can be arranged to handle svn.) Having to add an additional repository to your settings is a pain, and causes things like archetypes to not Just Work like they're supposed to. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
Voila, that's the kind of thing that we'd need more. (Speaking to no one in particular.) If I was going to pull a rabbit out of my hat ... I think it would be labeled patches. :( * https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10740 Though, now that the build is working for me again (thanks Nils!), I can go back to trying to apply at least one a day. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Googlecode Maven Repository for External Struts 2 Plugins
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
