[
https://issues.apache.org/jira/browse/LUCENE-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550551#comment-13550551
]
Steve Rowe edited comment on LUCENE-4134 at 1/10/13 11:06 PM:
--------------------------------------------------------------
bq. personally i would prefer if we don't have a separate script for changing
the maven files. I'm not really sure what this tester is currently doing.
s/changing/checking/ ?
Here's what the maven artifact checking portion of the smoke tester currently
does:
# Downloads the POM templates from the branch tag in Subversion (for later
checking that all checked-in POM templates have corresponding artifacts)
# Downloads all the files under the {{maven/}} directories at the RC location
# Verifies that there is a deployed POM for each binary jar/war
# Verifies there is a binary jar for each POM template
# Verifies that the md5/sha1 digests for each Maven jar/war exist and are
correct
# Verifies there is a source and javadocs jar for each binary jar
# Verifies that each deployed POM's artifactId/groupId (pulled from the POM)
matches the POM's dir+filename
# Verifies that there is the binary jar for each deployed POM
# Downloads and unpacks the official distributions, and also unpacks the Solr
war
# Verifies that the Maven binary artifacts have same-named files (after adding
"apache-" to the Maven Solr jars/war)
These are a couple of additional steps in there to handle non-Mavenized
dependencies, which we don't have any of anymore; these steps could be removed.
bq. Its scary to me that different build systems are producing different
artifacts
*All* the Maven artifacts are produced by Ant, not by Maven and not by
maven-ant-tasks.
bq. And i know the checking isn't good enough when i see basic shit like things
not even named the same way: SOLR-4287
maven-ant-tasks renames the Solr artifacts based on the Maven jar naming
convention: artifactId-version(-type).jar - groupId org.apache.solr is not
included. This has been the Solr Maven artifact naming scheme since Solr
artifacts started being published on the Maven central repository (v1.3).
Using the Solr naming convention would result in the coordinates
{{org.apache.solr.apache-solr.\*}}, or maybe even
{{org.apache.apache-solr:apache-solr.\*}}, both of which look goofy to me.
I *think* Maven can technically handle artifact naming schemes that differ from
artifactId-version(-type).jar, but I've never done that before, and I
personally don't think it's worth the effort, especially given the IMHO goofy
result. Before SOLR-4287, I haven't seen anybody complain. (If you look at
SOLR-4287, by the way, the suggestion isn't to change Maven naming, it's to
change the official Solr artifact naming.)
was (Author: steve_rowe):
bq. personally i would prefer if we don't have a separate script for
changing the maven files.
I'm not really sure what this tester is currently doing.
s/changing/checking/ ?
Here's what the maven artifact checking portion of the smoke tester currently
does:
# Downloads the POM templates from the branch tag in Subversion (for later
checking that all checked-in POM templates have corresponding artifacts)
# Downloads all the files under the {{maven/}} directories at the RC location
# Verifies that there is a deployed POM for each binary jar/war
# Verifies there is a binary jar for each POM template
# Verifies that the md5/sha1 digests for each Maven jar/war exist and are
correct
# Verifies there is a source and javadocs jar for each binary jar
# Verifies that each deployed POM's artifactId/groupId (pulled from the POM)
matches the POM's dir+filename
# Verifies that there is the binary jar for each deployed POM
# Downloads and unpacks the official distributions, and also unpacks the Solr
war
# Verifies that the Maven binary artifacts have same-named files (after adding
"apache-" to the Maven Solr jars/war)
These are a couple of additional steps in there to handle non-Mavenized
dependencies, which we don't have any of anymore; these steps could be removed.
bq. Its scary to me that different build systems are producing different
artifacts
*All* the Maven artifacts are produced by Ant, not by Maven and not by
maven-ant-tasks.
bq. And i know the checking isn't good enough when i see basic shit like things
not even named
the same way: SOLR-4287
maven-ant-tasks renames the Solr artifacts based on the Maven jar naming
convention: artifactId-version(-type).jar - groupId org.apache.solr is not
included. This has been the Solr Maven artifact naming scheme since Solr
artifacts started being published on the Maven central repository (v1.3).
Using the Solr naming convention would result in the coordinates
{{org.apache.solr.apache-solr.*}}, or maybe even
{{org.apache.apache-solr:apache-solr.*}}, both of which look goofy to me.
I *think* Maven can technically handle artifact naming schemes that differ from
artifactId-version(-type).jar, but I've never done that before, and I
personally don't think it's worth the effort, especially given the IMHO goofy
result. Before SOLR-4287, I haven't seen anybody complain. (If you look at
SOLR-4287, by the way, the suggestion isn't to change Maven naming, it's to
change the official Solr artifact naming.)
> modify release process/scripts to use svn for rc/release publishing
> (svnpubsub)
> -------------------------------------------------------------------------------
>
> Key: LUCENE-4134
> URL: https://issues.apache.org/jira/browse/LUCENE-4134
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Hoss Man
> Priority: Blocker
> Fix For: 4.1
>
>
> By the end of 2012, all of www.apache.org *INCLUDING THE DIST DIR* must be
> entirely managed using "svnpubsub" ... our use of the Apache CMS for
> lucene.apache.org puts us in compliance for our main website, but the dist
> dir use for publishing release artifacts also needs to be manaved via svn.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
