On Wed, May 08, 2002 at 01:00:33AM +1000, [EMAIL PROTECTED] wrote: > Guys, I know we've thrashed this out in IRC, but how about a compromise? > > -dev being an unsafe, unspecified development pre-release > -YYYYMMDD being an unsafe, specified development pre-release. > > Neither of these are maven's responsibility to keep up to date, e.g. your > idea of 20020507 is very different to mine,and it's up to us to > upload/update them when we see fit. No guarantees of new builds every > night for example.
Sounds fine to me, as long as maven:update-jars does not happen automatically. I don't think Maven should hit the net upon every invocation of an Ant target. Thus, in summary (a recap for those confused by this thread as part of the conversation was held on IRC): Maven automatically checks your lib.repo for all of the dependencies listed in the project descriptor (project.xml) upon every invocation. If any of these deps is not present in your lib.repo, Maven will fetch the missing deps from one or more of the remote repositories (specified by the maven.repo.remote property). The default repository is http://jakarta.apache.org/turbine/jars. This works well for uniquely identified JARs (deps). Unfortunately, for the development JARs this poses a problem because traditionally all of the dev JARs were named in this format: project-dev.jar. This does not provide any indication of the current version of the dev JAR. Why is this a problem? Lets pretend you have this deps in your project descriptor: <dependency> <name>some-project</name> <type>required</type> <version>dev</version> <jar>some-project-dev.jar</jar> <url>http://jakarta.apache.org/some-project/</url> </dependency> Also assume that your lib.repo already contains some-project-dev.jar. Now, lets pretend now that someone updates the some-project-dev.jar in the remote repository. Maven will _not_ automatically update this JAR because it is already located in your lib.repo. To address this issue, it was suggested that all dev JARs be uniquely identified (perhaps using a timestamp). Thus, as a project maintainer, you chose when to use a new dependency. If a new dev JAR is available, you would simply update the descriptor, for example: <dependency> <name>some-project</name> <type>required</type> <version>20020507</version> <jar>some-project-20020507.jar</jar> <url>http://jakarta.apache.org/some-project/</url> </dependency> Thus as project owner, you do not have to worry about someone else's change breaking your build. You have control. Note: Gump alleviates some of this pain (as will Maven will it does CI), but as a project maintainer, most people want a stable build all the time, rather than risking some 3rd party that uploads a JAR to screw up one's build. However, with that said, there are some that prefer to live on the edge and always use the most recent "-dev" JARs (no timestamps and have the risk of being udpated arbitrarily with non-compatible changes that haven't been fixed yet). In this case, Kurt is going to restore the "maven:update-jars" target. This target, when invoked (it does not happen automatically), will check the timestamps on the deps in your local repository with those in the remote repository and download any updated JARs. Thus enabling those that want to use the regular "-dev" JARs to do so. Hope this helps, Pete -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
