Bill, My desire to include ant also stems from the fact that sometimes some of us need multiple copies of ant hanging around. For example, I have an old project that MUST be built with ant 1.3 (don't ask, it's a long story). So moving in this direction would be a win. Either way, Like I've said before, you could still work like you always have. The only difference is that an extra 1MB will need to be checked out initially. Not a heavy price in my opinion.
-Pat ----- Original Message ----- From: "Bill Burton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "os-dev" <[EMAIL PROTECTED]> Sent: Tuesday, December 17, 2002 8:58 AM Subject: Re: [Opensymphony-developers] Re: [OS-webwork] OpenSymphony build process > Hello, > > Patrick Lightbody wrote: > > If we don't include ant but instead tell people to download ant, I can > > promise you that the mavenites will be clamoring for maven builds instead, > > since downloading maven or downloading ant are parallels. Besides, build.xml > > is there, you can use ant just like you always have. > > In the "old days" before Ant was the defacto standard Java build tool, > including Ant would be okay. But nowdays having Ant installed is a > requirement for any Java developer working with Open Source projects. > > Also, I don't think including Ant is going to make any difference for > those who want to use Maven. They will want to use it anyways so > including Ant is just extra space and a maintenance issue and will not > have any effect. > > If Ant is not included, there doesn't need to be a build.sh and build.bat. > > > src/java, src/test, src/etc, src/examples.... what can I say? I go both > > ways, but lately I've been happier about putting everything in subdirs in > > src. Keeps things less-flat. > > The main reason for a src/java is there can be other kinds of source > than Java :) . > > > Coding style: we need it. Live with it. It's nice. Basically, jalopy is > > REALLY cool and works very well. In this build script, any code that is > > compiled will be formatted as well. We'll immediately have the same coding > > standard in all our classes, regardless of people's choices for coding. So > > you can write your code your own way, compile, check in, and there is no > > work on your part to conform to a coding convention. We have failed in > > trying to enforce a particular coding convention on a per-project basis > > (look at the OSWorkflow sources, for example). > > Yeah. It's even a pain when some people are using hard tabs let alone > different coding styles. > > > Coverage reports and unit test reports... they should be on the website at > > least, and I tend to think along the lines of: anything on the website > > should also be in the distro. > > Rather, buildable from the distro. However, if this requires various > third party jars, they should probably not be included unless they are > few and small or maybe a key part of the build. > > > -Pat > > -Bill > > > ----- Original Message ----- > > From: "Hani Suleiman" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Cc: "os-dev" <[EMAIL PROTECTED]> > > Sent: Tuesday, December 17, 2002 8:23 AM > > Subject: [Opensymphony-developers] Re: [OS-webwork] OpenSymphony build > > process > > > > > > > >>On the whole this seems reasonable. Some reservations though: > >> > >>I really hate the src/java, src/blah structure. I'm trying to find a > >>logical reason for this hatred though but not succeeding ;) I'd like > >>src to just contain java. Maybe I'm old fashioned. > >> > >>I am vehemently opposed to build.bat and build.sh. All you need is ant. > >>I'm likewise against checking in ant to every single project. It's a > >>fairly reasonable assumption that people who might need to build a > >>project have ant installed (you don't bundle gnu make with every > >>project that has a Makefile). > >> > >>Likewise, I'm against forcing a particular coding style. the coverage > >>reports and suchlike are just eye candy really, so I'm ambivalent there. > >> > >>Also, I'm not sure there is much point in adding code coverage results > >>or test cases to a distribution. Those are aimed at end users, and huge > >>downloads full of mostly useless cruft do not encourage warm fuzzy > >>happy feelings towards fellow man/developer. > >> > >>On Tuesday, December 17, 2002, at 11:11 AM, Patrick Lightbody wrote: > >> > >> > >>>I think we should standardize the OpenSymphony build process. Here is > >>>my > >>>first cut at it, please comment: > >>> > >>>- attached is a build script for OSCore, but as you can see, it's very > >>>generic. We should use this as a base and not add much more to it, > >>>mostly > >>>instructions on how to package files like ejb-jar.xml in to the jar > >>>itself. > >>> > >>>-the directory structure of CVS would look like: > >>> > >>>project/ > >>>project/docs > >>>project/lib > >>>project/lib/build > >>>project/lib/build/jalopy > >>>project/lib/core > >>>project/lib/optional > >>>project/src/etc > >>>project/src/java > >>>project/src/test > >>>project/src/example [if needed] > >>> > >>>There would be build.bat and build.sh scripts to build the project, > >>>meaning > >>>CVS is self-contained (no ant install needed). So that means that ant > >>>and > >>>all the optional tasks would be in lib/build. > >>> > >>>- distribution structure: > >>> > >>>project.zip/ > >>>project.zip/project.jar > >>>project.zip/docs/ > >>>project.zip/docs/api > >>>project.zip/docs/clover > >>>project.zip/docs/junit > >>>project.zip/docs/lib > >>>project.zip/docs/src > >>> > >>>- if you see in the script, there would be three extra tasks built in > >>>to the > >>>build script: > >>> * jalopy (code formatting) > >>> * junit (unit tests) > >>> * clover (test coverage reports) > >>> > >>>- Documentation is assumed to be HTML right now, but pending Ken's > >>>final > >>>thoughts, this would change. Also, the junit and clover reports could > >>>be run > >>>through XSLs as well. > >>><build.xml> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > Opensymphony-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
