ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Ivy talk at ApacheCon Europe 2007?
Date Thu, 11 Jan 2007 12:29:08 GMT
Gilles Scokart wrote:
 > Steve,
 >
 > Thanks to share that.
 >
 > I'm curious.
 > - Did you consider setting up your own repository to eliminate the proxy
 > issue for the developers?

-We're an open source project; cannot hard code in links to anyone's 
private repository. Also I work from home a lot and that linux box is 
not in the work network, nor is gump, etc. For the same reason I cannot 
even hard code proxy settings into the build file via the <setproxy> task.

-in our new centrally managed IT world, any service infrastructure that 
has not been signed off by IT is a no-no

-we do secretly have a full 9GB rsync cache of the ibiblio repo for 
"research purposes", but I cannot hard code links to it in ivy.xml files 
that have to let outsiders build. Took a couple of days to load down, 
even outside term time when our connection to superjanet runs faster as 
the students are sharing less DVDs.


 > - Why did you publish the test jars?

Its just a proposal, with the rationale being:

1. The smartfrog runtime can dynamically load in JAR files given the 
URLs. you host the daemons on your machines and then deploy things with 
classpath URL lists that refer to file: or http: URLs. As I'm moving 
over to running junit tests under smartfrog, jarring the test files lets 
me deploy them.

2, When you are running smartfrog in secure mode, it only loads classes 
and resources from signed JARs.

We also have components that when 'deployed' will force an (async) 
download of any artifact from the remote repositories, and add a 
property on themselves to declare the local path (and file: URL) to the 
artifact. This lets you do late binding to things like a database, 
pulling in mysql on demand:

mysql5.jar extends JarArtifact {
     project "mysql";
     artifact "mysql-connector-java";
     version "5.0.4";
     sha1 "ce259b62d08cce86a68a8f17f5f9c8218371b235";
}


There's no transitive dependency logic; you get exactly what you ask 
for, with the SHA1 and md5 checksums tested too. Right now I have policy 
components to provide the maven2 and maven2 naming schemese, but I can 
add ivy ones too. That will let me load test artifacts that way too.

-steve



Mime
View raw message