Patrick, the idea is great - the implementations details are a bit problematic :-)
On Sat, 03 Aug 2002 09:04:18 -0700, Patrick Luby wrote: > Costin, > > I plan to post a patch to Ant for the enhanced data types (e.g. > syspropertyset) and the conditional <java> task elements (e.g. > sysproperty with "if" and "unless" attributes) back to Ant as I think > they would really enhance the Ant <java> task. I just haven't had time > yet but I will do so eventually. I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case the current ant ( even 1.5 ) seems to have all the elements it needs to start tomcat ( cactus and anteater are doing it ). > As for making the launcher functionality optional, I am OK with whatever > the community wants. But before the community takes it out, let me I don't think the 'community' wants something - and I must admit I had very little idea of this going on. If _you_ think this is a good idea - you must make a more explicit proposal, make sure everyone is aware of this, eventually have a vote and add some documentation ( a spec / the proposal / whatever ). I think it is an excelent idea and I would love to see it happen - but I don't like the implementation details I'm seeing so far. Depending on commons-sandbox and reinventing things that are already in ant, or doing things slightly differently than ant is doing is not very good. You can add the tasks that you need in tomcat, and 'antlib' is very likely to happen for ant1.6 ( the current feeling is that ant optional tasks should be split ). > 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are > notoriously flaky). > 2. Emulate the Unix startup on Windows (Windows has no "&" background > operator like Unix and you cannot redirect stderr to an output file) > 3. Run background applications (like Tomcat 5 or GUI applications) > without a DOS shell on Windows. > 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and > one set for Unix). And also: 5. make tomcat startup easy to automate from ant ( all the test frameworks will benefit ) 6. use a well-known format ( <path>, etc ) to describe the env. 7. reuse open-source code instead of reinventing the wheel ( ant ). 8. Add extra features - like multiple profiles ( using different targets ), ability to easily execute 'pre/post' tasks ( like generating the apache config files ) And I can go on - there are many other benefits. Nobody is arguing ( at least not me ) on the benefits of the idea. > From the above list of features, you probably have noticed that the > launcher does not add any new features for Unix platforms but really > adds a lot of "fit and finish" to Tomcat on Windows. I think it adds quite a bit on both unix and windows. > So, I think the basic trade-off with using the launcher vs. scripts is > that with the launcher you get a more native looking application on > Windows at the price of losing the simplicity of scripts and adding one > more dependency to the build. I disagree ( twice )- the bat scripts are not simple, and you _don't_ have to add dependencies to the build. > My recommendation for the community would be to either use the launcher > or use scripts and not try to accomodate both. I believe that keeping > the old scripts *and* the launcher would cause a lot more maintenance > and a more confusion among users. I partially agree - the scripts are well tuned and work, so there's no reason to drop them. At least in 3.3 we did a lot of simplifications - like 'guessing' tomcat.home, etc - so a lot of stuff can be removed. > If the community chooses not to use the launcher, feel free to remove it > from the Tomcat 5 build and restore the old scripts. I'm not the 'community' - but I agree with 'choosing' :-) Make a proposal, have a vote - that's the only way to know what the community chooses. Costin > > Patrick > > Costin Manolache wrote: >> Patrick ( and all ), >> >> The 'launcher' is a very good idea - reducing the use of .bat/sh and >> having 'keepalive' functionality and a clean startup file are all >> great. >> >> My only requirement is to keep the code clean and minimise >> dependencies. >> >> My understanding of the launcher is that it uses ant file to describe >> the paths, conditions, etc. I looked at the code in sandbox - and there >> are few issues ( many tasks that duplicate existing functionality in >> ant, etc ), and some should be contributed back to ant ( like the >> enhancements to Execute ). I support the idea - as long as tomcat code >> is kept clean and this is optional. >> >> Right now we have a mess of launchers / entry points. >> >> Costin >> >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> For additional >> commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
