On Mon, 4 Sep 2000, Jon Stevens wrote:
> yes, you should have coordinated your efforts with the list first in order
> to avoid duplication of effort. :-(
yup :<
> -1 on having an "optional" directory. There are other ways to do the same
> thing without the optional directory.
yep - but they involve platform specific shell scripting or
adding 1 entry per jar in build.xml. This is fine for a
small number of jars but as number increases or gets large
you end up doing too much maintaining of it. This way you
never have to alter classpath stuff - you just drop it in
lib/. The exception is when there are different versions for
different VMs etc.
> > The current turbine build file only allows per user
> > .ant.properties - I added a per project .ant.properties
> > aswell.
>
> per project? what do you mean?
The current turbine file grabs it from a users home
directory which can be considered *global* ant
properties. All my projects using ant read them and they
include things like compilers/log formatting etc.
Then there is per project ant.properties that are specific
to that particular project (like turbine) where users can
overide destination for dist/webapp targets etc.
> > I redid the webapp target so that it creates a valid webapp
> > and is off and running - with a line in .ant.properties
> > (webapp.dir=/path/to/my/tomcat/webapp/myturbineapp) it is
> > even *installed* in the correct place. The only thing you have to
> > do is
>
> ok, this stuff is outdated and should actually be removed. I want this stuff
> to live in the TDK instead.
Just curious (and not trying to start a falme war :P) why
seperate the two ? What advantage does it have. A simpler
turbine build helps everyone and TDK includes masses of
other junk IIRC like tomcat etc
Couldn't TDK just call turbines build file but do massaging
of properties passed into ant ? That would help both camps -
those who want to use TDK to run turbine and those who don't
??
> > 1> set up database
> > 2> edit proeprties files of both webmacro and turbine to
> > point log to correct place
>
> -1. this should be relative. the tdk manages to do this right by requiring
> people to start tomcat while they are in the sandbox directory.
I agree :P but it is how turbine works now :P
> actually, it is currently set as webappdir/logs in the TDK and there is a
> security rule in the web.xml file that prevents unauthorized access. the
> reason for putting it into webappdir/logs is that some automated tools will
> pull a log file off over http and analyze it.
sounds good.
> > deprecation=false
> > database.jar=mysql.jar
> > database.lib.dir=/RHI/lib
> > jsdk.jar=/RHI/tomcat/lib/servlet.jar
> > webmacro.jar=webmacro-jdk1.2-CVS.jar
>
> can we include a default .ant.props with relative paths to the directory
> above turbine?
>
> ie:
>
> jsdk.jar=../../jsdk/jsdk.jar
yep
> it is funny because i invented most of the directory structures that are
> used today because i was one of the first people to actually use Ant and i
> actually don't like a lot of the ways that things were changed.
perhaps but I am not proposing things to make it easier for
you but more for your users. I know of at least one group
when playing with jetspeed who classified codebase as messy
and didn't adopt it because it was following the semi-Apache
standard.
Following a standard decreases learning curve and increases
chance that it will be adopted. I am trying to push turbine
at people and they are much more likely to bite if a
standard is adopted.
> > build/ (directory for files generated from build)
> > build/classes (directory for compiled class files)
> > build/src (directory for java src after copy and filtering)
> > build/lib (directory for generated and supplied libs)
>
> -1. I really think bin/ is better. it is more easily removed. i can go for
> another name than bin/, but i want it to be top level.
build can be as easily removed as bin :P (ie rm -rf build
works fine :P).
> > conf/ (directory for configuration files)
> > src/java (directory for java src)
> > src/xdocs (directory for xml docs src)
> > src/sql (directory for sql src)
> > src/sh (directory for any scripts used in distribution but not in
> > build)
> > src/mf (directory for manfiests - if any)
> > src/mk (directory for extra ant build.xml files - ie unit
> > testing/profiling)
> > skins/ (directory to hold skins for xdocs)
>
> i would prefer xdocs/skins
that makes more sense - or perhaps src/skins ??? not sure
thou skins is standard place to put it.
> > bin/ (directory for ant build scripts/other scripts used while
> > building)
>
> i would prefer build/bin/
the problem is that the way ant is laid out it expects a
structure like
$ANT_HOME/bin/ant[sh|.bat]
$ANT_HOME/bin/antRun[|.bat]
$ANT_HOME/lib/ant.jar
$ANT_HOME/lib/xerces.jar
$ANT_HOME/lib/<other support libs>.jar
>
> > lib/ (all jars used in project)
> > lib/optional (all jars that have different version ie freemarker/webmacro)
>
> this is easy enough to deal with by simply removing the .jar files that you
> don't want at a later time in the build process.
but that requires thought and understanding by user. It is
much better to automate it so that no one has to think about
it after pulling it out of CVS.
What happens when you update from CVS - you have to again go
remove jars willy-nilly and if multiple people are working
on same project and an error pops up. One of the potentially
naive developers may stuff it up for the rest of us :P
> > build.[sh|bat] (convenience script to wrap ant script)
> > build.xml (turbine build script)
>
> i like what we currently have and i like the name of the project to be in
> there. it helps avoid confusion.
what confusion ? I would say this increases confusion. You
do not have commands like "make-turbine" you have
"make". Just like in ant world you don't have
"build-turbine" you have "build". (same reasoning make files
are Makefile by default, ant files are build.xml by
default).
Being an exception to the rule does not decrease confusion
it increases confusion.
> > README
> > INSTALL
> > TODO
>
> these should be stylebook documentation.
The problem is they often don't know how to creat
documentation. README can be as simple as a direction to
type "./build docs" and look in docs.new/index.html
INSTALL can be a basic install guide or else a direction on
how to build docs and redirection to apropriate docs.
TODO should definetly be stylebook thou.
Cheers,
Pete
*--------------------------------------------------*
| Latrobe University, | Does the name 'Pavlov' |
| Bundoora, Australia | ring a bell ? |
*--------------------------------------------------*
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
