Hi Sean,
I wish I'd checked and seen your response before sending... I started
my email last night and finished this morning without checking the
mail box...
On Jun 23, 2005, at 6:09 AM, Sean Schofield wrote:
Keep in mind that the 'download-dependencies' target need only be
called once. Actually, it need never be called if you want to get the
jars through your own methods. As you will see in the Struts build
process, you can set up your properties file to use your local copy of
the jar files at any point you wish. So you won't be prevented from
building if there is a problem with the Maven repository.
Only having to do it once (download-dependencies) is a good thing but
has the potential of issues with custom build jars such as the two
outlined in my previous email below.
I also really like having each dependency being a property in the
build process so that we can all point to our own local copies of the
jar files. However that requires greater discipline on our part to
not use 'unreleased' stuff like IDBNValidator and the RSSDigester.
Which IMO would be a good thing, but it keeps us from offering
features, which many will see as a bad thing.
Its bad practice to keep the jar files in SVN if you have a reasonable
alternative. A spot check of existing Apache projects reveals that
none of them store jar files in SVN. This includes Struts and Jakarta
Commons. IMO its time for MyFaces to adopt this practice as well.
The download-dependencies target is just an elegant solution used by
Struts to help the user get those jars.
Well, I partially agree. In most of my 'real job' work we keep open
source code and jars in a repo so that we can always have a 'working'
copy of the project in case one of the dependent OSS projects goes
off on a path the 'real job' project can't follow. In fact the svn
folks have a really cool tool to help you keep your dependent code up
to date (svn_load_dirs.pl). I'm not suggesting that we (MyFaces) be
so stringent in our approach but keeping the jars (esp the custom
built ones) in our repo is not all together bad.
In an ideal world though I'd buy into what you are suggesting if we
could keep from using any unreleased code and we had as part of our
auto build a way to build against the nightlies of the other projects
we depended on. That would allow us early warning that we are no
longer compatible with a 'soon' to be released version of something
(like in the case of digester).
Anyway, thanks again for all your hard work.
TTFN,
-bd-
On Jun 23, 2005, at 6:14 AM, Bill Dudney wrote:
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
