On Sat, 25 Jun 2005, Oliver Rossmueller wrote:
Martin Cooper wrote:
On Fri, 24 Jun 2005, Oliver Rossmueller wrote:
Martin Cooper wrote:
I would strongly recommend that you not store your dependencies in the
SVN repo. Consider the consequences if every ASF project did the same
thing. There would be many dozens of copies of the exact same
libraries taking up space in the repo, one (or more) per project. The
repo would end up being clogged with binaries, many of them duplicates.
Martin,
if saving hard disk space is the main argument, than it's -1 again. Of
course you end up with duplicates of the same jar in different projects
in the repository, but that's not the point. The point is simplicity of
the build process so it can be handled by any developer and not only the
MyFaces core team.
This is one reason that the ASF Java repo was created - so that there
is one place that libraries can be placed, so that they are available
to any project that needs them. This is a parallel to the Maven
repository at ibiblio, but neither of these require that Maven be used
for the builds.
Also, as Sean points out, if you prefer not to make use of automatic
downloads, you are free to configure your system that way. But for
many, if not most, people, the automatic downloads give them a way to
get up and running much more quickly than a manual configuration.
Of course I can configure anything manually, and I am also able to deal
with problems caused by failed automatic downloads. But that's because I
know how the build works. Consider somebody who just got the sources
from svn. The first step then would be to check for the existence of
build.xml and to run 'ant'. Now that first and straightforward attempt
fails because the default ant target does not download required jars or
the default target does download the jars but download fails for
whatever reason. From the POV of named user what would you do? I would
throw MyFaces to the trash can and don't have a look at it for at least
half a year as those MyFaces guys seem to be not able to handle their
build process so how good and stable can their software be?
You don't have much patience, do you? ;-) Personally, I would look for
an answer before just throwing it in the trash, and I suspect most
people would do the same.
Well, there is the JSF RI I can get from Sun without any problems, so
why would I care for fixing a broken MyFaces build if I just want to
give it a try? If the first impression you get from an open-source
product is a broken build what will you think? To provide convidence
does look different.
If all I cared about was *using* JSF, why would I be trying to *build*
MyFaces at all? If I'm trying to build MyFaces, it's probably because I'm
interested in helping develop it. If I'm interested enough to grab the
source, I honestly don't think I'm going to give up the very first time
something doesn't go as smoothly as silk. I think you need to give
potential developers a bit more credit that you seem prepared to give
them.
That's my point: ease of build for anybody. It should not be necessary
to be an ant and subversion guru to handle the build.
Come on, Oliver, nobody has said anything about needing to be an Ant
or SVN guru. Unless you count typing 'ant' as being an Ant guru. ;-)
OK, so what do you do when not all your dependencies have licenses
that allow you to store them in the SVN repo? All it takes is one.
That will immediately and permanently break your nice clean "pull
everything from the repo and go" model.
That's the first argument so far that makes kind of sense. But do we
have this problem the moment? As far as I know that's not the case. So
why are we trying to fix a problem that does not exist?
I haven't looked at the dependencies to see if you have the problem right
now. However, I would emphasise that it is *very* easy to get into this
type of scenario. So basing your build system on the hope that you're
never going to hit this is building on very shaky ground, at best.
--
Martin Cooper
Oliver
--
Martin Cooper
Oliver
--
Martin Cooper
On Thu, 23 Jun 2005, 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
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
