Re: struts build change questions
On Sun, 27 Feb 2005 12:32:31 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Ok, now this is interesting. "mock" depends on "core", and "core tests" > depend on "mock". Maven wants to build/test for each distribution, so the > "first time" developer is in a chicken-and-egg state trying to "maven > build-all" or even "maven dist" one at a time. > > I would say we put the mock objects back into core/src/test and simply > package them separately after (postGoal) the core 'dist'. > > Your thoughts? The first question that comes to my mind is "why does mock depend on core?". Is this something that could be fixed, or is there a hopeless dependency? It would be a shame to have to put it back in now, having just pulled it out. ;-) -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "James Mitchell" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Sunday, February 27, 2005 12:34 AM > Subject: Re: struts build change questions > > > done > > > > > > > > -- > > James Mitchell > > Software Engineer / Open Source Evangelist > > EdgeTech, Inc. > > 678.910.8017 > > AIM: jmitchtx > > > > - Original Message - > > From: "Craig McClanahan" <[EMAIL PROTECTED]> > > To: "James Mitchell" <[EMAIL PROTECTED]> > > Cc: "Struts Developers List" > > Sent: Saturday, February 26, 2005 1:16 AM > > Subject: Re: struts build change questions > > > > > >> On Sat, 26 Feb 2005 00:18:25 -0500, James Mitchell <[EMAIL PROTECTED]> > >> wrote: > >>> I agree on all points. > >>> > >>> So, you think I should yank it up to struts/current/ ? > >>> > >> > >> +1 > >> > >> Craig > >> > >>> -- > >>> James Mitchell > >>> Software Engineer / Open Source Evangelist > >>> EdgeTech, Inc. > >>> 678.910.8017 > >>> AIM: jmitchtx > >>> > >>> - Original Message - > >>> From: "Craig McClanahan" <[EMAIL PROTECTED]> > >>> To: "Struts Developers List" > >>> Sent: Friday, February 25, 2005 11:56 PM > >>> Subject: Re: struts build change questions > >>> > >>> > On Fri, 25 Feb 2005 23:40:41 -0500, James Mitchell > >>> > <[EMAIL PROTECTED]> > >>> > wrote: > >>> >> > >>> >> > >>> >> > It seems to me that a framework which ships (and supports) a > >>> >> > ready-made set of mock classes will have an advantage in today's > >>> >> > world. > >>> >> > >>> >> Yes. It's interesting how things work out. Over the years I used to > >>> >> swear > >>> >> by in-container based test suites, but after fighting with Cactus and > >>> >> fiddling with a few others I have a new appreciation for Mock vs. > >>> >> in-container testing. > >>> >> > >>> >> Aren't there already Mock test frameworks out there that we can use? > >>> >> I > >>> >> mean, why reinvent the wheel? I could see a problem if the license > >>> >> were > >>> >> incompatible. Your thoughts? > >>> >> > >>> > > >>> > From what I have seen (not exhaustive review, but high level > >>> > observation): > >>> > > >>> > * There are indeed a large number of MockXXX libraries in the world. > >>> > > >>> > * So many of them, in fact, that it's hard to decide what combination > >>> > you > >>> > need > >>> > to cover all the base classes you need. > >>> > > >>> > * Because there is no standardization of what a mock should do, there > >>> > is > >>> > a wide variety of extra API in the various versions. > >>> > > >>> > * The available mock libraries tend not to be a product of the > >>> > frameworks > >>> > they contain mock implementations for, meaning: > >>> > - Not necessarily synchronized with the latest changes in the > >>> > framework > &
Re: [announce] Hubert Rabago, newest Struts Committer
On Fri, 25 Feb 2005 18:21:47 -0500, Joe Hertz <[EMAIL PROTECTED]> wrote: > Damn Skippy! Hey, what did Skippy ever do to you? ;-) (For those that haven't a clue what I'm talking about: http://www.imdb.com/title/tt0060025/) Congrats, Hubert! -- Martin Cooper > -Original Message- > From: Shey Rab Pawo [mailto:[EMAIL PROTECTED] > Sent: Friday, February 25, 2005 5:15 PM > To: Struts Developers List > Subject: Re: [announce] Hubert Rabago, newest Struts Committer > > Congratulations, Hubert! This is a great choice in my opinion! > > On Fri, 25 Feb 2005 07:40:15 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >We were impressed by Hubert's sustained participation in both the user and > > dev mailing lists, where he has demonstrated knowledge and respect > > for the community. > > -- > No one ever went blind looking at the bright side of life. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled
On Fri, 25 Feb 2005 01:10:45 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Thanks, Martin, > > See within: > > > > On Thu, 24 Feb 2005 20:02:49 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > > First, let me say that I did not create the current > > MultipartRequestHandler interface, and have never liked it, for a > > variety of reasons. However, by the time I got involved with it, we > > were pretty much stuck with it for backwards compatibility reasons. In > > order to retain backwards compatibility in Struts 1.3, we > > unfortunately need to continue to live with it. However, that doesn't > > preclude the provision of an alternative; it just requires that the > > two can coexist. > > > If I am right about the MultipartRequestWrapper and it does not work, > we are lucky in that it cannot create backward compatibility issues! > ///;-) You are _not_ right. It does work, and it has worked for years. I have several production applications that use it, and use custom versions of it, and they work just fine. If you don't believe it works, then try the upload example application. That works too, and I test it before every release and test build goes out the door. It's possible that upload is broken in the latest SVN trunk, since we're in more than a little flux right now, but in 1.2.6 and earlier, it works fine. > > I would say, though, that even though the current interface is rather > > less than ideal, the fact that I've personally written three > > dramatically different implementations of it (the current Struts > > default, one that uses Resin to do the work, and one that uses a > > database for file storage) is at least some testament to its > > flexibility. > > My questions have to do more with architectural issues relating to > allowing others to do something different. I have no quarrel or > special critique with what is or has been done. > > > > > As far as the need for wrapping the request, others have mentioned > > this already, but the most basic reason is that, without a wrapper, > > calls to request.getParameter() would just plain fail for multipart > > requests. Hence any code that accesses parameters would need to be > > cognisant of whether the request was multipart or not. That's not > > something anyone should have to deal with in their applications, and > > it makes sense for a framework to provide this support. > > I agree. My previous remarks should suffice here. > > > > > What I would like to do is to move the multipart parsing out into a > > servlet filter that would sit in front of ActionServlet, passing on a > > wrapped request, and unwrapping on the way out. This is much cleaner > > than what we have today. > > This might be cleaner. I don't know for sure about that. But, I am > fairly certain that this will exacerbate the sorts of problems I am > worried about. This is the approach that Jason Hunter takes and I > know it has its merits. But, if we are talking about doing this in a > framework that might want to allow alternative and even experimental > implementations of file upload applications, I personally think this > is a mistake. Given that you could (a) choose to not use the filter, simply by not adding it to your web.xml, and (b) you can provide a custom implementation of FileUpload for the filter to use, I don't see how that is constraining. Remember, this point is about the filter only, not the way the uploaded request is made available to the application. > The reason that we do not use such a > > mechanism already is that filters only showed up in Servlets 2.3, and > > up to now we have said we were Servlets 2.2 compatible. Also, the > > reason the current code is always messing around with wrapping and > > unwrapping is that Servlets 2.2 did not permit wrapping a request. > > That meant that any time we were passing the request object back to > > the container, we needed to unwrap it, while we wanted to pass the > > wrapped request to actions, for example, so that calls to > > request.getParameter() worked as expected. > > You can keep 2.3 and 2.2 compatibility by making the parsing and the > wrapping take place at the end of the process, which I would very much > prefer anyway, for reasons given above. The end of what process? The point is that you cannot pass a wrapped request to the container in Servlets 2.2. When we pass a request to an action, it needs to be wrapped so that calls to request.getParameter() work (and they do work - there's clearly some problem with your testing), and when the action asks us to forward or include or whatever, we need to unwrap before passing
Re: Servlet 2.3 Multipart Request Handling
On Fri, 25 Feb 2005 04:51:27 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > - Original Message ----- > From: "Martin Cooper" <[EMAIL PROTECTED]> > Sent: Friday, February 25, 2005 4:25 AM > > > On Fri, 25 Feb 2005 04:15:17 -, Niall Pemberton > > <[EMAIL PROTECTED]> wrote: > > > AFAIK there were two issues with multipart request handling that needed > > > Servlet 2.3 to resolve: > > > > > > 1) Forwarding a "wrapped" Request > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=17583 > > > > > > 2) Un-implemented Servlet 2.3 methods > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=28983 > > > > > > I think we agreed to move to Servlet 2.3 now(?), so all thats needed to > > > resolve both of these is: > > > > > > 1) Change the MultipartRequestWrapper to extend the > > > HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3 > > > methods) > > > 2) Remove the "un-wrapping" code from the PerformForward Command > (anywhere > > > else?) > > > > > > Anyone have any objections/issues to doing this? > > > > Not really. However, if we end up going with the filter and wrapper > > I'm working on (slowly!) for Commons FileUpload, we wouldn't > > necessarily need our own wrapper. > > The changes are pretty minor and if your Commons stuff arrives in time, we > can simply remove the wrapper from Struts. That's fine. I can't predict when the FileUpload stuff will arrive anyway, since (a) I still have some work to finish up, and (b) I need to wait for IO to release a 1.1, since FileUpload 1.1 will depend on IO 1.1. > What do you think about factoring > the multipart handling in a command for backwards compatibility. Also it > would give the users two options - Command or Filter? As long as both work > in the same way, so that when the population mechanism is hit either would > work. How would this work? I can see parsing the input stream in a command, but I don't see how we'd then be able to change Chain's mind about what request object it hands out, so that it would subsequently hand out the wrapped one. > Another thought - rather than putting the FormFile fields in the wrapper > another approach is to put the Multipart handler in the request (I think we > already do this) and have the populate mechanims retrieve the FormFile > fields from the handler. The FileUpload filter will make the FileItems available via the wrapper, but yes, we could still make the FormFile items available though the handler. The handler is going to be a bit of a strange beast while it still exists, since it will no longer be necessary to do the parsing. Perhaps we should think about this from the "if we were starting from scratch" point of view, and then work back to how we can keep the current handler around. There's also the catch that people may have implemented their own handlers (I know I have in the past), which may raise some backwards compatibility questions. > > Also, you might want to add dummy methods for the new ones added in > > Servlets 2.4, so that we're compatible there too. Not sure if there's > > a bug in Bugzilla for that, but it's come up on the lists before. > > If were inheriting from HttpServletRequestWrapper then anyone running on > Servlet 2.4 will have "proper" implementations of those methods available? > Adding 'dummy' implementation methods would just mean that those methods > wouldn't work for Servlet 2.4 implementations. If we compile against 2.3, then there will be missing methods when we run under 2.4, which I believe is the issue I've seen come up on the lists. However, the issue you raise is also valid. I suspect that the only way we can resolve both is to use reflection to determine whether we're running under 2.3 or 2.4 and dummy up the method or invoke the superclass method, respectively. Not pretty. ;-( -- Martin Cooper > > -- > > Martin Cooper > > > > > > > Niall > > - > 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: Servlet 2.3 Multipart Request Handling
On Fri, 25 Feb 2005 04:15:17 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > AFAIK there were two issues with multipart request handling that needed > Servlet 2.3 to resolve: > > 1) Forwarding a "wrapped" Request > http://issues.apache.org/bugzilla/show_bug.cgi?id=17583 > > 2) Un-implemented Servlet 2.3 methods > http://issues.apache.org/bugzilla/show_bug.cgi?id=28983 > > I think we agreed to move to Servlet 2.3 now(?), so all thats needed to > resolve both of these is: > > 1) Change the MultipartRequestWrapper to extend the > HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3 > methods) > 2) Remove the "un-wrapping" code from the PerformForward Command (anywhere > else?) > > Anyone have any objections/issues to doing this? Not really. However, if we end up going with the filter and wrapper I'm working on (slowly!) for Commons FileUpload, we wouldn't necessarily need our own wrapper. Also, you might want to add dummy methods for the new ones added in Servlets 2.4, so that we're compatible there too. Not sure if there's a bug in Bugzilla for that, but it's come up on the lists before. -- Martin Cooper > Niall > > - > 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: multipart requests -- suggesting things be rethought and that the hardwiring be pulled
First, let me say that I did not create the current MultipartRequestHandler interface, and have never liked it, for a variety of reasons. However, by the time I got involved with it, we were pretty much stuck with it for backwards compatibility reasons. In order to retain backwards compatibility in Struts 1.3, we unfortunately need to continue to live with it. However, that doesn't preclude the provision of an alternative; it just requires that the two can coexist. I would say, though, that even though the current interface is rather less than ideal, the fact that I've personally written three dramatically different implementations of it (the current Struts default, one that uses Resin to do the work, and one that uses a database for file storage) is at least some testament to its flexibility. As far as the need for wrapping the request, others have mentioned this already, but the most basic reason is that, without a wrapper, calls to request.getParameter() would just plain fail for multipart requests. Hence any code that accesses parameters would need to be cognisant of whether the request was multipart or not. That's not something anyone should have to deal with in their applications, and it makes sense for a framework to provide this support. What I would like to do is to move the multipart parsing out into a servlet filter that would sit in front of ActionServlet, passing on a wrapped request, and unwrapping on the way out. This is much cleaner than what we have today. The reason that we do not use such a mechanism already is that filters only showed up in Servlets 2.3, and up to now we have said we were Servlets 2.2 compatible. Also, the reason the current code is always messing around with wrapping and unwrapping is that Servlets 2.2 did not permit wrapping a request. That meant that any time we were passing the request object back to the container, we needed to unwrap it, while we wanted to pass the wrapped request to actions, for example, so that calls to request.getParameter() worked as expected. Once a filter is in place, it then becomes a question of how the application obtains any uploaded files. The code I have in the works as part of Commons FileUpload has methods over and above the standard request methods that provide access to these through the wrapper. We can then plug those into FormFile fields in an action form as part of the population process. We can also look at alternative ways of providing access to them, if necessary / desirable. -- Martin Cooper On Wed, 23 Feb 2005 23:09:11 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Joe, > > I have rethought recent discussions on multipart requests and have a > different proposal. What I would suggest would be to take the whole > multipart business out of the framework altogether and to treat it as > I think it should be treated, as just another Action. > > There is nothing about a multipart request that indicates that it > should be take care of in any special manner, especially one that > curtails differing solutions unnecessarily, by the framework. There > is probably good reason to provide a default solution with an Action > in the actions directory and an associated ActionForm so that those > who don't quite know how to do these things will have the present > solution. This is like providing the DispatchAction, etc. But there > is, so far as I know, no good reason to have any solution be part of > the web framework itself. That just becomes a stumbling block rather > than any help at all. > > What do you think? I know that no solution has to be part of the > framework and this would leave the Action and ActionForm open for > whatever solutions, including the default solution. I think we have > been "overcoding" this. Any thoughts on this? > > I cannot think of one reason why the default solution has to be > hardwired into the framework. Maybe Martin has some reason that I > don't know about. > > Jack > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - > 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: Subversion reorg - Short term plans
On Thu, 24 Feb 2005 07:29:02 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Wed, 23 Feb 2005 20:25:33 -0800, Martin Cooper wrote: > > I haven't created 'site' yet. I'm going to come up with an overall > > docs plan, post it on the wiki, and then try to migrate all of the > > docs together, in as short an interval as possible. The 'site' > > subproject will show up at that time. > > In the meantime, if no one minds, I'll make some minor fixes and tweaks to > the docs that we already got. > > If someone is going to port these to another XML format, just give a shout > here a few minutes before, in case I have something open at that instant in > time. > Absolutely. That's why I want to have everything ready before I start - so that other folks like yourself can keep our docs up to date in the meantime. -- Martin Cooper > -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: Subversion reorg - Short term plans
On Wed, 23 Feb 2005 23:27:48 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Also (if it's even possible) I wouldn't mind working on a plugin (not sure > if one exists) that will allow us to publish the wiki pages for offline > viewing as part of a nightly.for now, just food for thought. Interesting idea. Getting the raw wiki content wouldn't be a problem, but replicating the formatting might not be so easy. -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Wednesday, February 23, 2005 11:25 PM > Subject: Re: Subversion reorg - Short term plans > > > On Wed, 23 Feb 2005 19:22:20 -0500, James Mitchell <[EMAIL PROTECTED]> > > wrote: > >> Did we ever make a site/ ? I remember discussing it, but haven't seen > >> anything yet. We are close to getting this puppy back on track. I've > >> finished tiles, bsf, and apps (while sitting in traffic), so I need to > >> check > >> those in, now that I'm home. > > > > I haven't created 'site' yet. I'm going to come up with an overall > > docs plan, post it on the wiki, and then try to migrate all of the > > docs together, in as short an interval as possible. The 'site' > > subproject will show up at that time. > > > > -- > > Martin Cooper > > > > > >> -- > >> James Mitchell > >> Software Engineer / Open Source Evangelist > >> EdgeTech, Inc. > >> 678.910.8017 > >> AIM: jmitchtx > >> > >> - Original Message - > >> From: "Ted Husted" <[EMAIL PROTECTED]> > >> To: "Struts Developers List" > >> Sent: Wednesday, February 23, 2005 5:30 PM > >> Subject: Re: Subversion reorg - Short term plans > >> > >> Should "site\" be on this list, James? > >> > >> On Wed, 23 Feb 2005 17:02:40 -0500, James Mitchell wrote: > >> > Here's where I am with the Maven build > >> > > >> > The items below that are 'done' mean you can run 'maven dist' and > >> > get a full distribution of that component. > >> > > >> > core/ - done > >> > tiles/ - in process > >> > taglib/ - done (pending tiles above) > >> > el/ - done > >> > apps/ - in process > >> > bsf/ - > >> > flow/ - > >> > faces/ - > >> > shale/ - > >> > sandbox - > >> > > >> > > >> > This doesn't mean the artifacts are complete though. Specifically, > >> > I need to add a task to copy the foo/build during the src > >> > distribution, but I'm close to having that done too. > >> > > >> > > >> > -- > >> > James Mitchell > >> > Software Engineer / Open Source Evangelist > >> > EdgeTech, Inc. > >> > 678.910.8017 > >> > AIM: jmitchtx > >> > > >> > > >> > > >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > >> > additional commands, e-mail: [EMAIL PROTECTED] > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion reorg - Short term plans
On Wed, 23 Feb 2005 19:22:20 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Did we ever make a site/ ? I remember discussing it, but haven't seen > anything yet. We are close to getting this puppy back on track. I've > finished tiles, bsf, and apps (while sitting in traffic), so I need to check > those in, now that I'm home. I haven't created 'site' yet. I'm going to come up with an overall docs plan, post it on the wiki, and then try to migrate all of the docs together, in as short an interval as possible. The 'site' subproject will show up at that time. -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Wednesday, February 23, 2005 5:30 PM > Subject: Re: Subversion reorg - Short term plans > > Should "site\" be on this list, James? > > On Wed, 23 Feb 2005 17:02:40 -0500, James Mitchell wrote: > > Here's where I am with the Maven build > > > > The items below that are 'done' mean you can run 'maven dist' and > > get a full distribution of that component. > > > > core/ - done > > tiles/ - in process > > taglib/ - done (pending tiles above) > > el/ - done > > apps/ - in process > > bsf/ - > > flow/ - > > faces/ - > > shale/ - > > sandbox - > > > > > > This doesn't mean the artifacts are complete though. Specifically, > > I need to add a task to copy the foo/build during the src > > distribution, but I'm close to having that done too. > > > > > > -- > > James Mitchell > > Software Engineer / Open Source Evangelist > > EdgeTech, Inc. > > 678.910.8017 > > AIM: jmitchtx > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r155075 - struts/core/trunk/xdocs
On Wed, 23 Feb 2005 16:23:49 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Should we go ahead and port the docs over to xdocs? Then move forward from > there? I'd prefer not to move them over just yet. IMO, we should have the docs plan all worked out before we start switching over, because we want to minimise the time it actually takes to make the switch (and thus mimimise the potential for things getting out of sync). I'll come up with the docs plan just as soon as I can. -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, February 23, 2005 4:22 PM > Subject: svn commit: r155075 - struts/core/trunk/xdocs > > Author: jmitchell > Date: Wed Feb 23 13:22:49 2005 > New Revision: 155075 > > URL: http://svn.apache.org/viewcvs?view=rev&rev=155075 > Log: > add new xdocs dir > > Added: > struts/core/trunk/xdocs/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r155070 - in struts/taglib/trunk/src: test/org/apache/struts/taglib/ webapp/test/java/org/apache/struts/taglib/
On Wed, 23 Feb 2005 20:52:35 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: jmitchell > Date: Wed Feb 23 12:52:34 2005 > New Revision: 155070 > > URL: http://svn.apache.org/viewcvs?view=rev&rev=155070 > Log: > moving test files to correct location, we still need to get cactus to run on > these, but this will at least let the project compile > Why is being pushed down into a webapp directory the correct location? The default location for Cactus tests would be test-cactus. Why isn't that the correct location? -- Martin Cooper > Added: > struts/taglib/trunk/src/webapp/test/java/org/apache/struts/taglib/ > - copied from r155068, > struts/taglib/trunk/src/test/org/apache/struts/taglib/ > Removed: > struts/taglib/trunk/src/test/org/apache/struts/taglib/ > > - > 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: Using Apache hardware for nightlies
On Wed, 23 Feb 2005 20:52:42 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Who do I need to ask to make this happen? Me? ;-) > Martin and I have discussed this a few times offlist, but I'm not sure we > had any concrete plans. I have both Craig's scripts and Glenn's scripts. My plan was to get these running on minotaur first, and then request infra's help to put it on a system that they would be comfortable with. This will all happen OOTFD (One Of These Fine Days ;). If my employer would stop making me work for my pay cheque, it would happen a whole lot sooner, but they don't seem to be interested in that proposal for some reason. ;-( -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - > 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: Ant or Maven (Pick one please)
On Wed, 23 Feb 2005 12:45:02 -0500, Kris Schneider <[EMAIL PROTECTED]> wrote: > "request-time" really is the correct interpretation of "rtexprvalue"... No, "request-time" would be the correct interpretation of "rt". By itself, it is meaningless. All actual attribute values are determined at request time, whether they are specified by expressions or not. "Request-time expression value" or maybe "Request-time expression", but not just "Request-time". -- Martin Cooper > Quoting Martin Cooper <[EMAIL PROTECTED]>: > > > On Wed, 23 Feb 2005 08:15:02 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > > At 7:14 AM -0500 2/23/05, James Mitchell wrote: > > > >I don't think that's what Joe was saying. > > > > > > > >Unless I'm mistaken, he means that the javadoc-like docs are > > > >generated from the actual TLDs. > > > > > > > >So, instead of this: > > > > > > > > ,-> struts-*.html > > > >struts-*.xml- > > > > '-> struts-*.tld > > > > > > > > > > > >...he means this: > > > > > > > >struts-*.tld -> struts-*.html (javadoc-like format) > > > > > > > >These javadoc-like docs would be directly linked as part of the > > documentation. > > > > > > > >Is this right Joe? > > > > > > It's true; the javadoc-like docs are generated from TLDs using > > > TagLibraryDoc: https://taglibrarydoc.dev.java.net/ > > > > > > So only one file (per tag library) would be maintained: it's just > > > that rather than it being a source for TLDs, which could also be used > > > to produce documentation, it would *be* the TLD. So rather than > > > having one Struts-custom XML file used to generate two documents, > > > we'd have one standard TLD file used to generate (through a > > > potentially more "standard" library) tag documentation. > > > > > > Besides some formatting, the language should be identical to what we > > > currently have on the userGuide pages. > > > > > > I wouldn't say I'm "lobbying" for this, but I do like the idea of one > > > less transformation. I mostly just wanted to see how it worked; I'd > > > been using Sun's online JSTL 1.1 doc (generated with the same tool) > > > for a while but hadn't generated my own. > > > > Ah, OK, now I get it. Well, the idea is good, and I wouldn't really > > mind the change to a Javadoc-like format, but I do see some problems. > > > > For one, there's a lot of formatting info that got dropped on the > > floor. I'm not sure if that's a GIGO issue or a problem with the tool, > > but we'd need to fix it somehow. > > > > The other problem is what appears to be a bug in the tool. It produces > > a column labelled "Request-time", which I think is supposed to > > represent 'rtexprvalue', and so should be "Runtime expression" > > instead. > > > > If we can resolve both of these, and the results look OK, then I'd be > > fine with switching to this approach. > > > > -- > > Martin Cooper > > > > > > > > > > http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/ > > > > > > Joe > > > -- > > > Joe Germuska > > > [EMAIL PROTECTED] > > > http://blog.germuska.com > > > "Narrow minds are weapons made for mass destruction" -The Ex > > -- > Kris Schneider <mailto:[EMAIL PROTECTED]> > D.O.Tech <http://www.dotech.com/> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant or Maven (Pick one please)
On Wed, 23 Feb 2005 08:15:02 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 7:14 AM -0500 2/23/05, James Mitchell wrote: > >I don't think that's what Joe was saying. > > > >Unless I'm mistaken, he means that the javadoc-like docs are > >generated from the actual TLDs. > > > >So, instead of this: > > > > ,-> struts-*.html > >struts-*.xml- > > '-> struts-*.tld > > > > > >...he means this: > > > >struts-*.tld -> struts-*.html (javadoc-like format) > > > >These javadoc-like docs would be directly linked as part of the > >documentation. > > > >Is this right Joe? > > It's true; the javadoc-like docs are generated from TLDs using > TagLibraryDoc: https://taglibrarydoc.dev.java.net/ > > So only one file (per tag library) would be maintained: it's just > that rather than it being a source for TLDs, which could also be used > to produce documentation, it would *be* the TLD. So rather than > having one Struts-custom XML file used to generate two documents, > we'd have one standard TLD file used to generate (through a > potentially more "standard" library) tag documentation. > > Besides some formatting, the language should be identical to what we > currently have on the userGuide pages. > > I wouldn't say I'm "lobbying" for this, but I do like the idea of one > less transformation. I mostly just wanted to see how it worked; I'd > been using Sun's online JSTL 1.1 doc (generated with the same tool) > for a while but hadn't generated my own. Ah, OK, now I get it. Well, the idea is good, and I wouldn't really mind the change to a Javadoc-like format, but I do see some problems. For one, there's a lot of formatting info that got dropped on the floor. I'm not sure if that's a GIGO issue or a problem with the tool, but we'd need to fix it somehow. The other problem is what appears to be a bug in the tool. It produces a column labelled "Request-time", which I think is supposed to represent 'rtexprvalue', and so should be "Runtime expression" instead. If we can resolve both of these, and the results look OK, then I'd be fine with switching to this approach. -- Martin Cooper > > http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/ > > Joe > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: Ant or Maven (Pick one please)
On Tue, 22 Feb 2005 22:25:11 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >I would like to move us to using the standard Maven doc generation > >mechanism, so that we get the benefit of all that site generation and > >reporting that Maven does for us. (In fact, I see that as one of the > >major advantages of moving to Maven.) Unless I'm mistaken, that means > >converting our docs to the XML format that Maven understands. (This is > >what the existing xdocs directory was an initial stab at.) > > > >The way we generate TLDs today - using either Ant or Maven - depends > >on an XML format of our own invention along with our own stylesheet. > >If we switch to Maven's xdocs, then we won't have that, and I doubt > >we'd have the luxury of simply dropping our own XML elements into the > >xdocs files for the purpose. > > > >My expectation is that we would need to "extend" the Maven format to > >make it suitable for generating TLDs, and then use a (proably trivial) > >XSLT stylesheet to morph that to standard Maven prior to site > >generation. One thing I certainly want to retain is generating the tag > >docs and the TLDs from the same source. > > > >If I'm missing something here, and we don't need to do what I'm > >expecting, I'd be happy to be set straight. ;-) > > I don't think it's so complicated. Check out > http://www.apache.org/~germuska/struts-taglib/docs/tlddoc/ and see if > it's even roughly acceptable as an alternative to > http://struts.apache.org/userGuide/struts-bean.html > > To make this work, we do a one time generation of the TLD files and > store them in the repository -- the maven taglib plugin defaults to > looking for them in src/tld, and that's where (for example), the > displaytag project keeps them. We would then need to modify the JAR > compilation process to include the TLDs in the JAR; this is a trivial > copy postGoal in maven.xml, and we might even just be able to declare > src/tld as another "Resource" directory, in which case they would > automatically be copied. (in my test, the TLDs were in src/tld > directly, not src/tld/META-INF/tlds). > > I haven't looked at generating the traditional (userGuide) doc from > the maven xdoc plugin, but you're right -- that's probably not quite > so simple. I think I'm still missing something. The link you provided shows tag docs that appear to have been generated from the Javadoc comments. That's not what we want (or at least not what I want ;). To guarantee that the docs are in sync with the TLDs, I want to continue to generate both the docs and the TLDs from the exact same XML file. I don't want to switch to generating these from Javadocs, because then we either end up embedding Maven-specific XML markup in the Java files, or we lose the ability to use some of the nice Maven formatting options (such as boxes for examples). -- Martin Cooper > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: Ant or Maven (Pick one please)
On Tue, 22 Feb 2005 21:50:02 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >At this point, I don't know which one is ahead. Ant is closer on site > >/ docs, but Maven is probably closer on an all-Struts build. If people > >would prefer Ant, I'm quite willing to pick up where I left off with > >that. I'm also happy to work on the Maven build, although I don't know > >if James M has got far enough with the shared build stuff for other > >people to work on it simultaneously. I'm not all that thrilled at the > >prospect of working on both, though. > > > >The site / docs is something I do want to work on, and I've said as > >much to James off-list more than once recently. One of the sticking > >points with Maven is going to be how we deal with generating the TLDs, > >which likely won't work from Maven xdocs. This is on my to-do list, > >right after writing up a plan for site creation (which is at the top > >of my list). > > I'm not quite sure what you're thinking of here; Maven already > generates the TLD files for taglib and el now as part of achieving > the "maven jar" goal. I would like to move us to using the standard Maven doc generation mechanism, so that we get the benefit of all that site generation and reporting that Maven does for us. (In fact, I see that as one of the major advantages of moving to Maven.) Unless I'm mistaken, that means converting our docs to the XML format that Maven understands. (This is what the existing xdocs directory was an initial stab at.) The way we generate TLDs today - using either Ant or Maven - depends on an XML format of our own invention along with our own stylesheet. If we switch to Maven's xdocs, then we won't have that, and I doubt we'd have the luxury of simply dropping our own XML elements into the xdocs files for the purpose. My expectation is that we would need to "extend" the Maven format to make it suitable for generating TLDs, and then use a (proably trivial) XSLT stylesheet to morph that to standard Maven prior to site generation. One thing I certainly want to retain is generating the tag docs and the TLDs from the same source. If I'm missing something here, and we don't need to do what I'm expecting, I'd be happy to be set straight. ;-) -- Martin Cooper > If anything about that turns out to be weird, we could also consider > generating the TLDs one last time and making those the SVN controlled > resource, and then generate doc from the TLD files using taglibdoc. > > I was just experimenting with that, and if people would like to > review the output, they can visit: > http://www.apache.org/~germuska/struts-taglib/docs/tlddoc/ > > I made some mild mods to the XSL file we use to generate the TLDs to > inline the doc; you'll see from reviewing that it's not perfect, and > I'm not saying that it's better than the familiar old tag reference > docs. But I'd been curious about using Maven and TLDDoc together for > a while, and it turns out that it's pretty straightforward. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: Ant or Maven (Pick one please)
On Tue, 22 Feb 2005 17:09:31 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Sorry to raise this controversial subject, but I feel our build > situation is getting a little out of control. We have maven and ant > build files scattered throughout our repository, making it very > confusing to determine which is "official" and which is "experimental". The act of breaking up the original repo into subprojects started us down this track, I think. We perhaps should have thought through the overall build system more fully when we started to do that, but that's water under the bridge now. In any event, the Ant builds got broken so that neither worked completely. > Even our documentation is fragemented with /doc and /xdoc directories > containing unsynchronized, mostly identical content. I'm not sure why we ever kept the xdocs stuff, since it was never going to stay in sync. IMO, we should have zapped it some time ago. At this point, I think the one reason for keeping it around is as a reference if we're going to migrate again. I'd be fine with moving it somewhere else - or even just keeping a copy on minotaur under my account, which might be as good as anything. > I think we need to just pick one and get rid of the other. I know for > some this is like deciding the meaning of life, but I think we need to > just pick one and remove the other or at least move it to an unsupported > sandbox area. Struts may currently be in a state where it wants to try > different ideas and see which ones "win", but the build environment > should "just work" and require little to no attention. Agreed. However, when you have a half-baked Maven build and a broken Ant build, it's not going to "just work" without some work. ;-) > Personally, I very much perfer Ant and find Maven slow, buggy, and > overextended, however, it seems those that have been volunteering on the > build lately perfer Maven, so I vote we go with Maven, convert all the > docs to xdocs, and clean the Ant-related files out completely. As I mentioned in another thread recently, I started working on an Ant build system, but at pretty much the same time, a couple of folks jumped back into the languishing Maven experiment, so I put my Ant work on hold (not that it had got all that far, other than what I'd done for my day job) and jumped into the Maven fray myself. At this point, I don't know which one is ahead. Ant is closer on site / docs, but Maven is probably closer on an all-Struts build. If people would prefer Ant, I'm quite willing to pick up where I left off with that. I'm also happy to work on the Maven build, although I don't know if James M has got far enough with the shared build stuff for other people to work on it simultaneously. I'm not all that thrilled at the prospect of working on both, though. The site / docs is something I do want to work on, and I've said as much to James off-list more than once recently. One of the sticking points with Maven is going to be how we deal with generating the TLDs, which likely won't work from Maven xdocs. This is on my to-do list, right after writing up a plan for site creation (which is at the top of my list). > Of course, I am willing to do whatever it takes to get this > accomplished. Let's get this, in my opinion, very boring and > unnecessarily confusing matter resolved so we can get back to the fun > stuff that is 1.3 and beyond. I agree that we should get this finished up and working. I haven't had as much time to put into this as I'd have liked recently, and am not in a good position at the moment to "plan" the time I can devote, so it will be "as it happens", so to speak. In any case, +1 for picking one and getting on with it. ;-) -- Martin Cooper > Don > > - > 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: Blank Questions
On Tue, 22 Feb 2005 13:51:07 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Why not pick the lowest we support (2.3), and provide instructions in > the readme if how to upgrade. Other versions would only be an issue if > they tried to use newer servlet features in their code, and if so, they > are probably comfortable enough to replace a servlet jar. I'm not so sure about that. Wouldn't they run into classloader issues if the 2.3 jar is bundled in the war file, but the container is a 2.4 container? -- Martin Cooper > Don > > Martin Cooper wrote: > > On Mon, 21 Feb 2005 22:14:31 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > > >>I was looking at updating the Blank application and had a few questions: > >> > >> 1. Can I get rid of the data source stuff including the jdbc > >>extensions? Hasn't data sources been deprecated for quite a while now? > >> > >> 2. Any way we could ship with servlet.jar? It would be nice if this > >>could be completely self-contained. > > > > > > That sounds like a nice idea, but I don't see how it would really work > > in practice. The problem is that we'd have to pick one version of the > > Servlet API, so it would be broken for everyone who uses a different > > version. That's likely a backwards step in getting people up and > > running quickly. > > > > -- > > Martin Cooper > > > > > > > >> 3. Does it need to come with chain-config.xml? Most people won't need > >>to customize this. > >> > >> 4. I take it the build is currently broken as the built war seems to > >>be missing things like WEB-INF/src Is anyone currently working on > >>fixing it? If not, I can give it a go. > >> > >> 5. A minor thing, but I'd also like to make the default "dist" > >>directory be a relative directory to avoid, hopefully, all external > >>directory modifications. > >> > >>Thanks, > >> > >>Don > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blank Questions
On Mon, 21 Feb 2005 22:14:31 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I was looking at updating the Blank application and had a few questions: > > 1. Can I get rid of the data source stuff including the jdbc > extensions? Hasn't data sources been deprecated for quite a while now? > > 2. Any way we could ship with servlet.jar? It would be nice if this > could be completely self-contained. That sounds like a nice idea, but I don't see how it would really work in practice. The problem is that we'd have to pick one version of the Servlet API, so it would be broken for everyone who uses a different version. That's likely a backwards step in getting people up and running quickly. -- Martin Cooper > 3. Does it need to come with chain-config.xml? Most people won't need > to customize this. > > 4. I take it the build is currently broken as the built war seems to > be missing things like WEB-INF/src Is anyone currently working on > fixing it? If not, I can give it a go. > > 5. A minor thing, but I'd also like to make the default "dist" > directory be a relative directory to avoid, hopefully, all external > directory modifications. > > Thanks, > > Don > > - > 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: Building Struts
On Tue, 22 Feb 2005 09:49:52 +0100, Mark Lowe <[EMAIL PROTECTED]> wrote: > Sorry if this sound stupid, I cant find the url that svn requires to > checkout shale et al. http://struts.apache.org/acquiring.html#SourceCode -- Martin Cooper > I saw that someone mentioned flowscript unit > testing, I'm working on a cocoon project and I'd like to see if > there's a way of testing the flowscripts we have. > > Mark > > > On Mon, 21 Feb 2005 11:28:04 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > Martin Cooper wrote: > > > > > OK, I've created a build subproject, with trunk / tags / branches, > > > added it to 'current', and also added it to the following subprojects: > > > apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to: > > > flow, sandbox, shale. Certainly shale uses a separate build system, > > > but should I go ahead and add it to flow and sandbox? > > > > Sure, flow's build was copied right from bsf. Flow does have a custom > > run-tests Ant task which uses a homegrown Javascript unit testing > > framework. It also has two other tasks for building the two example > > applications. I believe Maven can use Ant tasks, but I have no idea how. > > > > Thanks for the hard work. > > > > Don > > > > > > > > I added a little README file that tries to explain what the deal is > > > with this showing up in multiple places. With any luck, some people > > > will actually read it. ;-) > > > > > > -- > > > Martin Cooper > > > > > > > > > > > >>-- > > >>James Mitchell > > >>Software Engineer / Open Source Evangelist > > >>EdgeTech, Inc. > > >>678.910.8017 > > >>AIM: jmitchtx > > >> > > >>- Original Message - > > >>From: "Martin Cooper" <[EMAIL PROTECTED]> > > >>To: "Struts Developers List" > > >>Sent: Sunday, February 20, 2005 3:13 AM > > >>Subject: Re: Building Struts > > >> > > >> > > >>>On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <[EMAIL PROTECTED]> > > >>>wrote: > > >>> > > >>>>That seems like quite a hack > > >>> > > >>>I'd be interested to hear why you feel this way. It's actually pretty > > >>>much the exact scenario for which svn:externals were created, and, I > > >>>think, somewhat more in line with the expected usage of that > > >>>functionality that the whole 'current' thing is. ;-) > > >>> > > >>>-- > > >>>Martin Cooper > > >>> > > >>> > > >>> > > >>>>and going to be a bit awkward to the > > >>>>unsuspecting user/developer. But I honestly don't have a better option > > >>>>right now. I've already started the process of consolidating the > > >>>>various > > >>>>common maven configuration stuff. I'll be checking things in this > > >>>>weekend > > >>>>and next week. > > >>>> > > >>>> > > >>>>-- > > >>>>James Mitchell > > >>>>Software Engineer / Open Source Evangelist > > >>>>EdgeTech, Inc. > > >>>>678.910.8017 > > >>>>AIM: jmitchtx > > >>>> > > >>>>- Original Message - > > >>>>From: "Martin Cooper" <[EMAIL PROTECTED]> > > >>>>To: "Struts Developers List" > > >>>>Sent: Saturday, February 19, 2005 1:03 PM > > >>>>Subject: Re: Building Struts > > >>>> > > >>>> > > >>>>>On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <[EMAIL PROTECTED]> > > >>>>>wrote: > > >>>>> > > >>>>>>I am not really familiar with svn:externals, but it sounds great. I'm > > >>>>>>not > > >>>>>>100% sure that (2) is true, at least, if we're going to use maven dist > > >>>>>>to > > >>>>>>build distros. But even if we have to do a little, it will be much > > >>>>>>more > > >>>>>>straightforward. > > >>>>> > > >>>>>Yes, you&#
Re: Building Struts
On Sun, 20 Feb 2005 23:26:00 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Well, maybe not a 'hack' in the true sense of the word ;), but it will be > weird having to commit and 'svn up' any change made in build/ to see it > locally in the svn:external-ized build/ locations. I know that won't have > to happen very often once we are stable again, but it will cause a lot of > confusion up front. > > No matter how many times this gets discussed and reminded, someone will make > a change to one of the build/ copies (not realizing it will affect them all) > and effectively hose the entire build process till that change gets > reverted. You can count on it. Although that's not really enough to stop > us from going ahead with it. > > I am definitely -1 on having duplicate files and config stuff everywhere. > Your suggestion is probably the best solution. > > So, that said, let's move forward with it. I've already made a lot of > local changes that I'll have to fix, but it should be relatively painless. OK, I've created a build subproject, with trunk / tags / branches, added it to 'current', and also added it to the following subprojects: apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to: flow, sandbox, shale. Certainly shale uses a separate build system, but should I go ahead and add it to flow and sandbox? I added a little README file that tries to explain what the deal is with this showing up in multiple places. With any luck, some people will actually read it. ;-) -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Sunday, February 20, 2005 3:13 AM > Subject: Re: Building Struts > > > On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <[EMAIL PROTECTED]> > > wrote: > >> That seems like quite a hack > > > > I'd be interested to hear why you feel this way. It's actually pretty > > much the exact scenario for which svn:externals were created, and, I > > think, somewhat more in line with the expected usage of that > > functionality that the whole 'current' thing is. ;-) > > > > -- > > Martin Cooper > > > > > >> and going to be a bit awkward to the > >> unsuspecting user/developer. But I honestly don't have a better option > >> right now. I've already started the process of consolidating the various > >> common maven configuration stuff. I'll be checking things in this > >> weekend > >> and next week. > >> > >> > >> -- > >> James Mitchell > >> Software Engineer / Open Source Evangelist > >> EdgeTech, Inc. > >> 678.910.8017 > >> AIM: jmitchtx > >> > >> - Original Message - > >> From: "Martin Cooper" <[EMAIL PROTECTED]> > >> To: "Struts Developers List" > >> Sent: Saturday, February 19, 2005 1:03 PM > >> Subject: Re: Building Struts > >> > >> > On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <[EMAIL PROTECTED]> > >> > wrote: > >> >> > >> >> I am not really familiar with svn:externals, but it sounds great. I'm > >> >> not > >> >> 100% sure that (2) is true, at least, if we're going to use maven dist > >> >> to > >> >> build distros. But even if we have to do a little, it will be much > >> >> more > >> >> straightforward. > >> > > >> > Yes, you're right. We will need to tell Maven to include the build > >> > directory. But that should be pretty straightforward. > >> > > >> > If everyone's OK with this, I'll have a go at it tomorrow, if nobody > >> > beats me to it. (I'll be out all day today, starting about 5 minutes > >> > from now ;). > >> > > >> > -- > >> > Martin Cooper > >> > > >> > > >> >> > >> >> (for those who are interested: > >> >> Chapter 7. Advanced Topics: Externals Definitions > >> >> http://svnbook.red-bean.com/en/1.1/ch07s03.html > >> >> ) > >> >> > >> >> > >> >> I'm +1 on this approach. From the tail end of the page from the SVN > >> >> book, > >> >> it looks like we'll h
Re: Building Struts
On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > That seems like quite a hack I'd be interested to hear why you feel this way. It's actually pretty much the exact scenario for which svn:externals were created, and, I think, somewhat more in line with the expected usage of that functionality that the whole 'current' thing is. ;-) -- Martin Cooper > and going to be a bit awkward to the > unsuspecting user/developer. But I honestly don't have a better option > right now. I've already started the process of consolidating the various > common maven configuration stuff. I'll be checking things in this weekend > and next week. > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Saturday, February 19, 2005 1:03 PM > Subject: Re: Building Struts > > > On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >> > >> I am not really familiar with svn:externals, but it sounds great. I'm > >> not > >> 100% sure that (2) is true, at least, if we're going to use maven dist to > >> build distros. But even if we have to do a little, it will be much more > >> straightforward. > > > > Yes, you're right. We will need to tell Maven to include the build > > directory. But that should be pretty straightforward. > > > > If everyone's OK with this, I'll have a go at it tomorrow, if nobody > > beats me to it. (I'll be out all day today, starting about 5 minutes > > from now ;). > > > > -- > > Martin Cooper > > > > > >> > >> (for those who are interested: > >> Chapter 7. Advanced Topics: Externals Definitions > >> http://svnbook.red-bean.com/en/1.1/ch07s03.html > >> ) > >> > >> > >> I'm +1 on this approach. From the tail end of the page from the SVN > >> book, > >> it looks like we'll have to be conscious of some issues if we do any > >> future > >> repository re-orgs, but hopefully we won't have to. > >> > >> > >> Joe > >> > >> > >> > >> > >> At 7:43 AM -0800 2/19/05, Martin Cooper wrote: > >> By using svn:externals, we gain several things: > >> > >> 1) We get a "free" copy of 'build' along with each subproject, meaning > >> that it doesn't have to be checked out separately to build one > >> subproject. Checking out 'core', for example, would be enough to build > >> core. > >> > >> 2) The "free" copy means that we don't have to do anything special > >> when building the source distros, since the 'build' directory will > >> already be part of the checked out subproject when the distro is being > >> created. > >> > >> 3) We don't have to mess with Maven properties to deal with two > >> different build scenarios (i.e. checked out vs. source distro). > >> > >> 4) It's really simple! :-) > >> > >> WDYT? > >> > >> > >> > >> -- > >> > >> Joe Germuska > >> [EMAIL PROTECTED] > >> http://blog.germuska.com > >> "Narrow minds are weapons made for mass destruction" -The Ex > > > > - > > 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: Building Struts
On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > I am not really familiar with svn:externals, but it sounds great. I'm not > 100% sure that (2) is true, at least, if we're going to use maven dist to > build distros. But even if we have to do a little, it will be much more > straightforward. Yes, you're right. We will need to tell Maven to include the build directory. But that should be pretty straightforward. If everyone's OK with this, I'll have a go at it tomorrow, if nobody beats me to it. (I'll be out all day today, starting about 5 minutes from now ;). -- Martin Cooper > > (for those who are interested: > Chapter 7. Advanced Topics: Externals Definitions > http://svnbook.red-bean.com/en/1.1/ch07s03.html > ) > > > I'm +1 on this approach. From the tail end of the page from the SVN book, > it looks like we'll have to be conscious of some issues if we do any future > repository re-orgs, but hopefully we won't have to. > > > Joe > > > > > At 7:43 AM -0800 2/19/05, Martin Cooper wrote: > By using svn:externals, we gain several things: > > 1) We get a "free" copy of 'build' along with each subproject, meaning > that it doesn't have to be checked out separately to build one > subproject. Checking out 'core', for example, would be enough to build > core. > > 2) The "free" copy means that we don't have to do anything special > when building the source distros, since the 'build' directory will > already be part of the checked out subproject when the distro is being > created. > > 3) We don't have to mess with Maven properties to deal with two > different build scenarios (i.e. checked out vs. source distro). > > 4) It's really simple! :-) > > WDYT? > > > > -- > > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building Struts
On Fri, 18 Feb 2005 09:46:07 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 7:04 AM -0500 2/18/05, James Mitchell wrote:
> >
> >Ok, what about this:
> >
> >apps
> >bsf
> >struts-build/
> > site/
> > build/
> >core
> >el
> >faces
> >flow
> >sandbox
> >shale
> >site
> >taglib
> >tiles
> >
> >That would allow us to simply copy the nested build/ during the
> >source build of any specific subproject, and still allow the
> >relative references from struts-build/build/ to work (same for
> >site/).
>
> I hope I'm not being obtuse, but I don't understand how this gets us
> what we want any more automatically than anything else, and I really
> don't like the way it "looks."
>
> It is possible to use property expressions in POM files; maybe we could use:
> ${struts.shared.pom.path}
>
> I could imagine that maybe this is one place where the expressions
> can't be used since inheritance can also be used to resolve property
> values -- it will take just trying it to find out.
>
> But, if it works, we could define the standard value in
> "project.properties" for each project:
> struts.shared.pom.path=../build/project.xml
>
> Then as part of making the dist we could use maven.xml to copy the
> build directory into the dist as"./build" and copy in a
> "build.properties" file (which has priority over
> "project.properties") which specified the path to the distribution
> self-contained build-support files?
>
> If the initial property-for-extend-path works, I think this would all
> come together, but it'll take some playing around. I may have time
> to try it on Saturday, but if not, I'll be offline Sunday and Monday.
> If anyone else wants to give it a go, say so on the list.
This just gave me an even better idea (IMHO, at least ;). We do what I
had suggested before:
current/
build/
site/
core/
apps/
...
and then we use svn:externals to add 'build' to each of the
subprojects that need it. So when I check out 'core', I would see:
core/
build/
conf/
src/
...
By using svn:externals, we gain several things:
1) We get a "free" copy of 'build' along with each subproject, meaning
that it doesn't have to be checked out separately to build one
subproject. Checking out 'core', for example, would be enough to build
core.
2) The "free" copy means that we don't have to do anything special
when building the source distros, since the 'build' directory will
already be part of the checked out subproject when the distro is being
created.
3) We don't have to mess with Maven properties to deal with two
different build scenarios (i.e. checked out vs. source distro).
4) It's really simple! :-)
WDYT?
--
Martin Cooper
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> -
> 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: [OT] Wiki links
On Sat, 19 Feb 2005 14:07:42 +0100, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > I added a *link* to > http://wiki.apache.org/struts/StrutsResources > (StrutsELearning) > > But wiki doesn't generate a link to that > corresponding URL (http://wiki.apache.org/struts/StrutsELearning) > > Did I miss something? Fixed, but I don't know why it wasn't linked automatically. -- Martin Cooper > > Thanks, > Matthias > > - > 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: Building Struts
On Thu, 17 Feb 2005 22:20:39 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Right, sorry. > > If we don't want to include the build/ folder as a peer, then we can just > warn the user to go and fetch the src for that one as well (if not found). What I meant was that normally the subproject-level directory would not be a subdirectory of the distribution, so when you unzip the distro, you'd see something like this: struts-core-1.3.0-dev/ config/ src/ ... But if we include the build "subproject" in the distro, and have the structure above, we'd end up with this: struts-core-1.3.0-dev/ build/ config/ src/ ... which is "wrong" from a peer directory level, and wouldn't work without adjustment to the build files in one place or another. We'd have to include the original subproject directory in the distro as well to make this work. So that would mean: struts-core-1.3.0-dev/ build/ core/ config/ src/ ... so introducing a 'core' directory that we would normally not have in the distro. That's not necessarily a huge big deal, it just seems a little odd. (But it does avoid the weirdness with mixing levels in the distro, and it does let people build from the source distro, and those are both Good Things. ;) -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Thursday, February 17, 2005 4:09 PM > Subject: Re: Building Struts > > > On Thu, 17 Feb 2005 15:48:13 -0500, James Mitchell <[EMAIL PROTECTED]> > > wrote: > >> No, because the site/ directory would be included in the source > >> distribution. > > > > You mean the build/ directory. ;-) > > > > This could be tricky, though, since in this case it would be inside of > > the subproject directory rather than a peer of it, no? > > > > -- > > Martin Cooper > > > > > >> -- > >> James Mitchell > >> Software Engineer / Open Source Evangelist > >> EdgeTech, Inc. > >> 678.910.8017 > >> AIM: jmitchtx > >> > >> - Original Message - > >> From: "Joe Germuska" <[EMAIL PROTECTED]> > >> To: "James Mitchell" <[EMAIL PROTECTED]>; "Struts Developers List" > >> > >> Sent: Thursday, February 17, 2005 3:30 PM > >> Subject: Re: Building Struts > >> > >> > At 3:09 PM -0500 2/17/05, James Mitchell wrote: > >> >>>I think this is reasonable, but I'm not totally thrilled about the > >> >>>fact > >> >>>that you then cannot build the distributions with Maven. > >> >> > >> >>Sure we can, we just use the reactor and set the check style props to a > >> >>relative path (say ../site/conf/qa/CheckStyle and > >> >>../site/LICENSE.CheckStyle) > >> > > >> > I don't understand. If I've just downloaded > >> > struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and go > >> > into that directory and type"maven jar", what would happen? Wouldn't it > >> > immediately fail when it tried to read the POM file because the > >> > dependencies couldn't be found? > >> > > >> > Joe > >> > > >> > -- > >> > Joe Germuska[EMAIL PROTECTED] http://blog.germuska.com > >> > "Narrow minds are weapons made for mass destruction" -The Ex > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building Struts
On Thu, 17 Feb 2005 16:36:31 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Thu, 17 Feb 2005 12:12:49 -0800, Martin Cooper wrote: > > I am +1 on putting common build-related stuff in a common place, > > but I am -1 on combining / confusing the notions of 'build' and > > 'site'. IMO, we want: > > > > current/build: Shared build configuration, as you are describing. > > current/site: All of the stuff for the root Struts web site, to > > which subproject sites will "plug in" (when deployed). > > Is there an advantage to having both /build and /site? There are at least two that I can think of: 1) When someone is interested in building 'core', say, they need to check out 'build' but they don't have to check out all of the root web site docs, images and build system as well. 2) When we bundle the common build system in the subproject source distros, as James was describing, we don't have to bundle the root web site as well. Of course, people could avoid (1) by checking out only a part of the common subproject (if they knew to do that), and we could work around (2) by extracting only the necessary files to bundle, but it would just be simpler - and more transparent - if we have a 'build' place for the build process and a 'site' place for the web site. It would be very non-obvious to me to have to check out something called 'site' to have to build some other subproject, and I would expect lots of questions on the lists about that. -- Martin Cooper > Is there a reason why /site cannot play both roles? > > The general use case would be that /site is the "integration" module, both in > terms of subproject builds and subproject documentation/websites. > > -T. > > - > 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: Building Struts
On Thu, 17 Feb 2005 15:48:13 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > No, because the site/ directory would be included in the source > distribution. You mean the build/ directory. ;-) This could be tricky, though, since in this case it would be inside of the subproject directory rather than a peer of it, no? -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Joe Germuska" <[EMAIL PROTECTED]> > To: "James Mitchell" <[EMAIL PROTECTED]>; "Struts Developers List" > > Sent: Thursday, February 17, 2005 3:30 PM > Subject: Re: Building Struts > > > At 3:09 PM -0500 2/17/05, James Mitchell wrote: > >>>I think this is reasonable, but I'm not totally thrilled about the fact > >>>that you then cannot build the distributions with Maven. > >> > >>Sure we can, we just use the reactor and set the check style props to a > >>relative path (say ../site/conf/qa/CheckStyle and > >>../site/LICENSE.CheckStyle) > > > > I don't understand. If I've just downloaded > > struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and go > > into that directory and type"maven jar", what would happen? Wouldn't it > > immediately fail when it tried to read the POM file because the > > dependencies couldn't be found? > > > > Joe > > > > -- > > Joe Germuska[EMAIL PROTECTED] http://blog.germuska.com > > "Narrow minds are weapons made for mass destruction" -The Ex > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building Struts
On Thu, 17 Feb 2005 14:27:20 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:
> With the move to svn and the shake up of the directory layout, we seem to be
> (more often than not) in a half-baked state. I've been pushing hard trying
> to get most of the maven builds working.
>
> So far, here's what works: (this should work right now, unless I've
> forgotten to commit something)
>
> $ cd path/to/your/local/struts/current/core
> $ maven dist
> $ cd ../taglib
> $ maven dist
> $ cd ../apps
> $ maven dist
> $ cd ../tiles
> $ maven dist
> $ cd ../el
> $ maven dist
> $ cd ../bsf
> $ maven dist
>
> Doing this yields several things:
> - newly built jars in your ${user.home}/.maven/repository/struts/jars
> struts-1.3.0-dev.jar
> struts-mailreader-dao-1.3.0-dev.jar
> struts-taglib-1.3.0-dev.jar
> struts-tiles-1.3.0-dev.jar
>
> - a full maven distribution in each subproject's target (or m-target)
> directories
>
> My biggest complaint right now is with the way we are doing things and how
> much duplication we now have (and will have in the future) wrt maven and ant
> configuration. Each subproject has it's own copy of project.properties,
> maven.xml, and 90% of each project.xml is repeated. I've already wasted
> several hours trying to get these all in sync. I am -1 for keeping each
> separate for the sake of seperation.
>
> I prefer that we setup our maven project files to extend a single top
> project.xml under current/site/ (future), like it is done now in commons.
> This includes the CheckStyle config and license as well as other shared
> resources.
I am +1 on putting common build-related stuff in a common place, but I
am -1 on combining / confusing the notions of 'build' and 'site'. IMO,
we want:
current/build: Shared build configuration, as you are describing.
current/site: All of the stuff for the root Struts web site, to which
subproject sites will "plug in" (when deployed).
--
Martin Cooper
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> -
> 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: Building Struts Website
On Wed, 16 Feb 2005 14:17:24 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Wed, 16 Feb 2005 10:42:36 -0800, Don Brown wrote: > > I know I haven't been keeping up on this as I should have, but > > wasn't Martin reworking all the Ant scripts? Perhaps website > > building was included? > > > > Don > > Not that I can see. The HTML pages are built using stylesheets, and the only > place the Core build file does that is to create the TLDs. > Yah, I never got that far. > The Core jars seem to build just fine (), including the release > target. Building core with Maven should be just fine as well. > The website was associated with building the documentation.war, but that's a > separate subproject from Core now. Apps doesn't even have a master build.xml > yet. > > For now, I'd suggest moving the XML documents associated with the 1.2 website > to a separate Site subproject. We can get that to build (or "transform") into > HTML easily enough by cannibalizing the 1.2 build files. We wouldn't have to > worry about a WAR for this. Once we have the transformed pages, we can just > scp them up. > My thinking was that we'd have 'site' + all subprojects, where 'core' would play in the same way as other subprojects. Since that will involve separating 'site' files from 'core' files, I'd prefer, in the interim, to build the site from where it is now, rather than move everything out and then move some of it back again later. If we have a separate build file that reaches over into other subprojects, I think that's OK as a stopgap measure. > For new projects, ideally we'd want Site to link to the subproject for > detail, rather than try to plug everything into Site. (I suppose.) The > subproject links should probably be absolute links to > struts.apache.org/$subproject, so that we don't have to build it all locally. > +1 -- Martin Cooper > Maven Jumpstart > > My main station is in the shop, and I'm having trouble committing from the > laptop for some reason. But, if anyone is interested, I have a > build.properties file for Core that uses the Maven for a jumpstart. You can > use the Maven build to acquire the JARs, and this version of the properties > file will then get them out of your Maven repository. > > -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: Building Struts Website
(Man, I am drowning in dev@ messages these days! I'm about 100 behind right now and losing...) At one point I did start on an Ant based build system, since I had just finished one for my day job. However, before I got too far, James M started some serious hacking on Maven builds, so I switched camps and started cleaning up the core Maven build. A Maven build for the site is on my to-do list, but as you've no doubt noticed, I haven't had a whole lot of time to spend on it lately. I am hoping to get back to it soon - perhaps this thread will be sufficient as a nudge. ;-) -- Martin Cooper On Wed, 16 Feb 2005 10:42:36 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I know I haven't been keeping up on this as I should have, but wasn't > Martin reworking all the Ant scripts? Perhaps website building was > included? > > Don > > Ted Husted wrote: > > The best example of what I believe we want to do is the Jakarta Commons, > > which is Maven based. > > > > It might not be hard to add a Ant build file to Core to just build the web > > site, based on what is now over in Apps, or the build file from 1.2. > > > > It wouldn't have to build JARs, just run the XMLs through the Ant. > > > > Once we had the site building again, perhaps someone could add a section to > > the Roadmap on where we stand with this. There's been traffic on the list, > > but it's hard to keep up with the threads sometimes. > > > > My own preference would be to use Maven, but, in the end, them that does > > the work make the decisions. > > > > -Ted. > > > > On Wed, 16 Feb 2005 10:23:53 -0800, Don Brown wrote: > > > >> Ted Husted wrote: > >> > >>> In the midst of the reorganization, the targets that would build > >>> the website content were separated from the content. The usual > >>> approach was to build the documentation application and then > >>> upload that, so those Ant targets marched over to the Apps > >>> subproject. Meanwhile, the content is still under Core (in docs). > >>> I usually just built the website locally (there was a target for > >>> that) and would then scp the pages up to the server, without > >>> messing about with the WAR. > >>> > >> > >> Yes, this is what I have done in the past. So what you are saying > >> is that currently, the website build is broken. What I'm wanting > >> to do is update the website so I can announce Struts Flow. Struts > >> Flow will add three new pages so that might be too big to just hack > >> the HTML itself. > >> > >> > >>> The end-game is to create a separate "site" subproject for the > >>> top-level project that would introduce the project as a whole and > >>> link into each subproject. Each subproject would have its own set > >>> of documentation, in its own folder, perhaps done through Maven. > >>> Other "mega-projects", like Logging, seem to be doing that now. > >>> Building the Struts site would then be something like building > >>> the Jakarta Commons site. > >>> > >> > >> Well, that gets us back into the Maven vs. Ant debate. I'd imagine > >> we don't want to have part of the build require Ant, and the other > >> require Maven. Are there any examples of this being done that use > >> Ant? > >> > >> Don > >> > >> > >>> -Ted. > >>> > >>> > >>> On Tue, 15 Feb 2005 17:55:53 -0800, Don Brown wrote: > >>> > >>> > >>>> Ok, I give up - how do you build the Struts website? Last I > >>>> remember, I used ant which pulled the content from /docs but I > >>>> can't seem to find any site building task in build.xml. Are we > >>>> now only using maven and /xdocs? > >>>> > >>>> Don > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLDs not included in maven build of struts-taglib jar
On Sat, 5 Feb 2005 15:52:33 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 4:12 PM -0500 2/5/05, Bill Siggelkow wrote: > >Okay, the struts-taglib...jar now includes the TLD files. However, > >there is still an issue with the struts-mailreader application. > >Currently, it references the TLDs in the web.xml like this: > > > > > > /tags/struts-bean > > /WEB-INF/struts-bean.tld > > > > > >However, since the tlds are now in the taglib jar we need to change > >how this works. One way would be to remove the taglib declarations; > >but this would require changing the JSPs to use the absolute URI. > >Optionally, you can specify a jar file in the taglib location; > >however, I do not know if you can refer to a specific TLD in that > >jar? > > Although I don't think anyone has taken a firm step in this > direction, I believe we're all in consensus about shifting the > minimum specs for Struts 1.3 to Servlet 2.3/JSP 1.2. In so far as > that's true, then all containers should support the TLD autodiscovery > features, so I'd say we leave it out of the web.xml and use the > "official" URI from the TLD files. I'm +1 on using the packaged taglibs mechanism in the samples. Unfortunately, we'll still need to provide the TLDs as separate files with the taglib subproject, so that people will not be forced to change all their own apps. -- Martin Cooper > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: No mailing list link at http://struts.apache.org/ ?
On Sun, 6 Feb 2005 01:09:14 -0800, Shey Rab Pawo <[EMAIL PROTECTED]> wrote: > Should there be a "mailing list" link on the Struts home page > (http://struts.apache.org/) navigation tile? You'll find that information here: http://struts.apache.org/learning.html#More -- Martin Cooper > -- > The radiance of all the stars does not equal a sixteenth part of the > moon's radiance, likewise, good deeds giving us merit, all these do > not equal a sixteenth part of the merit of loving-kindness.. > > - > 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: duplicate files
On Thu, 3 Feb 2005 05:47:00 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Yes, I remember you mentioning that. However, I don't see the cactus test > being run when I do "maven dist", am I missing something? No, you're not missing anything. I just haven't tried to do that yet. ;-) -- Martin Cooper > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Wednesday, February 02, 2005 10:40 PM > Subject: Re: duplicate files > > >I moved TestActionServlet to test-cactus recently, as part of the > > Maven build cleanup for core. The point is that Maven expects to find > > JUnit tests in 'test' and the Cactus plugin expects to find Cactus > > unit tests in 'test-cactus'. Once I moved that one class, both the > > JUnit tests and the Cactus tests "just worked". I'd like to keep it > > that way. ;-) > > > > As far as duplicate files go, shouldn't it just be a case of > > taglib-independent stuff goes in core, and taglib-dependent stuff goes > > in taglib? Am I missing something? > > > > -- > > Martin Cooper > > > > > > On Wed, 2 Feb 2005 22:14:45 -0500, James Mitchell <[EMAIL PROTECTED]> > > wrote: > >> In case anyone missed it in the last batch of commits, there are > >> duplicate > >> files under: > >> > >> core/src/test > >> > >> and > >> > >> taglib/src/webapp/test/java > >> > >> I'm sure I screwed up somewhere, but the weird thing isunder > >> core/src, > >> there's a "test" and a "test-cactus", which only serves to split > >> TestActionServlet.java (and that's it!) Other than that, there's no > >> difference. I'm guessing this was an attempt to split off what is needed > >> by > >> cactus, and what can be handled by Mock objectsbut not sure. > >> > >> Anyone care to comment on this, or give me a suggestion which way to go? > >> > >> I was planning to remove the ones from core, since the corresponding JSPs > >> are already in taglib...your thoughts? > >> > >> -- > >> James Mitchell > >> Software Engineer / Open Source Evangelist > >> EdgeTech, Inc. > >> 678.910.8017 > >> AIM: jmitchtx > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: duplicate files
I moved TestActionServlet to test-cactus recently, as part of the Maven build cleanup for core. The point is that Maven expects to find JUnit tests in 'test' and the Cactus plugin expects to find Cactus unit tests in 'test-cactus'. Once I moved that one class, both the JUnit tests and the Cactus tests "just worked". I'd like to keep it that way. ;-) As far as duplicate files go, shouldn't it just be a case of taglib-independent stuff goes in core, and taglib-dependent stuff goes in taglib? Am I missing something? -- Martin Cooper On Wed, 2 Feb 2005 22:14:45 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > In case anyone missed it in the last batch of commits, there are duplicate > files under: > > core/src/test > > and > > taglib/src/webapp/test/java > > I'm sure I screwed up somewhere, but the weird thing isunder core/src, > there's a "test" and a "test-cactus", which only serves to split > TestActionServlet.java (and that's it!) Other than that, there's no > difference. I'm guessing this was an attempt to split off what is needed by > cactus, and what can be handled by Mock objectsbut not sure. > > Anyone care to comment on this, or give me a suggestion which way to go? > > I was planning to remove the ones from core, since the corresponding JSPs > are already in taglib...your thoughts? > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - > 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: feature request concerning locales
Good catch. Please file an enhancement request for this, so that it
doesn't get lost. See the instructions here:
http://struts.apache.org/faqs/helping.html#bugs
--
Martin Cooper
On Thu, 27 Jan 2005 21:57:06 +0100, Jeroen Kransen
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm not sure if this is the right way or the right place to place a
> feature request. If not, you can stop reading now. Instead of a feature
> request, it might also be considered a (minor) bug.
>
> I noticed the strong support for different locales by struts, which I
> like very much. There is however one thing I am missing. Imagine that my
> preferred language as set in the "Accept-language" setting of my browser
> (and HTTP header in requests) is: "fr,de" (French and German
> respectively). If I go to a Struts site that supports only English and
> German (en,de), there is no match at all, no matter that I accept
> German. Reason is the following lines in RequestUtils.java:
>
> if (userLocale == null) {
> // Returns Locale based on Accept-Language header or the
> server default
> userLocale = request.getLocale();
> }
>
> So, only the (first) preferred language is considered, and any
> successive languages are discarded. According to the HTTP specs, it can
> be a list of languages ("nl,en;q=0.8,de;q=0.5,..."). This is why the
> HttpServletRequest also has a method getLocales() which returns an
> Enumeration. I would like it if Struts would try to match any of the
> successive languages for which .properties files exist if the first
> isn't matched. I realize that it may cause a performance penalty, so
> maybe it can be made a configuration option
> (match-second-languages=true/false or something).
>
> I hope you will consider to add this feature.
>
> Regards, Jeroen Kransen
>
> -
> 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: ViewCVS Subversion interface is currently down
There was a period when the SVN repo kept getting hung up, and the finger was pointed at ViewCVS. While that is investigated further, and possible changes are made to ViewCVS, the interface was taken down. Notably, there have not been repo problems since then, so it looks like the finger was pointed in the right direction. Hopefully it will be back on line soon, butI haven't seen any news on that recently. -- Martin Cooper On Tue, 25 Jan 2005 14:44:41 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Browsing the Subversion repository seem to have been unavailable for a long > time now (weeks I think) - does anyone know whats happening with this? > > Trying to view http://svn.apache.org/viewcvs.cgi/struts/ results in the > following error > > "The Apache Software Foundation ViewCVS Subversion interface is currently > down while we investigate a problem with ViewCVS" > > Niall > > - > 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]
[ANNOUNCEMENT] New Struts subproject: Shale
The Apache Struts team is pleased to announce the adoption of its latest subproject, Struts Shale, a JSF-based framework. The Shale codebase was initiated by Craig McClanahan in the Struts sandbox, and development traffic regarding Shale has steadily increased. As the product is heading towards an initial release, the Struts PMC felt it time to formally adopt Struts Shale as a subproject. Today, Struts is comprised of eight subprojects: Core, Taglib, Tiles, El, Faces, Scripting, Applications, and (now) Shale. An initiative is underway to extract the Struts Tiles code into a standalone product. Several Struts developers plan to apply to the ASF to incubate Tiles as a toplevel project. [http://wiki.apache.org/struts/TilesTopLevel ] Extracts from the FAQ *Why are you offering both Struts Shale and Struts Classic? Don't they compete for new development?* We do offer Struts developers a choice, but, hey, choice is good. :) People who want to create and maintain Struts Classic are welcome to do so. People who want to create and maintain Struts Shale are equally welcome. As a volunteer organization, we are not constrained by the economics of competition. All we need are volunteers who are ready, willing, and able to do the work. So long as we have volunteers, we have work for them to do. :) Right now, we have volunteers who want to leverage the new JavaServer Faces framework by using Struts Shale for new development. We also have volunteers who prefer to leverage their existing investment in Struts Classic. All are welcome. For more about volunteering, visit our how to help page [http://struts.apache.org/faqs/helping.html]. *Will Struts Shale become Struts 2.x?* Right now, there are no concrete plans for a 2.x release of Struts Classic. The people working on the 1.x series want to evolve the code base without breaking backward compatibility. If we do our job right, then a 2.x release may never be needed. Meanwhile, Struts Shale has its own identity and its own release cycle. Struts Classic is one subproject, and Struts Shale is another. We encourage you to choose the framework that works best for you. (Even if it is not one of ours!) * Is Struts Shale a fork?* No. It's an entirely new codebase. Struts Shale is an MVC framework for web applications, like Struts Classic, but it's a fresh start. Struts Shale is the best choice for developers eager to leverage the latest technologies, like JavaServer Faces. Both frameworks will have a home here so long as there are volunteers ready to contribute. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ------HELP-----STRUTS source setup on WSAD5.1
On Sat, 22 Jan 2005 09:04:23 +0530, Vinod Easaw Varghese <[EMAIL PROTECTED]> wrote: > But my web .xml refers to the 2.2 DTD Do you have the DTD in the right place in the class path? org/apache/struts/resources/web-app_2_2.dtd -- Martin Cooper > PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" > "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";> > > With thanks and Regards > Vinod Easaw Varghese > > -Original Message- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 22, 2005 9:01 AM > To: Struts Developers List > Subject: Re: --HELP-STRUTS source setup on WSAD5.1 > > My guess is that you are using Servlets 2.4, and you are not online. > Struts has copies of the 2.2 and 2.3 DTDs locally, but not the 2.4 > XSD, so it will try to retrieve that from the Sun web site. If you're > not online, that will fail, obviously. > > -- > Martin Cooper > > On Sat, 22 Jan 2005 08:43:04 +0530, Vinod Easaw Varghese > <[EMAIL PROTECTED]> wrote: > > Hi , > > > >I am trying to setup the STRUTS framework source for > version > > 1.2.6 within WSAD5.1. When I try to create any JSP page utilizing the > > framework through the STRUTS source I have set up in the same project > I > > get the following error > > > > [1/22/05 8:40:24:040 IST] 4f8552d4 ActionServlet E > > org.apache.struts.action.ActionServlet The /WEB-INF/web.xml was not > > found. > > [1/22/05 8:40:24:087 IST] 4f8552d4 ActionServlet E > > org.apache.struts.action.ActionServlet TRAS0014I: The following > > exception was logged java.net.UnknownHostException: java.sun.com > > at java.net.InetAddress.getAllByName0(InetAddress.java:591) > > at java.net.InetAddress.getAllByName0(InetAddress.java:560) > > at java.net.InetAddress.getByName(InetAddress.java:469) > > at java.net.Socket.(Socket.java:121) > > at sun.net.NetworkClient.doConnect(NetworkClient.java:65) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:361) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:548) > > at sun.net.www.http.HttpClient.(HttpClient.java:296) > > at sun.net.www.http.HttpClient.(HttpClient.java:306) > > at sun.net.www.http.HttpClient.New(HttpClient.java:318) > > at > > > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.ja > > va:466) > > at > > > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec > > tion.java:562) > > at java.net.URL.openStream(URL.java:826) > > at > > > org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.jav > > a:748) > > at > > > org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager. > > java:708) > > at > > > org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImp > > l.java:258) > > at > > > org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XML > > DocumentScannerImpl.java:833) > > at > > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDo > > cumentFragmentScannerImpl.java:333) > > at > > > org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardPars > > erConfiguration.java:525) > > at > > > org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardPars > > erConfiguration.java:581) > > at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) > > at > > > org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java > > :1158) > > at org.apache.commons.digester.Digester.parse(Digester.java:1591) > > at > > > org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java:11 > > 42) > > at > > org.apache.struts.action.ActionServlet.init(ActionServlet.java:328) > > > > I believe this is happening within ActionServlet class when it is > > trying to parse the web.xml . Could anyone tell me why is this > happening > > > > With thanks and Regards > > Vinod Easaw Varghese > > > > > > - > 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: ------HELP-----STRUTS source setup on WSAD5.1
My guess is that you are using Servlets 2.4, and you are not online. Struts has copies of the 2.2 and 2.3 DTDs locally, but not the 2.4 XSD, so it will try to retrieve that from the Sun web site. If you're not online, that will fail, obviously. -- Martin Cooper On Sat, 22 Jan 2005 08:43:04 +0530, Vinod Easaw Varghese <[EMAIL PROTECTED]> wrote: > Hi , > >I am trying to setup the STRUTS framework source for version > 1.2.6 within WSAD5.1. When I try to create any JSP page utilizing the > framework through the STRUTS source I have set up in the same project I > get the following error > > [1/22/05 8:40:24:040 IST] 4f8552d4 ActionServlet E > org.apache.struts.action.ActionServlet The /WEB-INF/web.xml was not > found. > [1/22/05 8:40:24:087 IST] 4f8552d4 ActionServlet E > org.apache.struts.action.ActionServlet TRAS0014I: The following > exception was logged java.net.UnknownHostException: java.sun.com > at java.net.InetAddress.getAllByName0(InetAddress.java:591) > at java.net.InetAddress.getAllByName0(InetAddress.java:560) > at java.net.InetAddress.getByName(InetAddress.java:469) > at java.net.Socket.(Socket.java:121) > at sun.net.NetworkClient.doConnect(NetworkClient.java:65) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:361) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:548) > at sun.net.www.http.HttpClient.(HttpClient.java:296) > at sun.net.www.http.HttpClient.(HttpClient.java:306) > at sun.net.www.http.HttpClient.New(HttpClient.java:318) > at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.ja > va:466) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec > tion.java:562) > at java.net.URL.openStream(URL.java:826) > at > org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.jav > a:748) > at > org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager. > java:708) > at > org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImp > l.java:258) > at > org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XML > DocumentScannerImpl.java:833) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDo > cumentFragmentScannerImpl.java:333) > at > org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardPars > erConfiguration.java:525) > at > org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardPars > erConfiguration.java:581) > at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) > at > org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java > :1158) > at org.apache.commons.digester.Digester.parse(Digester.java:1591) > at > org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java:11 > 42) > at > org.apache.struts.action.ActionServlet.init(ActionServlet.java:328) > > I believe this is happening within ActionServlet class when it is > trying to parse the web.xml . Could anyone tell me why is this happening > > With thanks and Regards > Vinod Easaw Varghese > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning work-in-development (Re: svn commit: r125632 - /struts/el/trunk/project.xml)
I would suggest the following: * While in development, we continue to use the "-dev" suffix on the version number, with the version number itself being the next anticipated build. * Starting now, all subprojects use 1.3.0-dev as their version number. This is probably the only time they'll ever be in sync, but I think we should all start on the same page. * Subprojects increase their version numbers as needed, with no need to sync up with any other subproject's version number. As for bundles, I'm not totally convinced that we need them, especially as more people move to Maven. If we do decide to provide them, then I also don't have any good ideas for versioning them, or even how to define them, in terms of subprojects and when we would create a new one. (Would we create a new one each time any subproject has a new release? That would be a pain, and probably annoying / confusing to users. But if not, what would be the criteria for a new bundle?) As you mentioned, Joe, the J2EE numbering doesn't really tell you very much. It makes for interesting Cactus versioning, too, since Cactus embeds both its version number and the J2EE version number in its distro names. Yuk. I'd say let's forget about bundles, at least for the time being, and simply focus on getting the various subprojects sorted out and released in their new incarnations. Then we can see what the uptake is, and what the community thinks with respect to keeping things separate or defining some kind of bundling scheme. -- Martin Cooper On Wed, 19 Jan 2005 12:17:44 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > This raises a question which I don't feel we've really pinned down > yet -- how should we version artifacts between releases? Right now, > the result of maven jar for struts-el is "struts-el-1.2.6.jar", which > is misleading. > > This is independent of another question, which we should also > probably discuss, which is how we version non-core artifacts. I > generally prefer sharing version numbers -- I find the J2EE > methodology of rolling in a number of disparate version numbers into > a single release continually confusing, although I think that Ted has > suggested it as the approach for future Struts releases once we have > our pieces all broken out. I know that if we want things to have > their own release cycle, then we may not simply be able to share the > major "Struts version number", but like I said, I'm not real fond of > the only other alternative I have thought of. > > I admit to having no solid proposal for either of these things. > > For between-release artifacts, I have seen someone use "SNAPSHOT" in > a version name, which I would recommend against, as Maven always > tries to download dependencies which contain that string, something > which quickly becomes tiresome. I would prefer that we not use real > version numbers in the project.xml file until the moment when a > release is being cut, to avoid confusion. > > In my uncommitted work on the ActionContext, I am using > "struts-1.3.0-dev". I think using the expected next release number > plus "-dev" is a decent compromise, but I'm happy to hear other ideas. > > Joe > > At 5:46 PM + 1/19/05, [EMAIL PROTECTED] wrote: > >Author: jmitchell > >Date: Wed Jan 19 09:46:35 2005 > >New Revision: 125632 > > > >URL: http://svn.apache.org/viewcvs?view=rev&rev=125632 > >Log: > >el now builds a good distribution (well, with maven anyway) > >Modified: > >struts/el/trunk/project.xml > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: Struts build
On Wed, 19 Jan 2005 09:43:12 +0530, Rajaneesh <[EMAIL PROTECTED]> wrote: > Hey! > > I was intersted in looking the source code of struts. So I decided to > download it from http://cvs.apache.org/builds/jakarta-struts/nightly/src/ > > However I notices that the size of the source code has almost increased by 3 > times in > latest source code all of the sudden. Is there anything wrong with the > source code? Or are > these enhanced functionalities? You've picked an unfortunate time to start looking at the code. ;-) The repository is going through a good deal of change right now, as we pull apart what was one monolithic project into multiple independently releasable subprojects. What you are seeing is an intermediate state in which the nightly build process is to some extent waiting for the new structure to stabilise. Given the current state of things, you might want to check out the 1.2.x branch (named STRUTS_1_2_BRANCH) from the repository instead, or, if you are interested in specific pieces of the latest of Struts, check out the subproject(s) for those from the trunk in SVN. (By the way, browser access to the source code is not working at the moment. It has been temporarily disabled due to an infrastructure issue, so you'll need to check out the code using a Subversion client. If you're using Windows, I would recommend TortoiseSVN if you don't already have a client.) -- Martin Cooper > Regards > Rajaneesh > > Snapshot from the site! > > struts-src-20050115.tar.gz 15-Jan-2005 06:27 5.6M Automated test > builds > struts-src-20050115.zip 15-Jan-2005 06:36 7.6M Automated test > builds > struts-src-20050116.tar.gz 16-Jan-2005 21:27 22M Automated test > builds > struts-src-20050116.zip 16-Jan-2005 21:59 27M Automated test > builds > struts-src-20050117.tar.gz 17-Jan-2005 06:24 22M Automated test > builds > > - > 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: Adjustments to Struts Nightly Builds
On Mon, 17 Jan 2005 11:17:33 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Mon, 17 Jan 2005 14:10:57 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > > > For these reasons, I think the uber-build, if we have one, > > > should be kept very simple. > > > > Would the uber-build also generate the global 'site' that glues all the > > other docs together? > > > > Isn't building the site still the same as the result of building > "apps/documentation"? If so, that could be uploaded as a separate > artifact so it wouldn't have to be combined into the artifact for the > core library. What I would like to see is each subproject having its own docs, and 'site' having the glue that pulls the others together. I'd also like to see us move to a model where we check in the site(s) so that updating the live site is simply an 'svn up'. (I know the infra@ folks would like to see this too.) This would allow for automated site refreshes, eliminating the (funky, IMHO) current mechanism of uploading a war and logging on to explode it in place. -- Martin Cooper > > > > -- > > James Mitchell > > Craig > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adjustments to Struts Nightly Builds
On Mon, 17 Jan 2005 14:10:57 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > > For these reasons, I think the uber-build, if we have one, > > should be kept very simple. > > Would the uber-build also generate the global 'site' that glues all the > other docs together? I believe we decided that that would come out of a 'site' pseudo-subproject. I still think that's the right place for it. -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Monday, January 17, 2005 2:05 PM > Subject: Re: Adjustments to Struts Nightly Builds > > > On Mon, 17 Jan 2005 06:21:16 -0500, James Mitchell <[EMAIL PROTECTED]> > > wrote: > >> I was a bit disappointed last night while testing the Maven command > >> to generate an Ant build.xml. > >> > >> There were no hard coded paths (as you've experienced), but the > >> particular plugin that generates the build.xml is not as mature > >> (wrt multiproject builds) as I had assumed. > >> > >> No worries, I will put together a build that does (from current/apps) > >> everything that "maven apps:build-all" does from the same location. > >> > >> Note that maven target "apps:build-all" will probably change > >> shortly. It will probably end up as "dist" to align with our > >> Ant build. In core, build.xml will simply call apps/build.xml > >> with the same arguments, and apps/build.xml will (partly) take > >> over the job that build-webapps.xml used to have. > > > > We don't want 'core' building stuff in 'apps'. The 'core' subproject > > should not know about any other subprojects. As we discussed on > > another thread, any uber-build stuff we have should live in a 'build' > > pseudo-subproject, so that it's not part of any individual subproject. > > > > However, note that such an uber-build would serve only two purposes: > > (1) to make the nightly builds slightly simpler; (2) for the > > convenience of developers wanting to build everything. Since the > > subprojects will be independently released, we will not need an > > uber-build to handle the release process. For these reasons, I think > > the uber-build, if we have one, should be kept very simple. > > > > -- > > Martin Cooper > > > > > >> Current/apps is progressing quite nicely right now. I'm still > >> consolidating a few sets of duplicate code (partly due to my own > >> svn-newbie-ness and partly due to us actually _having_ duplicate > >> code out there). > >> > >> I've also moved the tiles stuff to tiles. > >> > >> There's still a lot of work to do to get us back to a clean distribution, > >> but I'm enjoying it so far. I've got a lot on my todo list. > >> > >> Stay tuned for more... > >> > >> -- > >> James Mitchell > >> Software Engineer / Open Source Evangelist > >> EdgeTech, Inc. > >> 678.910.8017 > >> AIM: jmitchtx > >> > >> - Original Message - > >> From: "Craig McClanahan" <[EMAIL PROTECTED]> > >> To: "Struts Developers List" > >> Sent: Monday, January 17, 2005 1:28 AM > >> Subject: Adjustments to Struts Nightly Builds > >> > >> > I've adjusted the scripts for the Struts nightly builds to use > >> > Martin's new "current" pseudo-project (thanks Martin!), to minimize > >> > problems in the face of all the restructuring that is currently going > >> > on. As a side effect of this change, the source distribution for > >> > Struts will now contain all the sources in "current", instead of just > >> > the "core/trunk" part we used to get. This seems to make more sense > >> > now that it's necessary to cross over all these subprojects in order > >> > to get a nightly binary. However, the source distro is now > >> > substantially bigger (22mb versus 7.6mb). > >> > > >> > I'm also assuming that running "ant clean dist" in the "core" trunk is > >> > still the right command to build the nightly binary releases. Let me > >> > know if you'd prefer something different. > >> > > >> > Craig > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adjustments to Struts Nightly Builds
On Mon, 17 Jan 2005 11:11:13 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Mon, 17 Jan 2005 11:05:30 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > > We don't want 'core' building stuff in 'apps'. The 'core' subproject > > should not know about any other subprojects. As we discussed on > > another thread, any uber-build stuff we have should live in a 'build' > > pseudo-subproject, so that it's not part of any individual subproject. > > > > However, note that such an uber-build would serve only two purposes: > > (1) to make the nightly builds slightly simpler; (2) for the > > convenience of developers wanting to build everything. Since the > > subprojects will be independently released, we will not need an > > uber-build to handle the release process. For these reasons, I think > > the uber-build, if we have one, should be kept very simple. > > We could also just have the nightly build script create a binary for > each of the top level subprojects, and skip having an uber-build at > all. Then, we'd just need a build at the top of each subproject's > tree, and most of them have one already. That would be fine with me. > I'd like to do just one source distro, though, that has all the > subprojects in it. Stripping out the JAR files that were incorrectly > included in last night's build will get the size back to reasonable. > Does this sound agreeable? Are you thinking that this would be just a part of the nightly build process, rather than something an uber-build would do (thus avoiding the uber-build again)? That would also be fine with me. At some point, though, I do want to get the nightly builds running on ASF hardware. (Yeah, I know, I've been saying that for ages and haven't done anything about it. But I will one day. Really. ;) -- Martin Cooper > > > > -- > > Martin Cooper > > > > Craig > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adjustments to Struts Nightly Builds
On Mon, 17 Jan 2005 06:21:16 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > I was a bit disappointed last night while testing the Maven command > to generate an Ant build.xml. > > There were no hard coded paths (as you've experienced), but the > particular plugin that generates the build.xml is not as mature > (wrt multiproject builds) as I had assumed. > > No worries, I will put together a build that does (from current/apps) > everything that "maven apps:build-all" does from the same location. > > Note that maven target "apps:build-all" will probably change > shortly. It will probably end up as "dist" to align with our > Ant build. In core, build.xml will simply call apps/build.xml > with the same arguments, and apps/build.xml will (partly) take > over the job that build-webapps.xml used to have. We don't want 'core' building stuff in 'apps'. The 'core' subproject should not know about any other subprojects. As we discussed on another thread, any uber-build stuff we have should live in a 'build' pseudo-subproject, so that it's not part of any individual subproject. However, note that such an uber-build would serve only two purposes: (1) to make the nightly builds slightly simpler; (2) for the convenience of developers wanting to build everything. Since the subprojects will be independently released, we will not need an uber-build to handle the release process. For these reasons, I think the uber-build, if we have one, should be kept very simple. -- Martin Cooper > Current/apps is progressing quite nicely right now. I'm still > consolidating a few sets of duplicate code (partly due to my own > svn-newbie-ness and partly due to us actually _having_ duplicate > code out there). > > I've also moved the tiles stuff to tiles. > > There's still a lot of work to do to get us back to a clean distribution, > but I'm enjoying it so far. I've got a lot on my todo list. > > Stay tuned for more... > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Craig McClanahan" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Monday, January 17, 2005 1:28 AM > Subject: Adjustments to Struts Nightly Builds > > > I've adjusted the scripts for the Struts nightly builds to use > > Martin's new "current" pseudo-project (thanks Martin!), to minimize > > problems in the face of all the restructuring that is currently going > > on. As a side effect of this change, the source distribution for > > Struts will now contain all the sources in "current", instead of just > > the "core/trunk" part we used to get. This seems to make more sense > > now that it's necessary to cross over all these subprojects in order > > to get a nightly binary. However, the source distro is now > > substantially bigger (22mb versus 7.6mb). > > > > I'm also assuming that running "ant clean dist" in the "core" trunk is > > still the right command to build the nightly binary releases. Let me > > know if you'd prefer something different. > > > > Craig > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adjustments to Struts Nightly Builds
On Sun, 16 Jan 2005 22:28:00 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I've adjusted the scripts for the Struts nightly builds to use > Martin's new "current" pseudo-project (thanks Martin!), to minimize > problems in the face of all the restructuring that is currently going > on. As a side effect of this change, the source distribution for > Struts will now contain all the sources in "current", instead of just > the "core/trunk" part we used to get. This seems to make more sense > now that it's necessary to cross over all these subprojects in order > to get a nightly binary. However, the source distro is now > substantially bigger (22mb versus 7.6mb). > > I'm also assuming that running "ant clean dist" in the "core" trunk is > still the right command to build the nightly binary releases. Let me > know if you'd prefer something different. Until we have an uber-build outside of 'core', that's probably right. At some point, though, the build in 'core' will build only 'core', and the nightly builds will want to use the uber-build instead. But we're not there yet... -- Martin Cooper > Craig > > - > 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]
New 'current' pseudo-subproject
I've set up a 'current' directory for Struts that uses a cool Subversion feature to make all of the individual subproject 'trunk' directories available through a single checkout. So now you can do this: svn co https://svn.apache.org/repos/asf/struts/current and get this: current/ apps/ bsf/ core/ el/ faces/ sandbox/ taglib/ tiles/ So now, if you're working on Struts as a whole, you can check out, update and commit for all subprojects at once. See the section on Externals Definitions in the Subversion book for how this works, and a couple of caveats: http://svnbook.red-bean.com/en/1.1/ch07s03.html Many thanks to Tim O'Brien for the idea. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn restructure
On Sat, 15 Jan 2005 20:47:52 -0600, Vic <[EMAIL PROTECTED]> wrote: > As far as site docs... that is a lot of work. One alternative is to use > one of PHP CMS systems... it is easy and no work. I'm obviously missing something. Are there PHP CMS systems that use the same XML format that our docs are currently in? Assuming there are not, then why is it a lot of work to do site docs as we have been discussing, and no work to use a CMS that doesn't understand our current doc format? In any case, the infrastructure folks are very unlikely to OK a non-static site system, because of the load it would put on our servers, especially for a project as popular as Struts. -- Martin Cooper > I know, I know. > (BasicPortal is Apache License, that is Struts and it works at several > comercial even that is less work). > Springframework.com uses something. Etc. etc. > I use Drupal and am properly shamed. > > .V > > - > 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: svn restructure
On Sat, 15 Jan 2005 17:52:15 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > See intermixed and below for more questions... > > > The xdocs folder was an early attempt to migrate to Maven. > > It did actually work, we just weren't ready to finish the migration, > > and the experimental xdocs have not been maintained. > > My ultimate goal (this year) is to get Struts and all of the subprojects > to be singing to the same tune and to the same beat. My choice of tools > is Maven, but the Ant scripts will be fully compatible. If we get the Maven builds right, we'll be able to generate the Ant builds anyway, right? > > Building the tld and reference documentation from the same source is > > a clever idea (though it does confuse everyone at first), and I > > imagine we want to retain it. > > I'm wondering about this. I'd like to see the same thing implemented with > maven. I don't know how much more it will buy us by doing: > > xdoc -> tld/doco/and the foo report > versus > doc -> tld/doco Are you talking about the same issue I was describing in my previous message? This definitely needs some more thought. > > > Conceptually, the dev*.xml files are like JavaDocs. They are the source > > for the TLDs, with embedded comments. > > These could be moved to the taglib subproject, along with the Java source. Yup, all the taglibs docs should be moved to that subproject. (BTW, shouldn't the subproject name be plural??) > Yes, that is just the coolest thing!! > > > Now all we need is an xdoc browser for Eclipse with full tag > completion. It would let you preview your changes without having > to fire off ant or mavenwow...I might actually pay for something > like that. > Dream on ... or scratch the itch. ;-) ;-) > > > The website for the taglib subproject could then link to the Developers > > Guide (embedded in the JavaDoc) and the "TagDoc" (generated from the > > dev*.xml files). > > It's on my todo list. > > I've got apps building (though they won't work without the .tld), Just FYI, the Maven build for 'core' is generating the tlds right now. ;-) > but I've > come across one strange problem. I remember mentioning it before and asking > about what we should do. The tile-documentation source are importing > classes that were removed during digester 1.5 -> 1.6. They were moved to > examples or samples or something like that (I remember reading about it in > the release notes), so tiles-documentation won't compile unless I downgrade > the dependency to 1.5. Can you expand on this? What went missing, and how were we using it? -- Martin Cooper > So, should I: > a) ask commons-digester people to (+1 I have to do the same sort of > thing > publish the sample.jar, so we for commons-resources db impls) > can pick it up? > > b) copy the java source here (-0 bad idea, but may be best solution > if a does not happen) > > c) refactor the source to not use (-0 i'd hate to lose good > documentation) > those classes > > d) let David Geary worry about it ;) (+1 he's a bright guy!!!) > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Saturday, January 15, 2005 3:45 PM > Subject: Re: svn restructure > > -Ted. > > On Sat, 15 Jan 2005 15:22:12 -0500, James Mitchell wrote: > > In "apps" are we getting to a single artifact per project.xml? Yes! > > > > So, what's the deal with docs? There's struts/trunk/doc and > > struts/trunk/xdoc. > > > > If I recall correctly, xdoc was a failed attempt to move us over to > > a different documentation builder. Is that not correct? > > > > Do we want to continue to build the tld and documentation from the > > same xml? (I am sure the answer is yes, but I need to know for > > sure). So, that said, what would be our best strategy? Given the > > new restructuring of apps, we can now build the apps against any > > version of struts, simply by changing the project.xml (locally). > > > > > > (from here down, when I say "install", I mean how Maven compiles, > > JARs, and sticks that jar under your local > > .maven/repository/struts/jars) > > > > > >> From a global perspective, what should a full build do? (and in > >> what > >> > > order?) > > >
Re: svn restructure
On Sat, 15 Jan 2005 15:22:12 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:
> In "apps" are we getting to a single artifact per project.xml? Yes!
Looking good!
> So, what's the deal with docs? There's struts/trunk/doc and
> struts/trunk/xdoc.
>
> If I recall correctly, xdoc was a failed attempt to move us over to a
> different documentation builder. Is that not correct?
As Ted mentioned, the idea with xdocs was to use Maven to build the
docs. What's in there now is probably not very useful, since it's so
out of date.
However, since we're now driving towards Maven again, we'll want to
decide on whether we want to migrate the docs and keep them that way
this time. IMO, we should focus on getting the various builds into
shape first, so that we're sure we're going to stick with Maven this
time. Assuming we get to that point, we can think about divvying up
the docs across the projects and migrating them to xdocs. (I guess we
could do the divvying up sooner, but that would lead to a bunch of
other things we'd need to change. One thing at a time, IMO.)
> Do we want to continue to build the tld and documentation from the same xml?
> (I am sure the answer is yes, but I need to know for sure). So, that said,
> what would be our best strategy? Given the new restructuring of apps, we
> can now build the apps against any version of struts, simply by changing the
> project.xml (locally).
Yes, we should continue to generate the tlds and docs from common
sources, as long as that's possible. One thing I don't know right now
is if we'll be able to mark up the xdocs directly (i.e. if Maven will
get confused if we add some of the tags we need). If that's the case,
we might end up having to start with a common source file and generate
xdocs as well as tlds, and then feed the xdocs to Maven. That would be
messy but still workable, I would think.
> (from here down, when I say "install", I mean how Maven compiles, JARs, and
> sticks that
> jar under your local .maven/repository/struts/jars)
>
> From a global perspective, what should a full build do? (and in what
> order?)
>
> - core
> - bsf
> - taglib
> - docs
> - apps
> - el
When you say 'docs' here, I'm not sure what you mean. With each
subproject building its own docs, perhaps you mean 'site'? That would
be the glue that holds the remainder together. Although I recall Ted
suggesting that 'core' own the main site and the remaining subprojects
would link to that. (The problem with that, IMO, is that we still need
some way of referring to the subprojects from the main page, so I
believe we still need a 'site'. We just need to decide what's in
that.)
Also, I would expect 'el' to come before 'apps'. Shouldn't 'apps' be
last, so that it can take advantage of all the other subprojects?
> ...come to think of it, with the dependencies declared correctly in
> project.xml, maven will automatically figure it out for us, right?
Dunno. I haven't got that far in my Maven education yet. ;-)
> Given the decision on a new global script, what kinds of targets do we want
> to setup?
>
> before:
> ant dist - did a full distribution
> ant test.tomcat.x.y - ran the full test suite under jakarta-tomcat-x.y
> ant release - the "do it all" target that got us
Well, there are scads of other targets, too. ;-) We'll need to decide
what to keep and what to drop (if anything).
The nightly builds do 'ant clean dist', so we'll need a way to do
that. The Cactus targets get taken care of by Maven ('maven cactus'),
and we should be able to use 'maven dist' instead of 'ant release'
(with a bit of work).
> Now that the project is fractured into smaller pieces, we are
> closer to a continuous integration strategy.
>
> So, those of use that want to use Maven...I'm thinking
> - core:dist (builds a struts-core-x.y.z)
> - core:install (this installs the new jar)
> - taglib:dist(simply builds a distribution for this project)
> - taglib:install (same as core...sort of)
> - and so on
> - and so forth
>
> and from core/trunk:
>
> > maven global:release
>(would build a complete distribution of all the latest components or
> artifacts)
Hmm. The intent is to have the subprojects individually versioned and
released, so I'm not sure we need a 'global:release' target. It would
be convenient for developers to be able to build everything at once
now and then, but we won't need to package everything up into a single
drop.
--
Martin Cooper
> Your thoughts?
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> -
> 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: svn
On Fri, 14 Jan 2005 22:22:52 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > I'm trying to create /struts/apps/trunk > > Do I need some special permission? Not that I'm aware of. I just created apps and apps/trunk, so you should be all set. -- Martin Cooper > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - > 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: svn repository
On Tue, 11 Jan 2005 21:09:48 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > > > >> ' ' > >> ' [-] test > >> ' ' (really need to get this back in order > >> ' ' or figure out a new strategy..more on > >> ' ' this later) > > > > Is this all taglibs tests right now? If so, perhaps it should live > > under 'taglibs' instead of 'apps', since it isn't a "real" > > application. If not, um, I dunno. This seems an odd place for tests. > > Yes, good point, I agree > > > > > You missed one. We also have 'struts-examples' directly under > > 'core/trunk', which has 'mailreader' in it. Just to complicate things, > > this also has a different source structure. > > Yes, I've done some diffs on the various mailreader apps that > seem to litter the landscape ;) > > I'd like to get them all consolidated (at least as much as can be done) > providing a single mailreader.jar for the variations. Do you mean one jar of the bits common to all flavours, and then separate apps for each variation? If so, I think this would be a good approach. If you mean combine the various mailreader apps into one, I think that would muddy the waters, and wouldn't work as well as examples of how to do things. > > > > We need to come up with one standard structure - we seem to have quite > > a few at the moment. The sources go in different places, the config > > files go in different places, etc. Not easy to follow at all. > > Yes, that's exactly what I intend to clean up. Please don't hesitate > if something looks odd, or if you prefer a diffent name. Where did 'conf' or 'config' go? We currently have 'conf/share', 'src/conf', etc., but I don't see where those land in your structures. > Not sure how many people caught my rename for 'examples' :D I admit that I missed it until you mentioned it just now. It could certainly use a new name, but I'm not sure about 'modules'. I don't hate it, though, and can't think of anything better right now. With SVN, renames are easy enough, so we could go with this for now and change it if someone comes up with a better name. > > > > >> - merge the mailreader sample app (and tests) from commons-chain > >> to struts "apps" (as indicated above) > > > > Need to check the relationship between this mailreader and the one > > under struts-examples. > > will do. > > > > >> I would like all the apps/trunk/foo to be mavenized, and each project.xml > >> creates a single .war file suitable for deployment. Each project > >> would/should inherit from a parent project.xml under apps/trunk that can > >> build the entire set of apps. So you can build any app you like, or just > >> build them all. The build.xml file will be generated by maven (hopefully > >> the path issues will be resolved). > > > > Do you plan to do Maven builds for the other subprojects as well, or > > just for the 'apps' subproject? Should I take the Ant build system off > > my to-do list? > > I hope you don't feel that I'm ripping the rug from under your feet. That > is > certainly not my intent. No, that's fine. If you have an itch to put a Maven build system together, more power to you. I was actually taking tips from Maven for the Ant build system anyway. ;-) > I was just hoping to get a consistent structure > and build for the "apps" for now. The repository seem to be in shambles at > the moment. Yah, it is. ;-( > As complicated as the build xml files (all 3 of them) seem to be to > some people, I know them pretty well, and it just makes my head hurt > looking at where we are now and what needs to happen to get a clean > "ant dist" and "ant release". I was hoping to do this incrementally. It'll be messy in the short term, but should get us up and running more quickly. Once we have a standard directory structure in place, as you're suggesting and as I was planning, it will be much easier to put a consistent build system in place across the board. -- Martin Cooper > I figured I would take my chances on the "apps" and generate the ant stuff. > Instead of the other way around (back into a project.xml by hand) > > Well, I'll wait to hear more on this before I actually pull out the axe and > 10 lb sledge ;) > > > > > -- > > Martin Cooper > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn repository
On Tue, 11 Jan 2005 13:58:32 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Actually, I had bigger things in mindwell, sort of ;) > > See intermixed. > > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Tuesday, January 11, 2005 12:19 PM > Subject: Re: svn repository > > > On Tue, 11 Jan 2005 06:35:25 -0500, James Mitchell <[EMAIL PROTECTED]> > > wrote: > >> Who is going to finish moving the directory structure? > > > > Whoever pitches in? ;-) > > > >> Right now, I can't load core as an Eclipse project because some of the > >> example apps rely on tiles, which relies on core. Creating a circular > >> reference as far as project dependencies goes. > > > > It should be easy enough to exclude the examples in your Eclipse > > project for now. > > Yes, but that's actually what I am after. > > > > >> I remember someone mentioning moving all the apps to an 'apps/trunk' > >> base. > >> Is that still going to happen? > > > > I had hoped to pull out the examples a couple of weekends ago, but the > > time didn't materialise as I had expected. It would be easy enough to > > pull them all out into an 'apps' subproject, but it's not quite as > > easy to get them all building again. > > > > However, if folks are OK with temporary breakage, I can pull them out > > tonight and leave them broken until the weekend, when I'll hopefully > > have time to make them build again. This sort of follows Ted's > > suggestion, from some time ago, to focus on getting Core into shape > > first and then clean up behind us after that. > > > Well, before you do that I have a few more questionsand a plan. > > 1. Why does commons-chain have a sample application called "mailreader"? > This looks to be the same mailreader as the one in Struts. I believe Joe's answer hits the nail on the head. > 2. core doesn't compile with "ant dist" or "maven dist" due to half baked > file structure changes. Specifically, the sample apps refer to TagUtils, > which they can't find. How does the nightly run anyway? It's failing at the moment. Phooey. I made local changes to get it running, but it seems I omitted to actually commit those changes. I'll try to fix that tonight. > 3. What is the status of tiles? I though David Geary was extracting > it from core and we would simply provide an integration library. I think we're in limbo at the moment. I believe the current thinking is that David G will bring his Struts-independence changes into the fold, and Tiles will live as a subproject for a while, potentially graduating to a TLP when it's "ready". > Also, tiles/trunk seems to be a copy of core/trunk, is this correct? > The tiles stuff seem to be under tiles/trunk.old Dunno. That's a question for Don, I think, since he did the Tiles & Taglibs extractions. > [The plan (yes, I'm volunteering) ] > So, unless someone says something, my plans are as follows: > - move all the sample apps to a new "apps" subproject as follows: >[-] trunk > ' [-] blank > ' ' [-] src > ' '[+] java (nothing in here right now) > ' '[+] resources > ' '[+] test > ' '[+] webapp > ' ' > ' [-] example (mailreader) > ' ' (needs to be merged with latest > ' 'from several places) > ' ' [-] src > ' '[+] java > ' '[+] resources > ' '[+] test > ' '[+] webapp > ' ' > ' [-] examples > ' ' (exercise, upload, validator) > ' ' (i feel this should be renamed to 'modules') > ' ' [-] src > ' '[+] java > ' '[+] resources > ' '[+] test > ' '[+] webapp > ' ' > ' [-] test > ' ' (really need to get this back in order > ' ' or figure out a new strategy..more on > ' ' this later) Is this all taglibs tests right now? If so, perhaps it should live under 'taglibs' instead of 'apps', since it isn't a "real" application. If not, um, I dunno. This seems an odd place for tests. > ' ' [-] src > ' '
Re: svn repository
On Tue, 11 Jan 2005 06:35:25 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Who is going to finish moving the directory structure? Whoever pitches in? ;-) > Right now, I can't load core as an Eclipse project because some of the > example apps rely on tiles, which relies on core. Creating a circular > reference as far as project dependencies goes. It should be easy enough to exclude the examples in your Eclipse project for now. > I remember someone mentioning moving all the apps to an 'apps/trunk' base. > Is that still going to happen? I had hoped to pull out the examples a couple of weekends ago, but the time didn't materialise as I had expected. It would be easy enough to pull them all out into an 'apps' subproject, but it's not quite as easy to get them all building again. However, if folks are OK with temporary breakage, I can pull them out tonight and leave them broken until the weekend, when I'll hopefully have time to make them build again. This sort of follows Ted's suggestion, from some time ago, to focus on getting Core into shape first and then clean up behind us after that. -- Martin Cooper > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - > 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: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
On Thu, 06 Jan 2005 22:43:53 -0600, Vic <[EMAIL PROTECTED]> wrote: > > For the slow people: Is Tiles moving as it's own Apache project... not a > Struts sub-project? Yah, I'm pretty sure that's what the "TopLevel" means in the name of the "TilesTopLevel" wiki page. ;-) > (I do not care, just... I assumed that since Struts was a Top level > project, it had freedom to do as it pleases) Up to a point, yes. But I think with Tiles, the idea is that it shouldn't be tied to any one framework, so it makes more sense for it to live an independent life, rather than be buried within Struts. That will give it greater visibility, hopefully leading to more widespread adoption, and the option of collecting together the Tiles adapters for multiple frameworks, such as Struts, Velocity and MyFaces, for starters. -- Martin Cooper > .V > > -- > RiA-SoA w/JDNC <http://www.SandraSF.com> forums > - help develop a community > My blog <http://www.sandrasf.com/adminBlog> > > > - > 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: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
On Thu, 6 Jan 2005 20:24:45 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, there's a draft proposal up at > [http://wiki.apache.org/struts/TilesTopLevel]. I noticed that the proposal mentions Jira. Without getting into a big flap about which one is better, I just wanted to point out that it would be much simpler to reallocate bugs in the Struts bug database to Tiles if Tiles uses Bugzilla. -- Martin Cooper > [Tell you what, after working in Confluence all day, Moin Moin feels like a > jalopy :)] > > On Wed, 29 Dec 2004 19:10:45 -0700, David Geary wrote: > > Le Dec 29, 2004, à 4:44 PM, Ted Husted a écrit : > > > >> Since there seems to be interest, why don't I setup the usual > >> proposal on the incubator wiki, and we can see who signs up. > >> > >> Even if we were able to dodge "incubation" per se, we would still > >> need to bring a resolution to the board, and do all the same > >> infrastructure things. > >> > > > > Excellent. I'm really excited about this. Let's do it. > > > >> David, if you wanted to contribute the package you extracted to > >> Struts, as Martin indicated, it would make it easier to frame the > >> proposal. > >> > > > > Sure, I'd be happy to do that. > > > >> Then, we could just remove it from the Core, rather than extract > >> it, and when the time comes, just move it from one Apache > >> instance to another. > >> > > > > Okay. > > > >> As mentioned, we can restore your karma upon request. (Merit > >> never expires.) All you would need to do is file a CLA > >> [http://apache.org/licenses/icla.txt] and ask us to update your > >> status. > >> > > > > I'll do that also. > > > > > > david > > > >> > >> -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: Bug in DownloadAction?
On Thu, 6 Jan 2005 12:50:26 -0600, Lane, Brad <[EMAIL PROTECTED]> wrote: > Thank you. How close is 1.2.6 to being released? 1.2.6 is Beta. There are a few outstanding issues in the bug database that we need to resolve before we can roll 1.2.7. As usual, there's no real predictable timeline for this, but I'd like to get 1.2.7 out reasonably soon. -- Martin Cooper > > -Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 06, 2005 12:06 PM > To: Struts Developers List > Subject: Re: Bug in DownloadAction? > > On Wed, 5 Jan 2005 15:31:34 -0600, Lane, Brad <[EMAIL PROTECTED]> wrote: > > I believe there's a bug in org.apache.struts.actions.DownloadAction. > > Overriding getBufferSize() doesn't have any effect since the byte > > array is created with the static field DEFAULT_BUFFER_SIZE. > > Fixed. Sorry about that. > > -- > Martin Cooper > > > Thanks, > > Brad > > > > Brad Lane > > Software Developer > > Pearson Educational Measurement > > eMeasurement(tm) Services > > http://www.pearsonedmeasurement.com/emeasurement/ > > Ph: (641) 844-0316 > > Fx: (641) 754-6580 > > > > ** > > ** This email may contain confidential material. > > If you were not an intended recipient, Please notify the sender and > > delete all copies. > > We may monitor email to and from our network. > > ** > > ** > > > > - > > 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] > > > This email may contain confidential material. > If you were not an intended recipient, > Please notify the sender and delete all copies. > We may monitor email to and from our network. > > > - > 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: Bug in DownloadAction?
Since you're on the dev list, you should have seen the commit messages go by... ;-) I made copy() non-static. -- Martin Cooper On Thu, 6 Jan 2005 10:10:56 -0800 (PST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > How did you decide to fix it Martin? Just out of curiosity. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Thu, January 6, 2005 1:06 pm, Martin Cooper said: > > On Wed, 5 Jan 2005 15:31:34 -0600, Lane, Brad <[EMAIL PROTECTED]> > > wrote: > >> I believe there's a bug in org.apache.struts.actions.DownloadAction. > >> Overriding getBufferSize() doesn't have any effect since the byte array > >> is > >> created with the static field DEFAULT_BUFFER_SIZE. > > > > Fixed. Sorry about that. > > > > -- > > Martin Cooper > > > > > >> Thanks, > >> Brad > >> > >> Brad Lane > >> Software Developer > >> Pearson Educational Measurement > >> eMeasurement(tm) Services > >> http://www.pearsonedmeasurement.com/emeasurement/ > >> Ph: (641) 844-0316 > >> Fx: (641) 754-6580 > >> > >> > >> This email may contain confidential material. > >> If you were not an intended recipient, > >> Please notify the sender and delete all copies. > >> We may monitor email to and from our network. > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in DownloadAction?
On Wed, 5 Jan 2005 15:31:34 -0600, Lane, Brad <[EMAIL PROTECTED]> wrote: > I believe there's a bug in org.apache.struts.actions.DownloadAction. > Overriding getBufferSize() doesn't have any effect since the byte array is > created with the static field DEFAULT_BUFFER_SIZE. Fixed. Sorry about that. -- Martin Cooper > Thanks, > Brad > > Brad Lane > Software Developer > Pearson Educational Measurement > eMeasurement(tm) Services > http://www.pearsonedmeasurement.com/emeasurement/ > Ph: (641) 844-0316 > Fx: (641) 754-6580 > > > This email may contain confidential material. > If you were not an intended recipient, > Please notify the sender and delete all copies. > We may monitor email to and from our network. > > > - > 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: [ANNOUNCE] Struts 1.2.6 Beta Released
On Tue, 04 Jan 2005 17:08:12 -0800, Abhishek Khandelwal <[EMAIL PROTECTED]> wrote: > Will struts 1.2.6 beta would be upgraded to production/GA release in > near future? The quality of the Struts 1.2.6 build has been deemed to be Beta, and will not be upgraded. There are a few outstanding issues in the bug database that need to be addressed before we can roll a 1.2.7 test build. Once that's done, we will decide whether or not that build is of suitable quality for Beta, GA, or neither. -- Martin Cooper > Thanks > Abhishek > > On Sun, 2004-12-12 at 12:32, Martin Cooper wrote: > > > The Struts team is pleased to announce the release of Struts 1.2.6 Beta. > > This release includes minor new functionality, and a number of fixes for > > bugs which were reported against previous versions. > > > > The binary, source and library distributions are available from the Struts > > download page: > > > > http://struts.apache.org/download.cgi > > > > The Release Notes are available on the Struts web site at: > > > > http://struts.apache.org/userGuide/release-notes.html > > > > -- > > Martin Cooper > > > > - > > 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: Taglibs and Tiles Extraction Issues
On Fri, 31 Dec 2004 12:16:10 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 10:03 AM -0800 12/31/04, Martin Cooper wrote: > > > Probably, the same thing should be done for Jakarta Commons. > >There are way too many Commons-This and Commons-That. > >> > > > >Agreed. The Maven elements support this for obtaining the > >dependencies, but I don't know what changes we'd need to make to the > >project.xml files to get the deploy to deal with that. Hopefully > >someone on the Commons list will know. > > I'm not sure if I understand the question. If it's simply "how to > construct project.xml so that a JAR is deployed correctly with maven > jar:deploy", then the answer is also simple. The EL project.xml is > set up correctly: Cool. Thanks, Joe, that was exactly the question. I looked at a few Commons components, and didn't see anything like that specified, so didn't see how this worked. As I've said before, I'm not much of a Maven maven. ;-) -- Martin Cooper > > > ... > struts-el > struts > > > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs and Tiles Extraction Issues
efore bringing out Taglibs. > When we have a set of production subproject releases that all play well > together, we could roll a new distribution. But, we would not have to roll a > new distribution every time a subproject brought out a new release. Only when > the pieces fit together. > If we make it easy enough for people to grab the pieces they need, we might not need the bundle eventually. But people will expect it in the near term, so we should provide it. > The one thing I don't ever want to get into again is another 1.1 death march, > where we are trying to fix several things at once, and have to have > everything perfect before we could release anything. Not releasing is very, > very bad, since most teams can't use what we don't release. Given our limited > resources, and the need to get things "out-there", we have to find a way to > do things hand-over-hand. > Yep. I expect we'll learn how to do that in the process of breaking things up, as we are. In fact, I suspect we'll learn things we never knew about the source code, too. ;-) -- Martin Cooper > -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: Taglibs and Tiles Extraction Issues
On Wed, 29 Dec 2004 07:29:46 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > > On Fri, 24 Dec 2004 14:30:24 -0800, Martin Cooper wrote: > > Struts as a group and Struts subprojects as artifacts within that > > group (using Maven terminology here ;). > > +1 > > The big difference here being that there would only be one top-level Struts > entry in a Maven repository, and the various Struts JARs would be nested > under that. > Yes, that's what we get by using a 'struts' group and then artifacts within it. > Probably, the same thing should be done for Jakarta Commons. There are way > too many Commons-This and Commons-That. > Agreed. The Maven elements support this for obtaining the dependencies, but I don't know what changes we'd need to make to the project.xml files to get the deploy to deal with that. Hopefully someone on the Commons list will know. > > It looks like EL "solved" this by copying the build files. > > Obviously, this is, um, less than optimal, but until the new build > > is ready, perhaps we should do the same thing. On the other hand, I > > don't think we want to put a lot of effort to making this all work > > when the build system is changing (hopefully next week). > > Thanks for all you hard work on this, Martin. Working on build systems drives > me batty :) > > And I do hope you and yours have a happy Hogmanay! Thanks! And a Happy Hogmanay to you too! -- Martin Cooper > -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: Any reason not to delete Jakarta Struts web site?
On Fri, 31 Dec 2004 09:48:21 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 2:14 PM -0800 12/30/04, Martin Cooper wrote: > >Folks, > > > >The old Struts web site within the Jakarta site is still hanging > >around. We've been redirecting from there to our struts.a.o site for > >quite some time now, so I think we should be able to zap the old one. > >Just wanted to ping the list to see if anyone knows of anything we > >need to save from it. If I don't hear anything in a couple of days, > >I'll zap it. > > Hm. I just hit an error when an older Struts config referencing > http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd > encountered your changes. > > Maybe we should restore that. This was an alternate webapp in a > container I restarted which I didn't even touch -- kind of a rude > surprise, but at least it was on a development server. It turned out that there was a problem with the match rule in the .htaccess file. I've fixed that now - or at least I think I have. -- Martin Cooper > Obviously, my Struts config probably has a bad public ID in it, or it > would be finding the DTD in the digester registrations -- but still, > we should put it back, or be prepared for a lot of questions on the > subject. > > Sorry to find this a bit late... > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: Any reason not to delete Jakarta Struts web site?
On Fri, 31 Dec 2004 08:22:54 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > Are you saying, zap the site, but not the redirect, or zap both? I mean zap the content of the Jakarta site, since it can't be reached any more, but leave the redirect (for a while, at least). Actually, it looks like Hen zapped the content already... -- Martin Cooper > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > ----- Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Thursday, December 30, 2004 5:14 PM > Subject: Any reason not to delete Jakarta Struts web site? > > > Folks, > > > > The old Struts web site within the Jakarta site is still hanging > > around. We've been redirecting from there to our struts.a.o site for > > quite some time now, so I think we should be able to zap the old one. > > Just wanted to ping the list to see if anyone knows of anything we > > need to save from it. If I don't hear anything in a couple of days, > > I'll zap it. > > > > -- > > Martin Cooper > > > > - > > 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]
Any reason not to delete Jakarta Struts web site?
Folks, The old Struts web site within the Jakarta site is still hanging around. We've been redirecting from there to our struts.a.o site for quite some time now, so I think we should be able to zap the old one. Just wanted to ping the list to see if anyone knows of anything we need to save from it. If I don't hear anything in a couple of days, I'll zap it. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic workflow engine
On Thu, 30 Dec 2004 10:18:54 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Thu, 30 Dec 2004 12:47:04 -0500, Sean Schofield > <[EMAIL PROTECTED]> wrote: > > I have developed a basic workflow engine that I have found to be > > extremely useful in my current Struts applications. I developed it > > after finding shortcomings in the open source workflow stuff that was > > available at the time. > > > > As you think about workflow, don't forget to keep an eye on a new > Apache Incubator project called Agila, which bills itself as a > "lightweight BPM engine and auxiliary services." There's no code yet, > so it's not possible to tell if it will meet your needs, but worth a > bookmark for future reference: > > http://incubator.apache.org/projects/agila/index.html > > I'm also curious if you looked at Don's continuations support (based > on the same idea in Cocoon) in Struts Flow. > > http://struts.sourceforge.net/struts-flow/index.html Also, if you're using JDK 5, Apache Beehive's Page Flow: http://incubator.apache.org/beehive/pageflow/pageflow_overview.html -- Martin Cooper > > I know Craig mentioned a possible need for workflow stuff for Shale. > > I'm not sure if its along the lines of what he is interested in as I > > have not had the time to delve into Shale yet. > > So far, I'm developing some ideas and design patterns around state > information that is saved longer than a request, but shorter than a > session -- and gracefully managing the associated pages and > corresponding view controllers. It's not quite ready for the rest of > the world to look at yet, but will be soon. > > > > > In a nutshell, it provides a simple and flexible framework for > > implementing workflows. It has states, operations, conditions and > > transitions. It provides a default implementation that writes to a > > database (but that is not required.) > > > > I am currently refactoring it to make it a little easier to be used by > > others (borrowing from some of the structural ideas I've seen used in > > commons-chain). I'd be happy to share it for anyone who might want to > > examine/borrow the code. > > > > Also, I'm interested in possibly taking it open source (perhaps as > > commons-sandbox first.) Let me know if anyone is interested in > > working with me on this. > > I'd be interested in seeing what you've come up with. > > > > > sean > > > > Craig > > - > 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: RoadMap [was Re: ViewUtils ... ]
On Wed, 29 Dec 2004 14:53:52 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I'm somewhat curious when the Struts committers might be willing to > > make a conscious choice for a Struts 2.x architecture. > > > > While I'm personally going to continue to support the 1.3.x changes > > for evolution of existing apps, and use of the Struts-Faces > > integration library with it, I believe that Struts will become > > gradually less relevant for new application development unless it > > adopts JSF strongly; and it would be a shame to have to *compete* with > > Struts instead of *being* Struts. > > > > I guess this would depend on one's view of JSF and where it's headed. > I'm interested in trying to use JSF in the next release of my project > at work, but I have some serious concerns about the current spec > (1.1). > > One concern is with the limitation surrounding dynamic includes. This > is a huge deal for us as we use Tiles all over the place to help with > our layouts. Tiles is great and I'd hate to give it up just so JSF is > happy. I'm not thrilled about the work-around either (using > f:verbatim tags everywhere). > > The other problem I discovered recently is with the "id" attribute > being determined by JSF (in the standard components.) We have tons of > javascipt that use the getElementById() method which won't work > without changes. Again there is a workaround > (http://www.jsftutorials.com/proxyTag.html) but this seems like a lot > of extra code that shouldn't be necessary. > > My understanding is that the first issue may be addressed in the 1.2 > spec (although its still missing from the latest draft.) I didn't see > anything on the second issue but I might have missed it. > > I understand why these two problems are going to be hard to solve . I > want to emphasize that I think JSF looks very promising and I > appreciate all of the hard work that went into it. But I think that > issues like these need to be addressed before programmers like myself > can fully embrace JSF. Maybe these concerns only affect me, but > judging from the postings I have been reading, it seems I am not > alone. No, you're definitely not alone. We also have scads of JavaScript code that uses getElementById(), and I wouldn't _want_ to change it, since that is the right way to grab elements you want to manipulate. (In fact, we just got done fixing some of our code to use this, instead of using the name, so that it works correctly on both IE and Mozilla / Firefox.) > I would agree that Struts without JSF could become less relevant, but > only once JSF becomes widely adopted. Right now I don't know any > developers who are using JSF in their applications. I'm sure there > are some people who are using JSF but I doubt it even approaches the > level of developers using Struts. Of course, the same could be said > about Struts a few years ago. There are certainly developers using JSF. Recently, though, I went looking to see how widely adopted it really is, and my impression was that it's not in nearly as widespread use as I had expected. Of course, I could have been looking in the wrong places, and thus have the wrong impression. > I think a key to Struts rapid acceptance was its rapid evolution. The > open source nature of Struts made it easier for people who had issues > with it, to make improvements. With JSF, all we can do is submit > something to the expert group and sit back and wait. IMO this will > slow the adoption of JSF. I understand why JSF is within the JCP, but > I think this is one of the negative results of that decision. This is an interesting point. The key is that we (Struts) need to take maximum advantage of this, and forge ahead while JSF sits in the JCP. ;-) > I guess this means that IMO, I think Struts 1.3 would be relevant for > quite a while yet. I'd hate to see all of (or the bulk of) the > development effort shift to Struts 2.0 at this point because of what I > foresee as a very slow evolution and adoption of JSF. On the other > hand, I could see why Craig wants to keep pusing with the Shale stuff > because that will take time to develop and evolve itself. I guess I > just see the JSF evolution itself as being the critical part missing > from an all-out effort on Struts 2.0/Shale. I don't think you're going to see everyone abandon 1.x any time soon. Speaking for myself, I recently elected to go with Struts 1.3 for a new project in my day job, after looking at a variety of other options, including JSF. Together with a client side framework, this is working out well for us (even if 1.3 technically doesn't exist yet ;). I'm unlikely to be interested in
Re: Shale for 2.x? (was Re: RoadMap)
On Wed, 29 Dec 2004 12:56:35 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Wed, 29 Dec 2004 14:44:47 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > > > Objectively, I think that Shale would be a better fit for Apache MyFaces. > > If the scope of the MyFaces proposal were expanded to "building a JSF > implementation and value added 'stuff' around it" instead of "building > a JSF implementation, and oh by the way here's some components too", > this might indeed be a possible future. I'm also looking at some > other alternatives if the Struts folks decide not to go this way. > > > Back in the day, it might have been better if we had placed most of our > > taglibs with Jakarta Taglibs, rather than keep them all here. I think this > > is the same sort of thing. > > The problem with this theory relates to a similar issue that would be > raised if Shale were a MyFaces subproject. It's the fact that the > Struts tag libraries have dependencies on the Struts core, which in > some cases (like manufacturing a form bean on demand, doing > transaction tokens, and interacting with validation rules) are fairly > deep. It would not have been particularly useful to create an > arbitrary binding API between the two, just so the tags could > theoretically be used on their own, without Struts. This is all water under the bridge, of course, but the goal wouldn't necessarily have been to make these tags usable without Struts. Rather, they would be located in a (sub)project that cares primarily about tag libraries. There are several taglibs in JT that rely on additional packages to be useful (e.g. BSF, JMS, JNDI, Mailer). The Struts tags would fit fine along with those. On the other hand, I suppose we could still move them over there. The JT lists sometimes get questions on the Struts taglibs already. ;-) -- Martin Cooper > The situation with Shale inside of MyFaces would be muddled by a > potential misunderstanding ... it would be silly to build such a thing > that was dependent on MyFaces internals, when you would really want > such an architecture to work on any JSF implementation (the same way > that Struts works on top of any servlet/JSP container). It would be > tiresome to keep having to deal with an incorrect perception, based on > the fact that it would be a subproject. > > Craig > > - > 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: RoadMap [was Re: ViewUtils ... ][Slightly OT]
On Wed, 29 Dec 2004 13:59:17 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield > <[EMAIL PROTECTED]> wrote: > > [snip] > > Probably a little bit off topic, but I wanted to respond to your > > theory. If your theory is correct, then yes, JSF is a dead-end. I > > don't agree with that theory, but I'm not sure that JSF will be the > > next step either. That will depend on how fast developers evaluate > > and then adopt the technology. And that will depend on how fast JSF > > evolves to address various issues (see an earlier post of mine about > > current JSF limitations.) > > Assuming that JSF and "highly dynamic" apps (i.. where a high degree > of interactivity happens on the client side via DHTML and JavaScript) > are mutually exclusive is too simplistic. The standard components in > 1.0/1.1 don't help you do this sort of thing, but there are already > JSF component libraries available that do. Such libraries use the JSF > components to persist the page author's design decisions (i.e. set the > correct attributes on the correct tags or whatever), rather than do > the actual rendering -- so they still fit nicely into development > tools that know how to manipulate components. Toolkits like FacesClient Components and ADF Faces are a step in the right direction, but they do not address most of the things I mentioned. At least as far as I'm aware, neither can handle drag and drop in the browser, real time updates, or wizard pages in the client. They do handle some of the simple cases for dynamic apps, but they don't tackle the hard problems. When you get to more complex components, and more complex interactions, I don't see how this is going to be handled in a way that makes it make sense to use JSF. (Also, I don't know about ADF Faces, but FacesClient Components appears to commit the cardinal sin of believing it owns the JavaScript global namespace, which is pretty much guaranteed to cause problems when any other JavaScript is used in the app.) -- Martin Cooper > > > > sean > > > > Craig > > > > - > > 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: RoadMap [was Re: ViewUtils ... ][Slightly OT]
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I would classify Gmail as "moderately dynamic", but it's heading in > > the right direction. I'm talking about things like handling wizard > > page changes entirely on the client, up until Apply or OK is clicked; > > drag and drop in the browser; master/detail handling within the > > browser; real-time updates (i.e. not polling). Stuff like that. One of > > the characteristics is minimising, if not eliminating, the number of > > full-page refreshes, which makes page-oriented technologies like JSF a > > whole lot less relevant. > > > > GMail is pretty much a standard web application (even if its a > relatively simple one from an interface standpoint.) Do you really > think these kinds of web applications are likely to be obsolete > anytime soon? No, I don't. People will still develop web apps using today's technology for a long time, but I don't think that's a reason not to innovate and work with newer, more dynamic technologies. > I'd admit it would be nice, but my feeling is that we are going to be > stuck with full page refreshes (or IFrame refreshes) for a long time. > This is the fundamental nature of web pages and the HTTP protocol. > Yes it sucks but I don't see anything on the horizon that is likely to > change this. There is nothing in the nature of HTTP that has anything to do with pages; it's simply a request / response protocol. Using HTTP doesn't tie you to full page refreshes at all, and it's quite feasible to make HTTP requests "behind the scenes", receive back HTML, XML, JavaScript, or whatever, and optionally pre-process it in the browser before updating some part of the page. This is all here today, and I'm using it today, in production. > I've written a lot of cool WebStart applications using JMS on the back > end. They work great but we had the luxury of installing WebStart on > the all of the customer's computers. I think of the browser as a > crappier version of WebStart. Its just a vehicle for running your > application. The key is that its a world-wide standard. Changing > this will take time. If and when this changes, its likely to be > influenced heavily by Microsoft. I wouldn't count on it supporting > Java ;-) The key to highly dynamic apps is JavaScript, not Java. The browser is actually a very powerful beast, it's just that it's a royal pain to tame it. ;-) -- Martin Cooper > Probably a little bit off topic, but I wanted to respond to your > theory. If your theory is correct, then yes, JSF is a dead-end. I > don't agree with that theory, but I'm not sure that JSF will be the > next step either. That will depend on how fast developers evaluate > and then adopt the technology. And that will depend on how fast JSF > evolves to address various issues (see an earlier post of mine about > current JSF limitations.) > > > Martin Cooper > > sean > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
On Wed, 29 Dec 2004 14:36:19 -0600, Michael Rasmussen <[EMAIL PROTECTED]> wrote: > > other page oriented technologies as the past. The future, as I see it, > > is in highly dynamic apps > > What exactly do you mean by "highly dynamic"? Are you referring to > applications like gmail? Do you mean XAML type applications? (God > willing they won't actually be XAML ;-) ) Or are you referring to > something all together different? I would classify Gmail as "moderately dynamic", but it's heading in the right direction. I'm talking about things like handling wizard page changes entirely on the client, up until Apply or OK is clicked; drag and drop in the browser; master/detail handling within the browser; real-time updates (i.e. not polling). Stuff like that. One of the characteristics is minimising, if not eliminating, the number of full-page refreshes, which makes page-oriented technologies like JSF a whole lot less relevant. -- Martin Cooper > Michael > > - > 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: RoadMap [was Re: ViewUtils ... ]
On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Wed, 22 Dec 2004 17:21:46 -0600, Joe Germuska wrote: > > I haven't felt like there's a clear consensus on how to move such a > > thing forward, and I guess I'm still in "ask permission" mode > > instead of "ask forgiveness" mode. I'm not really even sure how > > to move it forward in small measured steps to get people looking at > > something concrete for reactions. > > On the Milestones page [http://struts.apache.org/milestones.html], there are > actually two "API Beans". Once for the server-side and one for the view-side: > > * ActionContext - A Commons Chain Context that implements the Action class > logical API (same signatures). > > * ViewContext - A Commons Chain Context that implements the combined > VelocityStruts logical API (same signatures). > > Perhaps it would help if we could come to a consensus on the Roadmap, or used > the Roadmap to forge a consensus. (I have no illusions about getting this > page right the first time.) > > Does anyone disagree with the Roadmap [http://struts.apache.org/roadmap.html] > or Milestones [http://struts.apache.org/milestones.html] ? > In general, I'm OK with what's listed there. I would point out, though, that we seem to be discussing "Consider a 'smart' action type", listed under 1.5, at the moment, potentially as part of 1.3. (I'm not suggesting that we necessarily defer it, just pointing out the discrepancy.) There are a few points that I don't necessarily agree with, but they're all phrased as "Consider X". I can't argue with considering them, although I might argue against actually doing them. ;-) One particular area on which I am not in sync with some others is the whole JSF thing. I have no problem with Struts providing support for JSF, but I am not in favour of "adopt[ing] JSF strongly", as Craig put it. Craig and I see the future differently. He, I believe, sees JSF as the future (which is not entirely surprising ;), whereas I see JSF and other page oriented technologies as the past. The future, as I see it, is in highly dynamic apps. So what I'd like to see in a Struts 2.0 is strong support for highly dynamic apps.This might include handling requests submitted as XML, support for "serialising" to JavaScript or XML, etc. -- Martin Cooper > Is there anything someone would like put differently? > > -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: Taglibs and Tiles Extraction Issues
On Wed, 29 Dec 2004 09:46:17 -0700, David Geary <[EMAIL PROTECTED]> wrote: > Le Dec 29, 2004, à 5:29 AM, Ted Husted a écrit : > > > On Sun, 26 Dec 2004 14:40:44 -0700, David Geary wrote: > >> I'd like to see an open-source standalone version of Tiles. A > >> toplevel Apache project is one way to do that. > > > > I'd support whatever you wanted to do, David. > > > > If you, or anyone else, wanted to apply for incubation, I'd help in > > anyway I can. > > Thanks for the offer, Ted. If Tiles stays with Apache do we have to go > through incubation? It'd be nice if we could skip incubation, > considering that Tiles has been incubating in Struts for years. 8-) I think that we should be able to avoid incubation. We simply need to show that a community exists around Tiles itself. Once there is activity on the code base, and active discussion of its future on the lists, we should start to invite participants from places outside of Struts, and then at some point create separate mailing lists to support an independent community. (The model I'm thinking of here is Commons HttpClient.) We can also devote a "sub-site" of the main Struts site to Tiles to demonstrate our intent to grow Tiles as an independent entity. Then, when the community thinks it's ready, Tiles could be proposed as an Apache TLP. Much of this is similar to going through incubation, except that I think it will go faster by starting within Struts, because of the large Struts community, and large number of folks within that community that already use Tiles. There are already members of our community here who use Tiles with technologies other than Struts (e.g. Velocity and JSF / MyFaces), so I don't think that will be a stumbling block. -- Martin Cooper > > Or, if someone made a home for Tiles at SourceForge or Tigris or > > Codehaus, that would be great too. > > java.net is also an option. > > > That a community and its codebase lives is more important than where > > it lives. > > Absolutely. > > > david > > > > -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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles and David Geary
It would be great if David came back into the Struts fold to do that, since it's something we'd like to see too. There's no need for a fork. David is listed on the Struts "Who We Are" page as an Emeritus Committer, and can have his privs back just for the asking. http://struts.apache.org/volunteers.html I'd really like to prevent a fork, especially a needless one. -- Martin Cooper On Tue, 28 Dec 2004 21:11:49 -0600, Vic <[EMAIL PROTECTED]> wrote: > David just bloged that he wants to fork tiles to separate Struts > I think Struts deves have been looking for someone to develop Tiles, > like taglibs subproject. > > I suggest that DG be invited as a Struts committer in any case; and that > if he wants to make an idenepndet tiles, he be offer resource to create > a sub project of tiles, that works w/o Struts. > Win/Win. Dev has been looking for somone to do tiles. > > Since Struts is a top level project it can do this. > .V > -- > RiA-SoA w/JDNC <http://www.SandraSF.com> forums > - help develop a community > My blog <http://www.sandrasf.com/adminBlog> > > - > 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: Porting changes to the 1.2.x branch
Cool! Thanks, Hal. That was almost too easy. ;-) -- Martin Cooper On Tue, 28 Dec 2004 19:08:23 -0500, Deadman, Hal <[EMAIL PROTECTED]> wrote: > You could do this, without the --dry-run option and with the appropriate > committer urls. > > svn checkout > http://svn.apache.org/repos/asf/struts/el/branches/STRUTS_1_2_BRANCH/ > struts-el > > cd struts-el > > svn merge -r106044:123473 --dry-run > http://svn.apache.org/repos/asf/struts/el/trunk > > svn diff > > svn commit > > > > -Original Message- > > From: Deadman, Hal [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 28, 2004 6:49 PM > > To: Struts Developers List > > Subject: RE: Porting changes to the 1.2.x branch > > > > Would you use svn merge on the directories you changed? > > > > http://copenhagen.pm.org/presentations/subversion/subversion.htm > > See slide "Tags and branches" > > > > or > > http://deadbeast.net/~branden/svn_pres/merging_and_resolving.html > > > > or > > http://svnbook.red-bean.com/en/1.0/re16.html > > > > > > > -Original Message- > > > From: Don Brown [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, December 28, 2004 6:34 PM > > > To: Struts Developers List > > > Subject: Re: Porting changes to the 1.2.x branch > > > > > > Martin Cooper wrote: > > > > I just made a giant commit to the EL taglibs to bring them into > > > > alignment with the non-EL tags. Now these changes need to be > ported > > to > > > > the 1.2.x branch, since the omission of these changes was, in > part, > > the > > > > reason for classifying 1.2.6 as Beta rather than GA, and we'll > want > > to > > > > get to another GA release on that branch at some point, probably > > sooner > > > > rather than later. > > > > > > > > So now that we're in SVN-land, what is the simplest way of taking > > the > > > > changes in one commit and applying them to another branch? > > > > > > Dunno, perhaps you could get a diff between the two versions then > > apply > > > the patch to the other branch. > > > > > > Don > > > > > > > > > > > -- > > > > Martin Cooper > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r123585 - in struts/el/branches/STRUTS_1_2_BRANCH: doc/userGuide src/exercise-taglib/org/apache/struts/webapp/exercise src/share/org/apache/strutsel/taglib/html
Sync up the 1.2.x branch. Again, the commit message was too large, so this is just the file list. -- Martin Cooper -- Forwarded message -- Date: 29 Dec 2004 00:43:35 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: svn commit: r123585 - in struts/el/branches/STRUTS_1_2_BRANCH: doc/userGuide src/exercise-taglib/org/apache/struts/webapp/exercise src/share/org/apache/strutsel/taglib/html Author: martinc Date: Tue Dec 28 16:43:33 2004 New Revision: 123585 URL: http://svn.apache.org/viewcvs?view=rev&rev=123585 Log: Port the sync-up to the 1.2.x branch: Sync up the EL tags with their non-EL counterparts. This adds the 'bundle' attribute to many tags, and also the 'error*' attributes, and 'header', 'footer', 'prefix' and 'suffix' for the Errors tag. Fixes Bugzilla #32490. Modified: struts/el/branches/STRUTS_1_2_BRANCH/doc/userGuide/struts-html-el.xml struts/el/branches/STRUTS_1_2_BRANCH/src/exercise-taglib/org/apache/struts/webapp/exercise/HtmlSettersAction.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELButtonTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELButtonTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELCancelTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELCancelTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELCheckboxTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELCheckboxTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELErrorsTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELErrorsTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELFileTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELFileTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELFrameTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELFrameTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELHiddenTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELHiddenTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELLinkTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELLinkTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELMultiboxTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELMultiboxTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELPasswordTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELPasswordTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELRadioTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELRadioTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELResetTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELResetTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELSelectTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELSelectTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELSubmitTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELSubmitTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELTextTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELTextTagBeanInfo.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELTextareaTag.java struts/el/branches/STRUTS_1_2_BRANCH/src/share/org/apache/strutsel/taglib/html/ELTextareaTagBeanInfo.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain commit (Re: svn commit: r122947 -)
On Tue, 21 Dec 2004 11:46:31 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 7:34 AM + 12/21/04, [EMAIL PROTECTED] wrote: > > * removed unnecessary struts-chain sandbox project > > Should we be concerned about keeping this available for people using > chain in a pre Struts 1.3 environment? I suppose most people who are > using it now are going to be able to migrate to a newer Struts, but > the thought crossed my mind... This isn't a problem, since Don's removal only removed it from 'trunk'. It's still available in the 1.2.x branch, and so will still be part of 1.2.7, etc. -- Martin Cooper > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: Any comment on the SessionUtils ting I submitted?
On Tue, 28 Dec 2004 12:01:50 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > You know, I hesitate to say this because I'm not sure (a) I didn't miss > something and it already exists and (b) that it's a good idea in the > first place, but... > > Dumping all request/session parameters/attributes seems like something > that might make a good switch built-in to Struts... Maybe at the request > processor level or in the Action class itself... You know, a simple > boolean, false by default, that dumps everything when set to true. That > opens up questions of where to dump it to and how though, but a simple > stdout dump (as my code does) might be sufficient since this would > almost certainly just be for debugging purposes (although I actually use > this function in production myself). > > What do you think? I'd be more than happy to give up my code (not that > everyone on this list couldn't write it in 30 seconds flat, but hey, > I'll save ya the 30 seconds!) Again, this isn't something tied to Struts in any way. It's also something that comes with Tomcat already, in the form of a filter (RequestDumperFilter). -- Martin Cooper > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Frank W. Zammetti wrote: > > Hey, good deal, glad it helped someone! > > > > I wasn't aware of that book either... Must go order it! > > > > On a related note... I have a bunch of debug-type functions like you it > > sounds like... One of them, which I'd bet you have already, is just > > dumping all request/session parameters and attributes. I usually call > > this at the start of each Action. This comes is handy quite a bit. > > > > - > 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: Any comment on the SessionUtils ting I submitted?
On Thu, 23 Dec 2004 08:56:20 -0800 (PST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Just checking... I know it's the holidays and all, but it's been a couple of > days and no one posted any comment (unless I missed it). > This isn't something that I've had a need for myself. It also looks like a pretty expensive operation. However, I can see that some people might need it once in a while. Since it's not dependent on Struts, though, and would work in any servlet environment, it might be a better fit in Jakarta Commons, perhaps in the 'servlet' component in the Sandbox, alongside the RequestUtils class that's there now. -- Martin Cooper > - > 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]
Porting changes to the 1.2.x branch
I just made a giant commit to the EL taglibs to bring them into alignment with the non-EL tags. Now these changes need to be ported to the 1.2.x branch, since the omission of these changes was, in part, the reason for classifying 1.2.6 as Beta rather than GA, and we'll want to get to another GA release on that branch at some point, probably sooner rather than later. So now that we're in SVN-land, what is the simplest way of taking the changes in one commit and applying them to another branch? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r123473 - in struts/el/trunk: doc/userGuide src/share/org/apache/strutsel/taglib/html
The original commit message was rejected for being too large. Here's the first part. I forgot to mention in the message that this also includes the additional attributes for the 'errors' tag. -- Martin Cooper -- Forwarded message -- Date: 28 Dec 2004 05:32:42 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: svn commit: r123473 - in struts/el/trunk: doc/userGuide src/share/org/apache/strutsel/taglib/html Author: martinc Date: Mon Dec 27 21:32:40 2004 New Revision: 123473 URL: http://svn.apache.org/viewcvs?view=rev&rev=123473 Log: Sync up the EL tags with their non-EL counterparts. This adds the 'bundle' attribute to many tags, and also the 'error*' attributes. Fixes Bugzilla #32490. Modified: struts/el/trunk/doc/userGuide/struts-html-el.xml struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELButtonTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELButtonTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELCancelTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELCancelTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELCheckboxTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELCheckboxTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELErrorsTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELErrorsTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELFileTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELFileTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELFrameTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELFrameTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELHiddenTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELHiddenTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELLinkTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELLinkTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELMultiboxTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELMultiboxTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELPasswordTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELPasswordTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELRadioTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELRadioTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELResetTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELResetTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELSelectTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELSelectTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELSubmitTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELSubmitTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELTextTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELTextTagBeanInfo.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELTextareaTag.java struts/el/trunk/src/share/org/apache/strutsel/taglib/html/ELTextareaTagBeanInfo.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where should the build system live?
On Sat, 25 Dec 2004 00:42:13 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Martin Cooper wrote: > > The new build system will consist of a few shared build files, and a > > per-subproject build.xml file. This leads to the obvious question of > > where the shared build files should live. There are basically two > > options, as I see it: > > > > 1) In a 'build' subproject. This is the cleaner option, and the one I > > prefer. It does mean that an additional subproject has be to checked > > out, but that would be true for all but one subproject in any case, > > and an independent 'build' subproject is pretty much guaranteed to be > > a lot smaller than any other subproject. > > > > 2) In 'core'. The only advantage I see to putting the build system in > > 'core' is that a single checkout would be enough to build 'core' > > itself. However, to build any other subproject, 'core' would need to > > be checked out as well. The main disadvantage I see to this option is > > that if another subproject comes along that we need to build before > > 'core', it would be icky to have that subproject depend on 'core' when > > 'core' depends on it. (This might sound like an unlikely scenario, but > > I actually believe that's exactly what would happen if we bring > > StrutsTestCase into the fold, since we'd need to build that before > > 'core' could be built and tested.) > > Hmm..this raises an interesting issue. When you mention build > dependencies, do you really mean build one project then another in the > same process, or just that one project would depend on a jar from > another? Originally, I had been thinking of just the latter. However, James Mitchell's message requesting that we call him crazy ;-) got me thinking about the possibility of handling the former as well. We at least need some scheme for avoiding the need to build everything independently, as James's message demonstrates. -- Martin Cooper > In the case of StrutsTestCase, 1) I don't like Core being > dependent on a subproject, so perhaps another neutral mock library > should be used, and 2) even if the Core build depended on > StrutsTestCase, it would be the latter and use a jar. > > As for the build organization, I lean towards 1, but I don't really feel > strongly one way or another. > > Don > > > > > So what do people think? My preference, as I said, is (1). > > > > -- > > Martin Cooper > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs and Tiles Extraction Issues
Don, I just realised that there's another, rather large, issue that you'll come across, if you haven't already. All of the examples use the taglibs. That means we'll need to pull the examples out of core at the same time, probably into an 'examples' subproject. I ran into this while working on the build, since I was looking at the overall structure of what we have. There's a lot of inconsistency, and I'd like to clean that up. But I'm going to put the new build on hold for a bit, until we get the major restructuring out of the way. That means that I'll have some cycles this coming week, which I was going to spend on the build. So if you'd like some help with the restructuring you're working on, let me know. -- Martin Cooper On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I've made further progress in extracting tiles and taglibs, and have run > into several issues I'd like to get some feedback on. > > 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has > a link to taglib's TagUtils.getScope(). I could copy this method over > (it is a whole 5 lines), but this raises a larger question of subproject > dependencies and distribution. Will each subproject have its own > ibiblio entries? Ted suggested, and I agree, that subprojects will be > bundled with Struts releases ala Linux distributions, but how do we > communicate intra-subproject dependencies? > > 2. Mock objects. Currently, Struts contains mocks for the servlet, but > these classes would be useful for subprojects as well. I suggest we > adopt StrutsTestCase, or another test package, as a subproject or dependency > > 3. Cactus. I admit, I never got this working, and now with taglibs and > tiles unit tests requiring Cactus, I'm not sure how to migrate that > build process over, especially as we await the Ant reorganization Martin > is working on. I'm leaning to committing all my changes once I got all > the code compiling and let someone more knowledgable setup cactus for > these two subprojects. > > Thanks for the help, > > Don > > - > 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]
Where should the build system live?
The new build system will consist of a few shared build files, and a per-subproject build.xml file. This leads to the obvious question of where the shared build files should live. There are basically two options, as I see it: 1) In a 'build' subproject. This is the cleaner option, and the one I prefer. It does mean that an additional subproject has be to checked out, but that would be true for all but one subproject in any case, and an independent 'build' subproject is pretty much guaranteed to be a lot smaller than any other subproject. 2) In 'core'. The only advantage I see to putting the build system in 'core' is that a single checkout would be enough to build 'core' itself. However, to build any other subproject, 'core' would need to be checked out as well. The main disadvantage I see to this option is that if another subproject comes along that we need to build before 'core', it would be icky to have that subproject depend on 'core' when 'core' depends on it. (This might sound like an unlikely scenario, but I actually believe that's exactly what would happen if we bring StrutsTestCase into the fold, since we'd need to build that before 'core' could be built and tested.) So what do people think? My preference, as I said, is (1). -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs and Tiles Extraction Issues
On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I've made further progress in extracting tiles and taglibs, and have run > into several issues I'd like to get some feedback on. > > 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has > a link to taglib's TagUtils.getScope(). I could copy this method over > (it is a whole 5 lines), but this raises a larger question of subproject > dependencies and distribution. Will each subproject have its own > ibiblio entries? Ted suggested, and I agree, that subprojects will be > bundled with Struts releases ala Linux distributions, but how do we > communicate intra-subproject dependencies? The method is short, but it relies on a map that is set up in a static initialiser... If we want to make Tiles usable in the absence of Struts, as some people do, I think we'd have to clone the code within Tiles. With respect to ibiblio, I think it would make sense to consider Struts as a group and Struts subprojects as artifacts within that group (using Maven terminology here ;). I think you're asking about inter-subproject dependencies, right? This is one of the pieces of the build system I haven't yet found a solution for that I'm happy with. But I'm not sure if you're asking about that, or about communicating the information to users. > 2. Mock objects. Currently, Struts contains mocks for the servlet, but > these classes would be useful for subprojects as well. I suggest we > adopt StrutsTestCase, or another test package, as a subproject or dependency I still haven't taken the time to look at StrutsTestCase. If we used that for our own testing, I assume, from what you say, that we could then ditch the mock objects we have today? (What does StrutsTestCase use for its own unit tests?) > 3. Cactus. I admit, I never got this working, and now with taglibs and > tiles unit tests requiring Cactus, I'm not sure how to migrate that > build process over, especially as we await the Ant reorganization Martin > is working on. I'm leaning to committing all my changes once I got all > the code compiling and let someone more knowledgable setup cactus for > these two subprojects. It looks like EL "solved" this by copying the build files. Obviously, this is, um, less than optimal, but until the new build is ready, perhaps we should do the same thing. On the other hand, I don't think we want to put a lot of effort to making this all work when the build system is changing (hopefully next week). -- Martin Cooper > Thanks for the help, > > Don > > - > 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: download link broken or something
On Fri, 24 Dec 2004 09:47:04 -0600, Vic <[EMAIL PROTECTED]> wrote: > from main menu in struts clicking download binaries give a cgi error. Fixed. I've also changed the privs on the cgi script to try to prevent this from happening again. -- Martin Cooper > Is there another link for "1.3" nigly builds? > .V > -- > RiA-SoA w/JDNC <http://www.SandraSF.com> forums > - help develop a coomunity > My blog <http://www.sandrasf.com/adminBlog> > > - > 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: ViewUtils and UtilityFactory (was Extracting taglibs)
On Thu, 23 Dec 2004 10:58:16 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Thu, 23 Dec 2004 10:54:31 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > What does "Commons FileUpload being Filter-ized" mean? > > Martin has talked (on the Commons dev list) about his plans to upgrade > Commons FileUpload to use a Servlet Filter, and the request wrapper > features of Servlet 2.3, in the next version. This will enable much > cleaner integration of file upload processing with existing web > application architectures, because (for many use cases) the fact that > ths request is in mutipart/form-data can be made totally transparent > to the rest of the architecture. Yah. Much of this is done and sitting on my disk. I got busy with my day job and other things, but I'm hoping to get this finished up next week, since my company is shut down over the holidays. I'm also adding an XML config capability, to make it easier to configure the filter (but also usable outside the filter). Portlet support is already done and checked in. -- Martin Cooper > > > > Jack > > > > Craig > > - > 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: Extracting taglibs
On Tue, 21 Dec 2004 21:06:19 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > > I agree as well. This lets us follow a consistent approach to > > subprojects, where they may (and probably should) link to Struts core, > > but Struts core should not depend on them. > > I hope this can actually be accomplished ... but I recall playing > around with this particular separation when we had our testbed > Subversion installation, and the interdependencies were much more > invasive than I would have originally expected ... to the point that I > deferred actually finishing this particular separation (since I was > mostly focused on whether SVN made sense). This actually sounds like a good reason to go this route and ensure that the core has no dependencies on Tiles. If it isn't possible to extract all of the Tiles pieces into a separate subproject, then we have the wrong abstraction, and other people would not be able to build extensions like Tiles without help in the form of changes to the core. -- Martin Cooper > Craig > > - > 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: Extracting taglibs
On Tue, 21 Dec 2004 20:25:55 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I think a separate subproject for Tiles (including the code and the > tags) probably makes the most sense. +1 > If we don't mind the dependency > back onto Struts, then this could also include the Struts PlugIn that > is currently used to configure it -- although it would probably be > better that this class stay part of Struts so that the Tiles library > could be used stand alone. I'd prefer to see it the first way - Tiles has a (compile-time) dependency on Struts, and includes the plugin to be able to work with Struts. This is analogous to the way Commons Chain has compile-time dependencies on Servlets, Portlets and JSF, enabling it to work in those environments if desired. A Velocity adapter could then also live within Tiles, along with any others that people want to develop. Having the Struts adapter be a part of Tiles doesn't prevent the Tiles library from being used standalone any more than the Servlets, Portlets and JSF adapters for Chain prevent its use outside all of those environments. > In addition, there should be mechanisms to configure the Tiles > definitions even if Struts is not present, via TilesServlet (which I > believe already exists?) and/or a new ServletContextListener > implementation since we're willing to use Servlet 2.3. +1 -- Martin Cooper > Craig > > On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > It has been discussed, I believe, to separate Tiles from Struts, but no > > one seemed to know where it would go. jakarta-commons doesn't want > > taglibs, and for some reason I don't remember, the taglibs project > > wasn't accepted. It would be kinda funny, though, since Tiles used to > > be its own project that was assimilated into Struts when Struts was > > trying to divest iteself of code into commons. > > > > I mentioned the separation of Tiles from their taglibs as I thought I > > heard somewhere of Velocity being able to use Tiles. I could be wrong > > though. > > > > Don > > > > Eddie Bush wrote: > > > Actually, I'd tend to agree with that. It makes more sense than > > > separating Tiles and the Tiles taglibs - don't think you'd use the > > > former without the latter. Maybe ... but I don't. > > > > > > > > > On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal <[EMAIL PROTECTED]> > > > wrote: > > > > > >>Haven't look into this much but it would seem better to have a > > >>completely separate tiles sub-project that struts core would use. Don't > > >>JSF and Spring currently use tiles and have to include struts.jar when > > >>all they really want is tiles? > > >> > > >> > > >>>-Original Message- > > >>>From: Don Brown [mailto:[EMAIL PROTECTED] > > >>>Sent: Tuesday, December 21, 2004 7:51 PM > > >>>To: Struts Developers List > > >>>Subject: Extracting taglibs > > >>> > > >>>My basic assumption in approaching taglibs extraction into its own > > >>>subproject is it can reference Struts classes, but Struts classes > > >>>shouldn't reference it. > > >>> > > >>>If that is correct, here are the changes I see happening to extract > > >>>taglibs: > > >>> > > >>>1. Move o.a.s.taglib out into its own subproject src tree > > >>>2. Remove methods in RequestUtils that delegate to TagUtils. They are > > >>>marked as deprecated anyways and explicitly say they will be removed > > >>>after 1.2. > > >>>3. Move properties in o.a.s.taglib.html.Constants that are referred to > > >>>in Struts core code into o.a.s.Globals. (cancel and token keys) > > >>>4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not > > >> > > >>sure > > >> > > >>>about. Should/can tiles be used w/o its jsp taglibs? If not, then it > > >>>should stay in core w/ tiles. Otherwise, it could be moved out too. > > >>> > > >>>That should be it, as far as I can tell. taglibs are already pretty > > >>>well isolated from the rest of Struts which will make the extraction > > >>>pretty straightforward. > > >>> > > >>>I'd like to get this done before Christmas (25th) if there are no > > >>>objections. > > >>> > > >>>Don > > >&g
Re: Request Bugzilla components
On Tue, 21 Dec 2004 19:25:09 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I'd like to request the following Bugzilla components be added: > - bsf > - sandbox Done. -- Martin Cooper > If I do this myself, please point me in the right direction. Thanks. > > Don > > - > 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: Chain Integration Complete
On Mon, 20 Dec 2004 23:30:31 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > As you may have noticed, I've completed the merge of struts-chain with > Struts core (see the commit message for details). I would like to add > this is meant as a step forward, not as my ultimate vision for how > things should be, meaning if someone doesn't like a configuration > property name or process, please feel free to discuss/change it. Awesome, Don! Thanks for a great Christmas present! :-) I'm using 1.2.6 + Chain in my day job right now, so I'll be switching over to this as soon as makes sense for us. That will get me beating on this in short order, so that we can refine the way it works and iron out any issues. > Next up: extracting the taglibs :) You're a glutton for punishment, lad. ;-) -- Martin Cooper > Don > > - > 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: Any objections to adding Ant get's to build.xml?
On Sun, 19 Dec 2004 19:06:56 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Intermixed. > > On Sun, 19 Dec 2004 18:36:41 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On Sun, 19 Dec 2004 13:13:03 -0800, Craig McClanahan <[EMAIL PROTECTED]> > > wrote: > > > On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <[EMAIL PROTECTED]> > > > wrote: > > > > On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <[EMAIL > > > > PROTECTED]> wrote: > > > > > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > At worst case, it seems we could add a task to do the downloads of > > > > > > those binaries that are redistrutable. I think most folks would > > > > > > rather invoke an Ant task than have to chase down dependencies. It > > > > > > wouldn't even have to be tied to a compile. > > > > > > > > > > > > > > > > Absolutely agree that there needs to be a way to point at local copies > > > > > instead. The challenge for Mavenized projects that want to also be > > > > > Ant-friendly is the way that the Ant plugin generates its build.xml > > > > > files -- it does generate "get" tasks for pulling the dependencies, > > > > > but uses hard coded paths from the project.xml file. It would be much > > > > > better if the generated tasks used an Ant property for the "src" > > > > > attribute, so that one could override and point at your local copy. I > > > > > would like to see us do that in our Struts build.xml files (that are > > > > > manually maintained) if we start using get tasks ourselves. > > > > > > > > Perhaps I'm misunderstanding what you're saying, but the > > > > Maven-generated Ant build files work just fine if you're disconnected, > > > > as long as you have previously downloaded the dependencies. All you > > > > have to do is set the 'noget' property, and the attempts to the > > > > files will be skipped. The dependencies will then be picked up from > > > > your local repo. > > > > > > The standard Maven generated build.xml for Commons Email, for example, > > > creates hard coded get URLs for the JavaMail and JAF jars, based on > > > the values in project.xml (which in turn point at the Sun web page > > > where you have to click through the license to perform the downoads). > > > It would not do any good to change where these URLs point to some > > > "local" repository, because there is no canonical URL that would work > > > for all users. > > > > OK, I see what you mean. My way around this is to not attempt to get > > anything that isn't gettable automatically. ;-) The only thing I've > > hit so far is the JDBC 2.0 Ext jar, which, IIUC, is only required when > > building with JDK 1.3. > > I thought Commons Chain used to have some other dependencies; I'm sure > Commons Resources does. Chain no longer depends on anything that isn't available from ibiblio, now that it's building against the MyFaces version of the JSF API. Resources does depend on Hibernate, as well as some other things I've never heard of. I'm not sure that any of those things need to be available for building Struts or running the tests, but I could easily be wrong on that. I guess we'll see when we switch over to using Resources in Struts. > > BTW, I haven't decided whether or not to try to download a Cactus > > distro as part of this, or whether to assume that the user has one > > somewhere. I am assuming that Tomcat would already be installed prior > > to running Cactus tests. Comments? > > If we're going to be complete, we might as well be complete ... the > only thing we should really assume the user has is a JDK. That would > really mean downloading Tomcat as well. But isn't that the whole > point, that running "ant download" or whatever will get *everything* > you need? I suppose. The question I was asking myself was "download everything for what?". That is, downloading everything to just build, or downloading everything to build and test. The latter would imply downloading multiple versions of Tomcat, since we currently support 3 different versions (although the 5.5 tests don't pass yet). If we want to be able to download everything, then we might want to have 2 separate tasks - one to download everything to build, and one to downl
Re: Any objections to adding Ant get's to build.xml?
On Sun, 19 Dec 2004 13:13:03 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <[EMAIL PROTECTED]>
> > wrote:
> > > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote:
> > > > At worst case, it seems we could add a task to do the downloads of
> > > > those binaries that are redistrutable. I think most folks would
> > > > rather invoke an Ant task than have to chase down dependencies. It
> > > > wouldn't even have to be tied to a compile.
> > > >
> > >
> > > Absolutely agree that there needs to be a way to point at local copies
> > > instead. The challenge for Mavenized projects that want to also be
> > > Ant-friendly is the way that the Ant plugin generates its build.xml
> > > files -- it does generate "get" tasks for pulling the dependencies,
> > > but uses hard coded paths from the project.xml file. It would be much
> > > better if the generated tasks used an Ant property for the "src"
> > > attribute, so that one could override and point at your local copy. I
> > > would like to see us do that in our Struts build.xml files (that are
> > > manually maintained) if we start using get tasks ourselves.
> >
> > Perhaps I'm misunderstanding what you're saying, but the
> > Maven-generated Ant build files work just fine if you're disconnected,
> > as long as you have previously downloaded the dependencies. All you
> > have to do is set the 'noget' property, and the attempts to the
> > files will be skipped. The dependencies will then be picked up from
> > your local repo.
>
> The standard Maven generated build.xml for Commons Email, for example,
> creates hard coded get URLs for the JavaMail and JAF jars, based on
> the values in project.xml (which in turn point at the Sun web page
> where you have to click through the license to perform the downoads).
> It would not do any good to change where these URLs point to some
> "local" repository, because there is no canonical URL that would work
> for all users.
OK, I see what you mean. My way around this is to not attempt to get
anything that isn't gettable automatically. ;-) The only thing I've
hit so far is the JDBC 2.0 Ext jar, which, IIUC, is only required when
building with JDK 1.3.
BTW, I haven't decided whether or not to try to download a Cactus
distro as part of this, or whether to assume that the user has one
somewhere. I am assuming that Tomcat would already be installed prior
to running Cactus tests. Comments?
> > The scheme I'm working on still defines all of the 'foo.jar'
> > properties we use today, but internally to the build. It uses a very
> > similar scheme to Maven to go get the dependencies and put them in
> > 'local.repo.dir' unless the 'noget' property is set, and then builds
> > against what is in that directory. If someone really wants to put the
> > dependencies elsewhere, they can still define 'foo.jar' to do that.
> > The versions of each dependency can also be overridden if necessary.
> >
> > Will that work for you?
>
> That sounds like it would work for me
Great!
> ... it would also fix another
> annoying quirk with the way that Maven-generated build.xml files work
> now. The get tasks all copy JARs into a directory that is blown away
> by the "clean" target, so running "ant clean dist" (which the nightly
> build does for each package) redownloads all the dependencies every
> time.
That's the default behaviour, yes. However, if you define 'libdir' in
your ${user.home}/build.properties file, it will download to there and
not blow that away as part of 'clean'.
I actually have pretty much the same setup in what I'm doing for
Struts, where the default value of 'local.repo.dir' is
'target/repository'. This is for the simple reason that the default
needs to be on a path that the build system knows exists (or can
exist). However, it just occurred to me that I could make the default
value be '${user.home}/struts-repository' (or something along those
lines) instead. Comments on this?
--
Martin Cooper
> >
> > --
> > Martin Cooper
> >
>
> Craig
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any objections to adding Ant get's to build.xml?
On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote: > > At worst case, it seems we could add a task to do the downloads of > > those binaries that are redistrutable. I think most folks would > > rather invoke an Ant task than have to chase down dependencies. It > > wouldn't even have to be tied to a compile. > > > > Absolutely agree that there needs to be a way to point at local copies > instead. The challenge for Mavenized projects that want to also be > Ant-friendly is the way that the Ant plugin generates its build.xml > files -- it does generate "get" tasks for pulling the dependencies, > but uses hard coded paths from the project.xml file. It would be much > better if the generated tasks used an Ant property for the "src" > attribute, so that one could override and point at your local copy. I > would like to see us do that in our Struts build.xml files (that are > manually maintained) if we start using get tasks ourselves. Perhaps I'm misunderstanding what you're saying, but the Maven-generated Ant build files work just fine if you're disconnected, as long as you have previously downloaded the dependencies. All you have to do is set the 'noget' property, and the attempts to the files will be skipped. The dependencies will then be picked up from your local repo. The scheme I'm working on still defines all of the 'foo.jar' properties we use today, but internally to the build. It uses a very similar scheme to Maven to go get the dependencies and put them in 'local.repo.dir' unless the 'noget' property is set, and then builds against what is in that directory. If someone really wants to put the dependencies elsewhere, they can still define 'foo.jar' to do that. The versions of each dependency can also be overridden if necessary. Will that work for you? -- Martin Cooper > Craig > > - > 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: "extends" (was Struts chain integration)
On Fri, 17 Dec 2004 12:13:21 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Personally, I favor the approach Cocoon takes to "modules". Cocoon is > configured to use one sitemap (config file), but that sitemap can mount > or include other sitemaps through the "mount" element. See > http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Mounting+sitemaps > > Using wildcards, we could support a element which would > basically mount a module config. could also be used as an > include to include another struts config file full of definitions for > the current module. Therefore, a module mount in Struts would look like > this: > > > > > > This simplifies the config and, IMO, makes the module design much more > readable and straight-forward. Interesting idea. I *really* need to find some time to read up on Cocoon! ;-) (Are there good books to read, or is the web site best?) The only thing that I'm not so keen on here is that the main site map needs to be modified to add or remove a "module". (Of course, the way modules are in Struts today requires the modification of web.xml, which is essentially equivalent.) In one of the larger apps I've done, I needed to be able to add and remove modules as product components were installed and removed. Since I don't trust installers much, I didn't want them to have to modify any files. So I adopted an approach whereby I had each module live under WEB-INF/modules/foo, and I customised the Struts initialisation code to read all the module configs from there. Installing a module, then, meant dropping in a new subdirectory, and uninstalling it meant simply blowing that directory away. > Getting back to the "extends" idea, if we adopted an approach like > described above, the main config file could have configuration elements > that would automatically be inherited by modules, unless overridden. > This would also let us break up config files for single modules, and > even enable module hierarchies. Course the devil is in the > implementation details :) This is effectively the inverse of "extends", right? It's push rather than pull, in that the master pushes config down into the subs, rather than the subs pulling config from the master. I need to think a bit about the pros and cons of each of these... -- Martin Cooper > Don > > Martin Cooper wrote: > > > >I'm not keen on adding init params in general, and even less keen on > >adding such params that take lists of files. > > > >I do think we need to have a mechanism for specifying global stuff, > >but I think we can come up with a better way. For example, I don't > >like that I have to replicate the config in each module's > >struts-config.xml in a multi-module app. That's error prone. > > > >We've talked about allowing for for things like form bean > >definitions. What about having this concept right at the top of the > >config scheme? So I could define a global struts-config.xml file > >(which wouldn't be used directly by any module), and then > >that file to provide module-specific config files. > > > >If we added an optional section to struts-config, we could then > >specify a list of Chain config files in there. > > > > > > > >>I would suggest skipping the chainConfig and chainCommand parameters > >>in the web.xml in favor of explicitly setting them in each > >>controller. Too many config options can be more trouble than they > >>are worth. > >> > >> > > > >+1 > > > > > > > >>The discussion of how to configure the Controller or the > >>RequestProcessor touched off a lot of talk earlier on struts-dev, but > >>I'd be happy to settle for two properties on ControllerConfig just to > >>move forward. > >> > >> > >> > >>>>>struts-config.xml > >>>>>- The default request processor class would now be > >>>>>ComposableRequestProcessor, but the legacy ones would still be available > >>>>>(deprecated) > >>>>> > >>>>> > >>>>+1. One thing that I'm a little confused about, though, is that the > >>>>new request processor is (currently) in a package that includes > >>>>'legacy'. Anyone know why that is? > >>>> > >>>> > >>I don't know, but I think we should move it out to > >>o.a.s.chain.ComposableRequestProcessor. > >> > >> > > > >Fine with me. > > > > > > > >>>>>- The cont
Re: Struts chain integration
hort-sighted, or plain thick?) Yes, it would be nice to understand the rationale for the way things are now. ;-) I think, though, that it's going to be easier to get to where we want to be if we don't have to mess around with two separate subprojects. With moving and deleting things in SVN being as easy as it is, I think it would be fine to bring in what's there now. If we do think many of those will go away, then perhaps they should live in a 'legacy' package until we know what we really want. Then again, if Don is going to do the work of bringing struts-chain into the mainstream, perhaps we should let him make the call. ;-) > Also, if the default chain-config is (or may be) read from the > classpath, then having that in the core struts requires you to > override it. Including it instead in a separate JAR means you could > remove one and add in another and still get the auto-config feature. > Does it help to compare it to taglibs, which we are also talking > about removing from the core and including as a separate JAR? You > could even draw an analogy between the chain-config.xml and a TLD > file. I would expect that the most common reason for overriding the default chain config would be adding some extra commands into the chain, in which case you'd want all of the original struts-chain except for the chain config file (or at least you'd want a way to override the default). So I'm not sure this is a reason to keep them separate. How the default chain is overridden is a good question, though. If we set things up so that the default is loaded automagically, then overriding it would have to be done with explicit config somewhere - plugin or web.xml. But I'm not sure what happens when two config files with the same catalog name are loaded. Would a second "struts" catalog overwrite the first, or augment it? -- Martin Cooper > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts chain integration
On Fri, 17 Dec 2004 09:09:16 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 10:29 PM -0800 12/16/04, Don Brown wrote: > >Martin Cooper wrote: > >>On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > >> > >>>Who is working on bringing Struts chain into Struts core? If no one, I > >>>wouldn't mind doing the integration. > > I haven't made the time to do anything. I was hoping to have some > this weekend, but if you're ready to plunge ahead, I don't want to > hold things up. If you think there's a good way to split tasks up, > let me know. Below I've interspersed what I was thinking about doing. > > >>>I'm thinking about using the ComposableRequestProcessor to keep as much > >>>backwards compatibility as possible. The changes I'm proposing by layer: > >>> > >>>web.xml > >>>- A "chainConfig" parameter to override default catalog. If none > >>>specified, a default chain config will be loaded from the Struts jar. > >>>- A "chainCommand" parameter to specify the command to execute if none > >>>specified in modules (optional) > >> > >> > >>I'm probably misunderstanding something, but > >>ComposableRequestProcessor uses two context initialisation params for > >>these already. Those names and default values seem fine to me. > > > >The idea of these in web.xml is the ability to specify a custom > >chainConfig that would be used as the default for all modules; same > >with the command name. My goal would be to make it possible to use > >an existing Struts 1.1/1.2 app without any changes. To meet this > >goal, all these configuration options are optional and defaults will > >be used if necessary. > > Earlier, we had discussed using one init parameter in web.xml as a > list of chain-config files, each of which would be sought first in > the servlet context and then on the classpath, each of which would be > processed using the default chain digester that adds catalogs to the > pool. I'm not keen on adding init params in general, and even less keen on adding such params that take lists of files. I do think we need to have a mechanism for specifying global stuff, but I think we can come up with a better way. For example, I don't like that I have to replicate the config in each module's struts-config.xml in a multi-module app. That's error prone. We've talked about allowing for for things like form bean definitions. What about having this concept right at the top of the config scheme? So I could define a global struts-config.xml file (which wouldn't be used directly by any module), and then that file to provide module-specific config files. If we added an optional section to struts-config, we could then specify a list of Chain config files in there. > I would suggest skipping the chainConfig and chainCommand parameters > in the web.xml in favor of explicitly setting them in each > controller. Too many config options can be more trouble than they > are worth. +1 > The discussion of how to configure the Controller or the > RequestProcessor touched off a lot of talk earlier on struts-dev, but > I'd be happy to settle for two properties on ControllerConfig just to > move forward. > > >>>struts-config.xml > >>>- The default request processor class would now be > >>>ComposableRequestProcessor, but the legacy ones would still be available > >>>(deprecated) > >> > >> > >>+1. One thing that I'm a little confused about, though, is that the > >>new request processor is (currently) in a package that includes > >>'legacy'. Anyone know why that is? > > I don't know, but I think we should move it out to > o.a.s.chain.ComposableRequestProcessor. Fine with me. > >>>- The controller would have additional optional attributes: > > I think the controller should simply have optional command and > catalog attributes which would be used like this: > > CatalogFactory.getCatalog(catalog).getCommand(command) > > if no catalog is specified, the "default" catalog is retrieved with > getCatalog(). If no command is specified, then these default values > would be used: > catalog = struts > command = servlet-complete I believe that's what's in place now. > If catalog were specified without a command, an exception would be thrown. > > I am still inclined to package most of what is now struts-chain > separately from the core. I'm not so sure I agree here. Most, if not all, of the commands y
Re: Any objections to adding Ant get's to build.xml?
I'm working on this right now. I have the 'get' stuff done locally, but there's some other build stuff I want to clean up before I commit that. (Last night's Cactus property clean-up was part of that.) -- Martin Cooper On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I'm setting up Struts to build from Ant (again), and have to go through > the hassle of setting up build.properties. When I brought struts-bsf > in, I changed its build.xml to, if a "lib" directory didn't exist, > create one and use Ant's get task to pull the jars from ibiblio. It > wouldn't be a long term solution to our building woes, but I figure if I > have to go through the pain of setting up build.properties, I might as > well make it easier for the next guy/gal. > > Don > > - > 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]
