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.
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. 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). 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. -Pat ----- 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
