on 9/4/2000 9:28 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> 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.
i know that defining the .jar's is wrong, but there really isn't platform
specific stuff that needs to be done. look at how the TDK does java1/java2
build targets. remember, you are building turbine. i don't mind having build
targets for java1/java2 at all.
> 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.
+1
> Just curious (and not trying to start a falme war :P)
neither am i. ever. please don't assume that i am. i just don't have time
right now to fluff up my messages for you. i'm trying to get a boat load of
work done.
> 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
> ??
sure...make that happen then. :-)
>>> 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
no, it isn't. the tdk works with relative paths right now. you just have to
start tomcat while in the sandbox directory by executing ./bin/startup.sh in
order to get the paths correct. i have an email into JSR-053 (the servlet
spec private hodah that sun runs) to ask them what the proper procedure is
here.
>> 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.
no. the problem with jetspeed is that kevin hasn't done any work to make it
easy on his users to install it. that is different than categorizing ALL
apache projects based on just his project.
> 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.
then show me the documented definition of that standard and let me in on
that process.
>>> 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).
not in the current scheme because build-turbine.xml is in the build
directory. since turbine may eventually have a lot of build files, i want
them in a directory instead of at the top level root directory.
>>> 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.
i'm fine with xdocs/skins for now.
>>> 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
so? it works just fine with the way things are right now and it isn't in
that structure.
>>
>>> 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.
no, i meant having it automated.
> 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
no. automated works now.
>>> 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.
because we may have multiple build files in the future. turbine is a complex
project with potentially many different build files.
>>> 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
distributions come with the documentation pre-built and in fact, all this
documentation is already mirrored onto the website so it isn't an issue.
thanks,
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
