A little late to the party, but... On Sep 18, 2010, at 5:09 PM, Ryan McKinley wrote:
>> I cannot in good conscience sign with my key, nor vote over any maven >> artifacts. I noticed these guides only mentioned how to upload (which itself >> seems extremely complex). But nowhere do i see 'how do you test that your >> artifacts are correct'. And thats really the main problem I have with our >> maven support. > > I understand what you are worried about... and think we can avoid it. > How about: > > 1. Keep the "generate-maven-artifacts" in the release. This just > copies the "official" jar files to a special directory structure (same > keys etc) OK, I get that a lot of committers here don't like Maven and I don't think Lucene should switch to a Maven build and it's a pain to do complex things in, but I use it all the time for Lucene/Solr (for none complex things) and I know of a lot of people in user land who use it as well b/c it makes the common things _users_ do really easy. And, as much as Hoss restarted this thread by saying the PMC releases only source, it simply is not what users expect. That's why we sign all the artifacts. They are the RM saying I verify this and the PMC then votes on all the artifacts and it's why we push them all up for distribution. Of course, we are only required to release source, but you show me a project that does only that at the ASF and I'll show you a project w/ very few users. At any rate, the big problem w/ Maven and Lucene is not that generate-maven-artifacts doesn't work, it's that the POM templates aren't kept in sync. However, I think we now have a solution for that thanks to Steve and Robert's work to make it easier to bring Lucene into IntelliJ. In other words, that process does much of what is needed for Maven, so it should be relatively straightforward to have it automatically generate the templates, too. In fact, it would be just as easy for that project to simply produce POM files (which are well understood and have a published spec) instead of creating the IntelliJ project files, which are not well understood and not publicly spec'd and subject to change w/ every release and simply have IntelliJ suck in the POM file since IntelliJ supports that very, very well. Then, to automatically test Maven, we simply need to do a few things: 1. Generate the templates 2. Build the Maven artifacts and "install" them (this is a Maven concept that copies them to your local repository, usually in ~/.mvn/repository, but it can be in other places and it should be clean) 3. Generate a "test" pom that includes, as dependencies all the Lucene Maven artifacts and maybe even compiles a small source tree with it If that last step passes, you know everything is right. However, short of #2 and #3, as long as the POM's are being generated accurately, I think I would feel comfortable releasing them, whereas I agree, now, with Robert, that we probably shouldn't be releasing them now. (BTW, I love the "Maven is Magic" (and really any "It's magic, therefore I don't like it") reasoning for not liking it, whereby everyone complains that b/c Maven hides a bunch of details from you (i.e. it's "magic"), therefore you don't like it. At the same time, I'm sure said person doesn't understand every last detail of, oh, I don't know: the CPU, RAM, the Compiler, the JDK, etc. and yet they have no problem using that. In other words, we deal with abstractions all the time. It's fine if you don't get the abstraction or don't personally find it useful, but that doesn't make the abstraction bad.) -Grant --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
