Re: Hi all
On Mon, Dec 3, 2012 at 3:38 PM, vineet sood wrote: > Hi all, > > I just joined the party and new over here. Let me know how I can be of > help, as its boring to sit idle :) . > A good place to start is here: http://struts.apache.org/helping.html -- Martin Cooper Cheers, > Vineet >
Re: Using fluido once available
On Tue, Nov 27, 2012 at 11:51 PM, Rene Gielen wrote: > > Am 28.11.12 06:14, schrieb Martin Cooper: > > On Tue, Nov 27, 2012 at 1:55 PM, Johannes Geppert > wrote: > > > >> It looks there is a broad agreement related to the projects links and > the > >> Roadmap FAQ. > >> So i have dropped it from the site. > >> > >> Also I have added a Facebook and G+ Integration beside the Twitter > >> Integration. > >> Looks like this is our current News Section. ;-) > >> > > > > Why are we supporting commercial enterprises from our site? As a 501(c)3 > > organisation, are we allowed to do that? > > > > We have an "official" Twitter account - @TheApacheStruts - which we use > to spread news about Struts and to interact with our community. Just > like @TheASF, @TheApacheTomcat or @ApacheJames. > > On Facebook, there is as well a page voluntarily maintained by Struts > PMC members, called "Struts2 Users. Objective: spreading and dispatching > news, interacting with the community. Currently 1400+ "likes" aka > followers. See: > https://www.facebook.com/apachestruts > > On G+, there is again an page voluntarily maintained by Struts PMC > members, called "Apache Struts". Objective: spreading and dispatching > news, interacting with the community. Currently more than 3700 people > are following. See: > https://plus.google.com/+ApacheStruts/posts > See also on G+: "Apache Software Foundation", "Apache TomEE" > > The idea is to link this pages to our site just like we did with the > twitter account in the branch (and other Apache projects do as well on > their front page). > > So how is this "supporting commercial enterprises"? One could argue that > we are using (free) services of commercial companies, yes. We do that > all the time at Apache. I fail to see how this is promoting Twitter, > Google or Facebook as companies. If 100 other companies came along and asked us to put links to their sites on our site, would we do it? If not, why not? Would we be selective, or add anyone who asked? If the former, what are the criteria? Why isn't LinkedIn in the same group as the "special three" we've chosen to advertise? > Ironically, the latter two are getting > prominent ASF support since they are platinum sponsors: > http://apache.org/foundation/thanks.html > Sponsorship does *not* buy favours. That's very explicit. And that is also why there is a specific, foundation-central, and non-project-specific "thank you" page. > Linking to Struts related resources on Twitter, G+ or Facebook is as > much of a support for commercial enterprises as linking to Struts > Sourceforge is or Struts GitHub would be - free community resources > offered and hosted free of charge by a commercial enterprise like > SourceForge and GitHub. > Once we've checked with our legal people, and this usage has been approved by them, I'll be fine with it. Until then, I'm very conscious that the ASF is legally a charity, and is subject to losing that status if we don't abide by the rules. So I would rather ask the question and get the official answer than discover that we were responsible for the ASF losing its status over an assumption we made. -- Martin Cooper - René > > > -- > > Martin Cooper > > > > > > [...] > > -- > René Gielen > http://twitter.com/rgielen > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Using fluido once available
On Tue, Nov 27, 2012 at 1:55 PM, Johannes Geppert wrote: > It looks there is a broad agreement related to the projects links and the > Roadmap FAQ. > So i have dropped it from the site. > > Also I have added a Facebook and G+ Integration beside the Twitter > Integration. > Looks like this is our current News Section. ;-) > Why are we supporting commercial enterprises from our site? As a 501(c)3 organisation, are we allowed to do that? -- Martin Cooper On the bottom of our Welcome Page are some Books like "Starting with > Struts2" linked. > But this Links returns only a blank page to me. Does anybody know the right > Link? > > Johannes > > # > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep > > > > > 2012/11/27 Rene Gielen-2 [via Struts] < > ml-node+s1045723n5711187...@n5.nabble.com> > > > Am 26.11.12 22:41, schrieb Martin Cooper: > > > > > On Mon, Nov 26, 2012 at 12:41 PM, Lukasz Lenart <[hidden email]< > http://user/SendEmail.jtp?type=node&node=5711187&i=0>>wrote: > > > > > > > >> 2012/11/25 Johannes Geppert <[hidden email]< > http://user/SendEmail.jtp?type=node&node=5711187&i=1>>: > > > > >>> What others think about shrinking a little bit the menu and some > > Content? > > >> > > >> +1 :-) > > >> > > > > > > Depends on what you mean by "shrink". We have people (e.g. Link, very > > > recently) who don't seem to be able to find stuff on our menu, so > making > > it > > > smaller will not help at all. On the other hand, reducing the number of > > > items would undoubtedly help. > > > > > > > > > > I have to admit that the sheer amount of information both in the main > > menu and certain pages is what it makes hard for me to find something - > > even given that I'm involved with the site for some years now. While > > e.g. it is educative to hear about mailing list policies first, the > > actual information how to subscribe is buried under piles of letters ... > > and most of nowadays users seem to have an attention span not lasting > > longer than three paragraphs before they give up reading. At least the > > mailing list moderation experience seems to indicate that. > > > > Basically I think that careful reduction and hierarchical organization > > of information helps to succeed getting our messages between our site > > reader's ears. > > > > That said, reducing the main menu would be good first step in my opinion. > > > > > > >> > > >>> 1.) The "Roadmap FAQ" is really outdated! > > >>> We can update it, delete it or reference it to the current Struts3 > > Wiki > > >> Page > > >> > > >> I think we can remove that page, even if we plan S3 there is not too > > >> much to write - Struts 2 done better :-) > > >> > > > > > > A roadmap can be very useful, but it needs people committed to > > maintaining > > > it. I think Ted was probably the only one who did this for an extended > > > period. We should just remove it if we don't have something useful to > > say. > > > > > > > > > > +1 - unless there is valid maintained content, we should remove the > > roadmap FAQ. If at a later point we want to add up to date roadmap > > information again, we might consider to call it simply "Roadmap" rather > > than "Roadmap FAQ". > > > > >> > > >>> 2.) What is the mining of the "Project Minutes" ? Last update is from > > >> 2008! > > >> > > >> I think it would be nice to put here Reports to the ASF Board which > > >> Rene prepares, it's important to see what's going on with the project, > > >> thus will overtake Roadmap FAQ > > >> > > > > > > The board minutes are a matter of public record, and are always > > published. > > > See: > > > > > > http://www.apache.org/foundation/board/calendar.html > > > > > > It's not easy to find the Struts reports in that (e.g. you need to know > > our > > > schedule), so I'd be okay with re-publishing, if we think we'll keep it > > up > > > to date. But we should copy from the board minutes, rather than our > > list, > > > to be sure we capture accurately what the board accepted. > > > >
Re: Using fluido once available
On Mon, Nov 26, 2012 at 12:41 PM, Lukasz Lenart wrote: > 2012/11/25 Johannes Geppert : > > What others think about shrinking a little bit the menu and some Content? > > +1 :-) > Depends on what you mean by "shrink". We have people (e.g. Link, very recently) who don't seem to be able to find stuff on our menu, so making it smaller will not help at all. On the other hand, reducing the number of items would undoubtedly help. > > > 1.) The "Roadmap FAQ" is really outdated! > > We can update it, delete it or reference it to the current Struts3 Wiki > Page > > I think we can remove that page, even if we plan S3 there is not too > much to write - Struts 2 done better :-) > A roadmap can be very useful, but it needs people committed to maintaining it. I think Ted was probably the only one who did this for an extended period. We should just remove it if we don't have something useful to say. > > > 2.) What is the mining of the "Project Minutes" ? Last update is from > 2008! > > I think it would be nice to put here Reports to the ASF Board which > Rene prepares, it's important to see what's going on with the project, > thus will overtake Roadmap FAQ > The board minutes are a matter of public record, and are always published. See: http://www.apache.org/foundation/board/calendar.html It's not easy to find the Struts reports in that (e.g. you need to know our schedule), so I'd be okay with re-publishing, if we think we'll keep it up to date. But we should copy from the board minutes, rather than our list, to be sure we capture accurately what the board accepted. > > > 3.) Maybe we can create on Page for the Related and Similar Projects? > > This would make the Menu much more cleaner. > > +1 > Frankly, I think we should drop related and similar projects. There is no meaningful determination of what does, or does not, make it into either list. > > > 4.) The Link to "Our Blogs" looks also really outdated! Last Entry is > from > > 2008. > > http://people.apache.org/~rubys/planet/struts/ > > We can add few new, like your :-) > That planet link is long-obsolete. See instead: http://blogs.apache.org/ > > > 5.) Is the Struts Sourceforge active? Never heard about it. > > http://struts.sourceforge.net/ > > I've been using it some times ago, but not any more but I think it > should stay :-) > Yeah, it should stay. It's where we can point non-committers to check in Struts-related code, if they so wish. -- Martin Cooper > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: processing of multipart request
On Tue, Nov 20, 2012 at 6:30 PM, Fastupload wrote: > Lukasz, > > can you do me a favour to give me a reference about creation of struts > JIRA ticket and how to commit patch? > I strongly recommend that you read the Struts web site. In particular, look through the "Development" section in the navigation menu, and read the "How to Help FAQ". You've asked several times about how to create a patch, but all the information is there on the web site, and easy to find, if you'll just take some time to look. -- Martin Cooper > Link > > > On Nov 19, 2012, at 3:33 PM, Lukasz Lenart > wrote: > > > 2012/11/19 Fastupload : > >> I'm very happy to prepare a patch. but I'm not familiar with the > development process in Struts2 project. for example, register an account, > check in patch, etc. any guide about this? > > > > Right now there is just one option for you, as Dave has mentioned > > > >> Fastupload had registered groupId in Sonatype. it encounters 401 errors > in the deployment. Sonatype engineer find the root cause. He is resolving > it. > > > > Without that it will be impossible to do anything as Struts 2 base on > > Maven Central Repo in case of dependencies > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: processing of multipart request
On Sat, Nov 17, 2012 at 4:14 AM, Fastupload wrote:
> Umesh,
>
> thanks for your reply! Based on current file upload framework to write a
> plugin. it only support java.io.File, for example, the Action has to use
> File object to access multipart data of HTTP request. why not we do access
> multipart data directly and efficiently, in stead of temporary file?
>
> so I think we need to refactor current file upload framework in S2 to
> support more efficient way. the new file upload framework has the ability
> that enable user config his prefered file upload component and processing
> way.
>
Great. So do that. Provide a patch that refactors S2, such that the current
Commons FileUpload code is still the default, and such that an alternative,
like your fastupload plugin (but not restricted to it), can be configured
by the user if they want it. In your original post, you said you already
have that code, but I could not find it in your svn repo.
Please understand that there is no way that the existing code will be
*replaced* by a new implementation as the default any time soon. There are
tens of thousands of applications (S1, S2, and many others) that use
Commons FileUpload today, and have done for many, many years, so we know
that code is extremely robust. As far as I can tell, nobody else has ever
heard of fastupload before, and it certainly does not have the kind of
real-world testing that Commons FileUpload has had. If you want to provide
it as a plugin, people can experiment with it, and deploy it if they decide
they like it. But we are not going to throw out what has been solid for
years and replace it with something that hasn't been tested like Commons
FileUpload has.
--
Martin Cooper
this is current form of Action access multipart data
>
> public class StrutUploadAction2 extends ActionSupport {
>
> private File photo;
>
> @Override
> public String execute() throws Exception {
> // …
> return super.execute();
> }
> }
>
>
> But the efficient way is this or next ..
>
> public class StrutUploadAction1 extends ActionSupport {
>
> private MultiPartFile photo;
>
> private String description;
>
> @Override
> public String execute() throws Exception {
> // .. ..
> return super.execute();
> }
> }
> for more information please look at
> https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
>
> or
> -
> public class StrutUploadAction2 extends ActionSupport {
>
> private FileItemStream photo;
>
> @Override
> public String execute() throws Exception {
> / /…
> return super.execute();
> }
>
> }
> // in ASF commons fileupload, FileItemStream contains multipart data in
> memory… for more information, please look at
> http://commons.apache.org/fileupload/streaming.html
>
>
> Best Wishes,
> Link Qian
>
>
> On Nov 17, 2012, at 6:18 PM, Umesh Awasthi wrote:
>
> > Link,
> >
> > I believe that what suggested by others is good way to go,
> > you can easily create a plugin using fastupload.
> >
> > one of best feature of S2 is its flexibility to enhance and provide
> added
> > features using plugins.
> >
> > Thanks
> > Umesh
> >
> > On Sat, Nov 17, 2012 at 3:43 PM, Fastupload
> wrote:
> >
> >> Wes,
> >>
> >> I have read struts2 file upload framework and plugin guide about file
> >> upload. It requires the plugin provides a java.IO.File object to
> >> interceptors. so in the way, upload component has to use temporary file.
> >> it's not reasonable to better performance.
> >>
> >>
> >> Here are fast upload API usage and performance
> >>
> >> https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
> >>
> >> https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/
> >>
> >> Link
> >>
> >>
> >>
> >> On Nov 16, 2012, at 6:40 PM, Rene Gielen wrote:
> >>
> >>> Going to write a plugin should really be the way to go, as Wes and
> >>> Martin already pointed out. There is positive experience with
> successful
> >>> externally maintained Struts 2 plugins such as Struts 2 jQuery e.g.
> >>>
> >>> We also provide a platform for Struts 2 developers to stay in touch
> with
> >>> latest plugin developments, internally or externally maintained:
> >>> https://cwiki.apache.org/confluence/
Re: Struts 1 - what does the future hold?
On Thu, Nov 15, 2012 at 10:56 AM, Brian Holzer wrote: > Hi all, > In 2010 we finished a 6 year project of redeveloping our complete > application from COBOL and a bit of Java to a totally Java application > using Struts 1. We have tens of thousands of classes and millions of lines > of code. A new kind of "one off/stand alone" application has been > requested by the business, and the Analyst in charge is looking at > different frameworks and even languages ( ie Grails, Spring MVC ) for > completing this project. I asked why they weren't just going to use our > current environment (Struts 1 and Java). They expressed concerns about how > long Java and Struts 1 would remain viable. I don't happen to share these > concerns but am looking for some sort of confirmation from the development > team that my thinking is correct on this subject and that Struts 1 will be > maintained enough to keep it compliant and relevant. > >My feeling is that if anything they should maybe switch to Struts 2 for > this project to remain in the same realm as the rest of our apps. > >My question is: As Java SE and EE and all things java, continue to > evolve will Struts 1 be maintained in order to remain compliant and usable? > Not expecting any new features or anything but just wondering if we need > to be thinking about a possible end of life type situation for Struts 1. > There isn't really the concept of "end of life" for an open source project. As long as there are volunteers to maintain it, it will be maintained. Those volunteers might be existing committers, new volunteers, one of the companies that support open source commercially - or you, if you so choose, because you have the source available to you. -- Martin Cooper > Brian Holzer > IT Analyst > Saskatchewan Government Insurance > email: bhol...@sgi.sk.ca > phone: (306) 751-1573 > fax: (306) 569-7683 > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you are not the named addressee, please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that using, disclosing, copying or distributing the > contents of this information is strictly prohibited. > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: processing of multipart request
On Mon, Nov 12, 2012 at 4:39 AM, Fastupload wrote: > To who maybe concern, > > I just notice struts2 framework parses multipart/form-data requesting into > a temporary file, and marshal a java.io.File object for struts2 action > regarding file input of multipart-form data request. also the framework > parses all files in request and then make a filter rule in > FileUploadInterceptor.java. And finally, framework clean temporary files > after action is invoked. > > Following the processing, there are three disadvantages: > 1, use temporary file makes low performance > 2, redundancy operation -- clean up temporary file > 3, struts action only supports java.io.File class to represent a uploading > file in multipart/form-data request. > 4, filter all file after parsing has been done, the action may be prior to > interceptors. > All of those could be addressed without switching to a new file upload framework, since Commons FileUpload supports them. It would seem to make more sense to me to expand what we have already, rather than throw it out and replace it with something new and untested (i.e. not in widespread Struts production usage). Could you guys have a look into *fastupload* open source project in > https://sourceforge.net/projects/fastupload. Right now it is the fastest > form-based upload parsing component in java area. it makes a significant > performance improvement and advance features, such as, > 1, 2.x faster than Apache Commons FileUpload in stream method. certainly, > it's 5.x faster than apache commons file upload in disk method. > Please provide some links to the benchmarks you've run to measure those things, and the constraints you used when measuring them. > 2, filter boundaries with determining MIME and file name in advance. > > > > In fastupload-0.4.7 version, it has released some codes that work with > struts2 framework, enable parsing files with it in struts2 framework. To > improve features of struts2 multipart/form-data request, Could you consider > to integrate *fastupload* source code into struts2 framework. incurring > struts2 supports both *fastupload* and ASF commons file upload? > I can't find any reference to Struts in the codebase you provided a link to. Perhaps you could provide a reference to the Struts related code? The right approach to integration is basically what Wes originally suggested. It should be usable as a plugin. If changes need to be made to Struts to support that, you can propose those changes for consideration. If they're accepted, then people will be able to choose your fastupload as an alternative to what's there today, if they choose to do so for their application. By the way, your code is hard to check out because of the messed up repository structure, and there are also several typos even in the interface and method names. Those things detract from any confidence in the quality of your code, so you might want to clean them up. -- Martin Cooper best wishes, > Link Qian > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Examples app
On Fri, Jul 20, 2012 at 1:12 AM, Lukasz Lenart wrote: > Hi, > > What do you thinking about adding small example apps to Struts 2 ? Who will maintain them, and keep them up to date when the core framework changes? How will we ensure that they continue to represent best practices when new features or mechanisms are introduced into the framework? > I was thinking about adding some example how to use more advanced > futures of Struts 2 - mostly extension points. It would be a new Maven > module next to core / apps so on. > > Why inside the Struts 2 ? It's better to test and check if it works. > With separated project, I must build Struts 2, build project and test > it. So the RM would be responsible for manually testing all of these apps to ensure that they are working before a build could be considered ready to put to a vote? If they're "inside" S2, that would have to be true. You couldn't release if the apps were broken. Don't get me wrong - I'm all for having examples. But they need to be maintained, and that takes sustained effort over time. And as the RM for many releases of S1, I'll point out that manual testing of examples as part of every build is not a trivial task either - especially when you find that something over the last few months broke an app, nobody discovered the breakage until now, and now you can't release until you've fixed it. -- Martin Cooper > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: File upload interceptor/filter dispatcher temp file cleanup
On Thu, Jun 21, 2012 at 12:05 PM, Dave Newton wrote: > Anyone? I am just guessing, but perhaps this? http://y.ahoo.it/Qzl2h -- Martin Cooper > So far it appears as though the patch only fixed the old filter and not > those of the ng variety? > > Also, I'm wondering if we'd like to un-"ng" this, or barring that, at least > re-package to something named better and put a subclass in ng and deprecate. > > Dave > > > On Thu, Jun 21, 2012 at 6:14 AM, Dave Newton wrote: > >> Where are uploaded files currently cleaned up? >> >> The patch for WW-3490 [1] moved temp file deletion out of the interceptor >> into the dispatcher, but if the ng dispatcher is being used, when/how are >> the files deleted? I've dug a little bit and haven't seen it yet; at this >> point it's quicker to ask. >> >> Thanks, >> Dave >> >> [1] https://issues.apache.org/jira/browse/WW-3490 >> - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Redesign for Struts Showcase
On Tue, Jun 12, 2012 at 10:09 AM, Łukasz Lenart wrote: > 2012/6/11 Martin Cooper : >> And that last part is crucial. Before we head down that path, we need >> to ensure that we have at least 2 PMC members who are willing to >> maintain such a thing over the long term. Infra may provide the >> environment, but only if we're prepared to manage it over its >> lifetime. > > What kind of support is needed from our side ? You should check with infra@ directly for a definitive answer, but typically we'd need to deal with anything Java- or app-related, including restarting after a crash, diagnosing issues, addressing security issues, container upgrades, etc. -- Martin Cooper > Regards > -- > Łukasz > mobile +48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Redesign for Struts Showcase
On Fri, Jun 8, 2012 at 6:50 AM, Wendy Smoak wrote: > On Thu, Jun 7, 2012 at 11:16 AM, Johannes Geppert wrote: >> Maybe we should ask the infra team. They could provide a apps.apache.org >> server based on a apache jee server. Where different Apache Projects >> (Struts/Wicket/Tapestry/...) can run there showcases. > > We used to have the examples running in a virtual machine (a Solaris > 'zone' IIRC.) Infra provided the bare 'server' but it was the PMC's > responsibility to manage it. If there are enough volunteers to keep > it up and running you might want to check into that again. And that last part is crucial. Before we head down that path, we need to ensure that we have at least 2 PMC members who are willing to maintain such a thing over the long term. Infra may provide the environment, but only if we're prepared to manage it over its lifetime. -- Martin Cooper > -- > Wendy > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2 losing timestamp in java.util.Date when validation failed
On Wed, Jun 6, 2012 at 9:18 AM, s wrote: > > I have a form with java.util.Date (createTimestmp) and it has both date & > time. > createTimestmp is an hidden field on the form. When I fetch record from > database it has "5/17/12 12:58:33 PM.688" as value. This is a question about using Struts, and should therefore be directed to the User list. The Dev list is for discussion of the development of the Struts framework itself. -- Martin Cooper > If I change something on the form and if validation is GOOD, then > creatTimestmp value is retained to the original value. That is, its still > "5/17/12 12:58:33 PM.688". > > But if the validation fails, and user goes to input form again, then > createTimestmp value changes to "5/17/12". The timestamp is missing. > > Looks like a bug to me in struts 2. > > Why is struts 2 dropping timestamp on INPUT result...? > > Can someone please help. > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Update struts-master
On Mon, Jan 23, 2012 at 5:53 AM, Maurizio Cucchiara wrote: > Personally I did some changes in the struts master in the past which are > not yet released (I upgraded some plugin versions if I recall correctly). > So this is +1. Which is ... a vote for a vote? :-p -- Martin Cooper > Sent from my mobile device, so please excuse typos and brevity. > > Maurizio Cucchiara > > Il giorno 23/gen/2012 14.09, "Łukasz Lenart" > ha scritto: > Hi, > > A new version of Apache Master is available, number 10. I'm wondering > if we should update struts-parent to the latest version ? Maybe this > will help with archetypes issue ? > > > Regards > -- > Łukasz > http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2 Components
On Thu, Jan 26, 2012 at 3:34 AM, Christian Grobmeier
wrote:
> Last mail for today :-)
>
> Today there is a discussion on going, Tapestry vs Struts (on
> tapestry-users list). Of course people are convinced of Tapestry, and
> actually it is a great framework with huge benefits. And it is pretty
> modern. People now say (and not only there) Struts is a dinosaur.
>
> Well, what I really liked on Wicket was the idea on components. I
> think Wicket failed with it. But Tapestry did something similar, and
> there it is working. Then there is Vaading, another great framework
> supporting components.
>
> I look at Struts. I see, we can use different presentation layers here
> too. I am just not sure what other than jsp is really working. Are we
> sure JavaTemplates work? We support Sitemesh2, which is pretty
> outdated too.
>
> These days people go to Components. I have thought a while about it...
> shouldn't it be possible to use components in STruts too?
The classical distinction between styles of web frameworks is
action-oriented versus component-oriented. The two take different
approaches to the problem of building web apps, and each has its
place, depending on the goals and constraints of the app. Some people
pick one and try to use it for everything; others will pick the
appropriate tool for each job.
Since its very beginnings, Struts has been an action-oriented
framework. Over time, people have attempted to morph it into something
more component-oriented, or tried to build a component layer on top of
it. To me, that's a bit like trying to improve upon a screwdriver by
turning it into a hammer.
If you look back at the early history of JSF, you'll find the
beginnings of Apache Shale, which started out as a Struts subproject
to explore some component-oriented ideas in a Struts world. Shale was
split off from Struts because of the divergent perspectives of
action-oriented versus component-oriented developers. The project was
retired about 2 years ago, in part because many of the good ideas from
Shale were being adopted into JSF, and in part because of the
realisation that trying to morph an action-oriented framework into a
component-oriented one was an unnatural act. It made (and makes) more
sense, if you wanted a component-oriented framework, to focus on just
that, rather than bending another tool to needs for which it wasn't
designed.
Now, of course, that's not to say that there aren't ideas that might
be interesting for some people to explore, as a kind of Shale2 on top
of Struts2 (conceptually speaking). I'd just encourage you to think
carefully about why you would want to do that, rather than use an
existing component-oriented framework in a situation that warrants
that style. I'd also encourage you to think about why tens of
thousands of developers have chosen Struts as an action-oriented
framework when they too could have chosen a component-oriented
alternative if it fit their needs.
--
Martin Cooper
> We have DI
> in place, which is a good backbone for that.
>
> For example, look at this:
>
> class MyAction {
> @Inject
> MyComponent blub; // Implements StrutsComponent
> }
>
>
>
>
>
> Components might be able to return html. They can calculate. They can
> be used with JSP. Looking at this:
> http://tapestry.apache.org/component-reference.html
>
> We can learn a bit from Tapestry here. Probably we are able to reuse
> some of the components from them.
>
> I begin to think a good frontend layer would bring benefits. Otherwise
> it might happen S2 is more and more going into the direction "service
> layer", and for that it might not fit very well.
>
> What do you think?
>
> Cheers
> Christian
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: Generic Question about Struts2
On Fri, Dec 30, 2011 at 11:15 PM, Umesh Awasthi wrote: > My only point was Working on Struts2 in really Important but some time has > to be taken to let community know about it. Is there a problem? A community built up around Struts is great. If people are getting the answers they need at SO, that's great. If they're not, then they'll no doubt figure out that the User list is the right place to ask. In either case, I don't see that it really matters whether the answers are provided by Struts developers or by other members of the community. In fact, I'd prefer to see the latter, since that's a good sign of a healthy, vibrant community. The people here who work on Struts do so because they want to. They volunteer their time to scratch their itches. If showing up in SO conversations isn't part of their itch, they won't show up there. We don't do marketing or sales. -- Martin Cooper > On Fri, Dec 30, 2011 at 10:00 PM, Dave Newton wrote: > >> It's a curse! >> >> Really, I think it's just a matter of some people focus on actually >> *working* on Struts 2 instead of talking about it--I'm getting back in to >> the code base (finally) but others have been doing the real work. >> >> It's all a matter of priorities, both inside the Struts 2 world, and the >> "real" world. I like writing, talking, and thinking about stuff, other >> people prefer actually *doing* something with their time ;) >> >> Dave >> >> On Fri, Dec 30, 2011 at 11:27 AM, Steven Benitez >> wrote: >> >> > I used to be active there, but I've been busy lately. Besides, Dave is a >> > Titan on there. :) >> > >> > On Friday, December 30, 2011, Umesh Awasthi >> > wrote: >> > > Hi All, >> > > >> > > I am asking this question specifically in the dev list since i believe >> > that >> > > this is the best platform which can answer my question. >> > > Working for long on struts2 based application development and i am >> quite >> > > happy with it. >> > > >> > > On the Avg if some of us find any problem while in development one of >> the >> > > best way is to take help of Google.When i checked this out i found out >> > that >> > > SO is always coming on the top of search results. >> > > with tagging of around 2300 question its growing slowely. >> > > >> > > To my surprise i only saw one person (Dave Newton) from the Dev group >> > > active there on SO. >> > > >> > > I am not sure why other people are not so much active on the SO >> > > community,though user list if the best place but still. >> > > >> > > I asked this question out of curiosity so hope every one take it in >> right >> > > way. >> > > >> > > Thanks in advance and Happy New Year ! >> > > >> > > >> > > >> > > -- >> > > With Regards >> > > Umesh Awasthi >> > > http://www.travellingrants.com/ >> > > >> > >> > > > > -- > With Regards > Umesh Awasthi > http://www.travellingrants.com/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts 2.3.1.1 Vote (fast track)
On Wed, Dec 28, 2011 at 6:35 AM, Dave Newton wrote: > How should I vote if I can't run the tests at the moment, but I can review > the source changes? Given that the vote is on the actual bits, consider this. Suppose that somehow Lukasz's build process got completely messed up, and the zip file does nothing useful. At the same time, you reviewed the source code, not the bits, and you voted for GA. Other people did the same thing, and the end result was a "GA" release that didn't even work. -- Martin Cooper > So confused. Hmm, maybe I can run tests after all--I'll try tonight. > > On Wed, Dec 28, 2011 at 4:36 AM, Rene Gielen wrote: > >> Thanks for offering your help. If you feel like being able to test the >> binary distribution announced here and to give feedback, that is >> qualification enough :) We highly appreciate every casted vote. >> >> For details on the voting process and the difference between binding and >> non-binding votes, please see the "Decision Making" and "Voting" section >> in [1]. But remember that even though your vote will be non-binding, it >> will be taken into account by the PMC. Especially if you describe the >> reasons for your particular vote, say "Leave at test build" since you >> found a show stopper, it is likely to influence or change the PMC >> members' binding votes. >> >> - René >> >> [1] http://struts.apache.org/bylaws.html >> >> On 27.12.11 23:48, Jeffrey Black wrote: >> > Not sure whether I qualify, but I would be happy to test it for you. >> > >> > Best, >> > >> > jb >> > >> > On Tue, Dec 27, 2011 at 3:50 PM, Rainer Hermanns > >wrote: >> > >> >> Sorry, I've no time to test the short track release this time. >> >> Could someone step in? >> >> >> >> cheers, >> >> Rainer >> >> >> >> >> >> -- >> René Gielen >> http://twitter.com/rgielen >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
On Mon, Dec 19, 2011 at 2:49 AM, Rene Gielen wrote: > On Mon, 19 Dec 2011 09:35:33 +0100, Łukasz Lenart > wrote: >> Thanks for clarification but I'm still not sure if I get it right ;-) >> >> So I can start a new release process as soon I want to but it can be >> called an Alpha/Beta/GA build only because of Vote result ? I cannot >> predetermine the result and say "hey, lets release Beta1" ? > > Currently what we are doing is performing a release build - which just > means releasing in terms of technical lifecycle management, thus building > and releasing a non-SNAPSHOT version - and then announce it for > testing/voting. From our process perspective this is a release candidate. > The feedback from the vote determines what quality grade we rate it, most > notably whether we see it ready for primetime or still in Beta (or less, if > fundamentally broken). Yup. It's probably worth reiterating here that the word "release" is unfortunately imbued with two meanings. There is "release" in the Maven sense of the word, which is essentially just a way of building a package and pushing it places. And then there is "release" in the ASF sense of the (GA / Beta / Alpha) artifact that the Struts PMC is responsible for. The former sense does not imply the latter. We just happen to use the former for our build mechanics. >> >> And if during the Vote, the result is different than GA should the >> site and so on be published ? >> > > If say 2.3.2 is voted for GA quality, we announce it as GA and push it to > central. If on the other hand it would be rated as Beta, we basically don't > push it to central. Currently we are just announcing a vote result, we > *could* as well go and announce a Beta build to the lists and to > http://struts.apache.org/downloads.html (which actually contains a section > for that). The next possible GA release now is 2.3.3, because 2.3.2 is > technically released (as a Beta) and the next shot needs a new unique > version. And on it goes ... > > An important thing to remember is that we decided against version tags such > as 2.3.2-Beta-1, since this implies having to go through the whole > technical release process, including full testing, for the 2.3.2-GA > version. > > That said, what Martin referenced as the process we used to have was > basically > - performing 2.3.2 release process > - announce a Beta > - wait > - if no show-stoppers reported, cast a vote > - test, if not done in the Beta phase (!!!) > - if the vote result says GA, go for publishing Actually, no, not quite. A really, really long time ago, with early Struts 1 releases, we used to designate quality with the initial build. We got out of that bad habit quite a few years ago. The process I was referring to, which was used for later Struts 1 and earlier Struts 2 builds, was: - RM: Perform the (Maven) release process using next build number. - RM: Announce a new Test Build. - RM: Wait for about a week to give everyone a chance to download and test it. - All: Download, test, and provide feedback if appropriate. - RM: If no show-stoppers reported, start a vote thread for build quality designation. - All: Vote on quality - GA, Beta, Alpha, or just stay at test build. - RM: If the vote result is for an ASF release (i.e. not test build), update site, announce - RM: If the vote result is for GA, push to central Note that the *only* difference between the process above, and what we have been doing since we changed it, is the week-long wait to allow everyone in the community enough time to test the test build before a vote is called. Otherwise the process is identical. Really! -- Martin Cooper > If we feel that this is the better / cleaner process, we can document and > switch to it, of course. > > - René > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
2011/12/19 Łukasz Lenart : > Thanks for clarification but I'm still not sure if I get it right ;-) > > So I can start a new release process as soon I want to but it can be > called an Alpha/Beta/GA build only because of Vote result ? I cannot > predetermine the result and say "hey, lets release Beta1" ? Correct. > And if during the Vote, the result is different than GA should the > site and so on be published ? There was a discussion on another thread about what version the site should correspond to, so I won't address that here. If the result of the vote is a *release* (i.e. GA, Beta, Alpha) then we could choose to announce that on the site; however, if the result of the vote is *not* a release (i.e. the build remains a test build), then no, we shouldn't update the site. -- Martin Cooper > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
On Sun, Dec 18, 2011 at 1:58 PM, Rene Gielen wrote: > Hi, > > I'm both commenting on Martin's and Lukasz' mail - see inline > > On 18.12.11 22:35, Łukasz Lenart wrote: >> I've moved the discussion to the new thread as to not mismatch two >> different topics >> >> 2011/12/17 Martin Cooper : >>>> As a follow up, I've added one more point to the Release guide [1], is >>>> it enough ? >>> That looks fine, as long as everyone is in agreement. >>> >>> The question in my earlier message was just that - a question. The >>> answer, after digging around in the archives, appears to be yes, we >>> did stop doing that, quite some time ago, and somehow I never noticed >>> until now. As far as I can tell, we didn't make a conscious decision >>> to change; it just happened one time when somebody took on the release >>> task. Nobody noticed, and we've kept doing it that way ever since. > I cannot _remember_ that being a policy either, so without further > digging I am quite sure we're doing this for a long time now. I think > nobody noticed since our votes tended to be very lazy. It was not > unusual to have a vote casted without getting enough binding votes for > three weeks or more. >>> As for which way we do it going forward, it really depends on how >>> quickly people - PMC members especially, but not only PMC members - >>> feel they can test a new build. It is *very* important that people >>> vote, and test prior to it, based on the actual bits posted by the RM; >>> not their own build, or a recent snapshot they may have downloaded. If >>> enough people believe they can pick up a new build immediately, >>> incorporate it into their own environment, test it thoroughly, and >>> then vote, all within 72 hours, then there shouldn't be a problem with >>> continuing the way we have been. If that seems a bit tight, then we >>> should leave some time for testing before calling the vote. > I agree that taking the time for *thouroughly* testing the *actual > binary bits* is essential - everybody needs to remind that. Nevertheless > I would not see any improvement in splitting the process into a "Asking > for feedback"- and a voting-phase. The voting template is designed for > giving feedback on the build quality. If we however feel that 72h is not > enough, we might want to extend the period. That's fine too, as long as people know what to expect, and have an opportunity to chime in. What we want to avoid is something like "here's a build; vote now; done" before the people who care about it have a chance to even see the start of the thread. Not everyone can drop everything to try out a new build as soon as it's announced, and not everyone can read the list every day to ensure they don't miss a chance to participate in the process and test a build prior to release. >> I'm wondering how to proceed to release BETA1, BETA2, ..., RC1, RC2, >> , GA versions. With the current approach the name of packages must >> be specified during running mvn release:prepare command, even if we >> decide to call it Beta during a Vote it isn't possible to rename the >> artifacts, Subversion Tag and so on. And to meet the result of the >> Vote, a new mvn release:prepare command must be issued and a new Vote >> called (as we vote over the exact bits) - the whole release process >> must be started over. >> >> Do I miss something ? The build you post as an RM - the build that people download, test, and vote upon - is a test build; it's not a release yet. The vote is a vote on the quality of that test build. Depending upon the result of the vote, those bits may become a GA, Beta or Alpha release, or may not become a release at all. (Note that we do not have RC releases.) Regardless of the result of the vote, the version number doesn't change; only the designation changes. > We would in either case stick with clear and unchanged versioning and > single builds, even when introducing a testing phase before casting the > vote. So we would have announced 2.3.1 as test build, and if no clear > objections arose, cast a vote for exactly this binary to become GA or > not. So essentially, the difference for the release manager is one more > mail (announcing the test build) and some more patience (before casting > the vote). Exactly. My question was solely about the waiting period that we used to have (yes, some time ago) between announcing the availability of the test build and the start of a vote to determine the quality of that test build. > But again,
Re: Hi Urgent help needed
On Sun, Dec 18, 2011 at 11:26 AM, krishna wrote: > Hi All, > > This is krishna. We are migrating our project from Weblogic 8.1 to Jboss > 5.1.0. > > I have done all the changes and successfully generated a WAR file. > > When i deploy my WAR file in Jboss, my WAR file is getting deployed > successfuly. > > But when i run my application in jsp i getting the following errors in jsp. > > Note: http://localhost:8080/wapp - when use the following line in the IE i > getting the below errors as mentioned below in jsp. > > Please help me out. Please ask on the appropriate list. That would be the User list. There are many more people there who can help you out. The Dev list is for discussion of the development of Struts itself. -- Martin Cooper > -- > type Exception report > > message > > description The server encountered an internal error () that prevented it > from fulfilling this request. > > exception > > org.apache.jasper.JasperException: Failed to load or instantiate > TagExtraInfo class: org.apache.struts.taglib.logic.IterateTei > > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51) > > org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) > > org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:281) > > org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:415) > > org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:250) > > org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:163) > org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:429) > org.apache.jasper.compiler.Parser.parseDirective(Parser.java:491) > org.apache.jasper.compiler.Parser.parseElements(Parser.java:1438) > org.apache.jasper.compiler.Parser.parse(Parser.java:137) > > org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255) > > org.apache.jasper.compiler.ParserController.parse(ParserController.java:103) > org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:171) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:333) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:313) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:300) > > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:585) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:312) > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) > > > root cause > > java.lang.ClassCastException: org.apache.struts.taglib.logic.IterateTei > cannot be cast to javax.servlet.jsp.tagext.TagExtraInfo > > org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:413) > > org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:250) > > org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:163) > org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:429) > org.apache.jasper.compiler.Parser.parseDirective(Parser.java:491) > org.apache.jasper.compiler.Parser.parseElements(Parser.java:1438) > org.apache.jasper.compiler.Parser.parse(Parser.java:137) > > org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255) > > org.apache.jasper.compiler.ParserController.parse(ParserController.java:103) > org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:171) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:333) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:313) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:300) > > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:585) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:312) > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) > > > note The full stack trace of the root cause is available in the JBoss > Web/2.1.3.GA logs > > > > > -- > View this message in co
Re: [VOTE] Struts 2.3.1 Vote
2011/12/12 Łukasz Lenart : > 2011/12/9 Martin Cooper : >> We used to post the test build, announce it, wait for a week to give >> people some time to try it out, and then call the vote, since the vote >> is time-limited. Did we stop doing that at some point, and only give >> people 3 days (i.e. the duration of the vote) to test now? > > As a follow up, I've added one more point to the Release guide [1], is > it enough ? That looks fine, as long as everyone is in agreement. The question in my earlier message was just that - a question. The answer, after digging around in the archives, appears to be yes, we did stop doing that, quite some time ago, and somehow I never noticed until now. As far as I can tell, we didn't make a conscious decision to change; it just happened one time when somebody took on the release task. Nobody noticed, and we've kept doing it that way ever since. As for which way we do it going forward, it really depends on how quickly people - PMC members especially, but not only PMC members - feel they can test a new build. It is *very* important that people vote, and test prior to it, based on the actual bits posted by the RM; not their own build, or a recent snapshot they may have downloaded. If enough people believe they can pick up a new build immediately, incorporate it into their own environment, test it thoroughly, and then vote, all within 72 hours, then there shouldn't be a problem with continuing the way we have been. If that seems a bit tight, then we should leave some time for testing before calling the vote. -- Martin Cooper > [1] > https://cwiki.apache.org/confluence/display/WW/Building+Struts+2+-+Normal+release#BuildingStruts2-Normalrelease-Announceavailability > > > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts 2.3.1 Vote
On Fri, Dec 9, 2011 at 6:53 AM, Maurizio Cucchiara wrote: > I've been using the snapshot version for a long time now. Remember that you are voting on the *actual bits* that Lukasz posted, not a close facsimile that you might have used recently. > +1 To what? The vote is a quality vote, with 4 available choices. You need to pick the quality level that you are willing to tell the world you will stand by. :-) -- Martin Cooper > Twitter :http://www.twitter.com/m_cucchiara > G+ :https://plus.google.com/107903711540963855921 > Linkedin :http://www.linkedin.com/in/mauriziocucchiara > > Maurizio Cucchiara > > > On 9 December 2011 08:02, Łukasz Lenart wrote: > >> The Struts 2.3.1 test build is now available. >> Release notes:* [http://struts.apache.org/2.x/docs/version-notes-231.html] >> Distribution:* [http://people.apache.org/builds/struts/2.3.1/] >> Maven 2 staging repository:* >> [https://repository.apache.org/content/repositories/orgapachestruts-300/] >> Once you have had a chance to review the test build, please respond >> with a vote on its quality: >> [ ] Leave at test build[ ] Alpha[ ] Beta[ ] General Availability (GA) >> Everyone who has tested the build is invited to vote. Votes by PMC >> members are considered binding. A vote passes if there are at least >> three binding +1s and more +1s than -1s. >> The vote will remain open for at least 72 hours, longer upon request. >> A vote can be amended at any time to upgrade or downgrade the quality >> of the release based on future experience. If an initial vote >> designates the build as "Beta", the release will be submitted for >> mirroring and announced to the user list. Once released as a public >> beta, subsequent quality votes on a build may be held on the user >> list. >> As always, the act of voting carries certain obligations. A binding >> vote not only states an opinion, but means that the voter is agreeing >> to help do the work >> >> Kind regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> Warszawa JUG conference - Confitura http://confitura.pl/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts 2.3.1 Vote
We used to post the test build, announce it, wait for a week to give people some time to try it out, and then call the vote, since the vote is time-limited. Did we stop doing that at some point, and only give people 3 days (i.e. the duration of the vote) to test now? -- Martin Cooper 2011/12/8 Łukasz Lenart : > The Struts 2.3.1 test build is now available. > Release notes:* [http://struts.apache.org/2.x/docs/version-notes-231.html] > Distribution:* [http://people.apache.org/builds/struts/2.3.1/] > Maven 2 staging repository:* > [https://repository.apache.org/content/repositories/orgapachestruts-300/] > Once you have had a chance to review the test build, please respond > with a vote on its quality: > [ ] Leave at test build[ ] Alpha[ ] Beta[ ] General Availability (GA) > Everyone who has tested the build is invited to vote. Votes by PMC > members are considered binding. A vote passes if there are at least > three binding +1s and more +1s than -1s. > The vote will remain open for at least 72 hours, longer upon request. > A vote can be amended at any time to upgrade or downgrade the quality > of the release based on future experience. If an initial vote > designates the build as "Beta", the release will be submitted for > mirroring and announced to the user list. Once released as a public > beta, subsequent quality votes on a build may be held on the user > list. > As always, the act of voting carries certain obligations. A binding > vote not only states an opinion, but means that the voter is agreeing > to help do the work > > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JIRA karma for Struts project
On Tue, Dec 6, 2011 at 9:05 AM, Wes Wannemacher wrote: > I think I might have lost privileges to JIRA. I am unable to resolve > issues in the Struts 2 (WW) project. It has been a while since I tried > to close/resolve an issue, so I don't know if I wasn't paying > attention when I should have spoken up. Should be fixed now. -- Martin Cooper > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Using fluido once available
On Sun, Nov 27, 2011 at 6:04 AM, Christian Grobmeier wrote: > Hello Martin, > > On Sun, Nov 27, 2011 at 3:57 AM, Martin Cooper wrote: >> On Sat, Nov 26, 2011 at 2:51 PM, Christian Grobmeier > >>> I have added a hero section. > >> A what? > > This is the first huge section, showing what the page is about. > Like here: http://incubator.apache.org/directmemory/ > >>> Unfortunately I needed to remove the h2, h3 etc to make this work >>> because of a doxia bug. It seems it is already fixed in trunk, so I >>> think we can leave it now and replace it later. (the bug replaces h2 >>> with ... - this kills everything) >> >> I'd say the missing h2, h3, et al, is a showstopper. > > OK, then we can't use fluido now, except we add anything in sequence > (like it is today). This is terrible to read imho and so the question > is if we need to wait for a new doxia release then. The updated version you posted is better. The headings are important. Just bolding text doesn't provide for accessibility, and doesn't provide screen readers the means to navigate through the page. We need to be mindful, with a framework as popular as Struts, that we are addressing the needs of all readers, so accessibility is very important. >>> I think we should make the text somehow smaller if possible. It is >>> very much too read and probably we should just have a teaser on the >>> the various paragraphs. >> >> I disagree. The Recent Releases section needs to come back to the top, >> where it is prominent for the majority of existing users, who are >> returning for the latest update. The remainder of the page is designed >> for those new to Struts, and there needs to be enough meat right there >> on the home page to hold their interest and entice them to stay on the >> site, rather than just provide a bunch of links and hope they'll click >> on one. > > I didn't mean smaller in terms of font size, sorry for being unclear. Neither did I. :-) > Actually the "news" section is on top right and very prominent to me. > Struts has an "Announcements" page were everything is detail. This > page is pretty useless if we write nearly everything on the frontpage. > In addtion there are release notes. There are 3 different pages > containing similar information. I don't think this is good and should > be streamlined. The front page serves two sets of primary readers. Number one is the people who are looking for the latest update of the framework. That is why release notes is top and center on the existing site. Struts is so well known now that updates is *the* most needed information. Number two is introductory text for people new to Struts - just enough information for them to get oriented about the framework and understand where they need to go next. Everybody outside these two groups is on the way to somewhere else when they come to the front page. > In addition, the current "news" on the front page are from 2008 two > times and one from 2011. So... the 2008 news are not really helpful to > anybody. I would remove them or keep them on the annoucments page if > necessary. I agree with you about the 2.0.14 release. I expect it's still there just because nobody got around to removing it. The 1.3.10 release needs to stay because there are tens of thousands of people using Struts 1 in production, and they still need to be able to see what the latest release of that is, even if we think it's really old. >>> In addtion, we should use some kind of "news format". Like: >>> >>> 10.12.2001 >>> Struts 2.2.3.1 released >>> This release contains a security fix. >>> See: Release Note >>> >>> And so on. I mean: date, short headline, short content (just one >>> sentence) and the link to the release notes. >> >> For releases, that's exactly what Recent Releases is for, and that's >> why it should be at the top. Other announcements are on the >> Announcements page, linked from the menu. > > As mentioned it is on top (right). Only if you have a large screen *and* you dedicate that large screen to your browser window. See more below. > Announcements page contains only the 2011 release. And "recent > releases" cotains 2008 releases. Not very recent. See above. >>> So - what do you think abou it? >> >> I see some significant issues with the sample home page: >> >> * The dark menu bar thing at the top wraps in a weird way, and starts >> to cover up the logos, which looks really bad. (And it's not obvious >> that it's a wrapping issue unless you have enough real estate to &g
Re: Using fluido once available
On Sat, Nov 26, 2011 at 2:51 PM, Christian Grobmeier wrote: > Hello all, > > today fluido 1.0 came out. > > Here is my first draft (similar to Maurizios): > > http://code.grobmeier.de/struts-draft-v1/ > (just one page) > > I have added a hero section. A what? > Unfortunately I needed to remove the h2, h3 etc to make this work > because of a doxia bug. It seems it is already fixed in trunk, so I > think we can leave it now and replace it later. (the bug replaces h2 > with ... - this kills everything) I'd say the missing h2, h3, et al, is a showstopper. > I think we should make the text somehow smaller if possible. It is > very much too read and probably we should just have a teaser on the > the various paragraphs. I disagree. The Recent Releases section needs to come back to the top, where it is prominent for the majority of existing users, who are returning for the latest update. The remainder of the page is designed for those new to Struts, and there needs to be enough meat right there on the home page to hold their interest and entice them to stay on the site, rather than just provide a bunch of links and hope they'll click on one. > In addtion, we should use some kind of "news format". Like: > > 10.12.2001 > Struts 2.2.3.1 released > This release contains a security fix. > See: Release Note > > And so on. I mean: date, short headline, short content (just one > sentence) and the link to the release notes. For releases, that's exactly what Recent Releases is for, and that's why it should be at the top. Other announcements are on the Announcements page, linked from the menu. > So - what do you think abou it? I see some significant issues with the sample home page: * The dark menu bar thing at the top wraps in a weird way, and starts to cover up the logos, which looks really bad. (And it's not obvious that it's a wrapping issue unless you have enough real estate to resize and avoid the wrap.) There are also weird garbage artifacts when you work with this menu bar. Given that it provides no additional functionality, is very ugly, and doesn't work well, I'd recommend scrapping it. * There's a huge waste of space with just "Apache Struts" in a big font, one sentence, and two buttons. Given that this is right below both the ASF logo, at top left, and the Struts logo, at top right, this serves no function and just takes up space - and prime real estate, at that - and forces everyone to scroll to get to anything useful. * The column width does not increase as I resize my browser window. Yet I'm forced to resize the window to get the menu to render properly. * We need proper headings (as mentioned above) rather than the random first words in a section in a big bold font. Section titles are chosen for meaning. * The release information at the bottom is in a super-narrow column for no apparent reason, again forcing me to scroll unnecessarily. * The Next link, leading to the sequence running through our pages, is missing completely. * Visited links are not coloured differently from unvisited ones. Overall, it looks pretty and trendy, but actual usability has gone down the tubes and is pretty awful. I'd personally prefer to see us stick with what we have unless the usability can be brought back to at least what we have now. Usability is far more important than pretty or trendy. -- Martin Cooper > Cheers > Christian > > On Wed, Nov 16, 2011 at 6:43 PM, Maurizio Cucchiara > wrote: >> Just for the record looks like Simone has already moved out of the >> sandbox the plugin >> >> https://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin/ >> >> Anyway I would like to see a kind of refresh on struts website, you >> can count on my help. >> >> Twitter :http://www.twitter.com/m_cucchiara >> G+ :https://plus.google.com/107903711540963855921 >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara >> >> Maurizio Cucchiara >> >> >> >> On 16 November 2011 17:47, Maurizio Cucchiara wrote: >>> Hi Christian, >>> I have done some tests a couple of weeks ago, IIRC there was some >>> issue using the fluido plugin. >>> For what concern the website, consider that struts website root >>> resides, as you noticed before, belong the following path >>> http://svn.apache.org/repos/asf/struts/site/ >>> >>> Here there is the S2 website (nothing more than a single page :) ) >>> http://svn.apache.org/repos/asf/struts/struts2/trunk/src/site/ >>> >>> And the third one, is used by the Confluence export plugin (I'm pretty >>> sure, though I could be wrong) >>> >>> With that saying, I publi
Re: Options on UTF-8 Localizations
On Mon, Nov 21, 2011 at 10:20 AM, Christian Grobmeier wrote: > Folks, > > I use the property files for localization. But well, property files > are pretty limited as they can only do iso. I need UTF-8 urgently now, > because I have chinese characters at hand. What are my options? As long as you are using native2ascii, property files support CJKV. -- Martin Cooper > I have that: > > struts.i18n.encoding=UTF-8 > > > but it doesn't help. I need to use \u format but of course this > would mean my sudden death when I need to find out all the chinese > stuff in unicode. > > I have never seen a xml resource bundle which would support utf-8. > > Any ideas? I am willing to write something myself if necessary, just > need a starter. > And while we are at it, why is a property file still the default and not xml? > > Cheers > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Deprecate 2.1 version
On Tue, Oct 18, 2011 at 4:12 AM, Rene Gielen wrote: > Am 18.10.11 00:45, schrieb Łukasz Lenart: >> 2011/10/18 Rene Gielen : >>> We made "Struts 2" a brand, the basic question seems to be - do we want >>> to rebrand or not? If we do rebrand, I think the logical way is to call >>> it "Struts 3". But we have to be aware that this causes some other >>> problems. Is a Struts 2 book good for learning Struts 3 (yes, not >>> comparable to Struts 1 vs. Struts 2). What do people find at Google? >>> Will they search for Struts 3, Struts 2 or both to find useful >>> information (a lot of information for Struts 2 will still apply for 3). >>> Do we need new Logos? And there is even more if you dig deeper, I guess. >> Struts 3 version 1.0.0.1 ;-) > No, actually Struts 3 3.0.1.1 :) > > As I already said, I believe that if we counted right, we had already > 3.1.x, upcoming would be 4.0.x - but starting from major three, we > should IMO stay with consistent versioning following the said scheme. >> Maybe just keep the brand Struts and distinct them base on version >> number ? This follow the MAJOR.MINOR schema. > Basically I'm with you on that. Most likely though, after releasing a > Struts 3.0.0, people will coin the short term "Struts 3" within days. > > Also the problems mentioned in my last mail still remain - we once > searched a way to distinct two different frameworks, namely Struts 1 vs. > Struts 2. Struts 3.x will be in the Struts 2 framework line, and we will > have to make this clear to users. Buying a Struts 1 book is no good for > 3.x, Struts 2 is. Googling for Struts is bad, googling for Struts 2 is > not. Is the "Struts power 2" logo retired and will it be replaced by > just the good old Struts logo (also applies to the > WebWork+Struts=Strusts 2 icon)? And so on... - we should try to think > about all this beforehand and be very clear and well decided about our > communication and branding. René is right, there's a great deal involved in the apparently simple act of moving from 2 to 3. Back in mid-2005, when the discussions around the next generation of Struts were just getting underway, we called it Struts Ti (for Titanium). That let us get on with making the much more important technical decisions before we hashed out what the heck to call the thing, and why. Eventually we called it Struts 2, but that was as much a branding decision as anything else; it's not clear that was the right decision, either, looking back on it now. A naming change from Struts 2 to Struts 3, Struts NG or basically anything that's no longer Struts 2 will send a signal to the community that the changes are of the same magnitude as those between Struts 1 and Struts 2. That is, it's not compatible, and it's not clear that it's the same framework, but we like the Struts name too much to give it up. My feeling is that we shouldn't make such a decision without very careful thought to all of the implications, large and small, as René has suggested. -- Martin Cooper > - René > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Deprecate 2.1 version
On Wed, Oct 12, 2011 at 12:59 AM, Maurizio Cucchiara wrote: > Hi guys, > As René pointed out (see http://s.apache.org/2hn) we should seriously > take into consideration to deprecate 2.1.x version. > Another thing that I have just noticed is about the full releases > present on the download page (http://s.apache.org/GFV): why there is a > 2.0 version and not a 2.1? > We are going to release 2.3, so I think is the right time to afford this > topic. > > I guess we should open up a vote. Other than for some procedural things for which they are required (e.g. releases), we shouldn't need a vote for anything unless we can't come to consensus / agreement on it. In this case, we just need to discuss it, and if everyone agrees, do it. -- Martin Cooper > Twitter :http://www.twitter.com/m_cucchiara > G+ :https://plus.google.com/107903711540963855921 > Linkedin :http://www.linkedin.com/in/mauriziocucchiara > > Maurizio Cucchiara > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Move deprecated plugins to archive
On Thu, Jun 30, 2011 at 4:12 AM, Johannes Geppert wrote: > What about further development as a plugin outside of the Struts Project? > We can create a project at Google Code or Github like the jQuery Plugin. Who is "we"? If "we" is a group of Struts committers, why would "we" take the code somewhere else, rather than working on it where it is now? If "we" isn't Struts committers, then they can take the code and do what they will with it, under the terms of the Apache License. The caveat in the latter case is if there is an intent to bring the code back to the ASF later. In that case, there just needs to be an assurance of code provenance when it comes back (e.g. an iCLA mechanism), and then it would need to go through a software grant or some such process to bring it back in. Before someone goes off and creates a separate project, though, it'd be interesting to hear why we think contributors will appear if the project is elsewhere, when they have not done so here for the last several years. (Or am I mistaken and we do have patches attached that are not being applied?) -- Martin Cooper > Johannes > > - > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep > -- > View this message in context: > http://struts.1045723.n5.nabble.com/Move-deprecated-plugins-to-archive-tp4528259p4538454.html > Sent from the Struts - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JIRA Wiki syntax
On Thu, Jun 30, 2011 at 3:25 AM, Lukasz Lenart wrote: > So, how can change that ? I can't do anything about adjusting Dave's level of smartness or dumbness. Sorry about that. :P > Do we have a JIRA admin in our team ? I have admin, yes. I *think* I have enabled wiki comments. The UI is pretty confusing, though, so please check. It seems to want to do a reindex now, but it also says that will make JIRA unavailable to everyone, so now doesn't seem like the best time. -- Martin Cooper > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > > 2011/6/27 Dave Newton : >> So I proved myself wrong when I was right? >> >> Does that make me smart, or dumb?! >> >> On Mon, Jun 27, 2011 at 7:32 AM, Lukasz Lenart >> wrote: >>> My mistake, I've been thinking about Confluence :P >>> >>> Struts is using the same instance as Ognl, so it must be per project option. >>> >>> >>> Regards >>> -- >>> Łukasz >>> + 48 606 323 122 http://www.lenart.org.pl/ >>> Warszawa JUG conference - Confitura http://confitura.pl/ >>> >>> >>> 2011/6/27 Dave Newton : >>>> I was wrong; just checked the JIRA docs. >>>> >>>> http://confluence.atlassian.com/display/JIRA041/Configuring+Rich-Text+Renderers#ConfiguringRich-TextRenderers-ConfiguringRenderers >>>> >>>> (That might be the wrong version, though.) >>>> >>>> Sorry! >>>> >>>> Dave >>>> >>>> On Mon, Jun 27, 2011 at 7:15 AM, Lukasz Lenart >>>> wrote: >>>>> I don't see such option in Admin view (space and JIRA), could you >>>>> point me where can it be ? >>>>> >>>>> >>>>> Regards >>>>> -- >>>>> Łukasz >>>>> + 48 606 323 122 http://www.lenart.org.pl/ >>>>> Warszawa JUG conference - Confitura http://confitura.pl/ >>>>> >>>>> >>>>> 2011/6/27 Dave Newton : >>>>>> I don't know which for the renderer. I /think/ project, but don't >>>>>> recall... >>>>>> >>>>>> Dave >>>>>> On Jun 27, 2011 7:02 AM, "Maurizio Cucchiara" >>>>>> >>>>>> wrote: >>>>>>> Hi Dave, >>>>>>> do you mean JIRA admin (INFRA team) or JIRA project (Struts) admin? >>>>>>> >>>>>>> On 27 June 2011 12:57, Dave Newton wrote: >>>>>>>> Yep, the renderer is configurable; I think you need to be a JIRA admin >>>>>>>> to >>>>>> do >>>>>>>> it, but don't recall. (I actually brought this up several years ago, >>>>>> IIRC; I >>>>>>>> like having markup available.) >>>>>>>> >>>>>>>> Dave >>>>>>>> On Jun 27, 2011 6:23 AM, "Maurizio Cucchiara" >>>>>>>> wrote: >>>>>>>>> Hi everybody, >>>>>>>>> I've realized that the JIRA instance of Struts project allows only >>>>>>>>> comments in plain text format. >>>>>>>>> On the contrary the OGNL instance is able to handle comments in wiki >>>>>>>> format. >>>>>>>>> Looking the footer, it looks like is the same JIRA instance >>>>>>>>> (v4.3.4#620-r15266), so I'm wondering why we can't use wiki syntax >>>>>>>>> (maybe it's just a simple matter of configuration). >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Maurizio Cucchiara >>>>>>>>> >>>>>>>>> - >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Maurizio Cucchiara >>>>>>> >>>>>>> - >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>>>> >>>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>> >>>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Move deprecated plugins to archive
On Mon, Jun 27, 2011 at 6:35 AM, Lukasz Lenart wrote: > Do we need a Vote for that as well ? Good question. As far as I recall, and as far as I can determine, previous moves to the archive have been by lazy consensus. Thus as long as nobody's objecting here, we can go ahead and do the same thing. IMHO, as long as we have at least one regular dot release in which something is deprecated, it's reasonable to remove it in a subsequent dot release. -- Martin Cooper > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > > 2011/6/27 Dale Newfield : >> On 6/27/11 9:02 AM, Johannes Geppert wrote: >>> >>> What you all think about moving deprecated plugins to archive for the 2.3 >>> release? >> >> And the Dojo plugin... >> >> -Dale >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Portlet 2.0 Plugin was moved to trunk
On Fri, Jun 24, 2011 at 12:44 AM, Rene Gielen wrote:
> Great work, Johannes!
>
> The only thing that concerns me a bit is that we seem to have lost the
> commit history of the new plugin, since you have applied the sandbox
> sources as patch to the current plugin. The history how p1 mutated to p2
> is imo important ...
Ouch. You are right, keeping the history is important. If we can go
back and address this, I would suggest that we do that.
--
Martin Cooper
> How do others feel about this? It's not too late to revert this to a move.
>
> - René
>
> On 23.06.11 23:24, Johannes Geppert wrote:
>> Hi Guys,
>>
>> I have copied the latest version of the Portlet 1.0 Plugin to the archive
>> and replaced the version in trunk with the sandbox version. Also i have made
>> same small changes on the Portlet Sample App which is running fine in
>> jetspeed for me with the new portlet plugin version.
>>
>> I have only one Problem in Test PortletRequestMapTest in Method
>> testEntrySet()
>>
>> public void testEntrySet() {
>> MockPortletRequest request = new MockPortletRequest();
>> request.setAttribute("testAttribute1", "testValue1");
>> request.setAttribute("testAttribute2", "testValue2");
>>
>> PortletRequestMap map = new PortletRequestMap(request);
>> Set entries = map.entrySet();
>>
>> //TODO Why is Entry Size 3?
>> assertEquals(2, entries.size());
>> Iterator it = entries.iterator();
>> Map.Entry entry = (Map.Entry)it.next();
>> checkEntry(entry);
>> entry = (Map.Entry)it.next();
>> checkEntry(entry);
>>
>> }
>>
>> The Test runs into Failure because the entries.size() == 3 ?!?
>> This Test runs in the Sandbox version. Has anyone an Idea or Suggestion?
>>
>> Johannes
>>
>> -
>> web: http://www.jgeppert.com
>> twitter: http://twitter.com/jogep
>> --
>> View this message in context:
>> http://struts.1045723.n5.nabble.com/Portlet-2-0-Plugin-was-moved-to-trunk-tp4519115p4519115.html
>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>> For additional commands, e-mail: dev-h...@struts.apache.org
>>
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)163-2844164
> http://twitter.com/rgielen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: Java5 test issues on xwork-core, it passes in Java6
On Tue, Jun 14, 2011 at 4:08 AM, Lukasz Lenart wrote: > Just point here, we decided that the best option is to make a new Ognl > release from GitHub source code with Maurizio's patch and number it > 3.0.2. Huh? OGNL is in incubation. The source needs to be in ASF Subversion, as imported from OpenSymphony subversion with full history and provenance. I'd be exceedingly surprised if the mentors have signed up for an ASF incubation release from Github source. Can you point us to a discussion of where this discussion happened? It seems to me that this will sink any chances of a successful short term incubation. That's very bad. -- Martin Cooper > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Warszawa JUG conference - Confitura http://confitura.pl/ > > > 2011/6/8 Lukasz Lenart : >> We should ask on OGNL PMC list if we can do that ... >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> Warszawa JUG conference - Confitura http://confitura.pl/ >> >> >> >> 2011/6/8 Maurizio Cucchiara : >>> OK, I get the point... Frankly, at first glance it looked very familiar >>> >>> It's not struts' fault, rather OGNL is the responsible of this issue [1]. >>> This patch [2] solves the problem, but we will face a different >>> problem: this time we have a patch before, but we have not a place >>> where we can apply it. >>> >>> Lucasz, is there a chance to release the 3.0.2 version of OGNL? >>> >>> [1] >>> https://issues.apache.org/jira/browse/OGNL-9?focusedCommentId=13034888&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13034888 >>> [2] >>> http://svn.apache.org/viewvc/incubator/ognl/trunk/src/main/java/org/apache/commons/ognl/OgnlRuntime.java?r1=1103138&r2=1104581&diff_format=h >>> >>> On 7 June 2011 18:36, Maurizio Cucchiara >>> wrote: >>>> and the sad thing that is not yet finished :) >>>> >>>> On 7 June 2011 18:27, Jason Pyeron wrote: >>>>>> -Original Message- >>>>>> From: Maurizio Cucchiara >>>>>> Sent: Tuesday, June 07, 2011 11:41 >>>>>> To: Struts Developers List >>>>>> Subject: Re: Java5 test issues on xwork-core, it passes in Java6 >>>>>> >>>>>> Jason, >>>>>> we are going to know very soon :) >>>>> >>>>> Huston, >>>>> >>>>> We have a problem. >>>>> >>>>> https://builds.apache.org/job/Struts2/312/org.apache.struts.xwork$xwork-core/ >>>>> >>>>>> >>>>>> On 7 June 2011 17:37, Jason Pyeron wrote: >>>>>> >> -Original Message- >>>>>> >> From: Jason Pyeron [mailto:jpye...@pdinc.us] >>>>>> >> Sent: Tuesday, June 07, 2011 11:35 >>>>>> >> To: 'Struts Developers List' >>>>>> >> Subject: RE: Java5 test issues on xwork-core, it passes in Java6 >>>>>> >> >>>>>> >> > -Original Message- >>>>>> >> > From: Lukasz Lenart >>>>>> >> > Sent: Tuesday, June 07, 2011 11:27 >>>>>> >> > To: Struts Developers List >>>>>> >> > Subject: Re: Java5 test issues on xwork-core, it passes in Java6 >>>>>> >> > >>>>>> >> > It should pass base on Java 5. It's strange, Jenkins [1] >>>>>> >> runs Struts 2 >>>>>> >> > build on JDK 5 >>>>>> >> > >>>>>> >> > [1] https://builds.apache.org//view/S-Z/view/Struts/job/Struts2/ >>>>>> >> >>>>>> >> >>>>>> https://builds.apache.org/view/S-Z/view/Struts/job/Struts2/lastBuild/ >>>>>> >> >>>>>> >> Module Builds >>>>>> >> XWork: Core (didn't run) >>>>>> >> Webapps 2.1 sec >>>>>> > >>>>>> > ??? Ignore me, it was listed at the bottom too >>>>>> > >>>>>> https://builds.apache.org/view/S-Z/view/Struts/job/Struts2/las >>>>> tBuild/org.apache. >>>>>> > struts.xwork$xwork-core/ >>>>>> > >>>>>> > But as Maurizio says jenkins is still running on
Re: Unit test error for xwork-core in trunk
On Wed, Jun 1, 2011 at 6:41 PM, Dave Newton wrote: > On Wed, Jun 1, 2011 at 9:27 PM, Maurizio Cucchiara wrote: >> [...] relocate the opensymphony dtds in the meanwhile [...] > > Relo and announce, sure. > > An Atlassian guy shows up in the whois, should we reach out? To Mike? Sure, why not. Also to Patrick (emeritus Struts guy). -- Martin Cooper > Dave > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Replace the current Portlet Plugin with Sandbox Version
It is very important to recognise that two different steps are required to accomplish what you want here. 1) The promotion of anything out of the sandbox requires a vote. Thus, formally speaking, it is not possible to vote on the current topic, because we cannot include the sandbox version of the plugin in a release. The plugin must be promoted out of the sandbox before it can replace the current plugin. 2) Once the sandbox plugin has been promoted such that it _could_ become part of a release, there needs to be either consensus or a vote to include it as part of what we intend to release. Note that this does not _require_ a vote; consensus is sufficient. (Of course, a vote will be required later for the release itself, but that's just a normal release vote.) This vote needs to be recast first as a vote to promote out of the sandbox. Once that is done and has passed, either a second vote can be started for replacing the existing plugin, if there might be contention, or - more likely in this case, I believe - a proposal / discussion thread can be started to ensure that there is consensus to do so. -- Martin Cooper On Sun, May 29, 2011 at 11:47 PM, Johannes Geppert wrote: > The version in the Sandbax is based on JSR286 and except the Portlet event > handling feature complete. > The event feature is isolated and may be delivered later. > > https://issues.apache.org/jira/browse/WW-3620 > > +1 > > Johannes > > - > > -- > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep > -- > View this message in context: > http://struts.1045723.n5.nabble.com/VOTE-Replace-the-current-Portlet-Plugin-with-Sandbox-Version-tp4438472p4438472.html > Sent from the Struts - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Karma Upgrade
On Fri, May 27, 2011 at 5:15 AM, Jeff Black wrote: > Good day. > > Per the Struts 2 documentation I am respectfully requesting a "Karma Upgrade" > to my Confluence account granting me permission to contribute to the Struts 2 > documenation. > Done. -- Martin Cooper > I filed a CLA during the Summer of 2010. > > If you have any questions, comments, or observations please contact me. > > Jeffrey Black > jeffrey.bl...@yahoo.com - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java
On Wed, May 4, 2011 at 9:32 PM, Lukasz Lenart
wrote:
> Hi,
>
> I've removed the parts where concatenating was over constants -
> constant message plus constant as a string. I'm pretty sure that the
> modern JIT compilers would optimize that as well. And the code is more
> readable IMHO.
> Another thing, debug(), info(), etc checks if the given log level is
> set up or not and then performs logging (IO request, sending e-mail,
> etc). So, it will not affect performance as well (except if there is a
> bug ;-) )
Not true. In order to call the method in the first place, all of the
arguments must be evaluated.
If you do this, the expensive function will _always_ be invoked,
whether 'info' level logging is enabled or not:
log.info("And the answer is: " + doSomethingExpensive());
However, if you guard it, like this, the expensive function is _only_
evaluated when the guard is passed:
if (log.isInfoEnabled()) {
log.info("And the answer is: " + doSomethingExpensive());
}
The usual argument I've seen for getting rid of the guards is that
most of the calls don't do anything expensive, so there's little
reason to guard them. However, it's far too easy for someone else to
come along later and modify the log message without thinking about it
perhaps now needing a guard, because it's now more expensive than it
used to be. Better, then, to always guard rather than kill performance
later by accident.
--
Martin Cooper
> I agree, if we're using more complicated statements, we should
> consider to use or not logging gates, but it shouldn't be a common
> pattern. Maybe less logging would be better instead.
>
> I'm thinking to remove some other parts, like this for example:
>
> LOG.info("[findBeanManager]: Checking for BeanManager under JNDI key "
> + CDI_JNDIKEY_BEANMANAGER_COMP);
>
> It's just a useless information, by spec (CDI and Weld), BM have to be
> under two keys and if we've checked both and didn't find it, we should
> log message like this:
>
> LOG.error("Could not get BeanManager from JNDI context, checked under
> ["+CDI_JNDIKEY_BEANMANAGER_COMP+"] and
> ["+CDI_JNDIKEY_BEANMANAGER_APP+"], e);
>
> From a user perspective this's the most informative message.
> Performance shouldn't be the only factor here.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
> Warszawa JUG conference - Confitura http://confitura.pl/
>
>
> 2011/5/3 Rene Gielen :
>> Lukasz,
>>
>> why were you removing the logging gates, aka the if blocks around log
>> statements? I agree that for simple String parameters (without
>> concatenation) they might be left out, but for everything else they
>> really help a lot for performance - that's why I use them in general.
>>
>> We should even consider reviewing S2 code if there are more unguarded
>> log statements, to squeeze out the last bit of performance :)
>>
>> See also http://logging.apache.org/log4j/1.2/faq.html#a2.3
>>
>> - René
>>
>> On 01.05.11 16:29, lukaszlen...@apache.org wrote:
>>> Author: lukaszlenart
>>> Date: Sun May 1 14:29:02 2011
>>> New Revision: 1098322
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1098322&view=rev
>>> Log:
>>> Removes unnecessary checking for log level and uses ConcurrentHashMap
>>> instead of HashMap
>>>
>>> Modified:
>>>
>>> struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java
>>>
>>> Modified:
>>> struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java
>>> URL:
>>> http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java?rev=1098322&r1=1098321&r2=1098322&view=diff
>>> ==
>>> ---
>>> struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java
>>> (original)
>>> +++
>>> struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java
>>> Sun May 1 14:29:02 2011
>>> @@ -23,14 +23,14 @@ import com.opensymphony.xwork2.ObjectFac
>>> import com.opensymphony.xwork2.util.logging.Logger;
>>> import com.opensymphony.xwork2.util.logging.LoggerFactory;
>>>
>>> +import javax.enterprise.context.spi.CreationalContext;
>>> import javax.enterprise.inject.spi.BeanManage
[ANNOUNCE] New Struts PMC Chair - René Gielen
After six years, I've elected to step down as Chair of the PMC, and pass the torch to someone else. The Struts PMC recommended to the ASF Board that René Gielen be appointed to this position as my replacement, and the Board has approved that recommendation. Please welcome René as the new Struts PMC Chair. Congratulations, René! -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Is it preferable to file tickets or report doc issues here?
If you click Home from where you're looking, you'll land up at: http://struts.apache.org/2.x/docs/home.html In particular, see where is says "Have a suggestion, correction, or improvement?". -- Martin Cooper On Sat, Apr 9, 2011 at 12:03 PM, Jason Pyeron wrote: > Is it preferable to file tickets or report doc issues here? > > Ex: on http://struts.apache.org/2.x/docs/action-configuration.html the link to > http://www.planetstruts.org/struts2-mailreader/Welcome.do is bad. > > -Jason > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron PD Inc. http://www.pdinc.us - > - Principal Consultant 10 West 24th Street #100 - > - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > This message is copyright PD Inc, subject to license 20080407P00. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Build failed in Jenkins: Struts2 #285
On Fri, Mar 25, 2011 at 8:42 AM, Wendy Smoak wrote: > On Fri, Mar 25, 2011 at 8:53 AM, Apache Hudson Server > wrote: >> See <https://hudson.apache.org/hudson/job/Struts2/285/> >> >> -- >> Started by user lukaszlenart >> Building remotely on ubuntu1 > ... > > Are these supposed to be coming to the dev list? I thought we had a > separate list for automated messages. Confluence notifications go to the commits@ list. We could do the same with these. -- Martin Cooper > Hm. Looking at http://mail-archives.apache.org/mod_mbox/ , apparently > not. (I was expecting notifications@ which we have on some other > projects I'm on.) > > -- > Wendy > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts2 dojo
Please move this thread to the user list. Thanks. -- Martin Cooper On Fri, Mar 11, 2011 at 4:17 AM, Johannes Geppert wrote: > > How looks your filter configuration? > Do you have the filter configured only for *.action > or also for the reccources? > > Johannes > > > steev-dev wrote: >> >> >> >> Johannes Geppert wrote: >>> >>> Do you have included the tag in your head area? >>> >>> Johannes >>> >>> >>> >>> steev-dev wrote: >>>> >>>> I'm new in struts 2 in my form i use the Datetimepicker and >>>> autocompleter components in Struts2 dojo-plugin-2.2.1.1. my problem is >>>> when I execute my project in tomcat these components dosnt appear in the >>>> display. then i used firebug Under firefox to discover the error so i >>>> have error: djConfig.searchIds is undefined and >>>> Uncaught TypeError: Can not call method 'push' of undefined >>>> please help me? >>>> >>>> >>> >>> >> >> yes i have included >> but i have error : Uncaught ReferenceError: dojo is not defined >> > > > - > --- > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep > > -- > View this message in context: > http://old.nabble.com/struts2-dojo-tp31123840p31124534.html > Sent from the Struts - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: A new release
On Mon, Jan 31, 2011 at 10:52 PM, Lukasz Lenart wrote: > 2011/1/31 Paul Benedict : >> He he.. I'll give you the answer that I got whenever I wanted to do "beta" >> releases. Votes determine the quality of the release, not the version label. >> So 2.2.2 could be production if it's voted that way. When you put out your >> vote, ask: >> >> [ ] GA >> [ ] Beta >> [ ] Alpha >> >> If it's GA, it's production. Otherwise, beta can be published too. Alpha >> will just stay a developer build. > > It's quite uncommon, thanks Paul :-) Actually, it's not. If you look around even just the ASF, you'll find that a number of the best-known ASF projects use this same scheme. In fact, we didn't invent it, we adopted it from those projects. -- Martin Cooper > > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Kapituła Javarsovia http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: A new release
On Thu, Feb 17, 2011 at 7:35 AM, Lukasz Lenart wrote: > 2011/2/17 Wendy Smoak : > Yep, that's the one of the reasons I have, another is that we fixed 41 > bugs of total 50 assigned to 2.2.2 version. The most important are > done, the rest is related to JSONPlugin (not everyone uses) or > development improvement. Few users requested a new release, especially > that the most important bugs are done. So I can just postpone those > bugs and prepare a new release or start a new thread about changing > labeling. Hmmm preparing a new release will be faster ;-) Yup, especially since you will find me *extremely* hard to convince. :-) > Besides it's more about promoting a release. I was asking about that > sometime ago. It would be great to promote Betas or RCs without > calling for a Vote. There is no such thing as a release without a vote. Every release must be voted on by the PMC, no exceptions. It doesn't matter how it's labeled. Just to be clear, we start by building what we call a Test Build, with the latest 3-part number. That Test Build is made available to developers (i.e. dev@ only). After it's been available for long enough that people have had a chance to determine how stable it is, we vote on whether it should become a Beta release, a GA release, or not a release at all. As Wendy has implied, we vote on actual bits. That means that if we had created a build as an RC, we would need to vote on it to release the RC, and if everyone thought it was good enough to be GA, we would need to re-roll the release with the new name (i.e. not RC now), and vote on it *again*, because the bits are different. I don't think that's what you want. Having been Release Manager for about a dozen releases of Struts over the years (not counting test builds that didn't make releases), including through the transition from the old scheme to the new one, I can tell you, you don't want to go back. -- Martin Cooper > I was looking for that discussion about labeling but didn't find, > could you help and point to the right direction ? Maybe it was on PMC > group ? > > > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Kapituła Javarsovia http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JIRA - can't edit issues anymore
On Mon, Jan 31, 2011 at 10:40 PM, Paul Benedict wrote: > I may have lost some permissions. I should be able to edit any STR issue. > Who do I contact to get this back? Us. :-) It looks like there were two issues - one with the groups you were assigned to, and one with the project roles for Struts 1. I've fixed both, so you should be all set. -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Volunteers page
On Thu, Jan 27, 2011 at 10:01 PM, Maurizio Cucchiara wrote: > Some things are never easy as they seem :) > Upgrading the site plugin to 2.2 is worth it: > * it includes some cool stuff like chmod parameter, etc > * it generates a more clean and reliably html code (compare [1] and > [2] "how to create a patch", perhaps the right title should be "how to > create a patch in this way" :) ) > > Things that I changed: > * I removed the ApacheCon logo, I think it's been a long time since > November (furthermore my firefox showed it in a wrong way). I have a vague recollection that the ApacheCon logo addition / removal was supposed to happen automagically, driven by the concom people. Given that it's still there, either my memory is faulty, we didn't adopt whatever was supposed to give them control, or they (concom) forgot or changed their minds about it. Anyway, taking it off is fine with me. > * I also noticed that the date format on left-top page is changed, but > I think it sounds like a plugin-improvement, doesn't it?. It looked like the default has been changed to the ISO standard date format. That's fine. > * Another thing I realized is that the nightly build section [3] > contains a broken link. There is a dedicated bash script [4], but it > is a 4 years old script, it is almost ready to go to primary school. I > could take a look at this and try to rearrange it, but what do you > think if we drive the user to latest build on hudson? Ah, the nightly build is probably the one that used to run on the helios zone, which no longer exists (and hasn't for a while). We could point to Hudson if we think we need to make such builds available, or we can just let folks build it themselves. (These days, with Maven, that's not a big deal, IMO; it was a serious pain back in the early 1.x days, with the Ant builds.) > Anyway I published the new version of the struts website on my publilc > html folder [6] please take a look and let me know if there is > something wrong. I took a quick look, and it seems okay to me. -- Martin Cooper > Over and out. > > [1] http://struts.apache.org/helping.html#patches > [2] http://people.apache.org/~mcucchiara/site/helping.html#patches > [3] http://struts.apache.org/dev/builds.html#NightlyBuilds > [4] > http://svn.apache.org/viewvc/struts/maven/trunk/scripts/nightly/nightly-2.0.x.sh?view=log > [5] > https://hudson.apache.org/hudson/job/Struts2/org.apache.struts$struts2-assembly/lastBuild/ > [6] http://people.apache.org/~mcucchiara/site/index.html > On 27 January 2011 21:30, John Lindal wrote: >> Rather than deleting it, I moved /volunteers.html to my home directory, just >> in case somebody really still wants it. Not sure how long it takes for the >> change to be visible. >> >> John >> >> >> On 1/26/11 9:11 PM, "Maurizio Cucchiara" >> wrote: >> >> There should be no problem to delete it. We have to take care only of >> two pages according to google [1] >> I have already updated the announcement one. I also upgraded the site >> plugin, from now it won't ignore paragraph format (take a look at the >> differences between [2] and [3]). >> Does anyone know if mvn site:deploy goal works? are there any side >> effects (like file system permissions)? >> or I have to deploy by hand? >> >> [1] >> http://www.google.it/search?as_lq=http%3A%2F%2Fstruts.apache.org%2Fvolunteers.html&hl=it&btnG=Cerca >> [2] http://struts.apache.org/volunteers.html#craigmcc >> [3] http://struts.apache.org/dev/volunteers.html#craigmcc >> On 27 January 2011 04:33, Martin Cooper wrote: >>> On Wed, Jan 26, 2011 at 7:03 PM, Maurizio Cucchiara >>> wrote: >>>> What do you think if we simply replace the old page with a symlink which >>>> points to the update version? >>> >>> I see no reason to do that. It's an old, obsolete page, in the wrong >>> location. The location also predates the ASF requirement that dev >>> pages live only within the dev section of the site. >>> >>> Let's just maintain the site we actually want instead of preserving >>> cruft just because it's there. >>> >>> -- >>> Martin Cooper >>> >>> >>>> Maurizio Cucchiara >>>> >>>> On Jan 26, 2011 8:08 PM, "John Lindal" wrote: >>>> Google lists only 4 pages that link to the old /volunteers.html: >>>> >>>> >>>> http://www.google.com/search?q=link:http://struts.apache.org/volunteers.html&hl=en >>>> >>>> If nobody objects, I'll go ahead and delete i
Re: Volunteers page
On Wed, Jan 26, 2011 at 7:03 PM, Maurizio Cucchiara wrote: > What do you think if we simply replace the old page with a symlink which > points to the update version? I see no reason to do that. It's an old, obsolete page, in the wrong location. The location also predates the ASF requirement that dev pages live only within the dev section of the site. Let's just maintain the site we actually want instead of preserving cruft just because it's there. -- Martin Cooper > Maurizio Cucchiara > > On Jan 26, 2011 8:08 PM, "John Lindal" wrote: > Google lists only 4 pages that link to the old /volunteers.html: > > > http://www.google.com/search?q=link:http://struts.apache.org/volunteers.html&hl=en > > If nobody objects, I'll go ahead and delete it. > > I tried building the site from source, but it gave me errors, so I'll leave > that alone :) > > Thanks, > John > > > > On 1/25/11 9:03 PM, "Martin Cooper" wrote: > > Hmm. The first one is very old (l... > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Volunteers page
Hmm. The first one is very old (last published 15 Nov 2009), and at least after a quick look, appears to have no counterpart in Subversion any more, so it is quite probably an orphan page left over on the web server from a site re-org some time ago. How did you reach it? Unless we have incoming links to it from pages that are part of the site in Subversion, I'd say we should simply delete that page on the web server. With regard to updating volunteers.xml, as chair I generally add and remove people as they come and go. I've been remiss in doing so recently, though (as Maurizio and you have both noticed - sorry). The corresponding .html files are generated by the Maven site build. I'm not sure what our current status is for that site getting deployed by Maven, but it can be done by uploading and exploding the output from the build, if that's not working. -- Martin Cooper On Tue, Jan 25, 2011 at 10:58 AM, John Lindal wrote: > Currently, there are two different versions: > > http://struts.apache.org/volunteers.html > http://struts.apache.org/dev/volunteers.html > > The first one is clearly out of date, because the second one matches what is > in subversion. > > Should I add a redirect in .htaccess to point /volunteers.html to > /dev/volunteers.html? > > Also, is there a process for updating /dev/volunteers.html? Or do I just do > it manually, from the results of mvn site? > > Thanks, > John > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Code donation
On Wed, Dec 29, 2010 at 9:37 AM, Paul Benedict wrote: > That was my question, in a way, with the guy who wanted to donate a Chinese > translation of the user guide. I thought the CLA was only necessary for > someone gaining write access -- whether to SVN or the Wiki. The CLA is not only for write access. In fact, it's not even really related to write access. See the explanation here: http://www.apache.org/licenses/#clas In this particular case, the first question seems to be whether or not we believe the plugin needs to become part of the S2 core. The contributor believes so, but I haven't seen any opinions from the Struts developers one way or the other. If we don't believe it _needs_ to be part of the core, then we need do nothing, since it can stand just as well on its own as a 3rd party plugin. If we do believe it needs to be part of the core, then my preference would be to have the contributor complete a software grant. See: http://www.apache.org/licenses/#grants This isn't so much because of the size of the contribution (it's small) as it has to do with it being an identifiable entity in and of itself. Thus I'd prefer to see the "paper trail" reflect the donation explicitly. -- Martin Cooper > In the end, I > told him just to create a JIRA ticket and attach his stuff and I would > patch. > > Paul > > On Wed, Dec 29, 2010 at 11:32 AM, Rene Gielen wrote: > >> Good question. I'm still not sure at which point we'd need a CLA filed for >> donations. Who could enlight us here? >> >> - René >> >> >> "Lukasz Lenart" schrieb: >> >> >Hi, >> > >> >Attaching a patch with the whole project [1] is sufficient to be >> >treated as a code donation? >> > >> >[1] https://issues.apache.org/jira/browse/WW-3541 >> > >> > >> >Regards >> >-- >> >Łukasz >> >+ 48 606 323 122 http://www.lenart.org.pl/ >> >Kapituła Javarsovia http://javarsovia.pl >> > >> >- >> >To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> >For additional commands, e-mail: dev-h...@struts.apache.org >> > >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts 2.2.1.1
The NOTICE file in the root of the distro needs a copyright update. Right now it says "Copyright 2000-2007". Other NOTICE files (we seem to have a lot of them!) are similarly out of date. I don't consider this a blocker for this release, though, so +1 GA. -- Martin Cooper On Tue, Dec 14, 2010 at 4:20 AM, Lukasz Lenart wrote: > The Struts 2.2.1.1 test build is now available. It includes the latest > security patch regarding unblocked access to Dynamic Method Invocation > mechanism in REST plugin. > > Release notes: > * [https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.2.1.1] > > Distribution: > * [http://people.apache.org/builds/struts/2.2.1.1/] > > Maven 2 staging repository: > * [https://repository.apache.org/content/repositories/orgapachestruts-016/] > > Once you have had a chance to review the test build, please respond > with a vote on its quality: > > [ ] Leave at test build > [ ] Alpha > [ ] Beta > [ ] General Availability (GA) > > Everyone who has tested the build is invited to vote. Votes by PMC > members are considered binding. A vote passes if there are at least > three binding +1s and more +1s than -1s. > > The vote will remain open for at least 72 hours, longer upon request. > A vote can be amended at any time to upgrade or downgrade the quality > of the release based on future experience. If an initial vote > designates the build as "Beta", the release will be submitted for > mirroring and announced to the user list. Once released as a public > beta, subsequent quality votes on a build may be held on the user > list. > > As always, the act of voting carries certain obligations. A binding > vote not only states an opinion, but means that the voter is agreeing > to help do the work > > > Kind regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Kapituła Javarsovia http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Chinese developer want to translate the user guide of Struts
On Sat, Dec 11, 2010 at 8:25 AM, Paul Benedict wrote: > Is there any special procedures for this? Any CLA need signing or can > he contribute new documentation? I'm not sure what the guidelines are these days. It seems likely that it would fall under the Community Development Project: http://community.apache.org/ At some level, someone could do this without asking, although the use of trademarks would be something to check. I know it was done for (parts of) Jakarta years ago, but that was before there was a community development project, so these days I'd start by asking the folks there. -- Martin Cooper > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts Master 8 Vote
On Thu, Dec 9, 2010 at 12:47 AM, Lukasz Lenart wrote: > > [ ] Leave at test build > [ ] Alpha > [ ] Beta > [X] General Availability (GA) > -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 1.1 -old Error message on the previous submission has been added to current error message
Please ask questions about using the framework on the user list:
http://struts.apache.org/mail.html
--
Martin Cooper
On Wed, Dec 8, 2010 at 1:42 AM, ela-chennai wrote:
>
> Hi All
>
> I am a sr web developer working on struts , my issue is that the old Error
> message on the previous submission has been added to current error message
> and been displayed to Jsp , my form bean is in session scope , i am using
> the validate method for doing this validation, anybody having any idea about
> why the err msg adding with the previous requst submission err msg ?
>
> this is my code
>
> actionErrors.add(actionErrors.GLOBAL_MESSAGE, new
> ActionMessage("errors.SummaryForm.actioPlanDesc.NoOfCharInvalid"));
> --
> View this message in context:
> http://old.nabble.com/struts-1.1--old-Error-message-on-the-previous-submission-has-been-added-to-current-error-message-tp30403854p30403854.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: Unapproved licenses
On Sun, Dec 5, 2010 at 3:50 AM, Lukasz Lenart wrote: > 2010/12/5 Martin Cooper : >> I guess the real question is whether or not there is some other >> license in there, and if so, how that's categorized at the ASF. > > Hmm... my thought is that it never worked :P, just Maven 3 showed it > as a problem. > I've reviewed the source code of RAT tool [1] and a file to match the > ASF license must have such a header > > "Licensed under the Apache License, Version 2.0 (the \"License\")" Comparing that with what's written here: http://www.apache.org/legal/src-headers.html#headers suggests that it's wrong, but it looks to me like that RAT code may be looking for something that *used* to be considered correct, and therefore probably exists in a lot of places. Note that the RAT source you're referring to is itself old, and has been replaced by what's in the Incubator. The project page for it clearly states "This project is being retained only for history purposes.". We need to be using what's in the Incubator, not what's known to be obsolete. -- Martin Cooper > I don't know if it's a correct header, so then should we use rat plugin? > >> You might want to check with the RAT folks (via their own mailing >> list) to see if there's actually a problem here or not. > > Thanks, I will try but since the project is in Incubator and Struts is > using Codehause version it can be hard ;-) > > [1] > http://code.google.com/p/arat/source/browse/trunk/rat/src/java/rat/analysis/license/ApacheSoftwareLicense20.java > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 http://javarsovia.pl > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Unapproved licenses
On Thu, Dec 2, 2010 at 12:26 AM, Lukasz Lenart wrote: > Hi, > > I'm running a new release process and during launching mvn > release:perform rat plugin reported unapproved license in > app/jboss-blank/pom.xml - Apache License Header is missing. The > strange thing is that it was already included in the latest 2.2.1 > release. I'm suspecting it's because of I'm using Maven 3 to do that > ;-) I guess the real question is whether or not there is some other license in there, and if so, how that's categorized at the ASF. You might want to check with the RAT folks (via their own mailing list) to see if there's actually a problem here or not. -- Martin Cooper > And to be more mysterious, also main struts2-parent pom.xml is missing > the header but rat plugin isn't complaining :P > > How to obey that without rollbacking all the changes and adding > required headers? > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 http://javarsovia.pl > > PS. Anyway it's a huge work for the future to adjust project to Maven 3 :D > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: params in the url - struts 2
On Sat, Dec 4, 2010 at 3:22 AM, clockdva242 wrote: > > i'm using struts 2 Please address your questions to the User list. http://struts.apache.org/mail.html -- Martin Cooper > i have a form and a list in a page > > when i call the action of the form (insert for example), i loose the params > in the url > > how can i keep that params ? > > thanks and sorry for my bad english > -- > View this message in context: > http://old.nabble.com/params-in-the-url---struts-2-tp30366627p30366627.html > Sent from the Struts - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: submit of type image
Please take this discussion to the user list. This list is for
discussion of the development of the framework itself. Thanks.
--
Martin Cooper
On Fri, Nov 26, 2010 at 8:07 AM, wrote:
> I downloaded the struts2 samples 2.2.1
>
> Ok in struts2-blank-2.2.1\example\Login.jsp
> I added to the form and as you said it
> works like a charm.
>
> But I did the same thing for the
> struts2-showcase-2.2.1/conversion/enterPersonsInfo.jsp form and it generates
> the error previously describe.
>
> Could you tell me if it's reproducable on your side with the struts2-showcase
> sample?
>
> JONAS_4_10_3
> JDK 1.5.0.22
> Struts 2.2.1
>
>
> Thanks,
>
> Olivier Sagit
>
>
> -Message d'origine-
> De : Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com]
> Envoyé : jeudi 25 novembre 2010 19:01
> À : Struts Developers List
> Objet : Re: submit of type image
>
> Which struts version?
> I tried the following code and it works like a charm.
>
>
>
> 2010/11/25 :
>>
>> Hi everybody,
>>
>> Is the freemarker property <@s.property value="parameters.body"/> in
>> template/simple/submit.ftl usefull ?
>>
>> It is just set for the input of type image and not for the other
>> (submit and button types)
>>
>> <#if parameters.type?? && parameters.type=="image"> <@s.property
>> value="parameters.body"/> <#if
>> parameters.label??> ...
>>
>>
>>
>> Consequently, when using the struts tag I
>> obtain the following stack trace in debug mode :
>>
>> Rendering template /template/simple/submit
>> 16:56:40,862 BUG kerTemplateEngine [-9000-Processor20] Rendering template
>> /template/simple/submit.ftl
>> 16:56:40,862 BUG pPropertyAccessor [-9000-Processor20] Entering getProperty
>> (ognl.ognlcont...@1c8ed8be,{templateDir=template, theme=simple,
>> dynamicAttributes={}, label=Continuer,
>> onclick=$('textChatFormModalBox').action ='desactivateTextChat.do';,
>> title=Continuer, nameValue=Submit, id=proceed, type=image, align=right,
>> src=ihm/images/fr/btn_proceed_fr.gif},body)
>> 16:56:40,862 BUG ectTypeDeterminer [-9000-Processor20] Error while
>> retrieving generic property class for property=parameters
>> java.lang.NullPointerException
>> at
>> com.opensymphony.xwork2.conversion.impl.DefaultObjectTypeDeterminer.getClass(DefaultObjectTypeDeterminer.java:314)
>> at
>> com.opensymphony.xwork2.conversion.impl.DefaultObjectTypeDeterminer.getKeyClass(DefaultObjectTypeDeterminer.java:93)
>> at
>> com.opensymphony.xwork2.ognl.accessor.XWorkMapPropertyAccessor.getProperty(XWorkMapPropertyAccessor.java:93)
>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230)
>> at ognl.ASTProperty.getValueBody(ASTProperty.java:114)
>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
>> at ognl.SimpleNode.getValue(SimpleNode.java:258)
>> at ognl.ASTChain.getValueBody(ASTChain.java:141)
>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
>> at ognl.SimpleNode.getValue(SimpleNode.java:258)
>> at ognl.Ognl.getValue(Ognl.java:494)
>> at com.opensymphony.xwork2.ognl.OgnlUtil.getValue(OgnlUtil.java:217)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.getValue(OgnlValueStack.java:342)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValue(OgnlValueStack.java:331)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValueWhenExpressionIsNotNull(OgnlValueStack.java:307)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:293)
>> at org.apache.struts2.components.Property.start(Property.java:162)
>> at
>> org.apache.struts2.views.freemarker.tags.CallbackWriter.onStart(CallbackWriter.java:73)
>> at freemarker.core.Environment.visit(Environment.java:296)
>> at freemarker.core.UnifiedCall.accept(UnifiedCall.java:130)
>> at freemarker.core.Environment.visit(Environment.java:210)
>> at freemarker.core.MixedContent.accept(MixedContent.java:92)
>> at freemarker.core.Environment.visit(Environment.java:210)
>> ...
>>
>> I could provide the complete stack trace if needed.
>>
>> Thanks,
>>
>> Olivier Sagit
>> osagit@orange-ftgroup.com
>>
>>
>> *
>> This message and any attachments (the "message") are
Re: Struts2 threading in a Java EE application server environment
On Mon, Oct 18, 2010 at 8:02 PM, Phil Adams wrote: > Hi, > I'm trying to help a customer that is using Struts2 within a Java > EE-compliant application server. Unfortunately, I have no real > experience with Struts2 so I was hoping someone on this mailing list > could offer some help. You want the user list, rather than the dev list. The former is for assistance with using Struts, which is what you're looking for. The latter is for discussion of the development of the framework itself. http://struts.apache.org/mail.html -- Martin Cooper > The main issue that I'm dealing with is this... An HTTP request is > received by the app server's servlet container and because of the > configuration inside the webapp's web.xml file, struts2 is invoking an > action class's "execute()" method, but it appears to be doing this on > a "new" thread (i.e. a thread other than the servlet container's > "worker" thread). > > First of all, is this normal and expected? If so, is it controllable > by the user via some sort of configuration? Also, how does the > struts2 framework deal with thread context information? > Specifically, when creating new threads in a Java EE environment, the > thread context information needs to be copied from the original thread > to the new thread, otherwise various Java EE components will have > unpredictable results. > > Thanks in advance for any help! > > -- > Phil Adams > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Dojo plugin
On Sat, Aug 21, 2010 at 8:51 AM, Dave Newton wrote: > Should the Dojo plugin be removed from the distro now? > > WW-3484 was just entered against it--if it's not going to be supported, I > guess I'd vote for stripping it out and putting the code elsewhere like on > Google or something. Removing it from the release / distribution seems fine if that's what we want. I'm not so sure about moving the code elsewhere, though. If someone else wants to pick it up and copy it somewhere to work on, it's up to them, not us, where they want to take it and what source control system they want to use. If there's a good reason for not having the code in the main trunk, even when it's not part of the distribution, then I suppose it could be moved back to the sandbox, or even to the archive. -- Martin Cooper > Thoughts? > > Dave > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JIRA down/moved?
On Mon, Aug 23, 2010 at 11:27 AM, Dave Newton wrote: > Howdy, > > Is JIRA down or has it moved? The link on the Struts home page doesn't work, > and a JIRA referenced in the wiki gives me a 404 (eventually). The separate JIRA instance for Struts was merged into the main JIRA instance quite some time ago, but the links on the home page and elsewhere were still referencing the old one. I just checked in a site update to correct that (but have not refreshed the site). -- Martin Cooper > > Thanks, > Dave > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Move OGNL to Apache.org
On Wed, May 26, 2010 at 12:28 AM, Lukasz Lenart wrote: > Hi, > > What do you think about moving OGNL to Apache.org, eg. to Commons? > Right now OGNL is used by some project at Apache.org but support is > very poor. The code is available here http://github.com/jkuhnert/ognl > > I know it isn't the right place to ask but I just want to hear your opinion. You're correct, this isn't the right place to ask. First, the OGNL community would have to want to make the move; then some ASF project (perhaps Commons, perhaps not) would need to sponsor incubation; community would need to be built up around the code before incubation could complete; and so on. If you are personally committed to helping build up a community around OGNL at the ASF, then I'd certainly encourage you to press ahead with that. It's the community that will make the project successful. Simply bringing the code to the ASF, though, won't improve support for it. -- Martin Cooper > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Need of Comprehensive Documentation for Struts2
There is a new documentation initiative that was started earlier this year and is being primarily driven by Bruce Phillips, I think. New work is being added to the Struts2NewDocDraft wiki space at first, and later migrated into the main S2 docs. You might want to take a look there and see if it would make sense to help out. I'm a little surprised none of those involved have chimed in here, though. -- Martin Cooper On Mon, May 24, 2010 at 3:35 AM, shekher awasthi wrote: > Hi All, > > Working with Struts2 is always a good experience for our team.one thing > which i always tend to hear from my team members as well as what i found on > net is that people use to complain about the documentation for Struts2. > > Though official documentation site is a great place to get help from as well > as a good and mature mailing list but some how i feel that still struts2 > lack a comprehensive documentation which is equally helpful from struts2 > based application developer as well as for those who want to get some > insight how things have been placed and working in struts2. > > E.G. > in order to use Spring with our struts2 project we just downloaded the > official documentation PDF from Spring-source official site and to our joy > this guide was something which was equally helpful to developer as well as > for those all who want to get inside Spring. > > My idea to write mail here is to get the views of the developer community > about working on some comprehensive guide so that it can help the user of > all needs.. > > -Best > Shekher > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [jira] Closed: (INFRA-2682) Nexus access for Struts
On Tue, May 25, 2010 at 1:51 PM, Wes Wannemacher wrote: > On Tue, May 25, 2010 at 10:35 AM, Wendy Smoak wrote: >> On Tue, May 25, 2010 at 10:21 AM, Lukasz Lenart >> wrote: >> >>> It's is in staging repo but I want to use Nexus for that and waiting >>> for clarification. As I understood I can removed it from the repo and >>> do it again. If not I will call for a Vote. >> >> You're fine, just sort out how to stage it in the new repo and then >> call a vote to release the master pom. :) This is good practice >> learning to stage and promote a single artifact before you try it with >> the whole thing. >> >> -- >> Wendy > > +1 > > This was my motivation for moving to nexus... Martin, sometimes I > think we all get the verb "release" confused. That was basically my point. At the ASF, a release is a package made available to the general public, and as such it can only be made after a vote by the relevant PMC. I understand that Maven uses the term 'release' to mean something different, but that just means we need to qualify the term when we are talking about a Maven procedure. When Lukasz said he had "made the release", that, at the ASF, will normally be taken to mean an ASF release, which requires a vote. Thus it was an incorrect statement. For someone from another project, or the ASF board, who is not familiar with Maven to drop in here and see that statement and see no corresponding vote, well, that would be bad. So when we mean the Maven thing that they happen to call a release, let's just be explicit that we're talking about the Maven thing. And if we use the term 'release' without qualification, let's use that to refer only to what the ASF calls a release, with a corresponding vote. -- Martin Cooper > On one hand, there is > the logical act of "releasing" our artifacts to the public. On the > other, there is the mechanical act of invoking maven's release plugin. > What Lukasz is referring to is the mechanical act of invoking maven's > release plugin. It will push the artifact to the nexus staging > repository at which point, we can slurp it up and test it (hopefully > by running some test apps). Then, give our vote. This is a bit tricky > though because Lukasz is trying to commit changes that will result in > making nexus integration possible. So, he'll probably have to change > the pom, invoke the maven release plugin, and then check that nexus > received the new artifact in our staging repository. I assume we'll > see a small flurry of svn commits that look like traditional releases > (svn branches, poms having -SNAPSHOT versions removed, etc.). But, > nothing will end up on maven central or in people.a.o/dist until after > we've voted on the quality. > > To answer Lukasz's question, I would assume that the section you > mention does indeed at least need removed. I haven't looked at the > apache parent that we're inheriting from in struts-master, or our > nexus configuration, but IIRC, the reposit...@apache.org team > indicated that inheriting from the parent is all that is necessary. > > I would assume though, that we (anyone who plans to perform a release) > will need to setup our maven settings.xml file to include our LDAP > apache username and password. I would imagine that Nexus is configured > to only allow struts committers to push artifacts into the repository. > (Wendy, correct me if I'm wrong, but) I think usually this is handled > by having a server entry in your settings.xml file that matches up > with the record in the pom. > > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [jira] Closed: (INFRA-2682) Nexus access for Struts
On Tue, May 25, 2010 at 4:47 AM, Lukasz Lenart
wrote:
> 2010/5/15 Martin Cooper :
>> If it's a published artifact, it needs a release, so yes.
>
> I made the release
I did not see a vote...
--
Martin Cooper
>, but the artifact went to
> /www/people.apache.org/builds/struts/6/m2-staging-repository/org/apache/struts/struts-master/6
>
> As I understand, such section must be removed from struts-master.pom
> to use new Nexus repo:
>
> struts-staging
> Apache Struts Staging Repository
>
> scp://people.apache.org/www/people.apache.org/builds/struts/${project.version}/m2-staging-repository
>
>
> true
> apache.snapshots
> Apache Development Snapshot Repository
>
> scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository
>
>
> I will do the change and make a new release to test the whole process once
> again
>
>
> Regards
> --
> Łukasz
> http://www.lenart.org.pl/
> Kapituła Javarsovia 2010
> http://javarsovia.pl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: svn commit: r947374 - /struts/maven/trunk/build/KEYS
If an existing key has ever been used to sign a release, it should not be removed from the KEYS file. It's still needed to verify those older releases. New keys should just be added without removing anything that was there before. -- Martin Cooper 2010/5/23 : > Author: lukaszlenart > Date: Sun May 23 07:55:13 2010 > New Revision: 947374 > > URL: http://svn.apache.org/viewvc?rev=947374&view=rev > Log: > My new key > > Modified: > struts/maven/trunk/build/KEYS > > Modified: struts/maven/trunk/build/KEYS > URL: > http://svn.apache.org/viewvc/struts/maven/trunk/build/KEYS?rev=947374&r1=947373&r2=947374&view=diff > == > --- struts/maven/trunk/build/KEYS (original) > +++ struts/maven/trunk/build/KEYS Sun May 23 07:55:13 2010 > @@ -501,49 +501,38 @@ iyDHVsME8V688vPxA1IaiE8EGBECAA8FAkn3E4cC > 7ezCcACfU1IVPxZJdGJH2yZ3skUQ6Rb/hnkAn1JhYvhyPNivr9BctsSq1tyIgAF6 > =K6Iu > -END PGP PUBLIC KEY BLOCK- > -pub 1024D/DD8B8819 2009-12-16 > -uid Lukasz Lenart > -sig 3 DD8B8819 2009-12-16 Lukasz Lenart > -sub 4096g/66EFAD45 2009-12-16 > -sig DD8B8819 2009-12-16 Lukasz Lenart > +pub 4096R/63AFBB1F 2010-05-23 > + Key fingerprint = 0E00 8698 344E 62B9 0633 B7C6 2841 6106 63AF BB1F > +uid Lukasz Lenart (Signing Apache Distributions) > > +sig 3 63AFBB1F 2010-05-23 Lukasz Lenart (Signing Apache > Distributions) > > -BEGIN PGP PUBLIC KEY BLOCK- > Version: GnuPG v1.4.9 (Cygwin) > > -mQGiBEsouosRBADqYHGJ4BAM+v9OqrT0gzuZrnIxpimLNsZkj6WxO5r/Ub/kVBB4 > -GOZk65Bq26M+S1oMZo4jaI3+il8XZquUUa87gfBDcoVgiw32QUBvZzT3ietckI4o > -IGJu+oHggxQUdiyoAfz+3gvCGUc6kVYuSuFWgpwOwD9giPUIPV+eHnRLcwCgwHks > -wNaMFpvRzBrGTn4s+NhL+VMEALxZPmMLyIBQZ3zFcdsNmumkfv6HZ6DKJl3EILQA > -Eje8ihhKrpSdXXiQSNSNoXRwr4iEXJtdzkynLzHckmJMxp/T20sjZ+giPFsZP3El > -PSME1tfWr2X+K/DeoNAPDgZ1XwT/MbeMQTB9mttxDLh7iT0ydr1jZmc0G9072RX5 > -LLGmBADFRhTIif0kywiJyjLM47+H/ZMaPU8+hMuszfvSCL7HE9EXQmq743rNAlNh > -e/JC+Hpx/w6424nFMVQ6PQoUzWG2W8O9GuD6UTjXdhn7Gz7kH3pXvWnRWlMroGvP > -RMAtOUX3UL3VfCmVlag3nGqw9a4ZP4Cst1RTOY1NDKQ3NfXN17QnTHVrYXN6IExl > -bmFydCA8bHVrYXN6bGVuYXJ0QGFwYWNoZS5vcmc+iGAEExECACAFAksouosCGwMG > -CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRD1WHMi3YuIGTZ/AKCruOnMYkXXOjg6 > -CccBJFVbg4OBKACdH5CFT0zUSlrF1SM+S2etNT8A3iG5BA0ESyi6ixAQAIfLz7XS > -wcC5L32glQ/71InGR9wi1KVchAvP+soDuicqzS8kmvuxsYYyrSOTjrLRGs1kuZ3c > -uSTj2jgYD4peDVYyfhDDDe9PBsv3cN35XE7i/DII1qgfe5+cjND/6Wgwjcg5Doat > -zLrFcHCexKZKP21lG4AwblzvNojOuCvhnAPS+zbsqjQ1W0hByUH5TMaNTk0ZctXM > -WJzxYT5JBeboR+T/K2d0yYGUsq/A0DOtZ0JVzfDihF8QTzcbagFyP4y1O3Bp4TXd > -NSoETirrVnc+CyVAGMfNUpodNJizqytZlPMCujY7VhiOBvzKlc2Bq9E4TtE2g5Sd > -rKo8I/pYFNSUa/hkMcxj66VmC0LwNbbPTwFiUwloMWBYMH/nbq8oVvKU0NHnMyM6 > -FrwroPaFw5mCF7wesbJOwtW3vj5r8BCyfrpWbQXMlix14FOLaC10NG9NBGb9b648 > -ADEN4hNIUwBkhAiHR+Q374CRINqoe67jRgpyaW+CfdRhLM/m7Nuhj61VrUnZRQ1l > -B5taCw83GVsT+tTO5KiN6uLwJhkewgR3QXeuwOuhc1NY1EXy0rhH6eAMkwT03jPw > -AoMRLyLr97nBcHAB2XF1s5xCL16dmAnl5fpIgCtNQHZDp67un6/+0Yhbgr2bFrw6 > -ALq51cS79dhKIkressxI8439Odfg1B2qD1uHAAMFD/9L1n9HrSLlGtlHT8Cv6SV3 > -Z7o4piDM7jCUWfduNtYv8otwEq9sXYr6pAvjfTdq9jeyQrenpsuLni2eMTAJXhqz > -NfhSXfGRxdgC64TtK9LR9xIoZJQ0UQO5j4GFatbzvnLVJCf0TFZ9dEtrqEPMxjrc > -wg28Wy/UMlsd2W/FENll3bhAB4IUnf0h4NFZ42a2BKw91DIDGTap4r2gAWLMHR1y > -iyfGAZvmiMPocCE7Rgp2tNiUMVr01ZEcRmzZW5wg+2PpmkAR7BnVMwjsO6Bu+8fi > -C4q1pLLz1lRgru0lsZL/TxcXKRp94lElJ1V6Gz5MzCdY/iTnXgEXhXLTi0J2eUqQ > -xcYTiuI33uFRo1VsgHugkvFTlPe02fN+2tDJpG8mT0TQJT3+NdXfcK7Fg58DnP2W > -q7LLjJYHMZyPInXyfeVuT7a01yFkWmjKfl8gqrch1mlMaf2gkgGkMIT5gYEeA73U > -sfZtzcq0H0ciQyM4N0oXEbjo5/pwEQDeyZCpTI2z3cXq1N7zHhjv/gRWw51LZ65W > -bPJfQZwL7EnBidJFIYLMtf3wD4xheI5wgfhc7CfEoSoAgLiwPziIPS2ABM5TuYBd > -zuDvKSqd1VOIr0W+tHliXABRZEmQ7sONU9VptTmOIAIgB0uR4nBbt3OcEbNm2YIu > -V2krcFt8xJiczsflYfdF4IhJBBgRAgAJBQJLKLqLAhsMAAoJEPVYcyLdi4gZJdIA > -nA+r83IgYrCk9E5s2T3JhAEpPXX5AJ0d82Ug+2JyJvNyL8O+/61GrdDgSw== > -=+tUp > +mQINBEv43AABEAC6VkF/h0OnvcppCPkqzfNwNy/+D+aFhc+DESwxEznSSKSbeg3V > +r1wwTy90+7S/mEItm88RmkNBYe1Mz3syDcj9s4S34atEV6XzGAa+3gp2rkWskyZ9 > +jJhXuD5ctd3LWRsA+0b14oo4/Je4pfu5aVzEDscrorskueHOY1Z73OmwRGZlIBT9 > +bQU+wAkIwhkw7HepgSyLcwblcy+cM4P68Ir/HAEt19FDKtnUUTnqnKT8bQDaXUuH > +2iqNYTo3xZ6D2Eh6aBcUXgzAXHtuSnm4IEwipvi1OGo87N3ZEy++bs9GLNoI8ooC > +pwhYtYDetOTvujXkyi3SGRzVhKagcJQhZGcRq3587f49K0EJCumyNYw5q4E1FgKN > +T0k3Zed/LyaUSQZBGIWcmbtXaY+2s8wtUjBXFTYbbLlbijaD95RvL8xY9mWDPwJB > +Pe9DidEQ9qOSNC7jWnbwKhoeTN2AAQCcaZ5lNEx3SYw0pLz7H22l+/i2jBMzYqAu > +0ViRyiXkNstxrdmbTaR4hJdf3IH0fsJPjdJVV0dyHKcDKaUj1RmcUizBLYTXY6oY > +nEk5kp0A2pllRwE4ZLxeiT9KkqbPytqkQVGDzu4PQnMxIv0Uu7NrIbpP6fMJlt94 > +3N57N3lj8FCfGU1TediS2aXZx2rLVEPWFmZWeOATwqihA1fe0leMBWPnfwARAQAB &
Re: [jira] Closed: (INFRA-2682) Nexus access for Struts
On Wed, May 12, 2010 at 4:42 AM, Lukasz Lenart wrote: > 2010/5/12 Wes Wannemacher : >> What I'll do (in the near-term) is try to configure hudson so that it >> deploys snapshots to nexus and try to update confluence so that people >> will know to point to add apache's nexus as a snapshot repo for >> struts. > > As I understand I must upgrade that pom > https://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml > > to use the latest apache.org parent pom. Do we need a release for that? If it's a published artifact, it needs a release, so yes. -- Martin Cooper > Regards > -- > Łukasz > http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 > http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork license
On Wed, Apr 14, 2010 at 12:28 AM, Lukasz Lenart wrote: > I'm cleaning up Struts 2 assembly module and I'm thinking about XWork > licence, should it be Apache Licence right now? I changed the XWork license to Apache License 2.0 immediately after committing XWork to the Struts repo at the end of last year. See r894090. References to XWork from then on should be referencing the Apache License 2.0, yes. -- Martin Cooper > Regards > -- > Łukasz > http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 > http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Google code donation? (was Re: svn commit: r903559 - in /struts/sandbox/trunk/struts2-gxp-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/
On Mon, Apr 12, 2010 at 12:13 PM, Martin Cooper wrote: > Once it's correctly filled in as well as signed, and once it's > registered with the ASF Secretary, we can make progress, yes. I'll > reply to this thread again when both of those things are done. I believe we are now good to go. Thanks, Ben! -- Martin Cooper > -- > Martin Cooper > > > On Mon, Apr 12, 2010 at 11:13 AM, Ben McCann wrote: >> I just sent Martin the signed agreement. Hopefully we can get the code >> checked into the repository now. >> >> -Ben McCann >> >> >> On Sat, Apr 10, 2010 at 4:24 PM, Martin Cooper wrote: >> >>> This has been dragging on for a very long time now. The most recent >>> final "couple weeks" has turned into six weeks, with no sign of any >>> paperwork. The code will be deleted this coming Wednesday if the >>> paperwork is not filed by then. >>> >>> -- >>> Martin Cooper >>> >>> >>> On Sat, Feb 27, 2010 at 11:03 AM, chengas123 >>> wrote: >>> > >>> > I work at Google and am working on getting the paperwork. The form has >>> been >>> > sent to our VP for a signature. It's probably going to take a couple >>> weeks. >>> > Wish it could be faster, but only VPs have the power to sign for the >>> company >>> > and they are busy people. Please copy me on any correspondence related >>> to >>> > the GXP plug-in as I am not a member of struts-dev. >>> > >>> > Thanks, >>> > Ben McCann >>> > Software Engineer >>> > Google Inc. >>> > benmccann.com >>> > >>> > >>> > >>> > Martin Cooper-2 wrote: >>> >> >>> >> On Tue, Feb 9, 2010 at 7:22 AM, Lukasz Lenart >>> >> wrote: >>> >>> 2010/1/27 Lukasz Lenart : >>> >>>> 2010/1/27 Martin Cooper : >>> >>>>> Whoa, I obviously missed an important thread. Can someone provide a >>> >>>>> link, please, to the thread in which this was discussed? >>> >>>>> >>> >>>>> Do we have a software grant on file? That's the very minimum we need >>> >>>>> if this is a donation from Google and not from an (unaffiliated) >>> >>>>> individual. We probably also need to go through IP Clearance. >>> >>>> >>> >>>> Here you have the whole thread [1] but the most important is the last >>> >>>> message >>> >>>> >>> >>>> [1] >>> >>>> >>> http://old.nabble.com/-s2--Google-XML-Pages-%28GXP%29-to-replace-Freemarker-in-tags--td18663215.html >>> >>> >>> >>> Any news about this issue? >>> >> >>> >> We still do not have anything on file from Google that says they >>> >> donated the code. All I can find is a statement from Musachy that "the >>> >> guys from GXP sent me the code", which does not count. I'm going to >>> >> delete the code from the sandbox if I don't see any progress on this >>> >> soon. >>> >> >>> >> -- >>> >> Martin Cooper >>> >> >>> >> >>> >>> What about that code [1], can I include it if author marked for >>> >>> inclusion to ASF? >>> >>> >>> >>> [1] https://issues.apache.org/jira/browse/WW-3260 >>> >>> >>> >>> >>> >>> Regards >>> >>> -- >>> >>> Łukasz >>> >>> http://www.lenart.org.pl/ >>> >>> Kapituła Javarsovia 2010 >>> >>> http://javarsovia.pl >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >>> >>> >>> >> >>> >> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> >> For additional commands, e-mail: dev-h...@struts.apache.org >>> >> >>> >> >>> >> >>> > >>> > -- >>> > View this message in context: >>> http://old.nabble.com/Re%3A-Google-code-donation--%28was-Re%3A-svn-commit%3A-r903559---in---struts-sandbox-trunk-struts2-gxp-plugin%3A-.--src--src-main--src-main-java---src-main-java-org--src-main-java-org-apache--src-main-java-org-apache-struts2---src-main-java-org-apache-struts2-vie-tp27343223p27729764.html >>> > Sent from the Struts - Dev mailing list archive at Nabble.com. >>> > >>> > >>> > - >>> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> > For additional commands, e-mail: dev-h...@struts.apache.org >>> > >>> > >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Google code donation? (was Re: svn commit: r903559 - in /struts/sandbox/trunk/struts2-gxp-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/
Once it's correctly filled in as well as signed, and once it's registered with the ASF Secretary, we can make progress, yes. I'll reply to this thread again when both of those things are done. -- Martin Cooper On Mon, Apr 12, 2010 at 11:13 AM, Ben McCann wrote: > I just sent Martin the signed agreement. Hopefully we can get the code > checked into the repository now. > > -Ben McCann > > > On Sat, Apr 10, 2010 at 4:24 PM, Martin Cooper wrote: > >> This has been dragging on for a very long time now. The most recent >> final "couple weeks" has turned into six weeks, with no sign of any >> paperwork. The code will be deleted this coming Wednesday if the >> paperwork is not filed by then. >> >> -- >> Martin Cooper >> >> >> On Sat, Feb 27, 2010 at 11:03 AM, chengas123 >> wrote: >> > >> > I work at Google and am working on getting the paperwork. The form has >> been >> > sent to our VP for a signature. It's probably going to take a couple >> weeks. >> > Wish it could be faster, but only VPs have the power to sign for the >> company >> > and they are busy people. Please copy me on any correspondence related >> to >> > the GXP plug-in as I am not a member of struts-dev. >> > >> > Thanks, >> > Ben McCann >> > Software Engineer >> > Google Inc. >> > benmccann.com >> > >> > >> > >> > Martin Cooper-2 wrote: >> >> >> >> On Tue, Feb 9, 2010 at 7:22 AM, Lukasz Lenart >> >> wrote: >> >>> 2010/1/27 Lukasz Lenart : >> >>>> 2010/1/27 Martin Cooper : >> >>>>> Whoa, I obviously missed an important thread. Can someone provide a >> >>>>> link, please, to the thread in which this was discussed? >> >>>>> >> >>>>> Do we have a software grant on file? That's the very minimum we need >> >>>>> if this is a donation from Google and not from an (unaffiliated) >> >>>>> individual. We probably also need to go through IP Clearance. >> >>>> >> >>>> Here you have the whole thread [1] but the most important is the last >> >>>> message >> >>>> >> >>>> [1] >> >>>> >> http://old.nabble.com/-s2--Google-XML-Pages-%28GXP%29-to-replace-Freemarker-in-tags--td18663215.html >> >>> >> >>> Any news about this issue? >> >> >> >> We still do not have anything on file from Google that says they >> >> donated the code. All I can find is a statement from Musachy that "the >> >> guys from GXP sent me the code", which does not count. I'm going to >> >> delete the code from the sandbox if I don't see any progress on this >> >> soon. >> >> >> >> -- >> >> Martin Cooper >> >> >> >> >> >>> What about that code [1], can I include it if author marked for >> >>> inclusion to ASF? >> >>> >> >>> [1] https://issues.apache.org/jira/browse/WW-3260 >> >>> >> >>> >> >>> Regards >> >>> -- >> >>> Łukasz >> >>> http://www.lenart.org.pl/ >> >>> Kapituła Javarsovia 2010 >> >>> http://javarsovia.pl >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> >>> For additional commands, e-mail: dev-h...@struts.apache.org >> >>> >> >>> >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> >> >> >> >> >> > >> > -- >> > View this message in context: >> http://old.nabble.com/Re%3A-Google-code-donation--%28was-Re%3A-svn-commit%3A-r903559---in---struts-sandbox-trunk-struts2-gxp-plugin%3A-.--src--src-main--src-main-java---src-main-java-org--src-main-java-org-apache--src-main-java-org-apache-struts2---src-main-java-org-apache-struts2-vie-tp27343223p27729764.html >> > Sent from the Struts - Dev mailing list archive at Nabble.com. >> > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> > For additional commands, e-mail: dev-h...@struts.apache.org >> > >> > >> > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Google code donation? (was Re: svn commit: r903559 - in /struts/sandbox/trunk/struts2-gxp-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/
This has been dragging on for a very long time now. The most recent final "couple weeks" has turned into six weeks, with no sign of any paperwork. The code will be deleted this coming Wednesday if the paperwork is not filed by then. -- Martin Cooper On Sat, Feb 27, 2010 at 11:03 AM, chengas123 wrote: > > I work at Google and am working on getting the paperwork. The form has been > sent to our VP for a signature. It's probably going to take a couple weeks. > Wish it could be faster, but only VPs have the power to sign for the company > and they are busy people. Please copy me on any correspondence related to > the GXP plug-in as I am not a member of struts-dev. > > Thanks, > Ben McCann > Software Engineer > Google Inc. > benmccann.com > > > > Martin Cooper-2 wrote: >> >> On Tue, Feb 9, 2010 at 7:22 AM, Lukasz Lenart >> wrote: >>> 2010/1/27 Lukasz Lenart : >>>> 2010/1/27 Martin Cooper : >>>>> Whoa, I obviously missed an important thread. Can someone provide a >>>>> link, please, to the thread in which this was discussed? >>>>> >>>>> Do we have a software grant on file? That's the very minimum we need >>>>> if this is a donation from Google and not from an (unaffiliated) >>>>> individual. We probably also need to go through IP Clearance. >>>> >>>> Here you have the whole thread [1] but the most important is the last >>>> message >>>> >>>> [1] >>>> http://old.nabble.com/-s2--Google-XML-Pages-%28GXP%29-to-replace-Freemarker-in-tags--td18663215.html >>> >>> Any news about this issue? >> >> We still do not have anything on file from Google that says they >> donated the code. All I can find is a statement from Musachy that "the >> guys from GXP sent me the code", which does not count. I'm going to >> delete the code from the sandbox if I don't see any progress on this >> soon. >> >> -- >> Martin Cooper >> >> >>> What about that code [1], can I include it if author marked for >>> inclusion to ASF? >>> >>> [1] https://issues.apache.org/jira/browse/WW-3260 >>> >>> >>> Regards >>> -- >>> Łukasz >>> http://www.lenart.org.pl/ >>> Kapituła Javarsovia 2010 >>> http://javarsovia.pl >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> >> > > -- > View this message in context: > http://old.nabble.com/Re%3A-Google-code-donation--%28was-Re%3A-svn-commit%3A-r903559---in---struts-sandbox-trunk-struts2-gxp-plugin%3A-.--src--src-main--src-main-java---src-main-java-org--src-main-java-org-apache--src-main-java-org-apache-struts2---src-main-java-org-apache-struts2-vie-tp27343223p27729764.html > Sent from the Struts - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE 2] Release Struts 2 Maven Archetypes v2.1.8.1
On Sun, Jan 31, 2010 at 11:46 AM, Lukasz Lenart wrote: > 2010/1/19 Lukasz Lenart : >> The Struts 2 Archetypes version 2.1.8.1 test build is now available. >> This is the second attempt to vote Struts 2 archetypes, please ignore >> previous one. The following archetypes are ready for test: >> * struts2-archetype-blank >> * struts2-archetype-convention >> * struts2-archetype-dbportlet >> * struts2-archetype-plugin >> * struts2-archetype-portlet >> * struts2-archetype-starter > > Just to remember, this is new Vote, previous one was cancelled! Apparently this vote garnered zero responses. I won't try to interpret that, but I would recommend that you change the subject line the next time you need to restart a vote, so that it's clear to everyone that it's a new vote, and not just to those who are still reading the previous vote thread. -- Martin Cooper > > > Regards > -- > Lukasz > http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 > http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Google code donation? (was Re: svn commit: r903559 - in /struts/sandbox/trunk/struts2-gxp-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/
On Tue, Feb 9, 2010 at 7:22 AM, Lukasz Lenart wrote: > 2010/1/27 Lukasz Lenart : >> 2010/1/27 Martin Cooper : >>> Whoa, I obviously missed an important thread. Can someone provide a >>> link, please, to the thread in which this was discussed? >>> >>> Do we have a software grant on file? That's the very minimum we need >>> if this is a donation from Google and not from an (unaffiliated) >>> individual. We probably also need to go through IP Clearance. >> >> Here you have the whole thread [1] but the most important is the last message >> >> [1] >> http://old.nabble.com/-s2--Google-XML-Pages-%28GXP%29-to-replace-Freemarker-in-tags--td18663215.html > > Any news about this issue? We still do not have anything on file from Google that says they donated the code. All I can find is a statement from Musachy that "the guys from GXP sent me the code", which does not count. I'm going to delete the code from the sandbox if I don't see any progress on this soon. -- Martin Cooper > What about that code [1], can I include it if author marked for > inclusion to ASF? > > [1] https://issues.apache.org/jira/browse/WW-3260 > > > Regards > -- > Łukasz > http://www.lenart.org.pl/ > Kapituła Javarsovia 2010 > http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Google code donation? (was Re: svn commit: r903559 - in /struts/sandbox/trunk/struts2-gxp-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apac
Whoa, I obviously missed an important thread. Can someone provide a link, please, to the thread in which this was discussed? Do we have a software grant on file? That's the very minimum we need if this is a donation from Google and not from an (unaffiliated) individual. We probably also need to go through IP Clearance. -- Martin Cooper On Tue, Jan 26, 2010 at 11:44 PM, wrote: > Author: lukaszlenart > Date: Wed Jan 27 07:44:32 2010 > New Revision: 903559 > > URL: http://svn.apache.org/viewvc?rev=903559&view=rev > Log: > Initial commit of all code donated by Google, all packages were renamed to > org.apache.struts > > Added: > struts/sandbox/trunk/struts2-gxp-plugin/ > struts/sandbox/trunk/struts2-gxp-plugin/pom.xml > struts/sandbox/trunk/struts2-gxp-plugin/src/ > struts/sandbox/trunk/struts2-gxp-plugin/src/main/ > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/ > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/ > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/ > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/ > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/ > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/ > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/AbstractGxp.java > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/AbstractGxpResult.java > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/Gxp.java > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/GxpInstance.java > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/GxpResult.java > > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/Param.java > struts/sandbox/trunk/struts2-gxp-plugin/src/test/ > struts/sandbox/trunk/struts2-gxp-plugin/src/test/java/ > > Added: struts/sandbox/trunk/struts2-gxp-plugin/pom.xml > URL: > http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-gxp-plugin/pom.xml?rev=903559&view=auto > == > --- struts/sandbox/trunk/struts2-gxp-plugin/pom.xml (added) > +++ struts/sandbox/trunk/struts2-gxp-plugin/pom.xml Wed Jan 27 07:44:32 2010 > @@ -0,0 +1,71 @@ > +http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > + 4.0.0 > + > + org.apache.struts > + struts2-plugins > + 2.2.0-SNAPSHOT > + > + > + org.apache.struts > + struts2-gxp-plugin > + jar > + Struts 2 GXP Plugin > + http://struts.apache.org > + > + > + > scm:svn:http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-gxp-plugin > + > scm:svn:https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-gxp-plugin > + > http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/struts2-gxp-plugin > + > + > + > + > + org.apache.struts > + struts2-core > + 2.2.0-SNAPSHOT > + > + > + javax.servlet > + servlet-api > + 2.4 > + provided > + > + > + > + com.google > + gxp > + 0.2.4-BETA > + > + > + junit > + junit > + 3.8.1 > + test > + > + > + com.google.collections > + google-collections > + 1.0 > + > + > + > + > + install > + > + > + maven-compiler-plugin > + > + 1.5 > + 1.5 > + > + > + > + > + > + > > Added: > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/AbstractGxp.java > URL: > http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/AbstractGxp.java?rev=903559&view=auto > == > --- > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/apache/struts2/views/gxp/AbstractGxp.java > (added) > +++ > struts/sandbox/trunk/struts2-gxp-plugin/src/main/java/org/ap
Re: XWork has landed!
On Mon, Jan 18, 2010 at 9:24 AM, Musachy Barroso wrote: > Martin does this sound good to you? I think going with just core is a > safe option. I have no problem with it. I just want to make sure everyone understands, and is on board with, exactly what we're doing before we do it. -- Martin Cooper > musachy > > //when is gmail going to realize that no...I meant "musachy" not "mustache" :) > > On Fri, Jan 15, 2010 at 11:09 AM, Wes Wannemacher wrote: >> The xwork module are core, plugins and showcase. It was only recently >> that xwork was broken up and I think it was meant to make things more >> manageable. Personally, my vote is for #2 as well. If we need to make >> xwork-specific plugins or continue building the xwork showcase, then >> we can move those over to the apps and plugins struts2 modules. >> Struts2 depends on xwork-core, so I think we start with that one and >> bring plugins and showcase over if the need dictates. >> >> -Wes >> >> /summary - (b) >> >> On Fri, Jan 15, 2010 at 1:47 PM, Musachy Barroso wrote: >>> Well, I would like to hear from Rene or Rainer about #2 >>> >>> "2) (a) all of XWork, (b) just the XWork core, (c) some other subset of >>> XWork" >>> >>> To be honest I don't even know what the other stuff is(I vaguely >>> remember something about plugins for xwork), I think we should go with >>> b) just core. >>> >>> On Fri, Jan 15, 2010 at 10:34 AM, Martin Cooper wrote: >>>> On Fri, Jan 15, 2010 at 10:23 AM, Musachy Barroso >>>> wrote: >>>>> we are all now in the same page right? (meaning we agree to move xwork >>>>> under http://svn.apache.org/repos/asf/struts/struts2/trunk/) >>>> >>>> We don't have an answer to #2 yet (I saw opinions for both a and b), >>>> but we have answers to #1 and #3, so we're close. ;-) >>>> >>>> -- >>>> Martin Cooper >>>> >>>> >>>>> musachy >>>>> >>>>> On Sat, Jan 9, 2010 at 12:51 AM, Musachy Barroso >>>>> wrote: >>>>>> yes I meant under struts2, sorry for the confusion >>>>>> >>>>>> On Fri, Jan 8, 2010 at 5:22 PM, Martin Cooper wrote: >>>>>>> On Fri, Jan 8, 2010 at 4:20 PM, Musachy Barroso >>>>>>> wrote: >>>>>>>> What we have been talking about and (vaguely) mentioned before is to >>>>>>>> move it under /struts/trunk/xwork >>>>>>> >>>>>>> Unless I'm mistaken, that is _not_ where you want to move it. You want >>>>>>> it under 'struts2', don't you? >>>>>>> >>>>>>> Today it is here: >>>>>>> >>>>>>> http://svn.apache.org/repos/asf/struts/xwork/trunk/ >>>>>>> >>>>>>> and S2 is here: >>>>>>> >>>>>>> http://svn.apache.org/repos/asf/struts/struts2/trunk/ >>>>>>> >>>>>>> Since there is no 'struts/trunk', what you said above is unlikely to >>>>>>> be what you actually mean. This is why I'm trying to get an accurate >>>>>>> specification of what you *really* want. How can we agree if you're >>>>>>> not accurately stating what you want / plan to do? >>>>>>> >>>>>>>> and make it a module just like core >>>>>>>> is, so the release is coupled to the struts release and everything can >>>>>>>> be built easily >>>>>>> >>>>>>> Great. I have no problem with that. Now, why is 1a better than 1c, for >>>>>>> example? And what is the answer to 2? Neither of these are answered by >>>>>>> the statement that you want to be able to build easily. >>>>>>> >>>>>>> -- >>>>>>> Martin Cooper >>>>>>> >>>>>>> >>>>>>>> musahcy >>>>>>>> >>>>>>>> On Fri, Jan 8, 2010 at 3:56 PM, Martin Cooper >>>>>>>> wrote: >>>>>>>>> On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso >>>>>>>>> wrote: >>>>>>>>>> just to close this, is anyone opposed to moving xwork under the >>>>
Struts announcements page
I've just noticed that our announcements page is showing only the most recent release. It's supposed to be a news-like or blog-like page, on which new releases or other notable happenings are added at the top as they occur. Basically, everything from 2009 is missing right now except for the 2.1.8.1 release. (There are separate pages for prior years.) It would be nice if we could resurrect this. -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Release Struts 2 Maven Archetypes v2.1.8.1
Where are we on this? Lukasz, are you going to be able to kick off a new vote after we have all of the proper artifacts in place? -- Martin Cooper On Wed, Jan 6, 2010 at 2:38 AM, Lukasz Lenart wrote: > 2010/1/6 Frans Thamura : >> Lukasz, can u share, where is the source code of your archetype? >> >> so we can see the source > > I have a local copy of archetypes, the clean copy that was used for > release. I didn't clean it up after all, so I was able to generate all > missing files. > I can compress it and put on my web side if you wish. > > > Regards > -- > Lukasz > http://www.lenart.org.pl/ > http://javarsovia.pl > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Fri, Jan 15, 2010 at 10:23 AM, Musachy Barroso wrote: > we are all now in the same page right? (meaning we agree to move xwork > under http://svn.apache.org/repos/asf/struts/struts2/trunk/) We don't have an answer to #2 yet (I saw opinions for both a and b), but we have answers to #1 and #3, so we're close. ;-) -- Martin Cooper > musachy > > On Sat, Jan 9, 2010 at 12:51 AM, Musachy Barroso wrote: >> yes I meant under struts2, sorry for the confusion >> >> On Fri, Jan 8, 2010 at 5:22 PM, Martin Cooper wrote: >>> On Fri, Jan 8, 2010 at 4:20 PM, Musachy Barroso wrote: >>>> What we have been talking about and (vaguely) mentioned before is to >>>> move it under /struts/trunk/xwork >>> >>> Unless I'm mistaken, that is _not_ where you want to move it. You want >>> it under 'struts2', don't you? >>> >>> Today it is here: >>> >>> http://svn.apache.org/repos/asf/struts/xwork/trunk/ >>> >>> and S2 is here: >>> >>> http://svn.apache.org/repos/asf/struts/struts2/trunk/ >>> >>> Since there is no 'struts/trunk', what you said above is unlikely to >>> be what you actually mean. This is why I'm trying to get an accurate >>> specification of what you *really* want. How can we agree if you're >>> not accurately stating what you want / plan to do? >>> >>>> and make it a module just like core >>>> is, so the release is coupled to the struts release and everything can >>>> be built easily >>> >>> Great. I have no problem with that. Now, why is 1a better than 1c, for >>> example? And what is the answer to 2? Neither of these are answered by >>> the statement that you want to be able to build easily. >>> >>> -- >>> Martin Cooper >>> >>> >>>> musahcy >>>> >>>> On Fri, Jan 8, 2010 at 3:56 PM, Martin Cooper wrote: >>>>> On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso >>>>> wrote: >>>>>> just to close this, is anyone opposed to moving xwork under the struts >>>>>> dir as a maven module? >>>>> >>>>> Uh, it's already under the 'struts' dir as a Maven project. >>>>> >>>>> In the context of the options I listed before, you appear to want: >>>>> >>>>> 1) (a), although I'm interested in the advantages of this over (b) or >>>>> especially (c). >>>>> 2) Unspecified, since you're referring to 'xwork' but not defining >>>>> which of the options this is. >>>>> 3) Unclear. Maybe (b)? >>>>> >>>>> I'm not trying to be a pain, but I'm not seeing a clearly stated >>>>> proposal and an explanation of why it's the right way to go. >>>>> >>>>> -- >>>>> Martin Cooper >>>>> >>>>> >>>>>> On Fri, Jan 8, 2010 at 3:53 AM, Lukasz Lenart >>>>>> wrote: >>>>>>> 2010/1/6 Musachy Barroso : >>>>>>>>> Really? I haven't seen much discussion since I posted what I believe >>>>>>>>> is the set of alternatives that we need to choose from. I saw quite a >>>>>>>>> few different opinions expressed, almost all in different terms (which >>>>>>>>> is why I posted what I did), but I'm not sure I saw a consensus >>>>>>>>> emerge. >>>>>>> >>>>>>> I'm not so good in Maven but I'm for anything that will simplify >>>>>>> release process (XWork will be released with Struts2 together) and >>>>>>> allow me to work with XWork and see at the same time what will happen >>>>>>> with Struts2 code base (eg. launching tests in IDEA). >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> -- >>>>>>> Lukasz >>>>>>> Kapituła Javarsovia 2010 >>>>>>> http://javarsovia.pl >>>>>>> >>>>>>> - >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>>> >>>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>> >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Fri, Jan 8, 2010 at 5:40 PM, Wendy Smoak wrote: > On Fri, Jan 8, 2010 at 6:27 PM, Martin Cooper wrote: > >> We need to get past this. Where it lives does *not* have an impact on >> whether it's built together with, or separately from, the rest of S2. >> It can stay where it is and also be built along with, and released as >> part of, S2. There are multiple ways of achieving that, the use of >> externals being one of them. > > Externals are fine for convenience like 'trunks' or 'current' to check > out several things together, but they will cause trouble when you try > to tag a release. Since they are just properties on a directory, they > don't magically get updated when you tag. Definitely not recommended, > at least when releasing with Maven. > > The best way to do this is to have everything together in Subversion > in a directory structure that matches the Maven parent-and-child > module structure. Good answer. :-) Thanks, Wendy. -- Martin Cooper > (That doesn't mean that it has to be like this forever though. If the > mythical Struts 3 appears and xwork needs to be separate... then we > move it.) > > -- > Wendy > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Fri, Jan 8, 2010 at 5:11 PM, Paul Benedict wrote: > I agree with Wendy. > > XWork is currently located here: > http://svn.apache.org/viewvc/struts/xwork/ > > I advocate its move to here: > http://svn.apache.org/viewvc/struts/struts2/trunk/xwork/ (doesn't exist) > > PS: The one caveat is if XWork really is valuable and would make it > good in a theoretical Struts 3, it could stay where it is and be > released separately. But, as already stated by others, it would mean > it's an extra build -- but also forever tied to struts 2. We need to get past this. Where it lives does *not* have an impact on whether it's built together with, or separately from, the rest of S2. It can stay where it is and also be built along with, and released as part of, S2. There are multiple ways of achieving that, the use of externals being one of them. -- Martin Cooper > Paul > > On Fri, Jan 8, 2010 at 6:48 PM, Musachy Barroso wrote: >> one small point I forgot to mention. If we do it this way we won't get >> more folks complaining about struts not building because of a recent >> change in xwork. It will make it easier for the dev making a release >> and for people building from trunk. >> >> On Fri, Jan 8, 2010 at 4:29 PM, Wendy Smoak wrote: >>> On Fri, Jan 8, 2010 at 5:20 PM, Musachy Barroso wrote: >>>> What we have been talking about and (vaguely) mentioned before is to >>>> move it under /struts/trunk/xwork and make it a module just like core >>>> is, so the release is coupled to the struts release and everything can >>>> be built easily >>> >>> I agree. Right now it is a pain to release xwork separately, so let's >>> not do that. >>> >>> I would put xwork underneath struts2/trunk, so that it is a sibling of >>> 'core'. Here: http://svn.apache.org/repos/asf/struts/struts2/trunk/ >>> >>> This means you build (and release) struts and xwork all together. >>> >>> -- >>> Wendy >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Fri, Jan 8, 2010 at 4:29 PM, Wendy Smoak wrote: > On Fri, Jan 8, 2010 at 5:20 PM, Musachy Barroso wrote: >> What we have been talking about and (vaguely) mentioned before is to >> move it under /struts/trunk/xwork and make it a module just like core >> is, so the release is coupled to the struts release and everything can >> be built easily > > I agree. Right now it is a pain to release xwork separately, so let's > not do that. That is probably the one piece of the puzzle that is clear and agreed upon right now. :-) -- Martin Cooper > I would put xwork underneath struts2/trunk, so that it is a sibling of > 'core'. Here: http://svn.apache.org/repos/asf/struts/struts2/trunk/ > > This means you build (and release) struts and xwork all together. > > -- > Wendy > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Fri, Jan 8, 2010 at 4:20 PM, Musachy Barroso wrote: > What we have been talking about and (vaguely) mentioned before is to > move it under /struts/trunk/xwork Unless I'm mistaken, that is _not_ where you want to move it. You want it under 'struts2', don't you? Today it is here: http://svn.apache.org/repos/asf/struts/xwork/trunk/ and S2 is here: http://svn.apache.org/repos/asf/struts/struts2/trunk/ Since there is no 'struts/trunk', what you said above is unlikely to be what you actually mean. This is why I'm trying to get an accurate specification of what you *really* want. How can we agree if you're not accurately stating what you want / plan to do? > and make it a module just like core > is, so the release is coupled to the struts release and everything can > be built easily Great. I have no problem with that. Now, why is 1a better than 1c, for example? And what is the answer to 2? Neither of these are answered by the statement that you want to be able to build easily. -- Martin Cooper > musahcy > > On Fri, Jan 8, 2010 at 3:56 PM, Martin Cooper wrote: >> On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso wrote: >>> just to close this, is anyone opposed to moving xwork under the struts >>> dir as a maven module? >> >> Uh, it's already under the 'struts' dir as a Maven project. >> >> In the context of the options I listed before, you appear to want: >> >> 1) (a), although I'm interested in the advantages of this over (b) or >> especially (c). >> 2) Unspecified, since you're referring to 'xwork' but not defining >> which of the options this is. >> 3) Unclear. Maybe (b)? >> >> I'm not trying to be a pain, but I'm not seeing a clearly stated >> proposal and an explanation of why it's the right way to go. >> >> -- >> Martin Cooper >> >> >>> On Fri, Jan 8, 2010 at 3:53 AM, Lukasz Lenart >>> wrote: >>>> 2010/1/6 Musachy Barroso : >>>>>> Really? I haven't seen much discussion since I posted what I believe >>>>>> is the set of alternatives that we need to choose from. I saw quite a >>>>>> few different opinions expressed, almost all in different terms (which >>>>>> is why I posted what I did), but I'm not sure I saw a consensus >>>>>> emerge. >>>> >>>> I'm not so good in Maven but I'm for anything that will simplify >>>> release process (XWork will be released with Struts2 together) and >>>> allow me to work with XWork and see at the same time what will happen >>>> with Struts2 code base (eg. launching tests in IDEA). >>>> >>>> >>>> Regards >>>> -- >>>> Lukasz >>>> Kapituła Javarsovia 2010 >>>> http://javarsovia.pl >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso wrote: > just to close this, is anyone opposed to moving xwork under the struts > dir as a maven module? Uh, it's already under the 'struts' dir as a Maven project. In the context of the options I listed before, you appear to want: 1) (a), although I'm interested in the advantages of this over (b) or especially (c). 2) Unspecified, since you're referring to 'xwork' but not defining which of the options this is. 3) Unclear. Maybe (b)? I'm not trying to be a pain, but I'm not seeing a clearly stated proposal and an explanation of why it's the right way to go. -- Martin Cooper > On Fri, Jan 8, 2010 at 3:53 AM, Lukasz Lenart > wrote: >> 2010/1/6 Musachy Barroso : >>>> Really? I haven't seen much discussion since I posted what I believe >>>> is the set of alternatives that we need to choose from. I saw quite a >>>> few different opinions expressed, almost all in different terms (which >>>> is why I posted what I did), but I'm not sure I saw a consensus >>>> emerge. >> >> I'm not so good in Maven but I'm for anything that will simplify >> release process (XWork will be released with Struts2 together) and >> allow me to work with XWork and see at the same time what will happen >> with Struts2 code base (eg. launching tests in IDEA). >> >> >> Regards >> -- >> Lukasz >> Kapituła Javarsovia 2010 >> http://javarsovia.pl >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Wed, Jan 6, 2010 at 9:27 AM, Musachy Barroso wrote: > I think the agreement is to move it under the struts trunk and make it > a maven module, like core. Really? I haven't seen much discussion since I posted what I believe is the set of alternatives that we need to choose from. I saw quite a few different opinions expressed, almost all in different terms (which is why I posted what I did), but I'm not sure I saw a consensus emerge. -- Martin Cooper > musachy > > On Tue, Jan 5, 2010 at 11:37 PM, Lukasz Lenart > wrote: >> 2009/12/28 Paul Benedict : >>> My fault for not being clear. I was intending to say XWork should be a >>> "child module" (in the Maven sense) so it's actually part of Struts2 >>> build and versioning process. >> >> Any news? I would like to start some refactoring in Xwork and it will >> be nice to know where we are ;-) >> >> >> Regards >> -- >> Lukasz >> http://www.lenart.org.pl/ >> http://javarsovia.pl >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Release Struts 2 Maven Archetypes v2.1.8.1
On Tue, Jan 5, 2010 at 12:53 PM, Wes Wannemacher wrote: > On Tue, Jan 5, 2010 at 3:43 PM, Martin Cooper wrote: > [snip] >> ... If you download the files, you have no way of knowing >> if they are the same ones you put there... > > No way of knowing... except the checksums :) You mean the checksums that you download from the same potentially-corrupted server? Good plan! :-p Anyway, good that Lukasz still has the original files. -- Martin Cooper > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Release Struts 2 Maven Archetypes v2.1.8.1
On Tue, Jan 5, 2010 at 12:18 PM, Musachy Barroso wrote: > you can download the files from the repo and sign it/generate > checksums..but!..this happened before and there was a long discussion > over if it was right or not and so on. Do not do this. If you download the files, you have no way of knowing if they are the same ones you put there. They could have been corrupted, deliberately or otherwise, in the interim, and without signatures you cannot verify what you have (which is why we want the signatures in the first place). When you then sign those downloaded files, you could be signing anything. Think of it as signing a blank check and then giving that check to a stranger. Not something you want to be doing. -- Martin Cooper > You can either: > > 1. sign the files/generate checksums locally and upload them > 2. do the release again > > I'd say #1, considering how few people we have to test a new release, > and it takes a while to test (yeah I went and generated a project one > by one and ran it in jetty) > > musachy > > On Tue, Jan 5, 2010 at 12:06 PM, Lukasz Lenart > wrote: >> 2010/1/5 Wendy Smoak : >>> I just re-checked and there are still no .asc signature files in the >>> staging repo, so this cannot be released as-is. >> >> I found the problem - .asc files were only generated for >> struts2-archetype-plugin and struts2-archetype-starter. The reset is >> missing below entry in pom.xml - I have no idea how it was before >> released :D >> >> Nevertheless, is it possible to generate only .asc files? >> >> >> >> release >> >> >> >> org.apache.maven.plugins >> maven-gpg-plugin >> >> >> sign-artifacts >> verify >> >> sign >> >> >> >> >> >> >> >> >> >> >> >> Regards >> -- >> Lukasz >> http://www.lenart.org.pl/ >> http://javarsovia.pl >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Mon, Dec 28, 2009 at 11:37 AM, Wes Wannemacher wrote: > On Mon, Dec 28, 2009 at 2:16 PM, Paul Benedict wrote: >> Having XWork as a separate module is actually preferred, but only >> because it's a better design decision. It will create a clear >> separation of concerns within the code base. Now with that said, XWork >> should be a *child* module of Struts -- not a separate release. >> >> Paul > > When you (and Martin) are indicating a "child" of Struts, I assume you > mean for it to be a child outside of Struts2. I am a team player and > I'm willing to set it up, whatever the consensus, but I would really > prefer for it to be a child of Struts2. I understand the implications > of supporting it, etc. But, the biggest gripe (and *my* motivation for > voting to move it over) is that we often wait to release Struts2 > because we need a release of XWork. Not to knock Rainer, but sometimes > this process takes a while. If it is a part of the Struts2 umbrella, > then the release process outlined in the wiki will still apply, but > everything (including xwork artifacts) will go out at once. Plus, one > of my tasks for Struts 2.2 is to take advantage of maven's > dependencyManagement and pluginManagement. We could probably work that > into the struts-master, but I hate to push changes to Struts 1, since > I don't use it much. > > I would just like to balance making our lives easier against other > factors. In the end, if we make managing this beast easier we can move > on things faster. I know that "fast" isn't necessarily a goal, but I'd > still like to try to get to KISS so that potential patch-makers aren't > so intimidated by our code and build process. Where XWork lands up in the Struts repo, and how it gets built, have zero bearing on how it gets released (except if we see ourselves releasing it independently, which I did not think was the case). As I see it, we have a set of choices to make 1) (a) move, (b) copy, (c) create an 'external' reference for 2) (a) all of XWork, (b) just the XWork core, (c) some other subset of XWork 3) (a) to a peer of 'struts2', (b) to somewhere within 'struts2', (c) to somewhere else I believe 1c + 2a + 3a = what we have today except that it's one checkout instead of two. With that option, nothing about the build or the build documentation changes, AFAICT. Is that what we want? I don't know, I'm just suggesting that it's a low-cost way of moving forward now that the code is in our repo. I don't have a particular bias in regard to how we go about this, beyond some source control best practices. I just think we need to make sure we're all on the same page about where we want to end up. -- Martin Cooper > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Mon, Dec 28, 2009 at 10:29 AM, Wes Wannemacher wrote: > If no one objects, i can take a stab at taking care of this tonight... I guess I sort of object, unless I'm the only one without a full and clear picture of the fate of this new code base that we own. I think we need to make sure we're all on the same page before we start making changes. > I haven't looked much at Martin's check-in, but we only need to port > the xwork-core artifact... So, my plan would be to copy the source to > the struts2 folder as a first-class sub-project (adding it to the > modules section of the struts2 parent pom). Then, if that build works > out, the next check-ins can be renaming / refactoring of classes, etc. > But, if xwork-core is placed in the struts2 folder, alongside > struts2-core, struts2-plugins, etc., then, if nothing else, it will > make releasing easier. I'd imagine that refactoring class and package > names will be a bit troublesome. Although the IDE can handle most of > it for us, the trick isn't the easy stuff, the trick is finding the > classes that are no longer necessary and/or duplicated between > codebases. > > Thoughts? What I checked in is the entire XWork repo, since XWork is now our responsibility. That is, we don't have a copy of XWork that we're maintaining, we own XWork now. We have adopted it, lock, stock and barrel. If people need enhancements to XWork, they will come to us from now on. (What we do with such requests is something we should discuss at some point in the near future.) I was envisaging that we would add XWork to the 'current' external in such a way that it would look exactly the same as it does today when someone checks it out as a peer of the 'struts2' folder. I take it this is not what you have in mind? I have to say that 'copy' is not a word I like to see in reference to source control. ;-) It implies a forking of the code base that we would need to be very sure about. Is that actually what you mean? -- Martin Cooper > -Wes > > On Mon, Dec 28, 2009 at 1:16 PM, Musachy Barroso wrote: >> Are we going to rename the maven artifact names and package names for 2.2? >> >> musachy >> >> On Sun, Dec 27, 2009 at 12:39 PM, Martin Cooper wrote: >>> On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict >>> wrote: >>>> I recommend we immediately SVN tag or branch the initial check in so >>>> it can be refactored appropriately. >>> >>> I'm not sure I see a need to do that, given that we can create a tag >>> or branch from a specific revision at any time. However, if you feel >>> the need, you're welcome to do that. >>> >>> -- >>> Martin Cooper >>> >>> >>>> Paul >>>> >>>> On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart >>>> wrote: >>>>> 2009/12/27 Martin Cooper : >>>>>> As many of you have no doubt noticed already, I've checked in the >>>>>> XWork code base, and added the Apache License 2.0 headers. The new >>>>>> XWork tree is here: >>>>> >>>>> Hurra!!! Thanks a lot! >>>>> >>>>> >>>>> Regards >>>>> -- >>>>> Lukasz >>>>> http://www.lenart.org.pl/ >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>> >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict wrote: > I recommend we immediately SVN tag or branch the initial check in so > it can be refactored appropriately. I'm not sure I see a need to do that, given that we can create a tag or branch from a specific revision at any time. However, if you feel the need, you're welcome to do that. -- Martin Cooper > Paul > > On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart > wrote: >> 2009/12/27 Martin Cooper : >>> As many of you have no doubt noticed already, I've checked in the >>> XWork code base, and added the Apache License 2.0 headers. The new >>> XWork tree is here: >> >> Hurra!!! Thanks a lot! >> >> >> Regards >> -- >> Lukasz >> http://www.lenart.org.pl/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Accept the XWork project as donated by OpenSymphony
On Sun, Dec 27, 2009 at 10:23 AM, Niall Pemberton wrote: > Sorry I haven't really followed the reasoning behind bringing XWork > here. Who currently works on XWork and are they already Struts > committers? Committers who would be classified as 'active' are Rainer, Musachy, Wes, Lukasz and Rene, all of whom are Struts committers already. That's largely the point. -- Martin Cooper > Niall > > On Sat, Dec 26, 2009 at 7:11 PM, Martin Cooper wrote: >> This is a vote for the Struts PMC to formally accept the donation of >> the XWork project from OpenSymphony. This is a required step of the IP >> Clearance procedure documented here: >> >> http://incubator.apache.org/ip-clearance/index.html >> >> The XWork artifacts and software grant are available for your perusal here: >> >> https://issues.apache.org/struts/browse/WW-3248 >> >> Upon successful conclusion of this vote, the code base attached to the >> above issue will be checked in as a Struts subproject, and the IP >> Clearance procedure completed. >> >> PMC members, please indicate your vote below. >> >> [ ] Yes, accept the XWork project >> [ ] I don't really care one way or the other >> [ ] No, do not accept the XWork project, for these reasons (please specify) >> >> -- >> Martin Cooper >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
XWork has landed!
As many of you have no doubt noticed already, I've checked in the XWork code base, and added the Apache License 2.0 headers. The new XWork tree is here: http://svn.apache.org/repos/asf/struts/xwork/ I have *not* added it to 'current' at this point. I'll leave that to whoever wants to integrate it further. -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
On Sat, Dec 26, 2009 at 11:21 PM, Paul Benedict wrote: > I may have gotten the wrong impression, but it seems all SideWiki > content is stored in Google. I have a thing about letting Google > owning all the world's data. Okay. It was just an idea for how the community can add commentary to our content without any of us having to do anything. The community could still choose to use it, of course - it's more a question of whether or not we promote it and take feedback from it. I guess what I'm thinking is that, after this long, I can't imagine so much change coming to the S1 docs that converting them all to Confluence and then making the changes will actually save time over just making those changes to what we have. My expectation is that you'd spend far, far more time in the conversion than you'd save in any subsequent updates. That said, though, if that's where your itch lies, you are of course welcome to scratch it. :-) -- Martin Cooper > Paul > > On Sat, Dec 26, 2009 at 8:03 PM, Martin Cooper wrote: >> On Sat, Dec 26, 2009 at 5:42 PM, Paul Benedict wrote: >>> Can we defer the research into another wiki? I would at least get into >>> Confluence and then move everything to something new, if desired. >> >> Sigh. Please just take 2 minutes to look at what Sidewiki is. It's not >> something else we would move our content to, it's an alternative means >> for the community to add content to existing pages. >> >> -- >> Martin Cooper >> >> >>> Paul >>> >>> On Sat, Dec 26, 2009 at 11:55 AM, Martin Cooper wrote: >>>> On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict >>>> wrote: >>>>> Thanks Martin and Wendy for your replies. >>>>> >>>>> On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper >>>>> wrote: >>>>>> If you're concerned about the need for committership, then certainly >>>>>> the bar is a bit higher than just filing an iCLA. However, it's >>>>>> absolutely possible to gain committership for documentation, rather >>>>>> than code. I can think of two people, off the top of my head, who have >>>>>> been given committership in Struts primarily for documentation, at >>>>>> least initially. If there are people who are contributing patches for >>>>>> the docs, then perhaps we should be looking at that. >>>>> >>>>> I didn't know people could be given committer rights to only >>>>> documentation. Last time I probed this topic, I was told (and the >>>>> email thread exists somewhere) that there are no such thing as partial >>>>> rights -- you get to commit access to everything (or nothing) under >>>>> the struts group. >>>> >>>> That's not what I meant. Sorry if I wasn't clear. It's still true that >>>> commit access is for all of the Struts repo and not for pieces of it. >>>> What I meant is that people can earn commit rights on the basis of >>>> their work on documentation. Merit is not confined only to code. >>>> >>>> -- >>>> Martin Cooper >>>> >>>> >>>>> Since Confluence is a different system, perhaps >>>>> things became more lenient when I wasn't looking. >>>>> >>>>>> One other option that comes to mind is Sidewiki. I haven't actually >>>>>> played with this myself yet, but it seems like it might be an >>>>>> interesting option for allowing anyone to add content and comments >>>>>> alongside the official docs. Anyone have an opinion on how viable, or >>>>>> otherwise, this might be? >>>>> >>>>> I wasn't hoping to open up a new wiki discussion ;-) but I do remember >>>>> some committers saying they're unhappy with Confluence. If all of >>>>> Struts could put their documentation in one place, I am willing to go >>>>> wherever the group decides. >>>>> >>>>>> So I guess what I'm saying is that no, I don't think I have "technical >>>>>> objections", but I think there might be other alternatives worth >>>>>> discussing too. Migrating the docs would not be an easy task! >>>>> >>>>> Yes, I don't look forward to it, but I think keeping it in SVN is akin >>>>> to being frozen in an ice-berg. Even I hate editing it. Anyway, with >>>>
Re: Moving Struts 1 Doc to Confluence
On Sat, Dec 26, 2009 at 5:42 PM, Paul Benedict wrote: > Can we defer the research into another wiki? I would at least get into > Confluence and then move everything to something new, if desired. Sigh. Please just take 2 minutes to look at what Sidewiki is. It's not something else we would move our content to, it's an alternative means for the community to add content to existing pages. -- Martin Cooper > Paul > > On Sat, Dec 26, 2009 at 11:55 AM, Martin Cooper wrote: >> On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict wrote: >>> Thanks Martin and Wendy for your replies. >>> >>> On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper wrote: >>>> If you're concerned about the need for committership, then certainly >>>> the bar is a bit higher than just filing an iCLA. However, it's >>>> absolutely possible to gain committership for documentation, rather >>>> than code. I can think of two people, off the top of my head, who have >>>> been given committership in Struts primarily for documentation, at >>>> least initially. If there are people who are contributing patches for >>>> the docs, then perhaps we should be looking at that. >>> >>> I didn't know people could be given committer rights to only >>> documentation. Last time I probed this topic, I was told (and the >>> email thread exists somewhere) that there are no such thing as partial >>> rights -- you get to commit access to everything (or nothing) under >>> the struts group. >> >> That's not what I meant. Sorry if I wasn't clear. It's still true that >> commit access is for all of the Struts repo and not for pieces of it. >> What I meant is that people can earn commit rights on the basis of >> their work on documentation. Merit is not confined only to code. >> >> -- >> Martin Cooper >> >> >>> Since Confluence is a different system, perhaps >>> things became more lenient when I wasn't looking. >>> >>>> One other option that comes to mind is Sidewiki. I haven't actually >>>> played with this myself yet, but it seems like it might be an >>>> interesting option for allowing anyone to add content and comments >>>> alongside the official docs. Anyone have an opinion on how viable, or >>>> otherwise, this might be? >>> >>> I wasn't hoping to open up a new wiki discussion ;-) but I do remember >>> some committers saying they're unhappy with Confluence. If all of >>> Struts could put their documentation in one place, I am willing to go >>> wherever the group decides. >>> >>>> So I guess what I'm saying is that no, I don't think I have "technical >>>> objections", but I think there might be other alternatives worth >>>> discussing too. Migrating the docs would not be an easy task! >>> >>> Yes, I don't look forward to it, but I think keeping it in SVN is akin >>> to being frozen in an ice-berg. Even I hate editing it. Anyway, with >>> the help of Lukasz, I hope it is easier. >>> >>> Paul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Accept the XWork project as donated by OpenSymphony
My own vote: On Sat, Dec 26, 2009 at 11:11 AM, Martin Cooper wrote: > [X] Yes, accept the XWork project > [ ] I don't really care one way or the other > [ ] No, do not accept the XWork project, for these reasons (please specify) -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
[VOTE] Accept the XWork project as donated by OpenSymphony
This is a vote for the Struts PMC to formally accept the donation of the XWork project from OpenSymphony. This is a required step of the IP Clearance procedure documented here: http://incubator.apache.org/ip-clearance/index.html The XWork artifacts and software grant are available for your perusal here: https://issues.apache.org/struts/browse/WW-3248 Upon successful conclusion of this vote, the code base attached to the above issue will be checked in as a Struts subproject, and the IP Clearance procedure completed. PMC members, please indicate your vote below. [ ] Yes, accept the XWork project [ ] I don't really care one way or the other [ ] No, do not accept the XWork project, for these reasons (please specify) -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict wrote: > Thanks Martin and Wendy for your replies. > > On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper wrote: >> If you're concerned about the need for committership, then certainly >> the bar is a bit higher than just filing an iCLA. However, it's >> absolutely possible to gain committership for documentation, rather >> than code. I can think of two people, off the top of my head, who have >> been given committership in Struts primarily for documentation, at >> least initially. If there are people who are contributing patches for >> the docs, then perhaps we should be looking at that. > > I didn't know people could be given committer rights to only > documentation. Last time I probed this topic, I was told (and the > email thread exists somewhere) that there are no such thing as partial > rights -- you get to commit access to everything (or nothing) under > the struts group. That's not what I meant. Sorry if I wasn't clear. It's still true that commit access is for all of the Struts repo and not for pieces of it. What I meant is that people can earn commit rights on the basis of their work on documentation. Merit is not confined only to code. -- Martin Cooper > Since Confluence is a different system, perhaps > things became more lenient when I wasn't looking. > >> One other option that comes to mind is Sidewiki. I haven't actually >> played with this myself yet, but it seems like it might be an >> interesting option for allowing anyone to add content and comments >> alongside the official docs. Anyone have an opinion on how viable, or >> otherwise, this might be? > > I wasn't hoping to open up a new wiki discussion ;-) but I do remember > some committers saying they're unhappy with Confluence. If all of > Struts could put their documentation in one place, I am willing to go > wherever the group decides. > >> So I guess what I'm saying is that no, I don't think I have "technical >> objections", but I think there might be other alternatives worth >> discussing too. Migrating the docs would not be an easy task! > > Yes, I don't look forward to it, but I think keeping it in SVN is akin > to being frozen in an ice-berg. Even I hate editing it. Anyway, with > the help of Lukasz, I hope it is easier. > > Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
On Fri, Dec 25, 2009 at 10:51 PM, Paul Benedict wrote: > I would like to move the Struts 1 documentation from SVN to > Confluence. As old (10 years almost?!) as Struts 1 is, today it is not > possible for any community member to update it without having SVN > commit access. I think it's too high a bar. Does anyone have any > technical objections to this? I don't know about "technical objections", but I'd like to understand which bar you're referring to. Is it the bar of having to learn and use Subversion, versus editing a wiki page? Or is it the bar of having to become a committer before gaining access? In either case, it's still not going to be possible for "any community member" to update the official docs, since even if we switch to Confluence, access can be made available only to those who have filed an iCLA. That's why we have two spaces - one for official docs maintained only by those who have an iCLA on file, and another for anyone who wants to contribute, whether or not they have an iCLA on file. (So there already is no bar, for this second space.) If you're concerned about the need for committership, then certainly the bar is a bit higher than just filing an iCLA. However, it's absolutely possible to gain committership for documentation, rather than code. I can think of two people, off the top of my head, who have been given committership in Struts primarily for documentation, at least initially. If there are people who are contributing patches for the docs, then perhaps we should be looking at that. One other option that comes to mind is Sidewiki. I haven't actually played with this myself yet, but it seems like it might be an interesting option for allowing anyone to add content and comments alongside the official docs. Anyone have an opinion on how viable, or otherwise, this might be? So I guess what I'm saying is that no, I don't think I have "technical objections", but I think there might be other alternatives worth discussing too. Migrating the docs would not be an easy task! -- Martin Cooper > Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Jira at opensymphony
On Mon, Dec 21, 2009 at 9:15 AM, Musachy Barroso wrote: > Ah sweet I was waiting for that. Now I just need to learn git :). There's a pretty nice half-hour screencast on Git / GitHub here: http://pragprog.com/screencasts/v-scgithub/insider-guide-to-github That's quite possibly all you'll need. -- Martin Cooper > I > want to create a patch to make javassist optional it should take a > just a couple of lines. > > musachy > > On Mon, Dec 21, 2009 at 6:35 AM, Lukasz Lenart > wrote: >> Hi, >> >> A bit unrelated question, who manages JIRA at opensymphony? I want to >> have access to OGNL project to close some issues, but I don't have >> sufficient rights. The Ognl project was migrated to Github -> >> http://github.com/jkuhnert/ognl so anyone can have access to it ;-) >> >> >> Regards >> -- >> Lukasz >> http://www.lenart.org.pl/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Version number ordering
On Thu, Dec 17, 2009 at 3:40 PM, Paul Benedict wrote: > I am saying that if we keep the uppercase and underscore convention, > we can't accept the default of Maven's tag names. The release manager > just has to continue using the format we do today. That's all. I was trying to understand the disappointment you expressed. My own disappointment, to the extent that I have any, is that we let the Maven team define the standards that we use for our releases, but as I said before, I'm not married to keeping the "old" way. -- Martin Cooper > Paul > > On Thu, Dec 17, 2009 at 5:38 PM, Martin Cooper wrote: >> On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict wrote: >>> I have nothing against continuing the way *we* do it, but Maven >>> doesn't do it this way. Taking the defaults provided by the Maven >>> Release Plugin will create tag names like "struts-1.3.11" over >>> "STRUTS_1_3_11". >>> >>> Either way we decide, it is not a major loss for the other side, but >>> not able to accept Maven defaults is a bit disappointing. >> >> Who / what is not able to accept them? >> >> -- >> Martin Cooper >> >> >>> Paul >>> >>> On Thu, Dec 17, 2009 at 4:08 PM, Martin Cooper wrote: >>>> On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher wrote: >>>>> Not to split hairs, Lukasz, but this is the "released" pom - >>>>> >>>>> https://svn.apache.org/repos/asf/struts/maven/tags/struts2-archetype-starter-2.1.8.1/pom.xml >>>>> >>>>> Which looks fine. >>>>> >>>>> When I was checking this, it reminded me of something I have been >>>>> meaning to ask. If you look at the tag name that Lukasz used - >>>>> "struts2-archetype-starter-2.1.8.1" But, somewhere in our docs, we use >>>>> a tag name like this - "STRUTS2_ARCHETYPE_STARTER_2_1_8_1" which you >>>>> can see here - >>>>> >>>>> https://svn.apache.org/repos/asf/struts/struts2/tags/ >>>>> >>>>> The tag name that Lukasz used is what the release plugin defaults >>>>> to... Is there a reason we don't use it? I'm all about sticking to >>>>> defaults (since it tends to make the documentation easier), so I am >>>>> wondering if there is a reason, other than "that's the way we always >>>>> did it" >>>> >>>> To my knowledge, "that's the way we always did it" is the correct >>>> answer here, assuming the question is "upper case and underscores" >>>> versus "lower case and dashes". As you can see here, the former has >>>> been used since the very beginning of Struts, almost 10 years ago: >>>> >>>> http://svn.apache.org/repos/asf/struts/struts1/tags/ >>>> >>>> Bear in mind that there's an enormous amount of Struts history prior >>>> to us adopting Maven, let alone the Maven release plugin, so this is >>>> hardly surprising. That the Maven default is different is simply the >>>> result of the Maven team picking the wrong default release naming >>>> scheme. :-p >>>> >>>> If there's an easy way to tell the release plugin to use "upper case >>>> and underscores" instead of "lower case and dashes", the continuity >>>> would be nice, since there's no other good reason to change what we've >>>> been doing for so long. If there isn't an easy way to do that, though, >>>> and it's a nuisance to change the default for some reason, then I'm >>>> not dead set against adopting the Maven way. >>>> >>>> -- >>>> Martin Cooper >>>> >>>> >>>>> -Wes >>>>> >>>>> On Wed, Dec 16, 2009 at 12:50 PM, Lukasz Lenart >>>>> wrote: >>>>>> 2009/12/16 Martin Cooper : >>>>>>> In Lukasz's checkins just now, I see version numbers being changed to >>>>>>> 2.1.8-SNAPSHOT. Maybe I'm misinterpreting what's going on, but that >>>>>>> seems like going backwards. We already have a 2.1.8 and a 2.1.8.1, so >>>>>>> it seems to me that any snapshot version we should be using now would >>>>>>> need to be 2.1.9-SNAPSHOT, no? After all, snapshots precede the number >>>>>>> the
Re: Version number ordering
On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict wrote: > I have nothing against continuing the way *we* do it, but Maven > doesn't do it this way. Taking the defaults provided by the Maven > Release Plugin will create tag names like "struts-1.3.11" over > "STRUTS_1_3_11". > > Either way we decide, it is not a major loss for the other side, but > not able to accept Maven defaults is a bit disappointing. Who / what is not able to accept them? -- Martin Cooper > Paul > > On Thu, Dec 17, 2009 at 4:08 PM, Martin Cooper wrote: >> On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher wrote: >>> Not to split hairs, Lukasz, but this is the "released" pom - >>> >>> https://svn.apache.org/repos/asf/struts/maven/tags/struts2-archetype-starter-2.1.8.1/pom.xml >>> >>> Which looks fine. >>> >>> When I was checking this, it reminded me of something I have been >>> meaning to ask. If you look at the tag name that Lukasz used - >>> "struts2-archetype-starter-2.1.8.1" But, somewhere in our docs, we use >>> a tag name like this - "STRUTS2_ARCHETYPE_STARTER_2_1_8_1" which you >>> can see here - >>> >>> https://svn.apache.org/repos/asf/struts/struts2/tags/ >>> >>> The tag name that Lukasz used is what the release plugin defaults >>> to... Is there a reason we don't use it? I'm all about sticking to >>> defaults (since it tends to make the documentation easier), so I am >>> wondering if there is a reason, other than "that's the way we always >>> did it" >> >> To my knowledge, "that's the way we always did it" is the correct >> answer here, assuming the question is "upper case and underscores" >> versus "lower case and dashes". As you can see here, the former has >> been used since the very beginning of Struts, almost 10 years ago: >> >> http://svn.apache.org/repos/asf/struts/struts1/tags/ >> >> Bear in mind that there's an enormous amount of Struts history prior >> to us adopting Maven, let alone the Maven release plugin, so this is >> hardly surprising. That the Maven default is different is simply the >> result of the Maven team picking the wrong default release naming >> scheme. :-p >> >> If there's an easy way to tell the release plugin to use "upper case >> and underscores" instead of "lower case and dashes", the continuity >> would be nice, since there's no other good reason to change what we've >> been doing for so long. If there isn't an easy way to do that, though, >> and it's a nuisance to change the default for some reason, then I'm >> not dead set against adopting the Maven way. >> >> -- >> Martin Cooper >> >> >>> -Wes >>> >>> On Wed, Dec 16, 2009 at 12:50 PM, Lukasz Lenart >>> wrote: >>>> 2009/12/16 Martin Cooper : >>>>> In Lukasz's checkins just now, I see version numbers being changed to >>>>> 2.1.8-SNAPSHOT. Maybe I'm misinterpreting what's going on, but that >>>>> seems like going backwards. We already have a 2.1.8 and a 2.1.8.1, so >>>>> it seems to me that any snapshot version we should be using now would >>>>> need to be 2.1.9-SNAPSHOT, no? After all, snapshots precede the number >>>>> they're attached to, in terms of version number ordering. >>>> >>>> I just switched to 2.1.8-SNAPSHOT because Maven release plugin is >>>> complaining - after I did the release, everything is ok, please check >>>> already released pom.xml >>>> >>>> https://svn.apache.org/repos/asf/struts/maven/trunk/struts2-archetype-blank/pom.xml >>>> >>>> >>>> Regards >>>> -- >>>> Lukasz >>>> http://www.lenart.org.pl/ >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> >>> >>> -- >>> Wes Wannemacher >>> >>> Head Engineer, WanTii, Inc. >>> Need Training? Struts, Spring, Maven, Tomcat... >>> Ask me for a quote! >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
