.. Could we maybe just make the email, defaultDownloadService, etc. jarfiles
first, and worry about provisioning later ? :)

Cheers,
PS

On 5/17/06, Konstantin Ignatyev <[EMAIL PROTECTED]> wrote:

                                                                <!--            
@page
{ size: 8.5in 11in; margin: 0.79in }              P { margin-bottom:
0.08in }     -->       Those are valid concerns Brian. There are my
thoughts on that:
- Network is unavailable: dependency manager should maintain a local cache
of already downloaded artifacts to avoid unnecessary network trips.  Maven
dependencies resolver already has that but they have bad update policy IMO
that requires rechecking with repository at least once a day. Unnecessary
IMO and bad by design because this way they try to implement auto updates
based on version ranges in the dependencies: very bad idea because it leads
to the build unpredictability by design!
- Server is unavailable: there should be network of servers. It is very
common approach and works remarkably well (Gentoo, Ubuntoo, and other
GNU-Linux distros);
   - Speed of operations and network outages: for serious use company or
person should be able easily install a local copy of the repository within
own network that will allow (semi-)independent operation and provide place
for artifacts we or they cannot place on the public servers. Examples of
those:
     - SUNs j2ee interface jars cannot be placed in the repository because
of licensing limitations;
     - Company's private assets have no place in the public repositories
too;

All the above makes me believe that 'one download' concept should an can
be retired. The repository seed can be made downloadable as DVD image - that
would make sense IMO.

Konstantin Ignatyev



----- Original Message ----
From: Brian K. Wallace <[EMAIL PROTECTED]>
To: Tapestry users <users@tapestry.apache.org>
Sent: Wednesday, May 17, 2006 8:45:49 AM
Subject: Re: Tapestry to generate mails ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The "dependencies will be downloaded" from a "central repository" is
Maven 101. The problem I ran into was "this is your build machine. it
has NO connectivity outside this room". Corner case? Oh, yeah... but it
shows where the "Maven 101" logic falls short (dreadfully short).

Add to that - I am currently trying to build my Eclipse environment from
scratch (yes, again - this makes 4 Eclipse installs all for different
reasons/versions) and lo and behold - I cannot get the Maven plugin.
Why? Codehaus is down. Corner case? Not at all. Blue Security (one
example) took down sites recently (wanna piss of some spammers?).
Servers go down. Connections drop. And the impact of this spreads
exponentially as the "dependencies will be downloaded" concept grows.

Good idea, but I don't believe "retired" is a good word to use. Possibly
"used in addition to"?

My .02

Konstantin Ignatyev wrote:
>   Well, I think that the "one download" concept should be retired and we
can do better than that old fashioned rigid approach. IMO it should work
like this: a tiny project that defines     configuration and dependencies
has to be created and uploaded to the     central repository;
>      when somebody will want to use     the project then all the
dependencies will be downloaded from the     repository;
>      then if that someone will want     to add to more components to the
project it would be simple matter     of adding one line to the dependencies
section of the Ant's     build.xml or Maven's POM file (it works today) or
choosing new     dependency in an IDE (available in Eclipse with Maven
plugin).
>   That is why I have created the CJAR project, I want it to become THE
repository for Java community so we all can easily assemble our applications
in the way we want. There are some ideas on how to allow people to upload
libraries and components, please have a glance and send your thoughts.
> Common repositories serve well in other communities and I think we
should get one too.
>
> Konstantin Ignatyev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFEa0UsaCoPKRow/gARAvZTAJ9s3E64Q5uo7E+S0MdHKmPbPS6OEACeNle3
LjZ1OYGU9ryEldveC/5+dG8=
=ld62
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






Reply via email to