Re: Hi all
On Mon, Dec 3, 2012 at 3:38 PM, vineet sood vineette...@gmail.com 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 rgie...@apache.org wrote: Am 28.11.12 06:14, schrieb Martin Cooper: On Tue, Nov 27, 2012 at 1:55 PM, Johannes Geppert jo...@apache.org 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 jo...@apache.org 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=nodenode=5711187i=0wrote: 2012/11/25 Johannes Geppert [hidden email] http://user/SendEmail.jtp?type=nodenode=5711187i=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. I'm not sure if the board level reports - in this particular form - are of widespread interest, neither do they replace well maintained news content. Given that we had to implement a solution to automatically extract the content from the approved reports, as Martin stated, I wonder if this is worth the effort. A news section with targeted information bits might be a more relevant way to go, as long at it is well maintained. E.g., I could imagine snippets like - Struts Users Facebook Site hits 1.000.000 likes - Struts Downloads peeked with the release of 4.0.1 - Externally maintained Struts 2 BootQueryNateStrap-Plugin version 9.8.7 released - Appfuse 20.12 now with Struts2 LiquidDiamondAngular Theme support baked in - ApacheCon NA 2015 to feature five Struts 4 talks - John Doe has written an interesting blog post on Configuration over Convention in Struts 4 As for the noteworthy stuff assembled into the quarterly board report, I could volunteer to add a rehash-and-update-site workflow at around the time the report is submitted. But I think more voluntary help would be needed to keep such a news stream relevant. If we go for adding approved board reports
Re: Using fluido once available
On Mon, Nov 26, 2012 at 12:41 PM, Lukasz Lenart lukaszlen...@apache.orgwrote: 2012/11/25 Johannes Geppert jo...@apache.org: 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 fastupl...@outlook.com 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 lukaszlen...@apache.org wrote: 2012/11/19 Fastupload fastupl...@outlook.com: 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 fastupl...@outlook.com 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 umeshawas...@gmail.com 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 fastupl...@outlook.com
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 rgie...@apache.org 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/display/S2PLUGINS/Home
Regard,
- René
Am 12.11.12 16:13, schrieb Wes Wannemacher:
Another approach would be for you to take a look at our plugin API and
build a plugin for integrating your framework into a Struts 2 web-app.
-Wes
On Mon, Nov 12, 2012 at 7:39 AM, Fastupload fastupl...@outlook.com
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
Re: Struts 1 - what does the future hold?
On Thu, Nov 15, 2012 at 10:56 AM, Brian Holzer bhol...@sgi.sk.ca 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 fastupl...@outlook.com 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: File upload interceptor/filter dispatcher temp file cleanup
On Thu, Jun 21, 2012 at 12:05 PM, Dave Newton davelnew...@gmail.com 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 davelnew...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2012/6/11 Martin Cooper mfncoo...@gmail.com: 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 wsm...@gmail.com wrote: On Thu, Jun 7, 2012 at 11:16 AM, Johannes Geppert jo...@apache.org 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 srrem...@excite.com 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 maurizio.cucchi...@gmail.com 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 lukasz.len...@googlemail.com 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
grobme...@gmail.com 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
}
body
s2:component id=blub /
/body
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 umeshawas...@gmail.com 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 davelnew...@gmail.com 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 steven.beni...@gmail.comwrote: 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 umeshawas...@gmail.com 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 davelnew...@gmail.com 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 rgie...@apache.org 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 herma...@aixcept.de 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
2011/12/19 Łukasz Lenart lukasz.len...@googlemail.com: 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 Mon, Dec 19, 2011 at 2:49 AM, Rene Gielen gie...@it-neering.net wrote: On Mon, 19 Dec 2011 09:35:33 +0100, Łukasz Lenart lukasz.len...@googlemail.com 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
On Sun, Dec 18, 2011 at 1:58 PM, Rene Gielen rene.gie...@googlemail.com 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 mart...@apache.org: 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, I fail to see improvement in doing this - as long as we agree on testing seriously before voting. Right. And as long as the process is inclusive of those who wish to participate in the testing and quality determination. -- 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
Re: [VOTE] Struts 2.3.1 Vote
2011/12/12 Łukasz Lenart lukasz.len...@googlemail.com: 2011/12/9 Martin Cooper mart...@apache.org: 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
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 lukasz.len...@googlemail.com: 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
On Fri, Dec 9, 2011 at 6:53 AM, Maurizio Cucchiara mcucchi...@apache.org 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 lukasz.len...@googlemail.comwrote: 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 w...@apache.org 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 grobme...@gmail.com wrote: Hello Martin, On Sun, Nov 27, 2011 at 3:57 AM, Martin Cooper mfncoo...@gmail.com 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 div class=sectonh2... - 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 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. This dark menu bar is called topbar in fludio terms. It is pretty easy to disable it and I have no problems with doing that. Basically it contains the same link as on the left side. I have left it in b/c many people seem to like that nowadays. Anyway, I am with you and remove it. Btw, the covering of the logo is b/c the topbar is fixed position
Re: Using fluido once available
On Sat, Nov 26, 2011 at 2:51 PM, Christian Grobmeier grobme...@gmail.com 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 div class=sectonh2... - 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 mcucchi...@apache.org 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 mcucchi...@apache.org 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 published the fluido verson of struts website http://people.apache.org/~mcucchiara/struts/www/ Let's see the first impressions (for example I just realized that fluido doesn't provide the links to S1, S2 on top bar). 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 16:50, Christian
Re: Options on UTF-8 Localizations
On Mon, Nov 21, 2011 at 10:20 AM, Christian Grobmeier grobme...@gmail.com 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 constant name=struts.i18n.encoding value=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 rene.gie...@googlemail.com wrote: Am 18.10.11 00:45, schrieb Łukasz Lenart: 2011/10/18 Rene Gielen rene.gie...@googlemail.com: 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 mcucchi...@apache.org 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 jo...@apache.org 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 lukasz.len...@googlemail.com 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 davelnew...@gmail.com: 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 lukasz.len...@googlemail.com 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 davelnew...@gmail.com: 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 lukasz.len...@googlemail.com 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 davelnew...@gmail.com: 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 maurizio.cucchi...@gmail.com wrote: Hi Dave, do you mean JIRA admin (INFRA team) or JIRA project (Struts) admin? On 27 June 2011 12:57, Dave Newton davelnew...@gmail.com 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 mcucchi...@apache.org 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 lukasz.len...@googlemail.com 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 d...@newfield.org: 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 gie...@it-neering.net 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 lukasz.len...@googlemail.com 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 lukasz.len...@googlemail.com: 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 maurizio.cucchi...@gmail.com: 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=13034888page=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=1103138r2=1104581diff_format=h On 7 June 2011 18:36, Maurizio Cucchiara maurizio.cucchi...@gmail.com wrote: and the sad thing that is not yet finished :) On 7 June 2011 18:27, Jason Pyeron jpye...@pdinc.us 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 jpye...@pdinc.us 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 1.6 Regards -- Lukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/6/7 Jason Pyeron jpye...@pdinc.us: Would like some input before filing an issue. 1: Should xwork-core be built with java5 or 6? 2: If java5, does anyone else have a clean build on revision 1133024? snip/ -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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 -- Maurizio Cucchiara -- 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: Unit test error for xwork-core in trunk
On Wed, Jun 1, 2011 at 6:41 PM, Dave Newton davelnew...@gmail.com 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 jo...@apache.org 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 jeffrey.bl...@yahoo.com 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
lukasz.len...@googlemail.com 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 gie...@it-neering.net:
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=1098322view=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=1098322r1=1098321r2=1098322view=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.BeanManager;
import javax.enterprise.inject.spi.InjectionTarget;
-import javax.enterprise.context.spi.CreationalContext;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Map;
-import java.util.HashMap;
+import java.util.concurrent.ConcurrentHashMap;
/**
* CdiObjectFactory allows Struts 2 managed objects, like Actions,
Interceptors or Results, to be injected by a Contexts
@@ -52,7 +52,7 @@ public class CdiObjectFactory extends Ob
protected BeanManager beanManager;
protected CreationalContext ctx;
- MapClass?, InjectionTarget? injectionTargetCache = new
HashMapClass?, InjectionTarget?();
+ MapClass?, InjectionTarget? injectionTargetCache = new
ConcurrentHashMapClass
[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 jpye...@pdinc.us 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 wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 8:53 AM, Apache Hudson Server hud...@hudson.apache.org 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 jo...@apache.org 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 sx:head / 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 sx:head debug=true / 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 Thu, Feb 17, 2011 at 7:35 AM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2011/2/17 Wendy Smoak wsm...@gmail.com: snip/ 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: A new release
On Mon, Jan 31, 2011 at 10:52 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2011/1/31 Paul Benedict pbened...@apache.org: 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: JIRA - can't edit issues anymore
On Mon, Jan 31, 2011 at 10:40 PM, Paul Benedict pbened...@apache.org 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 maurizio.cucchi...@gmail.com 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 lind...@yahoo-inc.com 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 maurizio.cucchi...@gmail.com 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.htmlhl=itbtnG=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 mart...@apache.org wrote: On Wed, Jan 26, 2011 at 7:03 PM, Maurizio Cucchiara maurizio.cucchi...@gmail.com 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 lind...@yahoo-inc.com 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.htmlhl=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 mart...@apache.org 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 -- Maurizio Cucchiara - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Volunteers page
On Wed, Jan 26, 2011 at 7:03 PM, Maurizio Cucchiara maurizio.cucchi...@gmail.com 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 lind...@yahoo-inc.com 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.htmlhl=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 mart...@apache.org 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 lind...@yahoo-inc.com 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 pbened...@apache.org 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 gie...@it-neering.net 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 lukasz.len...@googlemail.com 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 lukasz.len...@googlemail.com 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 pbened...@apache.org 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 lukasz.len...@googlemail.com 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 ela.technoc...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/12/5 Martin Cooper mart...@apache.org: 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: params in the url - struts 2
On Sat, Dec 4, 2010 at 3:22 AM, clockdva242 sb.stefanobio...@gmail.com 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: Unapproved licenses
On Thu, Dec 2, 2010 at 12:26 AM, Lukasz Lenart lukasz.len...@googlemail.com 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: 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, osagit@orange-ftgroup.com wrote:
I downloaded the struts2 samples 2.2.1
Ok in struts2-blank-2.2.1\example\Login.jsp
I added s:submit type=image src=.../ 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.
s:submit type=image src=../images/image.gif/
2010/11/25 osagit@orange-ftgroup.com:
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/ input type=image#rt/ #if
parameters.label?? ...
/#if
Consequently, when using the struts tag s:submit type=image src= 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 confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed
or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
-
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
Re: Struts2 threading in a Java EE application server environment
On Mon, Oct 18, 2010 at 8:02 PM, Phil Adams padam...@gmail.com 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: JIRA down/moved?
On Mon, Aug 23, 2010 at 11:27 AM, Dave Newton davelnew...@gmail.com 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: Dojo plugin
On Sat, Aug 21, 2010 at 8:51 AM, Dave Newton davelnew...@gmail.com 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: 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 shekher.awas...@gmail.com 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: Move OGNL to Apache.org
On Wed, May 26, 2010 at 12:28 AM, Lukasz Lenart lukasz.len...@googlemail.com 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: [jira] Closed: (INFRA-2682) Nexus access for Struts
On Tue, May 25, 2010 at 1:51 PM, Wes Wannemacher w...@wantii.com wrote: On Tue, May 25, 2010 at 10:35 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, May 25, 2010 at 10:21 AM, Lukasz Lenart lukasz.len...@googlemail.com 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 id / 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
lukasz.len...@googlemail.com wrote:
2010/5/15 Martin Cooper mart...@apache.org:
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:
repository
idstruts-staging/id
nameApache Struts Staging Repository/name
urlscp://people.apache.org/www/people.apache.org/builds/struts/${project.version}/m2-staging-repository/url
/repository
snapshotRepository
uniqueVersiontrue/uniqueVersion
idapache.snapshots/id
nameApache Development Snapshot Repository/name
urlscp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository/url
/snapshotRepository
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 lukaszlen...@apache.org: Author: lukaszlenart Date: Sun May 23 07:55:13 2010 New Revision: 947374 URL: http://svn.apache.org/viewvc?rev=947374view=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=947374r1=947373r2=947374view=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 lukaszlen...@apache.org -sig 3 DD8B8819 2009-12-16 Lukasz Lenart lukaszlen...@apache.org -sub 4096g/66EFAD45 2009-12-16 -sig DD8B8819 2009-12-16 Lukasz Lenart lukaszlen...@apache.org +pub 4096R/63AFBB1F 2010-05-23 + Key fingerprint = 0E00 8698 344E 62B9 0633 B7C6 2841 6106 63AF BB1F +uid Lukasz Lenart (Signing Apache Distributions) lukaszlen...@apache.org +sig 3 63AFBB1F 2010-05-23 Lukasz Lenart (Signing Apache Distributions) lukaszlen...@apache.org -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 +tEZMdWthc3ogTGVuYXJ0IChTaWduaW5nIEFwYWNoZSBEaXN0cmlidXRpb25zKSA8 +bHVrYXN6bGVuYXJ0QGFwYWNoZS5vcmc+iQI4BBMBAgAiBQJL+NwAAhsDBgsJCAcD +AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAoQWEGY6+7H8sMD/92MJ2srnFeR7h5ULWr +FKU8ynBgL4ghfmEF6/2InxUtZG
Re: [jira] Closed: (INFRA-2682) Nexus access for Struts
On Wed, May 12, 2010 at 4:42 AM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2010/5/12 Wes Wannemacher w...@wantii.com: 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 lukasz.len...@googlemail.com 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 mart...@apache.org 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 b...@benmccann.com 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 mart...@apache.org 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 benjamin.j.mcc...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/27 Lukasz Lenart lukasz.len...@googlemail.com: 2010/1/27 Martin Cooper mart...@apache.org: 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 b...@benmccann.com 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 mart...@apache.org 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 benjamin.j.mcc...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/27 Lukasz Lenart lukasz.len...@googlemail.com: 2010/1/27 Martin Cooper mart...@apache.org: 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 benjamin.j.mcc...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/27 Lukasz Lenart lukasz.len...@googlemail.com: 2010/1/27 Martin Cooper mart...@apache.org: 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/
On Tue, Feb 9, 2010 at 7:22 AM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2010/1/27 Lukasz Lenart lukasz.len...@googlemail.com: 2010/1/27 Martin Cooper mart...@apache.org: 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
Re: [VOTE 2] Release Struts 2 Maven Archetypes v2.1.8.1
On Sun, Jan 31, 2010 at 11:46 AM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2010/1/19 Lukasz Lenart lukasz.len...@googlemail.com: 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
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, lukaszlen...@apache.org wrote: Author: lukaszlenart Date: Wed Jan 27 07:44:32 2010 New Revision: 903559 URL: http://svn.apache.org/viewvc?rev=903559view=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=903559view=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 @@ +project xmlns=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; + modelVersion4.0.0/modelVersion + parent + groupIdorg.apache.struts/groupId + artifactIdstruts2-plugins/artifactId + version2.2.0-SNAPSHOT/version + /parent + + groupIdorg.apache.struts/groupId + artifactIdstruts2-gxp-plugin/artifactId + packagingjar/packaging + nameStruts 2 GXP Plugin/name + urlhttp://struts.apache.org/url + + scm + connectionscm:svn:http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-gxp-plugin/connection + developerConnectionscm:svn:https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-gxp-plugin/developerConnection + urlhttp://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/struts2-gxp-plugin/url + /scm + + dependencies + dependency + groupIdorg.apache.struts/groupId + artifactIdstruts2-core/artifactId + version2.2.0-SNAPSHOT/version + /dependency + dependency + groupIdjavax.servlet/groupId + artifactIdservlet-api/artifactId + version2.4/version + scopeprovided/scope + /dependency + !-- + Until GXP is added to the Google Maven Repository in early 2010 (http://code.google.com/p/gxp/issues/detail?id=5) + Download http://gxp.googlecode.com/files/gxp-0.2.4-beta.jar + Run the following at the command line (do not use WindowsPowershell) + mvn install:install-file -DgroupId=com.google -DartifactId=gxp -Dversion=0.2.4-BETA -Dpackaging=jar -Dfile=gxp-0.2.4-beta.jar + -- + dependency + groupIdcom.google/groupId + artifactIdgxp/artifactId + version0.2.4-BETA/version + /dependency + dependency + groupIdjunit/groupId + artifactIdjunit/artifactId + version3.8.1/version + scopetest/scope + /dependency + dependency + groupIdcom.google.collections/groupId + artifactIdgoogle-collections/artifactId + version1.0/version + /dependency + /dependencies + + build + defaultGoalinstall/defaultGoal + plugins + plugin + artifactIdmaven-compiler-plugin/artifactId + configuration
Re: XWork has landed!
On Mon, Jan 18, 2010 at 9:24 AM, Musachy Barroso musa...@gmail.com 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 w...@wantii.com 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 musa...@gmail.com 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 mart...@apache.org wrote: On Fri, Jan 15, 2010 at 10:23 AM, Musachy Barroso musa...@gmail.com 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 musa...@gmail.com wrote: yes I meant under struts2, sorry for the confusion On Fri, Jan 8, 2010 at 5:22 PM, Martin Cooper mart...@apache.org wrote: On Fri, Jan 8, 2010 at 4:20 PM, Musachy Barroso musa...@gmail.com 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 mart...@apache.org wrote: On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso musa...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/6 Musachy Barroso musa...@gmail.com: 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
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 lukasz.len...@googlemail.com wrote: 2010/1/6 Frans Thamura fr...@meruvian.org: 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
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: XWork has landed!
On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso musa...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/6 Musachy Barroso musa...@gmail.com: 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 Fri, Jan 8, 2010 at 4:20 PM, Musachy Barroso musa...@gmail.com 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 mart...@apache.org wrote: On Fri, Jan 8, 2010 at 11:54 AM, Musachy Barroso musa...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/6 Musachy Barroso musa...@gmail.com: 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 4:29 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Jan 8, 2010 at 5:20 PM, Musachy Barroso musa...@gmail.com 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 5:11 PM, Paul Benedict pbened...@apache.org 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 musa...@gmail.com 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 wsm...@gmail.com wrote: On Fri, Jan 8, 2010 at 5:20 PM, Musachy Barroso musa...@gmail.com 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 5:40 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Jan 8, 2010 at 6:27 PM, Martin Cooper mart...@apache.org 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 Wed, Jan 6, 2010 at 9:27 AM, Musachy Barroso musa...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2009/12/28 Paul Benedict pbened...@apache.org: 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:18 PM, Musachy Barroso musa...@gmail.com 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 lukasz.len...@googlemail.com wrote: 2010/1/5 Wendy Smoak wsm...@gmail.com: 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? profiles profile idrelease/id build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-gpg-plugin/artifactId executions execution idsign-artifacts/id phaseverify/phase goals goalsign/goal /goals /execution /executions /plugin /plugins /build /profile /profiles 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 w...@wantii.com wrote: On Tue, Jan 5, 2010 at 3:43 PM, Martin Cooper mart...@apache.org 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: XWork has landed!
On Mon, Dec 28, 2009 at 10:29 AM, Wes Wannemacher w...@wantii.com 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 musa...@gmail.com 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 mart...@apache.org wrote: On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict pbened...@apache.org 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 lukasz.len...@googlemail.com wrote: 2009/12/27 Martin Cooper mart...@apache.org: 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 Mon, Dec 28, 2009 at 11:37 AM, Wes Wannemacher w...@wantii.com wrote: On Mon, Dec 28, 2009 at 2:16 PM, Paul Benedict pbened...@apache.org 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: Moving Struts 1 Doc to Confluence
On Sat, Dec 26, 2009 at 11:21 PM, Paul Benedict pbened...@apache.org 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 mart...@apache.org wrote: On Sat, Dec 26, 2009 at 5:42 PM, Paul Benedict pbened...@apache.org 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 mart...@apache.org wrote: On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict pbened...@apache.org wrote: Thanks Martin and Wendy for your replies. On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper mart...@apache.org 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 - 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
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: [VOTE] Accept the XWork project as donated by OpenSymphony
On Sun, Dec 27, 2009 at 10:23 AM, Niall Pemberton niall.pember...@gmail.com 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 mart...@apache.org 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
Re: Moving Struts 1 Doc to Confluence
On Fri, Dec 25, 2009 at 10:51 PM, Paul Benedict pbened...@apache.org 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: Moving Struts 1 Doc to Confluence
On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict pbened...@apache.org wrote: Thanks Martin and Wendy for your replies. On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper mart...@apache.org 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
[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: [VOTE] Accept the XWork project as donated by OpenSymphony
My own vote: On Sat, Dec 26, 2009 at 11:11 AM, Martin Cooper mart...@apache.org 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
Re: Moving Struts 1 Doc to Confluence
On Sat, Dec 26, 2009 at 5:42 PM, Paul Benedict pbened...@apache.org 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 mart...@apache.org wrote: On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict pbened...@apache.org wrote: Thanks Martin and Wendy for your replies. On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper mart...@apache.org 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: Jira at opensymphony
On Mon, Dec 21, 2009 at 9:15 AM, Musachy Barroso musa...@gmail.com 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 lukasz.len...@googlemail.com 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 12:27 PM, Wes Wannemacher w...@wantii.com 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 lukasz.len...@googlemail.com wrote: 2009/12/16 Martin Cooper mart...@apache.org: 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
Re: Version number ordering
On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict pbened...@apache.org 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 mart...@apache.org wrote: On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher w...@wantii.com 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 lukasz.len...@googlemail.com wrote: 2009/12/16 Martin Cooper mart...@apache.org: 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
Re: Version number ordering
On Thu, Dec 17, 2009 at 3:40 PM, Paul Benedict pbened...@apache.org 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 mart...@apache.org wrote: On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict pbened...@apache.org 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 mart...@apache.org wrote: On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher w...@wantii.com 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 lukasz.len...@googlemail.com wrote: 2009/12/16 Martin Cooper mart...@apache.org: 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
Version number ordering
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. -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Shared filters in JIRA
On Wed, Dec 16, 2009 at 2:13 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: Hi, I noticed I'm not able to create shared filters - as is mentioned in release guide. Regarding that [1] I should have assigned Create Shared Filter permission to do that, can someone do it for me? Or should I contact with infra? I just gave you jira-admin, so you should be able to take care of it now. ;-) -- Martin Cooper [1] http://jira.atlassian.com/browse/JRA-2054 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
Re: struts 2.2 and guice
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso musa...@gmail.com wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. If it's internal use only, so to speak, then why do we care about whether it's JSR annotations versus Guice annotations, and why would we want to make it pluggable? Those are things that app authors might care about, but not something we need to complicate the internal implementation with. -- Martin Cooper On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - 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
