Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
Greg Reddin ha scritto: On Jun 9, 2006, at 3:10 AM, Antonio Petrelli wrote: I don't think it is what you mean, because this is already there. Can you clarify what you mean with an example? No that's what I meant. I just never have actually used that. How does that look on the JSP doing ? The tag is perfectly the same, the only difference is that the nested definition is also evaluated. You'd think I'd know this already :-) Err... well yes... this is because I asked you for an example. Anyway this kind of things happens very often to me, if you don't use a thing you don't know its existence, right? :-) If that works the way I think it does then I'd much prefer that than the "nested" tiles. If you are thinking of "tiles inside tiles" they work perfectly. :-) I'm not against support for the nested tiles, I'd probably just never use it myself. I think it makes things look cleaner if you do something like the above. I don't think it is a question of clearness, but someone could abuse of the presence of nested Tiles, e.g. repeating the same code again and again. Anyway I am going to write some code to support nested Tiles and when I'm finished I will submit to your judgment :-) I will start from the SVN committed code (with no patch made by me, I mean). Of course I rarely use nested anonymous classes with Java either. But it's just a personal preference. I agree with you, Java anonymous classes are very obscure. I prefer inner classes or normal classes in some "internal" package. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
I don't think it is a question of clearness, but someone could abuse of the presence of nested Tiles, e.g. repeating the same code again and again. Anyway I am going to write some code to support nested Tiles and when I'm finished I will submit to your judgment :-) I will start from the SVN committed code (with no patch made by me, I mean). Long long time ago in a bussiness far away... (I've moved location and bussiness) I had to wrote a tree-menu (no faces!) and I used a recursive tile... inserting itself again and again and again... which created all the JS vars and code for a tree strutcure from Java Menu-Like structure. It performed not-so-bad (If I recall correctly those was struts 1.2.insert_low_number_here), but we ran into some troubles with flush'ing and some non-standard locales under I.E. 5 for Mac, but those were M$ and IE problems, not tiles. Good luck. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tiles] Non-standard locales (WAS: Re: [Tiles] Inline definitions)
Juan Ara ha scritto: It performed not-so-bad (If I recall correctly those was struts 1.2.insert_low_number_here), but we ran into some troubles with flush'ing and some non-standard locales under I.E. 5 for Mac, but those were M$ and IE problems, not tiles. I am not sure about that. Sorry for my lack of knowledge, but what are "non-standard locales"? I mean, probably there is something in Tiles that is not taken in consideration at all. I don't want to hide a bug that may appear lately. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Non-standard locales (WAS: Re: [Tiles] Inline definitions)
Antonio Petrelli wrote: Juan Ara ha scritto: It performed not-so-bad (If I recall correctly those was struts 1.2.insert_low_number_here), but we ran into some troubles with flush'ing and some non-standard locales under I.E. 5 for Mac, but those were M$ and IE problems, not tiles. I am not sure about that. Sorry for my lack of knowledge, but what are "non-standard locales"? I mean, probably there is something in Tiles that is not taken in consideration at all. I don't want to hide a bug that may appear lately. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Drawing Latin-1 characters into JS variables and JS code at all performs badly on IE on Macs. For example: var menu = "España"; //whould break some I.E 5 on macs Even linebreaks performed bad. I remember (it was a hard hard day) myself rounding all jsp code with <% %> in a way like this:
Re: [Tiles] Non-standard locales (WAS: Re: [Tiles] Inline definitions)
Juan Ara ha scritto: I'm not sure if I'd be able to get a working sample from that time, I changed work and location and I don't think will have an example on my old backups. If you want, I can try to ask my former employeer to submit a bug or to send some examples. Don't bother, I thought it was a Tiles problem with locales, or at least a Struts' problem. Now I know it is (or was) DEFINITELY an IE-5-on-mac problem. You have all my sympathy for those bad days :-) Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action 2- how stable
If you mean use to write a production application, then I'd recommend going with WebWork 2.2 for now. WW2/SAF2 has it's own take on HTML tags. While it would seem possible to write an interceptor that would support the SAF2 tag envinroment, I don't think anyone has volunteered to write it. You can run both frameworks in the same web application, though. For a work in progress, existing workflows could be handled by SAF1 and new workflows could be handled by SAF2. But, I think very few people would be interesting in upgrading a deployed application. Even today, many people have not upgraded deployed 1.1 applications to 1.2. There is an Ajax theme in WebWork 2.2 and even more support is being added for SAF2. -Ted. On 6/12/06, netsql <[EMAIL PROTECTED]> wrote: How stable is action 2 to use? Do the old Struts HTML tags work? Does it come w/ Ajax support built in? tia, .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Proposal: Remove explicit support for action!method syntax
On 6/11/06, Don Brown <[EMAIL PROTECTED]> wrote: Thoughts? We used the ! idiom extensively in the WW MailReader and WW CookBook in the sandbox. I'll update those for the latest build to see how effective if the wildcard workaound. Are we going to introduce wildcard support in WebWork 2.2.2.1? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
On 6/9/06, Don Brown <[EMAIL PROTECTED]> wrote: Also, I'll be moving items from our TODO lists over to issues so be prepared for more emails :) Which TODO lists? This JIRA report [1] should contain everything we are planning for in the 2.0.0 release slated for August. For 2.x, I'd like to take this one step farther and ask that ALL SVN commits to Action2 refer to a JIRA issue, even if we have to create a new one. I realize this means a bit of extra work sometimes, but if a change is worth committing, then it's worth having a JIRA issue. We already conduct a lot of the development discussions on Bugzilla tickets, and I'd like to try to make this the expected norm for Action2. The advantage is that development discussions remain linked to the commits. The SVN commit refers to a JIRA ticket, which contains all the background discussions. Conversely, thanks to the JIRA-SVN plugin, we can go from a ticket to the corresponding commits. The plugin should pickup any unadorned reference to a JIRA ticket. I tend to put it by itself on the first line, just to be sure, followed by the usual commit message. (Though, it doesn't look like the plugin is working quite yet. ) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] download
Dear DevTeam, We are at arvato systems Hungary, wanted to tryout SHALE framework, but none of the binary zip file was found in the given access path: http://people.apache.org/builds/struts/nightly/struts-shale/ The directory is empty, and we don't know how to get the beta. Can you help us with a working binary? Best wishes, Tibor Nagy - arvato systems Hungary Kft. H-1038 Budapest Ráby Mátyás u. 26. Telefon: (36-1) 453-4100 Fax: (36-1) 453-4101
Re: [action2] Struts Action 2.0.0 Issues
On 6/12/06, Ted Husted <[EMAIL PROTECTED]> wrote: The plugin should pickup any unadorned reference to a JIRA ticket. I tend to put it by itself on the first line, just to be sure, followed by the usual commit message. (Though, it doesn't look like the plugin is working quite yet. ) It was working, then it quit. If it's not something that we can fix, an infrastructure ticket needs to be opened. (I think I saw a note about the same thing on one of the other ASF JIRAs, come to think of it.) When it's working, it seems to pick up issues numbers anywhere in the text. I referred to a Maven issue in one of my messages, and now the commit is listed in the 'External References' section on that issue. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] download
On 6/12/06, Nagy Tibor <[EMAIL PROTECTED]> wrote: We are at arvato systems Hungary, wanted to tryout SHALE framework, but none of the binary zip file was found in the given access path: http://people.apache.org/builds/struts/nightly/struts-shale/ The directory is empty, and we don't know how to get the beta. There is a link to Shale 1.0.2 (Alpha) on the downloads page: http://struts.apache.org/downloads.html Sorry for the inconvenience. We're in the process of converting to Maven 2, and nightly builds should be back soon. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] Maven 2 profile activation
On [EMAIL PROTECTED], Roland Asmann pointed out that a profile can be activated if a certain property is *not* present. We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. Be sure to 'mvn clean' when you switch implementations, or the webapps will have both myfaces and the RI in WEB-INF/lib. (I think Maven 2.1 will better handle the concept of 'This jar provides an implementation of xyz specification' during dependency resolution.) With defaultGoal=install in the pom, you can now simply execute 'mvn' from the top of the branch, and it should work. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] download
On 6/12/06, Nagy Tibor <[EMAIL PROTECTED]> wrote: Dear DevTeam, We are at arvato systems Hungary, wanted to tryout SHALE framework, but none of the binary zip file was found in the given access path: http://people.apache.org/builds/struts/nightly/struts-shale/ The directory is empty, and we don't know how to get the beta. Can you help us with a working binary? At the moment, nightly build creation is disabled because we are in the midst of converting the process of building Shale from Ant to Maven2. This process is nearing completion, at which point we will re-enable creating nightly builds of Shale. In the short term, it is necessary to build Shale from sources, as described on the website[1]. Craig [1] http://struts.apache.org/struts-shale/building.html Best wishes, Tibor Nagy - arvato systems Hungary Kft. H-1038 Budapest Ráby Mátyás u. 26. Telefon: (36-1) 453-4100 Fax: (36-1) 453-4101
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On [EMAIL PROTECTED], Roland Asmann pointed out that a profile can be activated if a certain property is *not* present. We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. Be sure to 'mvn clean' when you switch implementations, or the webapps will have both myfaces and the RI in WEB-INF/lib. (I think Maven 2.1 will better handle the concept of 'This jar provides an implementation of xyz specification' during dependency resolution.) With defaultGoal=install in the pom, you can now simply execute 'mvn' from the top of the branch, and it should work. Cool idea. So, I tried "mvn clean" then "mvn -Pjsf=ri" from the top of the branch. The sample apps are still packaged with the MyFaces API and IMPL jars (see my comment on SHALE-179). -- Wendy Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Note that this is -D for a system property (not -P for a profile id). Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. But this part isn't true -- you'll end up with *both* MyFaces and the RI if you do 'mvn -Pjsfri'. I'll add properties to the other profiles tonight, and we'll switch to only using -D to avoid confusion. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > We now have the MyFaces profile is active if the 'jsf' property is not > set. The JSF RI profile is activated with -Djsf=ri on the command > line. Note that this is -D for a system property (not -P for a profile id). D'oh ... not enough coffee to tell the difference between a "D" and a "P". Using -Pmyfaces and -Pjsfri still works. Profiles can always be > activated by their ids. But this part isn't true -- you'll end up with *both* MyFaces and the RI if you do 'mvn -Pjsfri'. I'll add properties to the other profiles tonight, and we'll switch to only using -D to avoid confusion. That makes sense. -- Wendy Craig
Re: [action2] Proposal: Remove explicit support for action!method syntax
Ted Husted wrote: On 6/11/06, Don Brown <[EMAIL PROTECTED]> wrote: Thoughts? We used the ! idiom extensively in the WW MailReader and WW CookBook in the sandbox. I'll update those for the latest build to see how effective if the wildcard workaound. Are we going to introduce wildcard support in WebWork 2.2.2.1? As I understand the next WebWork release, 2.2.3, it will be mainly just a bug fix release and avoid untested new features. Wildcard support was built into XWork 2.0, which requires Java 5 and has seen considerable work since it was branched. Of course if it was really necessary, support could be backported, but I wouldn't recommend it for a minor release since wildcards need to be tested more thoroughly to see how they affect other parts of Struts. Don -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
Ted Husted wrote: On 6/9/06, Don Brown <[EMAIL PROTECTED]> wrote: Also, I'll be moving items from our TODO lists over to issues so be prepared for more emails :) Which TODO lists? I'm thinking of all the "rough spots" and that short list of features on the release plan. This JIRA report [1] should contain everything we are planning for in the 2.0.0 release slated for August. For 2.x, I'd like to take this one step farther and ask that ALL SVN commits to Action2 refer to a JIRA issue, even if we have to create a new one. I realize this means a bit of extra work sometimes, but if a change is worth committing, then it's worth having a JIRA issue. We already conduct a lot of the development discussions on Bugzilla tickets, and I'd like to try to make this the expected norm for Action2. Agreed. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] Nightly Builds Resumed
For those of you following Shale, you've probably noticed that there have not been any nightly builds available for the past few weeks. This was due to a combination of circumstances, but the primary reason is we've been focusing on migrating the build environment from Ant-based scripts to use Maven2 instead. When completed, it will be *much* easier to build Shale, or applications based on Shale. However, in the mean time, I'm pleased to announce that creation of nightly builds for Shale have been restored. You can get the 20060612 version from: http://people.apache.org/builds/struts/nightly/struts-shale/ NOTES: * The Shale website currently has a bad link to this page (it points at " cvs.apache.org"). That will be fixed soon. In the mean time, use the link above. * When the conversion to Maven2 is complete, the organization of the artifacts published as nightly builds (as well as the organization of Shale releases as well) will be changed. Watch here for an announcement of the date that this goes into effect for the nightly builds. Craig McClanahan
Re: [Action2] STATUS - Documentation
Continues on [http://issues.apache.org/struts/browse/WW-1340] -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
I was looking at the shale-usecaes build under the mvn_reorg branch and it looks like the war is bring everything but the kitchen sink as a dependency. The WEB-INF/lib contains the RI, myfaces, freemarker, struts, ant, and a couple versions of velocity. It it picking this up from cargo or parent project dependencies? Gary -- Original message -- From: "Craig McClanahan" <[EMAIL PROTECTED]> > On 6/12/06, Wendy Smoak wrote: > > > > On 6/12/06, Wendy Smoak wrote: > > > > > We now have the MyFaces profile is active if the 'jsf' property is not > > > set. The JSF RI profile is activated with -Djsf=ri on the command > > > line. > > > > Note that this is -D for a system property (not -P for a profile id). > > > D'oh ... not enough coffee to tell the difference between a "D" and a "P". > > > Using -Pmyfaces and -Pjsfri still works. Profiles can always be > > > activated by their ids. > > > > But this part isn't true -- you'll end up with *both* MyFaces and the > > RI if you do 'mvn -Pjsfri'. > > > > I'll add properties to the other profiles tonight, and we'll switch to > > only using -D to avoid confusion. > > > That makes sense. > > -- > > Wendy > > > Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: I was looking at the shale-usecaes build under the mvn_reorg branch and it looks like the war is bring everything but the kitchen sink as a dependency. The WEB-INF/lib contains the RI, myfaces, freemarker, struts, ant, and a couple versions of velocity. It it picking this up from cargo or parent project dependencies? Did you do a clean recently? A bunch of stuff has changed, and that'll be the only way to get good results, including just MyFaces (if you do "mvn clean install") and just the RI (if you do "mvn -Djsf=ri clean install"). There was also a ton of stuff being inherited from the Spring 1.2.2 POMs ... updating the dependency to 1.2.5 cleared up a lot of that. Gary Craig -- Original message -- From: "Craig McClanahan" <[EMAIL PROTECTED]> > On 6/12/06, Wendy Smoak wrote: > > > > On 6/12/06, Wendy Smoak wrote: > > > > > We now have the MyFaces profile is active if the 'jsf' property is not > > > set. The JSF RI profile is activated with -Djsf=ri on the command > > > line. > > > > Note that this is -D for a system property (not -P for a profile id). > > > D'oh ... not enough coffee to tell the difference between a "D" and a "P". > > > Using -Pmyfaces and -Pjsfri still works. Profiles can always be > > > activated by their ids. > > > > But this part isn't true -- you'll end up with *both* MyFaces and the > > RI if you do 'mvn -Pjsfri'. > > > > I'll add properties to the other profiles tonight, and we'll switch to > > only using -D to avoid confusion. > > > That makes sense. > > -- > > Wendy > > > Craig
Re: [action2] Struts Action 2.0.0 Issues
On 6/12/06, Don Brown <[EMAIL PROTECTED]> wrote: I'm thinking of all the "rough spots" and that short list of features on the release plan. I setup issues for the short list, but not every rough spot. Anyone who is ready, willing, and able to work on any of the others is welcome to create the ticket when the time comes. (And link to it from the release plan.) I also categorized the major rough spots, to make them easier to digest. * http://wiki.apache.org/struts/StrutsActionRelease200 I'm flipping through the other issues now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
On 6/12/06, Ted Husted <[EMAIL PROTECTED]> wrote: For 2.x, I'd like to take this one step farther and ask that ALL SVN commits to Action2 refer to a JIRA issue, even if we have to create a new one. But, we should still try to include a meaningful log message about each commit. The reference to the JIRA issue should not be the only comment. A lot of people *do* review the commit logs, and so we should try and include some kind of a comment as an aid to those trying to follow along. -ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
On 6/12/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/12/06, Ted Husted <[EMAIL PROTECTED]> wrote: > For 2.x, I'd like to take this one step farther and ask that ALL SVN > commits to Action2 refer to a JIRA issue, even if we have to create a > new one. But, we should still try to include a meaningful log message about each commit. The reference to the JIRA issue should not be the only comment. A lot of people *do* review the commit logs, and so we should try and include some kind of a comment as an aid to those trying to follow along. Yes, please. I've seen quite a few commits go by recently with only a JIRA issue reference, and it would be very helpful to have some idea of the purpose of the commit. -- Martin Cooper -ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
Perfect! I agree, we shouldn't make tickets for everything yet, but let developer and user demand drive it. I know turning all this brainstorming talk into specific tickets has helped me to better organize my time and visualize where we are in the development process. Thanks for the hard work! Don Ted Husted wrote: On 6/12/06, Don Brown <[EMAIL PROTECTED]> wrote: I'm thinking of all the "rough spots" and that short list of features on the release plan. I setup issues for the short list, but not every rough spot. Anyone who is ready, willing, and able to work on any of the others is welcome to create the ticket when the time comes. (And link to it from the release plan.) I also categorized the major rough spots, to make them easier to digest. * http://wiki.apache.org/struts/StrutsActionRelease200 I'm flipping through the other issues now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Nightly Builds Resumed
Craig, James and I are going to attempt to setup the Shale continuum server on Wednesday. Should we try to setup the publishing of Shale nightlies as well? Sean On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: For those of you following Shale, you've probably noticed that there have not been any nightly builds available for the past few weeks. This was due to a combination of circumstances, but the primary reason is we've been focusing on migrating the build environment from Ant-based scripts to use Maven2 instead. When completed, it will be *much* easier to build Shale, or applications based on Shale. However, in the mean time, I'm pleased to announce that creation of nightly builds for Shale have been restored. You can get the 20060612 version from: http://people.apache.org/builds/struts/nightly/struts-shale/ NOTES: * The Shale website currently has a bad link to this page (it points at " cvs.apache.org"). That will be fixed soon. In the mean time, use the link above. * When the conversion to Maven2 is complete, the organization of the artifacts published as nightly builds (as well as the organization of Shale releases as well) will be changed. Watch here for an announcement of the date that this goes into effect for the nightly builds. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Nightly Builds Resumed
On 6/12/06, Sean Schofield <[EMAIL PROTECTED]> wrote: Craig, James and I are going to attempt to setup the Shale continuum server on Wednesday. Should we try to setup the publishing of Shale nightlies as well? That would be awesome! But I wouldn't bother setting up the Ant based builds, though; the focus should be on getting the Maven based things to work. A wrinkle is you might have to be a bit adaptable on the assembly stuff, as we're not quite done creating that. And, that actually raises a question about what MyFaces is doing on the topic of sample applications (as well as to solicit advice from other folks here as well). For maximum user benefit, it's nice to ship sample apps "ready to run", with all their dependent jars included. But with four apps already, that would mean lots of jar files duplicated -- which would really bloat an all-in-one download. For the Ant based builds, I took the tack of creating several kinds of artifacts: * A zip of the framework itself (library jars, sources, javadocs) * A zip of the dependencies (which Maven will eliminate the need for * A war file for each example (ideally with a buildable source module and javadocs for the application classes included inside). What do you think of this kind of strategy for Maven based builds as well? Sean Craig
Re: svn commit: r413781 - /struts/shale/branches/mvn_reorg/shale-dist/src/assemble/dist.xml
On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: craigmcc Date: Mon Jun 12 18:40:30 2006 New Revision: 413781 URL: http://svn.apache.org/viewvc?rev=413781&view=rev Log: Add filesets for the rest of the top-level framework modules (but comment out the one for shale-designtime ... I still need to do cleanup work on that module). Issue -- it copies all the sources, but the only shale-*.jar included is the one for core. Also, add an Apache license at the top of the assembly configuration file. Thanks. :) To make it pick up the rest of the jars, add them as in pom.xml. Only shale-core is listed right now. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r413781 - /struts/shale/branches/mvn_reorg/shale-dist/src/assemble/dist.xml
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: craigmcc > Date: Mon Jun 12 18:40:30 2006 > New Revision: 413781 > > URL: http://svn.apache.org/viewvc?rev=413781&view=rev > Log: > Add filesets for the rest of the top-level framework modules (but > comment out the one for shale-designtime ... I still need to do cleanup > work on that module). Issue -- it copies all the sources, but the only > shale-*.jar included is the one for core. Also, add an Apache license > at the top of the assembly configuration file. Thanks. :) To make it pick up the rest of the jars, add them as in pom.xml. Only shale-core is listed right now. Thanks ... noticed they were missing from the pom.xml right after this commit ... see the next one. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Nightly Builds Resumed
On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: For maximum user benefit, it's nice to ship sample apps "ready to run", with all their dependent jars included. But with four apps already, that would mean lots of jar files duplicated -- which would really bloat an all-in-one download. For the Ant based builds, I took the tack of creating several kinds of artifacts: * A zip of the framework itself (library jars, sources, javadocs) * A zip of the dependencies (which Maven will eliminate the need for I think 'jars without dependencies' is possible. Asking for the dependencies, but not the jar they came from, might be more difficult. Could the second one be a library distribution of Shale + dependencies? * A war file for each example (ideally with a buildable source module and javadocs for the application classes included inside). It's usually WEB-INF/src for the sources, but I haven't seen Javadocs in a .war file. WEB-INF/apidocs? (There's an example of copying the sources in Struts Action, probably in apps/pom.xml.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Nightly Builds Resumed
That would be awesome! But I wouldn't bother setting up the Ant based builds, though; the focus should be on getting the Maven based things to work. A wrinkle is you might have to be a bit adaptable on the assembly stuff, as we're not quite done creating that. And, that actually raises a question about what MyFaces is doing on the topic of sample applications (as well as to solicit advice from other folks here as well). I will try to take a look tomorrow night and see where things stand with the maven build. Even if we don't get things running completely the main thing is to get continuum up and running. Also, it will be good to build the jars at a minimum just to make sure everything is compiling and things are running smoothly. We can add the assembly and publish stuff later. For maximum user benefit, it's nice to ship sample apps "ready to run", with all their dependent jars included. But with four apps already, that would mean lots of jar files duplicated -- which would really bloat an all-in-one download. For the Ant based builds, I took the tack of creating several kinds of artifacts: * A zip of the framework itself (library jars, sources, javadocs) Certainly very easy to do with maven. * A zip of the dependencies (which Maven will eliminate the need for * A war file for each example (ideally with a buildable source module and javadocs for the application classes included inside). What do you think of this kind of strategy for Maven based builds as well? Hmmm good idea. This would come in handy with MyFaces now that you mention it. Of course you have to weigh the possible confusion of "missing" dependencies vs. the bandwith you save. How are existing shale users responding on the user list? (I'm not currently monitoring that one.) Craig Sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
I had to wack my m2 shale repos and then rebuild all of the libraries. That was the was the ticket. I'm having trouble building shale-test. Is anyone seeing this error? [INFO] [compiler:compile] Compiling 34 source files to c:\shale2\mvn_reorg\shale-test\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\shale2\mvn_reorg\shale-test\src\main\java\org\apache\shale\test\mock\MockServ letContext.java:[53,7] org.apache.shale.test.mock.MockServletContext is not abst ract and does not override abstract method getContextPath() in javax.servlet.Ser vletContext -- Original message -- From: "Craig McClanahan" <[EMAIL PROTECTED]> > On 6/12/06, Gary VanMatre wrote: > > > > I was looking at the shale-usecaes build under the mvn_reorg branch and it > > looks like the war is bring everything but the kitchen sink as a > > dependency. The WEB-INF/lib contains the RI, myfaces, freemarker, struts, > > ant, and a couple versions of velocity. > > > > It it picking this up from cargo or parent project dependencies? > > > Did you do a clean recently? A bunch of stuff has changed, and that'll be > the only way to get good results, including just MyFaces (if you do "mvn > clean install") and just the RI (if you do "mvn -Djsf=ri clean install"). > There was also a ton of stuff being inherited from the Spring 1.2.2 POMs ... > updating the dependency to 1.2.5 cleared up a lot of that. > > > Gary > > > Craig > > > -- Original message -- > > From: "Craig McClanahan" > > > > > On 6/12/06, Wendy Smoak wrote: > > > > > > > > On 6/12/06, Wendy Smoak wrote: > > > > > > > > > We now have the MyFaces profile is active if the 'jsf' property is > > not > > > > > set. The JSF RI profile is activated with -Djsf=ri on the command > > > > > line. > > > > > > > > Note that this is -D for a system property (not -P for a profile id). > > > > > > > > > D'oh ... not enough coffee to tell the difference between a "D" and a > > "P". > > > > > > > Using -Pmyfaces and -Pjsfri still works. Profiles can always be > > > > > activated by their ids. > > > > > > > > But this part isn't true -- you'll end up with *both* MyFaces and the > > > > RI if you do 'mvn -Pjsfri'. > > > > > > > > I'll add properties to the other profiles tonight, and we'll switch to > > > > only using -D to avoid confusion. > > > > > > > > > That makes sense. > > > > > > -- > > > > Wendy > > > > > > > > > Craig > >
Re: [action2] Struts Action 2.0.0 Issues
Speaking of reviewing the commit messages... can we get FishEye set up? I'd love to use RSS to review the commits :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=33879&messageID=66381#66381 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Proposal: Remove explicit support for action!method syntax
Don, I'm totally in favor of that, but only if we make sure that struts-action-default.xml (originally webwork-default.xml) includes this pattern as a default. Does that seem fair? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34032&messageID=66382#66382 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Proposal: Remove explicit support for action!method syntax
What do you mean? Every action would have the option to use this pattern. How would we set it as the default for all actions? Don Patrick Lightbody wrote: Don, I'm totally in favor of that, but only if we make sure that struts-action-default.xml (originally webwork-default.xml) includes this pattern as a default. Does that seem fair? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34032&messageID=66382#66382 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
On 6/12/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: Speaking of reviewing the commit messages... can we get FishEye set up? I'd love to use RSS to review the commits :) That was one reason we split the lists, right? If it helps, the official list archives have an Atom feed link: http://mail-archives.apache.org/mod_mbox/struts-commits/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Nightly Builds Resumed
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > For maximum user benefit, it's nice to ship sample apps "ready to run", with > all their dependent jars included. But with four apps already, that would > mean lots of jar files duplicated -- which would really bloat an all-in-one > download. For the Ant based builds, I took the tack of creating several > kinds of artifacts: > > * A zip of the framework itself (library jars, sources, javadocs) > > * A zip of the dependencies (which Maven will eliminate the need for I think 'jars without dependencies' is possible. Asking for the dependencies, but not the jar they came from, might be more difficult. Could the second one be a library distribution of Shale + dependencies? Right now we're creating the framework distro with all the Shale jars + the dependencies ... that seems like the most convenient packaging for a non-Maven user, and the size is currently just over 9mb, which shouldn't be any big deal. (Interestingly, the Shale part of that is < 400k ... it's nice to not have to implement everything JSF already provides :-). So I don't really see a need for a separate dependencies-only distro. * A war file for each example (ideally with a buildable source module > and javadocs for the application classes included inside). It's usually WEB-INF/src for the sources, but I haven't seen Javadocs in a .war file. WEB-INF/apidocs? (There's an example of copying the sources in Struts Action, probably in apps/pom.xml.) The other way we could do this would be build a "src/main/assembly" directory for each webapp, and package sources/javadocs/war file with the POM in the expected place (top level directory). It's marginally more complicated for someone to have to extract the WAR, but the project would look like an out-of-the-box Maven module. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
On 6/12/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: I had to wack my m2 shale repos and then rebuild all of the libraries. That was the was the ticket. I'm having trouble building shale-test. Is anyone seeing this error? [INFO] [compiler:compile] Compiling 34 source files to c:\shale2\mvn_reorg\shale-test\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\shale2\mvn_reorg\shale-test\src\main\java\org\apache\shale\test\mock\MockServ letContext.java:[53,7] org.apache.shale.test.mock.MockServletContext is not abst ract and does not override abstract method getContextPath() in javax.servlet.Ser vletContext Hmm ... getContextPath() was added to the Servlet API in 2.4, so you'd get an error like this if you compiled against the 2.4 version of the API. We don't explicitly specify a version in the test framework's POM, so for me (and I'd guess for Wendy too) it's picking up a 2.3 version of the servlet API. Since Shale as a whole depends on Servlet 2.4, I'm going to go through all the POMs and make sure we're explicit about the version number ... and also clean up any problems that this causes (including this one). Look for a commit later this evening. Craig -- Original message -- From: "Craig McClanahan" <[EMAIL PROTECTED]> > On 6/12/06, Gary VanMatre wrote: > > > > I was looking at the shale-usecaes build under the mvn_reorg branch and it > > looks like the war is bring everything but the kitchen sink as a > > dependency. The WEB-INF/lib contains the RI, myfaces, freemarker, struts, > > ant, and a couple versions of velocity. > > > > It it picking this up from cargo or parent project dependencies? > > > Did you do a clean recently? A bunch of stuff has changed, and that'll be > the only way to get good results, including just MyFaces (if you do "mvn > clean install") and just the RI (if you do "mvn -Djsf=ri clean install"). > There was also a ton of stuff being inherited from the Spring 1.2.2 POMs ... > updating the dependency to 1.2.5 cleared up a lot of that. > > > Gary > > > Craig > > > -- Original message -- > > From: "Craig McClanahan" > > > > > On 6/12/06, Wendy Smoak wrote: > > > > > > > > On 6/12/06, Wendy Smoak wrote: > > > > > > > > > We now have the MyFaces profile is active if the 'jsf' property is > > not > > > > > set. The JSF RI profile is activated with -Djsf=ri on the command > > > > > line. > > > > > > > > Note that this is -D for a system property (not -P for a profile id). > > > > > > > > > D'oh ... not enough coffee to tell the difference between a "D" and a > > "P". > > > > > > > Using -Pmyfaces and -Pjsfri still works. Profiles can always be > > > > > activated by their ids. > > > > > > > > But this part isn't true -- you'll end up with *both* MyFaces and the > > > > RI if you do 'mvn -Pjsfri'. > > > > > > > > I'll add properties to the other profiles tonight, and we'll switch to > > > > only using -D to avoid confusion. > > > > > > > > > That makes sense. > > > > > > -- > > > > Wendy > > > > > > > > > Craig > >
Re: [shale] Maven 2 profile activation
On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 6/12/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > I had to wack my m2 shale repos and then rebuild all of the > libraries. That was the was the ticket. I'm having trouble building > shale-test. Is anyone seeing this error? > > > [INFO] [compiler:compile] > Compiling 34 source files to c:\shale2\mvn_reorg\shale-test\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > > c:\shale2\mvn_reorg\shale-test\src\main\java\org\apache\shale\test\mock\MockServ > letContext.java:[53,7] org.apache.shale.test.mock.MockServletContext is > not abst > ract and does not override abstract method getContextPath() in > javax.servlet.Ser > vletContext Hmm ... getContextPath() was added to the Servlet API in 2.4, so you'd get an error like this if you compiled against the 2.4 version of the API. We don't explicitly specify a version in the test framework's POM, so for me (and I'd guess for Wendy too) it's picking up a 2.3 version of the servlet API. Off by one? I think the getContextPath() method was added in Servlet 2.5, and both of us are correctly compiling against 2.4. Since Shale as a whole depends on Servlet 2.4, I'm going to go through all the POMs and make sure we're explicit about the version number ... and also clean up any problems that this causes (including this one). Look for a commit later this evening. The section of the shale-parent pom controls the version number, and it has 2.4. It does not need to be specified in each pom. The only way I can reproduce this error is to add 2.5 to the servlet-api dependency in shale-test/pom.xml. Gary, can you make sure you've updated everything, or try this with a fresh checkout, and let us know if it still happens? I think you have an updated shale-test pom, but an old shale-parent pom. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 6/12/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > I had to wack my m2 shale repos and then rebuild all of the > > libraries. That was the was the ticket. I'm having trouble building > > shale-test. Is anyone seeing this error? > > > > > > [INFO] [compiler:compile] > > Compiling 34 source files to c:\shale2\mvn_reorg\shale-test\target\classes > > [INFO] > > > > [ERROR] BUILD FAILURE > > [INFO] > > > > [INFO] Compilation failure > > > > c:\shale2\mvn_reorg\shale-test\src\main\java\org\apache\shale\test\mock\MockServ > > letContext.java:[53,7] org.apache.shale.test.mock.MockServletContextis > > not abst > > ract and does not override abstract method getContextPath() in > > javax.servlet.Ser > > vletContext > > > Hmm ... getContextPath() was added to the Servlet API in 2.4, so you'd get > an error like this if you compiled against the 2.4 version of the API. We > don't explicitly specify a version in the test framework's POM, so for me > (and I'd guess for Wendy too) it's picking up a 2.3 version of the servlet > API. Off by one? I think the getContextPath() method was added in Servlet 2.5, and both of us are correctly compiling against 2.4. Yep ... it was indeed added in 2.5. Since Shale as a whole depends on Servlet 2.4, I'm going to go through all > the POMs and make sure we're explicit about the version number ... and also > clean up any problems that this causes (including this one). Look for a > commit later this evening. The section of the shale-parent pom controls the version number, and it has 2.4. It does not need to be specified in each pom. The only way I can reproduce this error is to add 2.5 to the servlet-api dependency in shale-test/pom.xml. I'm trying to reduce redundancy by removing the javax.servlet:servlet-apiand javax.servlet:jsp-api dependencies inside the subordinate modules, since they are declared in shale-parent ... but that causes compile errors indicating that no API classes are getting added to the classpath. Shouldn't the subordinate POMs be inheriting this dependency from shale-parent? Gary, can you make sure you've updated everything, or try this with a fresh checkout, and let us know if it still happens? I think you have an updated shale-test pom, but an old shale-parent pom. Indeed, you'd have to execute "mvn clean install" from the parent directory to insure that the new parent POM gets installed first. -- Wendy Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: I'm trying to reduce redundancy by removing the javax.servlet:servlet-apiand javax.servlet:jsp-api dependencies inside the subordinate modules, since they are declared in shale-parent ... but that causes compile errors indicating that no API classes are getting added to the classpath. Shouldn't the subordinate POMs be inheriting this dependency from shale-parent? No. Dependencies come transitively from artifacts, they are not inherited from poms. In this case, servlet-api and jsp-api are marked 'provided' so they are not transitive. The section in the parent pom doesn't take effect until you actually add one of those dependencies to a child pom. It exists to control dependency versions in a single place, so that you only need to specify the groupId and artifactId in the child pom. The net effect here is that you need to leave the javax.servlet:servlet-api and javax.servlet:jsp-api in each pom that needs it. You'll probably want to read about this on the Maven website, something tells me I'm not explaining it very well. :/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: I'm trying to reduce redundancy by removing the javax.servlet:servlet-apiand javax.servlet:jsp-api dependencies inside the subordinate modules, since they are declared in shale-parent ... but that causes compile errors indicating that no API classes are getting added to the classpath. Shouldn't the subordinate POMs be inheriting this dependency from shale-parent? Never mind ... in the parent POM is essentially templates for picking version numbers ... it doesn't behave the same as at the top level. Should we think about declaring in the shale-parent POM instead, for the stuff that is guaranteed to be common (servlet-api, jsp-api, etc.)? (It would still have to be legal, for example, for a particular webapp to declare dependency on Servlet 2.5 even if the parent says use 2.4.) Craig Gary, can you make sure you've updated everything, or try this with a > fresh checkout, and let us know if it still happens? I think you have > an updated shale-test pom, but an old shale-parent pom. Indeed, you'd have to execute "mvn clean install" from the parent directory to insure that the new parent POM gets installed first. -- > Wendy Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: No. Dependencies come transitively from artifacts, they are not inherited from poms. In this case, servlet-api and jsp-api are marked 'provided' so they are not transitive. Okay... the second part is true. :) Dependencies are inherited, no idea what I was thinking there. From your other message, I think you've got it worked out, so go ahead and do whatever makes sense. As with Martin's question about the in the parent poms, I'd rather see some duplication until we're certain these things are common to all of the modules. While you can override a dependency version in a child pom, you can't really get rid of an inherited one that you don't want. (The trick of marking things provided keeps them from being transitive, but it does put them on the classpath for compilation.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
