The assembly plugin release goes to an rsync-staging repository before it's shunted on to repo1. It usually takes a couple hours to make it all the way out into the open.
I'm sure many people have hit this plugin-versioning problem before, and I know that versioning everything is a huge pain in the ass...but, if you think you might have to build something from an old tag someday, the reproducibility is probably worth a little tedium. If you don't think so, then why tag? As a side note, I guess those who are *really* hard-core about reproducibility won't even use repo1 directly, but will opt for an internal proxy repository instead, where they can have better control over what's available. Not that we intend to cull old plugin releases, but if your business depends on it, then it's a real risk to put that control in someone else's hands... -john On 4/11/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
I would think most corporate users have run into this already.. I know we have :) I've been saying people still need to know and understand which plugins and versions they are using and why, even if Maven makes it nice and automated. Sorry for OT, but since you mentioned - what's going on with the assembly 2.2-beta-1 release? It looks like the release was made (following the dev thread and new snapshot versions), but it's not available on repo1? I'm sure at least :) a million people are waiting for a new assembly release, beta or not. Kalle On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > I wanted to send out a quick email to let everyone know about some > discussion that's been taking place on the developers' list regarding > plugin > versions. In trying to release the 2.2-beta-1 version of the assembly > plugin, it became apparent that this version fixes some bugs in the > 2.1version that don't necessarily look like bugs. All discussion about > what is > or is not a bug aside, the discussion raises an interesting point: if you > do > not specify a version for the plugins in your POMs, a situation can arise > where Maven will seamlessly resolve an incompatible plugin version and try > to use it. > > Here's an example: > > Say I create a project that uses the assembly plugin, version 2.1. My > assembly descriptor takes advantage of a bug in this version where the > explicit inclusion of a .tar.gz dependency does not have its own > transitive > dependencies included, unless they too are explicitly included. This is > incorrect, because there is no ArtifactHandler that specifies that the > .tar.gz file contains its own dependencies (so, therefore, should not have > its transitive dependencies resolved, much less factored into > inclusion/exclusion)...also, from a semantics point of view, Maven's other > dependency usages indicate that specifying a dependency implies that > you're > specifying that dependency's transitive dependencies...the whole sub-graph > should be handled, in other words. > > Having created this project with its assembly descriptor, but WITHOUT A > VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some > time later, after the next version of the assembly plugin fixes this bug, > a > user comes along. He installs Maven, checks out my project, and tries to > build. Without a single line of code changing in my project, the build > fails, because his Maven instance resolved the plugin to the newer > version. > I cannot replicate his failed build, because my assembly-plugin version > had > not been updated (I didn't use -U during the build). > > > You can say that the next version should make an effort to support users > exploiting bugs like this, and you can say that plugins need to deprecate > and gradually move away from behavior that has turned out to be bad > design, > counter-intuitive, etc. To this extent, you could argue that the next > release that "fixed" the bug above should have made an allowance for this > scenario. > > However, consider what happens if the plugin has been released several > times...say that the newest version is actually 3.1 now. In this scenario, > it's entirely reasonable to think that the developers have provided a long > migration period - along with deprecation warnings - that spanned multiple > versions, and then finally dropped the support for this broken > configuration. However, Maven has no idea of any of this, and the > aforementioned setup will break. > > All of this can be avoided by simply being careful about evaluating, then > migrating, to new plugin versions in a very deliberate fashion. If you > take > a look at the world of systems administration, you see this sort of thing > everywhere. People take enough time to pour over release notes and > determine > whether the new version is likely to wreck the existing setup. The same > should go for building a reproducible build infrastructure. > > I'm going to start a discussion on the developers' for getting rid of the > plugin-version auto-resolver in Maven 2.1 immediately, to start pushing > the > tools down this path. However, it will make everyone's lives easier to > start > the process now. Please, take a moment and put the plugin versions into > your > POMs. > > Thanks, > > John >
