www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: duplicate data
Date Fri, 20 Feb 2004 23:10:44 GMT
Th issue is... the jars/distributables are placed into the 
java-repository using maven. so, currently, if you look in something 
like the commons project.properties you'll see that they are pointing to 
the central repository for the location of where to "publish" files.

######################################################################
# Apache Central Repository
######################################################################
maven.repo.central=www.apache.org
maven.repo.central.directory=/www/www.apache.org/dist/java-repository
maven.remote.group=apcvs


To publish using Maven, the only logical way I can see to resolve this 
discrepancy is to symlink from the projects dir itself, something like

.../java-repository/<project> ---> /dist/<tlp>/**<subproject>/...

The "convergence issues" we currently have for the repository:

1.) We want single copies of files on the mirrors.

2.) we want the repository to reflect the hierarchical structure of our 
projects/subprojects.

3.) Many projects already have groupId/projectIds in maven that do not 
match the hierarchical nature of the the projects at apache. Its very 
difficult to actually move these at this time due to dependency issues.

for instance

/java-repository/commons-collections

I can't identify if this is jakarta, xml or apache commons...(we all 
know from experience its jakarta commons collections.

So the issue is, which direction is the convergence going to go. I'd 
personally like to see the day when

/www/www.apache.org/dist

is the repository location and the maven project ids are something like:

jakarta/commons/collections/<artifact>/<version>/...
xml/commons/resolver/<artifact>/<version>/...
commons/.../<artifact>/<version>/...
avalon/.../<artifact>/<version>/...

which would match fairly well the directory structure of the dist 
directory, the major changes would then be

<subproject>/source
<subproject>/binary

would be replaced with

<subproject>/<artifact>/<version>/<artifact>-<version>.<ext>

or whatever we can agree upon finally for the repository url structure 
(One thats not "theoretical", but actually "used" by tools)...

So the point is, yes, we want to resolve the replication issues. My best 
conclusion is

A.) Currently just keep "jars" in the java-repository, do not keep them 
in your /dist/<project>/<binaries> directory. Remove all distributions 
form the java-repository. Currently, I haven't seen much use in actually 
releasing tarballs/zips into the Maven repository, others may have 
better opinions.

B.) If a project really wants to publish both jars and tar/zip 
distributions to the same location. Then have them have them symlnk the 
  appropriate java-repository dir into their appropriate "dist" directory.

C.) Discussion about how to finalize the directory structure such that 
"Repository", "Dist/Mirror" and "Maven" has to move forward. Refactoring 
steps and interim solutions have to be discussed and thought about.

This will probably make for a great weekend discussion,
-Mark

Noel J. Bergman wrote:

> Mark,
> 
> An issue was raised earlier today that should be addressed.  The impression
> is that java-repository is publishing copies of jars that are also under
> dist/TLP/..., which puts more of a load on the mirrors.  It might be best if
> the jars/ directories contained symlinks and not copies of artifacts
> published elsewhere.
> 
> This doesn't address the fact that at some point an artifact may exist only
> in the archives, but that would require meta-data aware clients.
> 
> 	--- Noel
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

Mime
View raw message