As a rule, everything should go through JIRA on its way to svn -- this is important so that we have somewhere to point for why we did things. Even small things.
With patches from contributors it is especially important they are added to JIRA because they need to grant the license to ASF. Also attachments are often stripped from mailing list archives, so down the road its really hard to know what happened. I understand the desire to keep maven support low key -- but we should do that with a good README in dev-tools. Even as officially non-official tools, it still gets into svn so we need a trail of where it came from and hopefully a log of why we thought it was important. ryan On Wed, May 4, 2011 at 6:52 PM, Steven A Rowe <sar...@syr.edu> wrote: > Hi Ryan, > >> Do you want to make a JIRA issue with a patch? >> >> This is a good example of a patch that is easy to get committed >> quickly because it is simple, clear, and understandable. > > Earlier today on #lucene IRC, David described the changes he had in mind, and > asked me where to put the patch, and I told him that if the patch was small, > the mailing list might make sense. > > I also told him that JIRA issues are generally a good idea, but that for the > officially-non-official Maven stuff, I haven't been using JIRA, since it > seemed to me like the attendant noise to signal ratio would be too high. > (Maven appears to be appreciated by Lucene/Solr users way more than the devs, > and the users don't generally follow JIRA.) > > That said, I'm open to being convinced otherwise. > > Steve > >> On Wed, May 4, 2011 at 5:41 PM, Smiley, David W. <dsmi...@mitre.org> >> wrote: >> > Steve Row, >> > >> > I thought I'd put together a list of interesting differences between >> the ant build output and the maven build output. Before each build I did >> a full clean and then after the build I saved a file listing to a text >> file so that I could diff it. >> > >> > I'm using svn revision 1087373 (March 31st). >> > >> > 1. The ant build invokes a JSP compiler to validate them. The maven >> build does not. >> > 2. Maven seems(?) to compile more modules' tests than the ant build >> does. >> > 3. The ant build builds the tools module. The maven build does >> not. Probably fine it stays this way? >> > 4. Ant doesn't build the benchmark module; maven will by default. A >> problem for the ant build? >> > 5. The ant build artifacts tend to have a leading "apache-" in front of >> them. But the maven artifactId does not have this so the artifacts file >> names are different, trivially so any way. >> > 6. The ant solr build puts all its final artifacts into the solr/dist >> directory, the maven build does not--it leaves all of them in their build >> directory. Not a big deal but maybe there's a way to have the output file >> go someplace else? Not sure. >> > >> > There were two issues that seemed like clear bugs to me that I fixed >> with an attached patch. >> > 1. solrj's build directory and compile output directory were the same >> directory, but that's problematic since building the output jar will >> result in an error if it sees its own jar file as an input file to its >> output jar. So I added a "classes" directory. This will result in a >> different directory than where the ant builds, though. >> > 2. The dataimporthandler-extras output location was specified such that >> there was a redundant path: /extras/extras/, so I fixed this. >> > >> > By the way, I think it would be really nice to have a maven build >> instructions file that is put into place when the get-maven-poms task is >> run. The file would have the essential instructions, it would explain >> some of the relevant differences to the ant build (notably output file >> placement, file name differences), and it would include tips such as how >> to install the sources and javadoc jar files into your local repo. >> > >> > ~ David Smiley > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
