> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Monday, July 07, 2003 1:16 PM > To: Maven Developers List > Subject: Re: Artifact managment - deploy & fetch > > On Mon, 2003-07-07 at 04:13, Michal Maczka wrote: > > I hope to find time today (latest tomorrow) and finish reaming issues of > > artifact deployer. > > > > > > I have some issues I want to discuss: > > > > 1) > > When artifacts are big (few MB) frequent deployment of snapshots to > > repository (local or remote) results in MB of unused space, > > as snapshot == latest version (we don't need older versions of the > snapshots > > anymore) > > Yes we do. You can never know which timestamped version someone might be > dependending on. You can't just remove them. > > > I suppose that in case of snapshot it wouldn't be so bad > > if during deployment we will delete an older version of the artifact > > If you mean the removal of timestamped JARs that have been deployed then > most definitely -1. You can't remove them.
Yeap. I see the problem. I realized that it is not so easy, if at all possible. However I see that there is a certain problem there: I have 5 MB large wars. After 20 deployments of snapshots 100 MB of space in repository gets eaten. 20 deployments = 3/4 days. Currently when we deploy snapshot - we also deploy a time-stamped file. In most of the cases (I am speaking about company-wide remote repository, not about repositories like IBiblio) most of this files become obsolete once new snapshot is replacing an old one. And those files are taking up a lot of space. We need timestamped jars(artifacts) when we want to resolve real versions of snapshots and when we need to convert them to immutable dependencies (e.g while making the release) But for example for "intranet reposositories" we can imagine that those timestamped version will appear in repository only when we will start to need it. So I dare to say that: artifact:deploy-snapshot != artifact:deploy-timestamped-file So we can imagine that when other project needs to convert a snapshot version of artifact delivered by other project to immutable, timestamped artifact - that this project will be responsible to upload timestamped version of the other artifact to remote repository. That is just immature idea. What I really want is to "save my disk space" :) There are maybe better possibilities. > > 2) > > I think it will be nice to start using POMs as descriptor of the > artifact. > > Yes, I often use them just not a widely known feature. > > > E.g I would prefer to retrieve information about artifact URL from the > POM > > of this artifact rather then do: > > > > <dependency> > > <id>xerces</id> > > <version>2.2.1</version> > > ><url>http://xml.apache.org/xerces2-j/</url > > </dependency> > > Sorry, not sure what you mean here? You mean looking up the POM to find > it's URL and other information about the artifact? In that case, yes, > definitely. > That's what I meat. I think only artifact's own POM should be used for providing metadata information about this artifact. We should avoid using things like: <url>http://xml.apache.org/xerces2-j/</url> So e.g the the report like: http://maven.apache.org/dependencies.html can contain much more information (e.g. short description about each artifact) > > What about deploying (installing) also the POM to the repository, every > time > > The POM really only needs to be deployed for releases. I'm not sure it > would be wise to start deploying snapshot POMs though I haven't thought > about it much. > Between two deployments of snapshot something might get added/changed in the POM. It is even often the case. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
