> : Finally, as far as getting someone to do the work, I can certainly > : volunteer to help in the following ways: > : * being RM if you are ok with a non-maven release (until LUCENE-2268 > : is fixed, i am uncomfortable with maven) > > In the past i've argued that enough users care about maven we should > really try to make sure we play nicely, but the more i think about it the > less i think it should be part of the release process.
+1 - release managers shouldn't have to be in the love-Maven camp, which seems to be mighty small here in Lucene/Solr dev-land. User-land, however, is likely a very different story. > the ASF releases source code. When we vote on a release, tha's what we > are voting on: source. We may also distribute precompiled binary jars > via the download mirrors, or via maven, but that's not what the release is > about -- so let's get hte pom template files out of hte src tree, let's > get the maven related tasks out of the build.xml file and treat publishing > to maven as a seperate process that happens *after* the release. We vote > on the release, we release it, and then the folks that care about maven > can publish the jars after the fact. If what you mean is that maven artifact production tools should not be in the Lucene/Solr source tree: -1000. Requiring these to be hosted elsewhere would very likely kill Lucene/Solr maven compatibility, and I don't think that's your intention. Maven artifact production under Lucene's/Solr's Ant build suffers from the same problem as releasing generally: lack of automation. Too much manual intervention is required to keep the .pom templates in sync, etc. LUCENE-2268 would afford confidence in the produced artifacts, but it would do nothing to address the current production process problems. Steve
