Re: Enterprise Users may not trust availablity of Internet for repeatable builds.

[Nick Chalko]

Adam R. B. Jack wrote:
 

Any other ideas ?
   

So a local repository that isn't version controlled isn't good enough? Why
don't we just download to a local one?
 

As long as it is on a backup schedule that would be fine. 
Using CVS  is my lazy way to get backups.

It may be a loosing battle. 

Perhaps in situation like this it is better for each project just to 
check needed jars in to its own ./lib dir.
Perhaps we should have depot support the update of a local  ./lib dir.

R,
Nick

Re: Enterprise Users may not trust availablity of Internet for repeatable builds.

[Adam R. B. Jack]

> "I found its [Maven] insistence on connecting to an Internet repository
> offensive; in a production environment it has a snowflakes chance in
> hell of automated downloading of anything from the Internet."

So don't do builds in productions. ;-) ;-)

FWIIW: Gump seems to manage to automatically download stuff pretty often. :)

> Enterprise users trust there own CVS so perhaps a CVS backed local cache
> would handle the concerns

I think SVN is a good fit with Depot, heck -- I'd like to follow their lead
on lots of things (from security to command line to ...). I wonder if we
could integrate as an SVN client (better than pyeclipse does, I hope) from
Java.


> Any other ideas ?

So a local repository that isn't version controlled isn't good enough? Why
don't we just download to a local one?

regards,

Adam

Enterprise Users may not trust availablity of Internet for repeatable builds.

[Nick Chalko]

Scot Mcphee says in
http://jroller.com/page/scotartt/20040225#maven_too_hard
"I found its [Maven] insistence on connecting to an Internet repository 
offensive; in a production environment it has a snowflakes chance in 
hell of automated downloading of anything from the Internet."

I have faced the same issue at work. 
I would like to support tools reduce this fear. 
Enterprise users trust there own CVS so perhaps a CVS backed local cache 
would handle the concerns

ie check in your local.repository, so it is "always available".
Any other ideas ?
R,
Nick