Re: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Date: Sat, 07 Jun 2003 16:55:07 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Status check? Craig R. McClanahan wrote: By the way, I uploaded the new Struts-Faces integration library stuff (and copied over the old one for legacy purposes) to a new directory: http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/ I left a web server redirect in place so to that the old URL comes here. Is this a temporary location related to the hard drive problems? Posting these at http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ seemed cool, but we don't want to keep things under release unless there's been an actual vote, n'est pas? The nightly directories get any file older than five days cleaned out -- and, because I'm not able to deal with getting them published in the time I'm at JavaOne, that means a somewhere else or nothing policy is important. That being said, we definitely need to figure out a strategy for stuff not in Struts core but having releases by whatever definition is appropriate. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Vic Cekvenich wrote: I downloaded and it apears to work with a sample app of mine, just FYI. Phil Steitz wrote: Ted, Don't know if this is useful, but I did the following successfully: 1. Hack build.xml to remove compile.library depends for tomcat, junit test targets. 2. Replace contents of my local cvs co/target/library with jararta-struts-1.1-rc2-lib 3. execute test.tomcat.all and test.junit targets using the hacked build.xml. All tests ran clean and no compile targets were executed. I do not have tc 3 installed, so only the 40 and 41 tc tests ran, hitting tc 4.04 and 4.1.24 resp. I ran once using (Sun Linux) JDK 1.4.1_01 and once using JDK 1.3.1_03. Thanks, guys. More eyes always help. =:) I'll have some (liquid) java and run through the standard suite now, and then we can ship this puppy! -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check? - Houston we have a problem
I'm still play-testing the web apps against all three, but here's an early warning: Running the exercise app under Tomcat 3.3.1a The logic-compare test kills container - nothing in log to indicate why. This is a big test, so it may be rendering problem. (TC41 is OK) Same result under NN and IE for Windows XP. The Tomcat test memory usage is under 50%. Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal), http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp Error: 500 Location: /struts-exercise-taglib/bean-cookie.jsp Internal Servlet Error: org.apache.jasper.JasperException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:430) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Root cause: java.lang.IllegalAccessException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57) at java.lang.reflect.Method.invoke(Method.java:317) at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:428) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
I've gotten some requests for a list of library file versions for my SecurityFilter project, so I've been looking into automatically creating a file that lists the library file versions as part of my build. The idea was to use the version information from the manifest files from the jars. However, many projects do not provide this information in their jars, or at least not the correct info. The commons projects are pretty good compared to the other dependencies I have, but commons-beanutils reports 1.6 for the 1.6.1 release, and commons-digester has 1.5 (with the quotes) for the 1.5 release. The quotes aren't a big deal since anyone reading it would correctly recognize it as the 1.5 release. But commons-beanutils would mislead you to think you had 1.6 when it was really 1.6.1. commons-logging has good version info commons-codec has a good Implementation-Version number (which is what I would use anyway) commons-collections has good version info jakarta-oro is pretty good, but adds a date and time to the Implementation-Version in additon to the correct version number, which might be confusing I'm not sure about other commons (oops, I mean jakarta-commons ;-)) projects. I think it is ideal to set things up so you can just do a cvs checkout or update with a tag to get all the files you need to build a particular release. It seems weird to tag another project's tree with your release, though, if the current setup would require tagging commons project trees when there is a Struts release. This is perhaps a good reason to commit the library jars in the struts CVS tree, or do something Maven-like where your project specifies what versions of external dependencies you need and it retrieves them into a shared local repository. I think there is an Ant extension that will do retrieval like Maven. I don't know if you guys ever do this, but I have in the past moved some files CVS repositories by moving the repository file (ends in ,v) itself. After doing that a few times, I have given up the practice since it screws up the history -- the file will be in the wrong place if you do a checkout based on a tag that existed before the move. It's better to just remove the old file and add it in the new location with a CVS client rather than mucking with the repository files, but you get a discontinuity in the history that way. I am hopeful that Subversion will support real moves, and will catch on enough to displace CVS some day. -Max - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 06, 2003 1:48 PM Subject: Re: Status check? It makes more sense to me to *not* tag the commons files with Struts. The commons doesn't need to be notified every time Struts cuts a release. The commons jars contain version information in their manifests so it would be very easy to recreate an old Struts build by looking there. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
I have been struggling with this for another project, too. Ideally, it would be great to have a continuous integration build that would also deploy and test the app(s) in a bunch of containers automatically. You'd still have to install and configure some deployment details, of course, but it would be nice to have a machine with a bunch of containers on it that would run and test builds in all of them automatically. I imagine the same system could be used to deploy to a developer's favorite container or containers for local testing on a much smaller scale. Are there any projects out there intended to make it easier to test the same app(s) in a variety of containers? -Max - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, June 06, 2003 3:39 PM Subject: Re: Status check? Martin Cooper wrote: For the main Struts release, the most time-consuming part is just testing that everything works with all the supported containers (including all the web apps). So, I take it we would be satisfied with testing our sample applications against the binary distribution (rather than against all the permutations of Java 1.2, 1.3, 1.4, and Servlet 2.2 and 2.3). And then for Cactus, I take it we would run TC 3.3 against Servlet 2.2, and TC 4.x against Servlet 2.3, as that would be the expected use. -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: Status check? - Houston we have a problem
So, I tried it under Tomcat 3.3.1 (no a), with the same result. =:( I had compiled the release under servlet 2.3, but I redid it under servlet 2.2 with the same result. I don't use cookies much, and off-hand I don't know if it's a problem with the test, Tomcat, or Jasper. The other cats are happy, though. And everything else for TC3 is nominal I suspect that the comparison test would pass, but that Jasper is running out of resources. If there's a way to reconfigure TC3 so this one will run, let me know. I'm also seeing some Servlet Exceptions in the tiles example for TC3 that don't appear for the TC4s. For example, http://localhost:8080/tiles-documentation/tutorial/extendedDefinitionTag.jsp throws [ServletException in:/common/menuViewSrc.jsp] TOMCAT/JSP/common/menuViewSrc.jsp' but only in TC3. So, pending advice from the other committers, the release seems to be stalled, since our exercise-taglib tests and some of our tiles-documentation pages do not seem to run successfully against one of our supported containers. Tiles is an optional component, so I could live with there being TC3 issues for that (if we document them). But I'm not sure what to think about the cookies error. -T. Ted Husted wrote: I'm still play-testing the web apps against all three, but here's an early warning: Running the exercise app under Tomcat 3.3.1a The logic-compare test kills container - nothing in log to indicate why. This is a big test, so it may be rendering problem. (TC41 is OK) Same result under NN and IE for Windows XP. The Tomcat test memory usage is under 50%. Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal), http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp Error: 500 Location: /struts-exercise-taglib/bean-cookie.jsp Internal Servlet Error: org.apache.jasper.JasperException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:430) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Root cause: java.lang.IllegalAccessException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57) at java.lang.reflect.Method.invoke(Method.java:317) at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:428) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Craig R. McClanahan wrote: The nightly directories get any file older than five days cleaned out -- and, because I'm not able to deal with getting them published in the time I'm at JavaOne, that means a somewhere else or nothing policy is important. Understood and agreed. Making the s-f distruibution available to the community is more important that observing the letter of our procecures. (Apache was made for developers, not developers for Apache.) That being said, we definitely need to figure out a strategy for stuff not in Struts core but having releases by whatever definition is appropriate. +1. All the optional components, the original struts-tags, struts-el, tiles, validator, struts-faces, should all have their own release cycles. We need to emphasize the fact that Strut is (and always has been) pluggable, and everyone's favorite flavor of the day will work just fine. The only thing that really needs to be in the struts-core is the Action package and its direct dependencies. For Struts-faces, I think if you just call for a [VOTE] when you get back, we can just release it as a milestone, like anything else. So long as it's a positive vote, and we get the minimum three binding +1s, we could just leave them there. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o. I've created the .asc signature files, and the .md5 digest files, but only for the .tar.gz and .zip files, since we don't usually release the .tar files. (They're only needed to produce the .tar.gz files.) OK, got 'em. Thanks! -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check? - Houston we have a problem
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:37 AM To: Struts Developers List Subject: Re: Status check? - Houston we have a problem I'm still play-testing the web apps against all three, but here's an early warning: Running the exercise app under Tomcat 3.3.1a The logic-compare test kills container - nothing in log to indicate why. This is a big test, so it may be rendering problem. (TC41 is OK) Urk. It doesn't just kill the container, it kills the JVM (on Sun JDK 1.4.1_01). I didn't see that before, but maybe I was using an earlier JVM. If I have time, I'll try that. Same result under NN and IE for Windows XP. The Tomcat test memory usage is under 50%. Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal), http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp Error: 500 Location: /struts-exercise-taglib/bean-cookie.jsp Internal Servlet Error: org.apache.jasper.JasperException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public The part of the test that is failing is: jsp:getProperty name=sess property=name/ The jsp:getProperty tags earlier on the page succeeded. The only difference I can see is that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) -- Martin Cooper at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:430) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Root cause: java.lang.IllegalAccessException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57) at java.lang.reflect.Method.invoke(Method.java:317) at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:428) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) - 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: Status check? - Houston we have a problem
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 10:24 AM To: 'Struts Developers List' Subject: RE: Status check? - Houston we have a problem -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:37 AM To: Struts Developers List Subject: Re: Status check? - Houston we have a problem I'm still play-testing the web apps against all three, but here's an early warning: Running the exercise app under Tomcat 3.3.1a The logic-compare test kills container - nothing in log to indicate why. This is a big test, so it may be rendering problem. (TC41 is OK) Urk. It doesn't just kill the container, it kills the JVM (on Sun JDK 1.4.1_01). I didn't see that before, but maybe I was using an earlier JVM. If I have time, I'll try that. I just tried Sun JDK 1.4.0, and it kills that too. ;-( Don't know if I have any others lying around. I'll see... -- Martin Cooper Same result under NN and IE for Windows XP. The Tomcat test memory usage is under 50%. Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal), http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp Error: 500 Location: /struts-exercise-taglib/bean-cookie.jsp Internal Servlet Error: org.apache.jasper.JasperException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public The part of the test that is failing is: jsp:getProperty name=sess property=name/ The jsp:getProperty tags earlier on the page succeeded. The only difference I can see is that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) -- Martin Cooper at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:430) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Root cause: java.lang.IllegalAccessException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57) at java.lang.reflect.Method.invoke(Method.java:317) at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:428) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Status check?
Ted Husted wrote: BUILD FAILED file:C:/projects/Apache/jakarta/jakarta-struts/build.xml:308: java.lang.IllegalM onitorStateException: current thread not owner Total time: 3 seconds Any thoughts? J2SE 1.3 compiles fine, and of course 1.4 is good, and I thought I had 1.2 working too, but now it doesn't like me anymore =:( -Ted. OK, for the purposes of this release candidate, I am going to take it on faith that given a proper JAXP installation, that Struts will compile under J2SE 1.2. If someone does know how, *starting from scratch*, you can download the latest J2SE 1.2 and add JAXP support from resources *now available*, please provide a patch to the installation page. If it turns out you-can't-get-there-from-here anymore (because the Sun JAXP RI is no longer available as bundled release), we'll just have to move our dependency to J2SE 1.3. Time marches on. I'm running the Tomcat tests now and updating the release notes. Film at 11. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
OK, the release-notes are updated. ]My, we have been busy little beavers:-)]. There were a good number of refactoring and fixes, but no new major changes aside from those stated. (Though, I'll need to add the new deprecations to the What's Different list. If there's anything else we've done recently that should be added to the What's New and What's Different sections, please let me know. I need to run some errands. If anyone is around and is up for starting on some of the Tomcat tests for me, that would be great. We need to run the Cactus tests and playtest the examples apps for the supported containers. Otherwise, I'll get to it this afternoon. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted wrote: OK, the release-notes are updated. The page is not linked, but I uploaded it already. http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc2.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
I'm doing a cleanup pass over the release notes right now, fixing some things and cleaning up the text in some places. Is it OK for me to go ahead and check that in when I'm done, Ted? -- Martin Cooper On Sat, 7 Jun 2003, Ted Husted wrote: OK, the release-notes are updated. ]My, we have been busy little beavers:-)]. There were a good number of refactoring and fixes, but no new major changes aside from those stated. (Though, I'll need to add the new deprecations to the What's Different list. If there's anything else we've done recently that should be added to the What's New and What's Different sections, please let me know. I need to run some errands. If anyone is around and is up for starting on some of the Tomcat tests for me, that would be great. We need to run the Cactus tests and playtest the examples apps for the supported containers. Otherwise, I'll get to it this afternoon. -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: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Date: Sat, 07 Jun 2003 14:25:23 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Status check? Yes, go ahead, Martin. I made a couple of very minor changes to my local copy, but nothing that won't reconcile after you chedck in yours. A very popular FAQ after each release has been what version of the commons libraries was included. Can we be explicit about this, perhaps in the what's included section? By the way, I uploaded the new Struts-Faces integration library stuff (and copied over the old one for legacy purposes) to a new directory: http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/ I left a web server redirect in place so to that the old URL comes here. Martin Cooper wrote: I'm doing a cleanup pass over the release notes right now, fixing some things and cleaning up the text in some places. Is it OK for me to go ahead and check that in when I'm done, Ted? One more status note ... it doesn't look like I'm going to be able to resurrect my nightly build process (for Commons packages and Struts) before getting on a plane tomorrow for JavaOne, so nightly builds will probably not be available until I can get back and clean that up. I hate disk hardware problems :-(. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sat, 7 Jun 2003, Craig R. McClanahan wrote: On Sat, 7 Jun 2003, Ted Husted wrote: Date: Sat, 07 Jun 2003 14:25:23 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Status check? Yes, go ahead, Martin. I made a couple of very minor changes to my local copy, but nothing that won't reconcile after you chedck in yours. A very popular FAQ after each release has been what version of the commons libraries was included. Can we be explicit about this, perhaps in the what's included section? I'm actually in the middle of adding that now. ;-) I remember you asked me a while ago to make sure we list the explicit versions we use. The What's Included section seems like the logical place. My only concern is that, because of the length of the RC/Beta Fixes section, it's quite far down the page. But I don't know where else I would put it... -- Martin Cooper By the way, I uploaded the new Struts-Faces integration library stuff (and copied over the old one for legacy purposes) to a new directory: http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/ I left a web server redirect in place so to that the old URL comes here. Martin Cooper wrote: I'm doing a cleanup pass over the release notes right now, fixing some things and cleaning up the text in some places. Is it OK for me to go ahead and check that in when I'm done, Ted? One more status note ... it doesn't look like I'm going to be able to resurrect my nightly build process (for Commons packages and Struts) before getting on a plane tomorrow for JavaOne, so nightly builds will probably not be available until I can get back and clean that up. I hate disk hardware problems :-(. 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: Status check?
Martin Cooper wrote: I'm actually in the middle of adding that now. ;-) I remember you asked me a while ago to make sure we list the explicit versions we use. The What's Included section seems like the logical place. My only concern is that, because of the length of the RC/Beta Fixes section, it's quite far down the page. But I don't know where else I would put it... It would be best to carry the explicit list on the installation page installation.html as we always have, and then add a cross-reference from the Release Notes, to remind people where to find it. =;) We might also mention that the packages are also cited in the build.properties.sample file. But, we should avoid keeping the actual list in a third place =:) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Martin Cooper wrote: I'm actually in the middle of adding that now. ;-) I remember you asked me a while ago to make sure we list the explicit versions we use. The What's Included section seems like the logical place. My only concern is that, because of the length of the RC/Beta Fixes section, it's quite far down the page. But I don't know where else I would put it... It would be best to carry the explicit list on the installation page installation.html as we always have, and then add a cross-reference from the Release Notes, to remind people where to find it. =;) The list on the installation page refers to what you need if you want to build Struts from source, rather than what is bundled with Struts itself. They're similar, but not identical, since in the former, we refer to version 123 or later, whereas in the latter, we need to specify an exact version. I'd actually prefer to put the list in the What's Included and then change the installation page to say that you need to build against what's included with Struts, or a later version, and have the link point the other way. Since I'm already done adding the list to the release notes, I'll go ahead and check that in, but feel free to move it if you'd prefer. Incidentally, I noticed that the installation page still references DBCP and Pool, and the build file is still including those jars in the build. We obviously need to fix those before the release. Let me know if you'd like me to take care of either of those. -- Martin Cooper We might also mention that the packages are also cited in the build.properties.sample file. But, we should avoid keeping the actual list in a third place =:) -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: Status check?
Martin Cooper wrote: Incidentally, I noticed that the installation page still references DBCP and Pool, and the build file is still including those jars in the build. We obviously need to fix those before the release. Let me know if you'd like me to take care of either of those. I'm trying to run my integration tests again before releasing the final version of Struts-Legacy JAR. But, the Struts 1.1 RC1 version of my isn't connecting to my database right now, and I don't know why. I'm going to bring the Struts 1.02 version back up, to make sure that works, and then change my local CVS to use RC2 with Struts-Legacy, and plug that into the Struts 1.1 version of the same app, then see if that tests OK. If it does (which it did before), we can release Struts-Legacy and then RC2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Craig R. McClanahan wrote: By the way, I uploaded the new Struts-Faces integration library stuff (and copied over the old one for legacy purposes) to a new directory: http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/ I left a web server redirect in place so to that the old URL comes here. Is this a temporary location related to the hard drive problems? Posting these at http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ seemed cool, but we don't want to keep things under release unless there's been an actual vote, n'est pas? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Martin Cooper wrote: http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases I added the section on PGP 8.0 Freeware, since that's what I use, but you can also use GPG, which I think is installed on daedalus. The MD5 tool is definitely installed on daedalus, since that's where I create the digests for Struts releases. If you're still having trouble, you could put the zip and tar.gz bundles in your home directory on cvs and give me access, and I can create the sigs and upload them, if you want. OK, I admittedly haven't even tried signing these, but I still need to pack. =:) I uploaded struts-legacy to my home directory on cvs.apache.org. Could you could sign these for me, Martin? You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o. I've created the .asc signature files, and the .md5 digest files, but only for the .tar.gz and .zip files, since we don't usually release the .tar files. (They're only needed to produce the .tar.gz files.) -- Martin Cooper There aren't any lib files, since this distribution is nothing but lib :) (Really loving that release target!) -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: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Martin Cooper wrote: You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o. I've created the .asc signature files, and the .md5 digest files, but only for the .tar.gz and .zip files, since we don't usually release the .tar files. (They're only needed to produce the .tar.gz files.) OK, I've made the changes regarding the DBPC/Pool dependencies, and play tested the new build in an application that exercises the datasource, along with the Tiles and the Validator -- all systems nominal! I can do the stock Tomcat testing in the morning, and, should everything pass, we can tag this puppy and ship it! (If anyone wants to be the Release Test Manager, jump in now! There's a working candidate at http://cvs.apache.org/~husted/ - This is a preview only - it is *not* the final RC! but it's what we want to test.) Assuming the rest is done, Martin, old friend, will you be around tomorrow at mid-day to sign the Struts jar for me? If you mean mid-day EDT, yes, I should be around then. By mid-day PDT, though, I'll be out at a lunch appointment. So the earlier you're ready, the better. ;-) -- Martin Cooper (I promise to get setup to do signing for next time.) -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: Status check?
SNIP: Ted Husted wrote: There's a working candidate at http://cvs.apache.org/~husted/ - This is a preview only - it is *not* the final RC! but it's what we want to test.) I downloaded and it apears to work with a sample app of mine, just FYI. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted wrote: Martin Cooper wrote: You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o. I've created the .asc signature files, and the .md5 digest files, but only for the .tar.gz and .zip files, since we don't usually release the .tar files. (They're only needed to produce the .tar.gz files.) OK, I've made the changes regarding the DBPC/Pool dependencies, and play tested the new build in an application that exercises the datasource, along with the Tiles and the Validator -- all systems nominal! I can do the stock Tomcat testing in the morning, and, should everything pass, we can tag this puppy and ship it! (If anyone wants to be the Release Test Manager, jump in now! There's a working candidate at http://cvs.apache.org/~husted/ - This is a preview only - it is *not* the final RC! but it's what we want to test.) Assuming the rest is done, Martin, old friend, will you be around tomorrow at mid-day to sign the Struts jar for me? (I promise to get setup to do signing for next time.) -Ted. Ted, Don't know if this is useful, but I did the following successfully: 1. Hack build.xml to remove compile.library depends for tomcat, junit test targets. 2. Replace contents of my local cvs co/target/library with jararta-struts-1.1-rc2-lib 3. execute test.tomcat.all and test.junit targets using the hacked build.xml. All tests ran clean and no compile targets were executed. I do not have tc 3 installed, so only the 40 and 41 tc tests ran, hitting tc 4.04 and 4.1.24 resp. I ran once using (Sun Linux) JDK 1.4.1_01 and once using JDK 1.3.1_03. hth, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
-1 Two weeks seems a little tight. I only say this because the change to the nested tags after RC1 wasn't the smallest of changes, and I personally feel a little nervous that it would be shoved out the door with only two weeks on a release. It was a big fix to get Tomcat 4.1.x going with them, and it was agreed that having the RC2 timespan to allow uptake on any glaring problems would be fine, but two weeks seems a little quick. I've done my best to usher the latest of the tags onto the masses but the broadcast of a release brings in more people than I could ever hope of reaching personally. When RC2 comes out I'd like a little more time to be assured people are comfy with the changes. And as ted mentioned, some of the docs need updating, and for FileUpload to run its course. I know people want it out there but could I stretch the friendship and ask that there's at least a month of RC2 before final?... (what's two more weeks?... they'll fly by, I promise :) Arron. - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
What if we compromise on 3 weeks? I understand the tag testing issue but we shouldn't be holding back because of documentation issues. David -1 Two weeks seems a little tight. I only say this because the change to the nested tags after RC1 wasn't the smallest of changes, and I personally feel a little nervous that it would be shoved out the door with only two weeks on a release. It was a big fix to get Tomcat 4.1.x going with them, and it was agreed that having the RC2 timespan to allow uptake on any glaring problems would be fine, but two weeks seems a little quick. I've done my best to usher the latest of the tags onto the masses but the broadcast of a release brings in more people than I could ever hope of reaching personally. When RC2 comes out I'd like a little more time to be assured people are comfy with the changes. And as ted mentioned, some of the docs need updating, and for FileUpload to run its course. I know people want it out there but could I stretch the friendship and ask that there's at least a month of RC2 before final?... (what's two more weeks?... they'll fly by, I promise :) Arron. - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
What if we compromise on 3 weeks? I understand the tag testing issue but we shouldn't be holding back because of documentation issues. It's all about getting the tags and other changes tested more completely. (what's documentation? ;) I can very munch understand something happening for JavaOne, it's a big deal to be able to say something new is out there. But after JavaOne, a week isn't much when there's not too much going on and it helps assure a more quality product, IMHO. Arron. David -1 Two weeks seems a little tight. I only say this because the change to the nested tags after RC1 wasn't the smallest of changes, and I personally feel a little nervous that it would be shoved out the door with only two weeks on a release. It was a big fix to get Tomcat 4.1.x going with them, and it was agreed that having the RC2 timespan to allow uptake on any glaring problems would be fine, but two weeks seems a little quick. I've done my best to usher the latest of the tags onto the masses but the broadcast of a release brings in more people than I could ever hope of reaching personally. When RC2 comes out I'd like a little more time to be assured people are comfy with the changes. And as ted mentioned, some of the docs need updating, and for FileUpload to run its course. I know people want it out there but could I stretch the friendship and ask that there's at least a month of RC2 before final?... (what's two more weeks?... they'll fly by, I promise :) Arron. - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - 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: Status check?
Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I'm installing 1.2 now, to at least be sure it still builds (as I remember, the nightlies are building on Craig's machine under 1.4). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: The tagging for the main Struts release will actually be a bit more painful for RC2 since you can't just blanket-tag the Commons packages - they'll have to be tagged individually to match the specific versions we're bundling. I can understand why we tagged the Commons packages when we were building betas against the nightly builds, but now that we are basing our RCs on Final Releases or other Release Candidates, tagging the Commons CVS seems futile and dangerous. Don't they already have tags for the versions upon which we have declared our dependency? And, I'd have to be sure I had the release version checked-out (some of which are months old now) rather than the current trunk. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
For Java 1.2 and 1.3, we need to have JAXP available to build the distribution. The RI isn't distributed separately anymore, but is part of the Web Services bundle. http://java.sun.com/xml/jaxp/faq.html#jaxp-ri-latest I tried pulling out the jaxp-api.jar, but that didn't seem to work. Before I go down the trial-and-error route, does anyone know exactly what JARs we need to add from the Web Services bundle to build Struts under 1.2 or 1.3? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. -- Martin Cooper I'm installing 1.2 now, to at least be sure it still builds (as I remember, the nightlies are building on Craig's machine under 1.4). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: The tagging for the main Struts release will actually be a bit more painful for RC2 since you can't just blanket-tag the Commons packages - they'll have to be tagged individually to match the specific versions we're bundling. I can understand why we tagged the Commons packages when we were building betas against the nightly builds, but now that we are basing our RCs on Final Releases or other Release Candidates, tagging the Commons CVS seems futile and dangerous. Don't they already have tags for the versions upon which we have declared our dependency? And, I'd have to be sure I had the release version checked-out (some of which are months old now) rather than the current trunk. I disagree that it is either futile or dangerous. It is useful because you can, at some point in time, just do a CVS checkout using the appropriate Struts tag and get everything you need to build that version of Struts. That way, you don't have to refer to a (possibly erroneous) document to look up which versions you need to get. It isn't dangerous, because you can simply ask CVS to tag the code for a specific version of a Commons component with the relevant Struts tag. It could be dangerous if it was done off a local code base rather than tagging CVS against CVS itself, but that's not necessary. I'll take care of tagging our dependencies once RC2 is out. -- Martin Cooper -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 1:54 PM To: [EMAIL PROTECTED] Subject: Re: Status check? Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. I don't believe this is correct. I think it actually is the COMPILER that can cause a compatibility issue. There is an article over at Java World that details this problem. The first example makes it clear. http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version.html? --- - Nayan Hajratwala - Chikli Consulting LLC - http://www.chikli.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
Perhaps a -target 1.2 option should be specified on our javac targets? I would guess the number of issues with down-compilation from 1.4 to 1.2 is very small, but if we have one in our code base, the compiler won't tell us about it. -Original Message- From: Hajratwala, Nayan (N.) [mailto:[EMAIL PROTECTED] -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. I don't believe this is correct. I think it actually is the COMPILER that can cause a compatibility issue. There is an article over at Java World that details this problem. The first example makes it clear. http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version.html? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: I'll take care of tagging our dependencies once RC2 is out. Hey, if setting CVS tags is something you like to do, more power to you, brother =:) But don't forget to tag ORO too, not to mention the jdbc2_0-stdext.jar and Servlet JAR =:) We also have external dependencies on them, just as we have *external* dependencies on the Commons JARs. But, for the record, I'm planning on building the distribution from that same possibly erroneous document that you will later use to set the tags. So if the document is wrong, everything else will be wrong too. If compiling our distribution from JARs distributed by another CVS is not acceptable to the team, and I totally misunderstand the point of sending these packages to the Commons in the first place, then please let me know now, and I'll pass the baton. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: As far as building and packaging go, you might want to take a look at the 'release' target I added to the main Struts build file. That really helps with putting the binary and source uploads together. Very nice work here, Martin. This target certainly simplifies things! Just sorting out what I need to do to retrofit 1.2/1.3 with JAXP these days, so I can confirm we still compile with the old guard =:0) -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. Works for me. I'll just confirm that we still build under 1.2-1.4, as alleged by the installation page. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
It makes more sense to me to *not* tag the commons files with Struts. The commons doesn't need to be notified every time Struts cuts a release. The commons jars contain version information in their manifests so it would be very easy to recreate an old Struts build by looking there. David But don't forget to tag ORO too, not to mention the jdbc2_0-stdext.jar and Servlet JAR =:) We also have external dependencies on them, just as we have *external* dependencies on the Commons JARs. But, for the record, I'm planning on building the distribution from that same possibly erroneous document that you will later use to set the tags. So if the document is wrong, everything else will be wrong too. If compiling our distribution from JARs distributed by another CVS is not acceptable to the team, and I totally misunderstand the point of sending these packages to the Commons in the first place, then please let me know now, and I'll pass the baton. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted wrote: Just sorting out what I need to do to retrofit 1.2/1.3 with JAXP these days, so I can confirm we still compile with the old guard =:0) I downloaded the latest Web Services pack (I had an older version), and at first the JAXP from that distribution seemed to work, but now for J2SE 1.2 I'm getting init: [echo] - jakarta-struts 1.1-rc2 - [echo] java.class.path = C:\Javasoft\jdk1.2.2\lib\tools.jar;C:\opt\Ant\jaka rta-ant-1.5.1\lib\xsltc.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\xml-apis.jar;C:\opt \Ant\jakarta-ant-1.5.1\lib\xercesImpl.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\xalan .jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\src.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\s ax.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\optional.jar;C:\opt\Ant\jakarta-ant-1.5. 1\lib\junit.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\junit-src.jar;C:\opt\Ant\jakart a-ant-1.5.1\lib\jaxp-api.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\dom.jar;C:\opt\Ant \jakarta-ant-1.5.1\lib\ant.jar;. [echo] java.home = C:\Javasoft\jdk1.2.2\jre [echo] user.home = C:\Documents and Settings\ted prepare.library: compile.library: [style] Transforming into C:\projects\Apache\jakarta\jakarta-struts\target\l ibrary [style] Processing C:\projects\Apache\jakarta\jakarta-struts\doc\userGuide\s truts-bean.xml to C:\projects\Apache\jakarta\jakarta-struts\target\library\strut s-bean.tld [style] Loading stylesheet C:\projects\Apache\jakarta\jakarta-struts\doc\sty lesheets\tld.xsl A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/xalan/processor/StylesheetHandler.init (Lorg/apache/xalan/processo r/TransformerFactoryImpl;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cg i A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/xalan/templates/OutputProperties.getDefaultMethodProperties (Ljava /lang/String;)Ljava/util/Properties;': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cg i A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/xalan/transformer/TransformerImpl.setErrorListener (Ljavax/xml/tra nsform/ErrorListener;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cg i [style] Failed to process C:\projects\Apache\jakarta\jakarta-struts\doc\user Guide\struts-bean.xml BUILD FAILED file:C:/projects/Apache/jakarta/jakarta-struts/build.xml:308: java.lang.IllegalM onitorStateException: current thread not owner Total time: 3 seconds Any thoughts? J2SE 1.3 compiles fine, and of course 1.4 is good, and I thought I had 1.2 working too, but now it doesn't like me anymore =:( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: For the main Struts release, the most time-consuming part is just testing that everything works with all the supported containers (including all the web apps). So, I take it we would be satisfied with testing our sample applications against the binary distribution (rather than against all the permutations of Java 1.2, 1.3, 1.4, and Servlet 2.2 and 2.3). And then for Cactus, I take it we would run TC 3.3 against Servlet 2.2, and TC 4.x against Servlet 2.3, as that would be the expected use. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
If you're going to cross-compile, you really need to go whole-hog and use the target, bootclass, and extdirs options. See: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#crosscomp-options and: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#crosscomp-example Karr, David wrote: Perhaps a -target 1.2 option should be specified on our javac targets? I would guess the number of issues with down-compilation from 1.4 to 1.2 is very small, but if we have one in our code base, the compiler won't tell us about it. -Original Message- From: Hajratwala, Nayan (N.) [mailto:[EMAIL PROTECTED] -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. I don't believe this is correct. I think it actually is the COMPILER that can cause a compatibility issue. There is an article over at Java World that details this problem. The first example makes it clear. http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version.html? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Status check?
On Fri, 6 Jun 2003, David Graham wrote: Date: Fri, 06 Jun 2003 14:48:13 -0600 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Status check? It makes more sense to me to *not* tag the commons files with Struts. The commons doesn't need to be notified every time Struts cuts a release. The commons jars contain version information in their manifests so it would be very easy to recreate an old Struts build by looking there. I think tagging made lots of sense during our beta period, when we were grabbing arbitrary nightly builds of the commons libraries. However, for this release our release notes should be really explicit about what versions we included -- each of which is already tagged as a release in the commons CVS, so it shouldn't be an issue. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sat, 31 May 2003, Martin Cooper wrote: Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2 this weekend, I can then cut RC2 with that, if you like. The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).) So it's just a matter of what release this will be, and what to do about the deprecated methods. Then I can send out the vote. OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. -- Martin Cooper I'm going to release the struts-generic package first thing in the morning, and move the nightly build dependencies over to that, so we can then just plug in the latest FileUpload. IMHO, you might consider taking FileUpload straight to RC1. It's unreleased software and API changes are to be expected. If this were FU 2.0, and you were removing something that was in FU 1.0's established API, it would be different. But greater latitude as to API changes should be given to unreleased, pre-1.0 packages. So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK? Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. Tapestry won't be affected, since Mr. Tapestry doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts already has the necessary changes. -- Martin Cooper If you were to go to FileUpload RC1, then perhaps Struts and FileUpload can then go to final together. -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: Status check?
Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want to set a date for Struts 1.1 final? Think we can have RC2 live before we head off for SF? It would be a nice trophy to bring to JavaOne, especially with a target release date for Final. James -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:25 PM To: Struts Developers List Subject: Re: Status check? Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
Setting release dates is not a good idea for many reasons. IMO, 1.1 final should be released after enough time that people have tested apps with RC2 and there are no show stopping bugs. David Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want to set a date for Struts 1.1 final? Think we can have RC2 live before we head off for SF? It would be a nice trophy to bring to JavaOne, especially with a target release date for Final. James -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:25 PM To: Struts Developers List Subject: Re: Status check? Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Wed, 4 Jun 2003, Ted Husted wrote: Date: Wed, 04 Jun 2003 14:25:15 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Status check? Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. From a planning perspective, this sounds fine. On a release date, is anyone going to believe any date we publish in the plan, no matter what it is? :-) I do think we should say something like two weeks after RC2, barring any major bugs so that we can encourage people to actually try RC2 in that time frame. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
Right, but what's the right amount of time to wait? James -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:34 PM To: [EMAIL PROTECTED] Subject: RE: Status check? Setting release dates is not a good idea for many reasons. IMO, 1.1 final should be released after enough time that people have tested apps with RC2 and there are no show stopping bugs. David Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want to set a date for Struts 1.1 final? Think we can have RC2 live before we head off for SF? It would be a nice trophy to bring to JavaOne, especially with a target release date for Final. James -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:25 PM To: Struts Developers List Subject: Re: Status check? Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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: Status check?
Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. David James -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:34 PM To: [EMAIL PROTECTED] Subject: RE: Status check? Setting release dates is not a good idea for many reasons. IMO, 1.1 final should be released after enough time that people have tested apps with RC2 and there are no show stopping bugs. David Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want to set a date for Struts 1.1 final? Think we can have RC2 live before we head off for SF? It would be a nice trophy to bring to JavaOne, especially with a target release date for Final. James -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:25 PM To: Struts Developers List Subject: Re: Status check? Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
Good for me too. James -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:43 PM To: [EMAIL PROTECTED] Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. David James -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:34 PM To: [EMAIL PROTECTED] Subject: RE: Status check? Setting release dates is not a good idea for many reasons. IMO, 1.1 final should be released after enough time that people have tested apps with RC2 and there are no show stopping bugs. David Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want to set a date for Struts 1.1 final? Think we can have RC2 live before we head off for SF? It would be a nice trophy to bring to JavaOne, especially with a target release date for Final. James -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:25 PM To: Struts Developers List Subject: Re: Status check? Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellent. I'm blocking out Friday morning to work on releasing struts-legacy and then RC2. I assume it's OK with everyone if we just update the RC1 plan and work from that. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - 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: Status check?
- Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted wrote: Craig R. McClanahan wrote: I do think we should say something like two weeks after RC2, barring any major bugs so that we can encourage people to actually try RC2 in that time frame. June 15 would the be second anniversary of Struts 1.0 -- but I reckon that's a might too close, so let's say June 22, barring any showstoppers. Though, sigh/, JavaOne is next week, and so that shouldn't really count. Meanwhile, there's still a few places where the 1.1 documentation is a bit skimpy, and the News and Resources sections are way behind, and I'd like to beef those up before the world comes knocking on our door. There's also the small matter of whether FileUpload has gone final. AFAIK, we need final versions of all our dependent JARs, or else Struts will still not be accessible to many teams. So, pending advice to the contrary, I'll plan on putting 29 June 2003 in the Release Plan (two years and two weeks after Struts 1.0). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
From: Ted Husted [mailto:[EMAIL PROTECTED] So, pending advice to the contrary, I'll plan on putting 29 June 2003 in the Release Plan (two years and two weeks after Struts 1.0). Sounds very Lincoln-ian... Two years and two weeks ago, Craig McClanahan brought forth upon the Java community a new framework, conceived of MVC, and devoted to the notion that all business logic should be treated separate. Advice to Craig: Avoid theatres. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check?
On Wed, 4 Jun 2003, James Turner wrote: Sounds very Lincoln-ian... Two years and two weeks ago, Craig McClanahan brought forth upon the Java community a new framework, conceived of MVC, and devoted to the notion that all business logic should be treated separate. :-) Advice to Craig: Avoid theatres. Hope the stage in Hall E at JavaOne doesn't count :-) James Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
If anyone had a mind to, it would be really great to have the Struts News and Resources pages updated this week, before the next RC. There's been a bunch of stuff announced on the list lately. (If not, I'll try to do it before we go to final release.) I'm still getting my head around the release procedures [never signed a JAR before, except with a marker =:)], but do hope to have it sorted out by Friday or Saturday. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Tue, 3 Jun 2003, Ted Husted wrote: If anyone had a mind to, it would be really great to have the Struts News and Resources pages updated this week, before the next RC. There's been a bunch of stuff announced on the list lately. (If not, I'll try to do it before we go to final release.) I'm still getting my head around the release procedures [never signed a JAR before, except with a marker =:)], but do hope to have it sorted out by Friday or Saturday. You shouldn't have to sign any jars - we haven't done that for Struts before. The only things I sign for the releases are the zip and tar.gz bundles. There's a page on the Wiki that might help you with that: http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases I added the section on PGP 8.0 Freeware, since that's what I use, but you can also use GPG, which I think is installed on daedalus. The MD5 tool is definitely installed on daedalus, since that's where I create the digests for Struts releases. If you're still having trouble, you could put the zip and tar.gz bundles in your home directory on cvs and give me access, and I can create the sigs and upload them, if you want. -- 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: Status check?
Martin, I'm trying to release the struts-legacy package with our GenericDataSource implementation. I'm working from the Commons instructions (but substituting jakarta-struts where appropriate). http://jakarta.apache.org/commons/releases.html At step 5, it looks like I should log into cvs.apache.org first, tag the live files there, and create the binary distribution on that machine, as is done with the source distribution at step 9. Is that correct? Otherwise, do I check the files in (again) between #8 and #9, so the tag propagates. I've haven't had to set CVS tags myself before, and so I'm a bit nervous about that part. -Ted. -- Ted Hustled, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sun, 1 Jun 2003, Ted Husted wrote: Martin, I'm trying to release the struts-legacy package with our GenericDataSource implementation. I'm working from the Commons instructions (but substituting jakarta-struts where appropriate). http://jakarta.apache.org/commons/releases.html The instructions here are more up to date and more comprehensive: http://jakarta.apache.org/commons/releases/ I proposed switching the link to that not too long ago, but Robert wanted to do some cleanup first. IMHO, they're still better, though. At step 5, it looks like I should log into cvs.apache.org first, tag the live files there, and create the binary distribution on that machine, as is done with the source distribution at step 9. When you tag something in CVS, you're tagging the repository rather than the files per se. So yes, you need to be connected to cvs.apache.org. Basically, you need to make sure what you have on your local disk is what you want to tag, and then run the CVS 'tag' command. That will tag the repository. The reason your local files need to be up to date is because the version tagged in the repo is whatever you have locally. You can also use 'cvs rtag' if you want to tag the repo regardless of what you have, but I think most people, myself included, stick with 'cvs tag'. The binary and source distributions come from your local machine. You won't be able to build them on cvs.a.o or www.a.o, since they don't have the JDK available. As far as building and packaging go, you might want to take a look at the 'release' target I added to the main Struts build file. That really helps with putting the binary and source uploads together. For the main Struts release, the most time-consuming part is just testing that everything works with all the supported containers (including all the web apps). I don't know how much you'll need to do for the legacy stuff. Another time-consuming step is signing everything and creating digests. The tagging for the main Struts release will actually be a bit more painful for RC2 since you can't just blanket-tag the Commons packages - they'll have to be tagged individually to match the specific versions we're bundling. Hope this helps. -- Martin Cooper Is that correct? Otherwise, do I check the files in (again) between #8 and #9, so the tag propagates. I've haven't had to set CVS tags myself before, and so I'm a bit nervous about that part. -Ted. -- Ted Hustled, Struts in Action http://husted.com/struts/book.html - 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: Status check?
Martin Cooper wrote: Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2 this weekend, I can then cut RC2 with that, if you like. I'm going to release the struts-generic package first thing in the morning, and move the nightly build dependencies over to that, so we can then just plug in the latest FileUpload. IMHO, you might consider taking FileUpload straight to RC1. It's unreleased software and API changes are to be expected. If this were FU 2.0, and you were removing something that was in FU 1.0's established API, it would be different. But greater latitude as to API changes should be given to unreleased, pre-1.0 packages. If you were to go to FileUpload RC1, then perhaps Struts and FileUpload can then go to final together. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2 this weekend, I can then cut RC2 with that, if you like. The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).) So it's just a matter of what release this will be, and what to do about the deprecated methods. Then I can send out the vote. I'm going to release the struts-generic package first thing in the morning, and move the nightly build dependencies over to that, so we can then just plug in the latest FileUpload. IMHO, you might consider taking FileUpload straight to RC1. It's unreleased software and API changes are to be expected. If this were FU 2.0, and you were removing something that was in FU 1.0's established API, it would be different. But greater latitude as to API changes should be given to unreleased, pre-1.0 packages. So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK? Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. Tapestry won't be affected, since Mr. Tapestry doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts already has the necessary changes. -- Martin Cooper If you were to go to FileUpload RC1, then perhaps Struts and FileUpload can then go to final together. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK? On one hand, it seems rude to break the builds with not much notice. On the other, you're setting a dangerous precedent of maintaining backward compatibility between betas. If the changes can be fixed in a reasonably short amount of time, I think you can just rip out the methods. If not, can you leave them there and remove them in 1.1? Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. What if you sent a note to the mailing lists with a warning? David -- Martin Cooper If you were to go to FileUpload RC1, then perhaps Struts and FileUpload can then go to final together. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Martin Cooper wrote: So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK? Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. Tapestry won't be affected, since Mr. Tapestry doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts already has the necessary changes. The question is what's best for the community. From what you say, these methods are already doomed. It's just a matter of whether they fix the dependency now or a fortnight from now. (Or just stick with whatever JAR they are already using.) Yes, Gump may break. That's why we have Gump. =:) Sam did not create Gump to chain us, but to free us to make changes. When Gump breaks people get the heads-up that they need to make changes themselves. (Before they *voluntarily* elect to use the new version.) And, I agree with David. We've been taking backward compatibility between betas way too seriously. In the case of Struts, our betas have languished so long that it did become prudent for us to take that into account. They became de-facto releases. But I don't agree that as a rule we have to maintain full backward compatibility between betas *and* between final releases. Otherwise, why even have betas? When the software is released, you have established an API contract. But a beta is not a contract, it is a *proposed* contract, and subject to change until we sign on the dotted line and cut a final release. Personally, I don't think anyone will be astonished that things change in an unreleased product between betas. If they are, then maybe they should step up to bat and give you a hand with what is supposed to be a community-supported product. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Wed, 28 May 2003, James Turner wrote: Ok folks, things have been mighty quiet lately here. So I'm going to summerize where I think things are right now: 1) Struts core is basically ready to go, and the dependency on the latest version of DBCP has been removed 2) What we're waiting on is the final release of FileUpload, which Martin is working on. Can we get a status check on FileUpload? It would be mighty nice to get RC2 out before JavaOne. First, the FileUpload status. I have had some e-mail exchanges off-list with the reporters of the two outstanding bugs. A partial solution exists for one of them, and, when completed, should actually solve both of them. Unfortunately, those solutions won't work for Struts users, since they involve passing new information to FileUpload, which Struts obviously doesn't do right now. However, that could potentially be deferred to a Struts 1.2 release, as long as we promise ourselves that we'll be better about getting releases out more frequently. My problem right now with getting this finished up is that I am really swamped at my day job. With the hours I'm having to devote to that at the moment, there aren't many left for anything else. (Somebody told me last weekend was a holiday weekend. What weekend? ;) I promise I'll try to find some time this coming weekend to get a fix in that will hopefully resolve both issues. Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I just don't see how that can happen, given the steps that FileUpload has to go through before a final release. I almost felt like finishing up the following paragraph with Sorry, folks. But I decided to rant instead. |- rant For a long time now, not one other committer to FileUpload has put in any effort to finish it up and/or get it released. This is despite the fact that FileUpload is used by Tomcat, Turbine and Tapestry, as well as by Struts. I feel like I'm running a one-man show, which is exactly what Jakarta (and Apache) projects are not supposed to be. Running such a one-man show makes me feel guilty when I don't have the time to put in to help get Struts 1.1 RC2 out the door. It makes me feel like it's my fault. But it shouldn't be up to just me. /rant (Can you tell that I'm really stressed out right now? ;) Important note: The above rant should *not* be read as a complaint that other Struts developers are not getting involved with FileUpload. I don't expect you guys to do that at all. Rant over. Now back to my day job. (A day job at 11pm? What's wrong with this picture?) -- Martin Cooper James Turner Director of Software Development Benefit Systems, Inc. [EMAIL PROTECTED] Track Chair, Strategic Open Source 2003 Fall COMDEX Author: MySQL JSP Web Applications Struts Kick Start JavaServer Faces Kick Start - 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: Status check?
how easy it to become a commiter? I've got some time, I'll take a look at all the notes , cvs logs and bugzilla for fileUpload, and see if i can help. cheers mark On Thursday, May 29, 2003, at 07:18 Europe/London, Martin Cooper wrote: On Wed, 28 May 2003, James Turner wrote: Ok folks, things have been mighty quiet lately here. So I'm going to summerize where I think things are right now: 1) Struts core is basically ready to go, and the dependency on the latest version of DBCP has been removed 2) What we're waiting on is the final release of FileUpload, which Martin is working on. Can we get a status check on FileUpload? It would be mighty nice to get RC2 out before JavaOne. First, the FileUpload status. I have had some e-mail exchanges off-list with the reporters of the two outstanding bugs. A partial solution exists for one of them, and, when completed, should actually solve both of them. Unfortunately, those solutions won't work for Struts users, since they involve passing new information to FileUpload, which Struts obviously doesn't do right now. However, that could potentially be deferred to a Struts 1.2 release, as long as we promise ourselves that we'll be better about getting releases out more frequently. My problem right now with getting this finished up is that I am really swamped at my day job. With the hours I'm having to devote to that at the moment, there aren't many left for anything else. (Somebody told me last weekend was a holiday weekend. What weekend? ;) I promise I'll try to find some time this coming weekend to get a fix in that will hopefully resolve both issues. Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I just don't see how that can happen, given the steps that FileUpload has to go through before a final release. I almost felt like finishing up the following paragraph with Sorry, folks. But I decided to rant instead. |- rant For a long time now, not one other committer to FileUpload has put in any effort to finish it up and/or get it released. This is despite the fact that FileUpload is used by Tomcat, Turbine and Tapestry, as well as by Struts. I feel like I'm running a one-man show, which is exactly what Jakarta (and Apache) projects are not supposed to be. Running such a one-man show makes me feel guilty when I don't have the time to put in to help get Struts 1.1 RC2 out the door. It makes me feel like it's my fault. But it shouldn't be up to just me. /rant (Can you tell that I'm really stressed out right now? ;) Important note: The above rant should *not* be read as a complaint that other Struts developers are not getting involved with FileUpload. I don't expect you guys to do that at all. Rant over. Now back to my day job. (A day job at 11pm? What's wrong with this picture?) -- Martin Cooper James Turner Director of Software Development Benefit Systems, Inc. [EMAIL PROTECTED] Track Chair, Strategic Open Source 2003 Fall COMDEX Author: MySQL JSP Web Applications Struts Kick Start JavaServer Faces Kick Start - 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]
