ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: <libraries>& cache
Date Fri, 03 Dec 2004 15:47:54 GMT
On Fri, 03 Dec 2004, Steve Loughran <> wrote:
> On Fri, 03 Dec 2004 16:01:17 +0100, Stefan Bodewig
> <> wrote:
>> On Wed, 01 Dec 2004, Steve Loughran <> wrote:
>> > 1. should we adopt a default repository, and if so, what one? the
>> > maven one? which is hooked off user.dir?
>> Probably whatever the list (that I haven't
>> ever followed) comes up with.  I have no idea whether it is alive
>> and what the result could be - I do know that there was some
>> content on the old wiki that needs to get migrated.
> its not an active list, really. 
> Actually, what I meant to say was "should we have default place on
> the local hard disk to store downloaded files",

Probably yes.

> in the maven layout.

This is where repository@ASF would come in.  In absence of any other
standard, Maven probably is the route to go.

> I know maven does this, I was just wondering where they did it.

${user.home}/.maven or something like that, I guess one can see it in
one of the Gump logs, lemme see:

     [echo] maven.home = /usr/local/gump/public/workspace/maven/bootstrap/maven.home
     [echo] maven.home.local = /home/gump/.maven
     [echo] maven.repo.local = /home/gump/.maven/repository
     [echo] +----------------------------------------------------------
     [echo] |
     [echo] |  Maven bootstrap now creates a repository in
     [echo] |  ${user.home}/.maven/repository
     [echo] |  if you do not have the maven.repo.local property set
     [echo] |  before bootstrapping.
     [echo] |
     [echo] |  Maven bootstrap also expands plugins to
     [echo] |  ${user.home}/.maven/cache
     [echo] |  if you do not have the MAVEN_HOME_LOCAL environment
     [echo] |  variable or
     [echo] |  maven.home.local property set before bootstrapping.
     [echo] |
     [echo] |  This feature is to accomodate the new ability of Maven
     [echo] |  to work from a read only install to MAVEN_HOME.
     [echo] |
     [echo] +----------------------------------------------------------

from <>.

>> > (b) <lib> in WAR/EAR must flatten filesets during copy.
>> Why?
> imagine we store stuff in a central shared repository
> <libraries pathid="compile.path" dir="store">
>  <library project="tomcat" archive="servlets" version="2.4" />
>  <makefileset filesetid="deploy.fileset"
> </libraries>
> this would download
> store/tomcat/servlets-2.4.jar
> Now, make the war
> <war ... >
>  <lib>
>   <fileset filesetref="deploy.fileset" />
>  </lib>
> </war>
> I believe this will currently pull in the servlets.jar, but include
> the path relative to the base dir of the fileset in the
> process.

Correct - if you do it that way.

> Which stops the jar being found. That is my belief, based on some
> past bug report.

I still don't think it is a bug.  I'd agree there could be an option
to flatten, but not that it should be the default.  Too much magic.

> Note that once you start signing jars (or to be precise, sealing
> them), you cannot load classes into the packages.

sealing is the problem, I don't think you need to seal a jar to sign

> I dont know what would happen if we signed ant.

Would break since ant-launcher.jar and ant.jar would try to place
classes into the same packages.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message