>> Despite issues anyone may have with Maven, why not use ibiblio for it? 
>> Instead of YAPTG (yet another place to go)?

                                                        <!--            @page { 
size: 8.5in 11in; margin: 0.79in }              P { margin-bottom: 0.08in }     
-->If ibiblio can be that place then we do not need YAPTG!  There are issues 
with ibiblio maven2 repository:
 - Ever tried to put artifacts into ibiblio?
 - There is nobody interested in the repository itself as client agnostic 
provider of artifacts. There is too much Maven agenda behind the repository at 
mu taste;
 - The repository is dirty: incomplete metadata, unknown artifact origins, 
incorrect dependencies info, etc.
 - The current Maven repository is incomplete;
 Personally I would be happy if we in Java community had a repository that we 
would be able to use daily like this: 
http://area51.sourcelabs.com/cjar/info/about/cjar_everyday_use.png
 I do not care much if it is iBiblio, area51, repo.sun.com, I just badly want 
this thing to be available for Java community.
 
 
Konstantin Ignatyev



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

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

There are reasons why I'll never see that methodology in some places,
but let's stick to where it can work: Despite issues anyone may have
with Maven, why not use ibiblio for it? Instead of YAPTG (yet another
place to go)?

I'm still in favor of getting more of the commonly requested services
packaged together. Some I believe would be nice in Tapestry (not core,
but as contrib is today), some less so. I just think we need to start
getting the "componentization" (what Tapestry preaches) back into
services as well as into presentation.

Konstantin Ignatyev 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

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

iD8DBQFEa0xDaCoPKRow/gARAqr+AJ4ttVE9hLKCT0QOMPjbmwRcUBT8XwCfaKIa
N6LlPaDUiPbjsVFx9my9xgE=
=Qrex
-----END PGP SIGNATURE-----

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




Reply via email to