Stephen you can publish the artifact to your repo under a different name, right? IIRC Maven will take care of the pom change along the way. Yes you would not ever want to mess with changing an artifact after it's published.
http://maven.apache.org/plugins/maven-install-plugin/examples/specific-local-repo.html That's how I thought people did this, if they needed to do more than test a tarball. On Mon, Nov 24, 2014 at 3:54 AM, Stephen Haberman <stephen.haber...@gmail.com> wrote: > Hi, > > I wanted to try 1.1.1-rc2 because we're running into SPARK-3633, but > the"rc" releases not being tagged with "-rcX" means the pre-built artifacts > are basically useless to me. > > (Pedantically, to test a release, I have to upload it into our internal > repo, to compile jobs, start clusters, etc. Invariably when an rcX artifact > ends up not being final, then I'm screwed, because I would have to clear > the local cache of any of our machines, dev/Jenkins/etc., that ever > downloaded the "formerly known as 1.1.1 but not really" rc artifacts.) > > What's frustrating is that I know other Apache projects do rc releases, and > even get them into Maven central, e.g.: > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.tapestry%22%20AND%20a%3A%22tapestry-ioc%22 > > So, I apologize for the distraction from getting real work done, but > perhaps you guys could find a creative way to work around the > well-intentioned mandate on artifact voting? > > (E.g. perhaps have multiple votes, one for each successive rc (with -rcX > suffix), then, once blessed, another one on the actually-final/no-rcX > artifact (built from the last rc's tag); or publish no-rcX artifacts for > official voting, as today, but then, at the same time, add -rcX artifacts > to Maven central for non-binding/3rd party testing, etc.) > > Thanks, > Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
