I like simple, so I'm inclined to vote with Oliver.
I really like the new structure BTW, thanks again Sean for all the
work you have put into making this happen!
I've grabbed the new layout and started to make it work in Eclipse
and here is what I've found.
1) Digester has removed the RSS classes from their standard build, so
we either have to do a custom build of Digester or we have to have
version 1.5 (which is what was in the lib dir)
2) Validator does not have the ISBN validator in its current release
build (1.1.4), this class is in the 1.2 branch (which might be head,
I did not dig into it). So we have to have the latest nightly (which
is currently hosed on the apache servers at 45 bytes) or build it
ourselves from their repo.
So this points to the simplicity factor that Oliver argues. In order
for us to have an auto download from ibiblio we will have to make our
code depended on one of the released versions of these libraries. If
we have the jar files in a repo (probably linked in with
svn:externals?) then we have the ability to put in a dev version of
some dependency jar.
In addition, we should probably have a way to ensure that these
dependencies on non-released versions of libraries are more
explicitly called out and I guess going to ibibilo would help us in
that regard.
Regardless of which way we go we should probably have some way of
quickly distinguishing 'dev' versions of what we are using. If we do
go back to a lib directory in subversion we should name the validator
jar with a version so that its obvious its not a released version.
Are there further benefits to having the lib not be part of the repo
besides download/update times that I'm missing?
Thanks again Sean!
-bd-
On Jun 22, 2005, at 6:18 PM, Oliver Rossmueller wrote:
-1 on that. Please don't make the build more complex than needed. Not
any stuff that seems to be cool to implement should be implemented.
What's your problem with having the required libs in the
repository? For
me there are advantages only:
- one source fits it all: you check out the svn module and have
everything you need to build
- the libs are versioned with the code which depends on the libs
- you have everything maintained in one place, the svn repository; no
need for external jar repositories or stuff like that
- no build is blocked because the download of a required lib is not
working for whatever reason (firewalls, network failures, ...)
If you ever had the html of a http 500 page as the contents of a jar
file in your maven repository instead of the required jar itself you
know what I'm talking about. So do not try to imitate maven just by
other means but follow the KISS principle and keep it simple, please.
Oliver
Manfred Geiler wrote:
yes, looks good
+1 for automatic download of jars
-Manfred
2005/6/21, Sean Schofield <[EMAIL PROTECTED]>:
First off, thanks to James Mitchell (of the Struts team) who has
been
teaching me the wonders of svn:externals. I hope my SVN reorg will
make him proud. :-)
While James and I were discussing the Struts layout he also
mentioned
something interesting. They no longer keep any jar files in their
repository. He has figured out a way to deal with the jar file
dependencies that does *not* require Maven (ie. can be done from
Ant.)
I'm planning on doing something similar as part of the reorg. Check
out the following steps that allow you to build struts 1.2 without
specifying a single jar file in your properties ...
$svn co https://svn.apache.org/repos/asf/struts/core/branches/
STRUTS_1_2_BRANCH/
struts-1.2
$cd struts-1.2
$ant download-dependencies release
Nice! I see no reason to deprive ourselves of the same cool build
process ;-) Also, its possible to build using local jar files if
that
is your cup of tea (just don't run the download-dependencies target
and specify the jar file locations in your local props file.)
sean
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
