Chris Hostetter wrote: > : Couldn't we just add various ANT targets that package the jars per > : the Maven way, and even copy them to the appropriate places? I > : wonder how hard it would be > : to have ANT output the POM and create Maven Jars. I know it is > > This is what i would view as the ideal situation ... a patch to the > current ant build.xml that caused the package-all-binary and > package-all-src to produce a new maven directory with everything we need > to copy ot the maven repository would be the best way to get people to get > on board -- it's hard to complain with something that requires no effort > to adopt.
Where and how would you store for example the dependency information that you would be using to generate the poms? For lucene java it is easy for most modules as there is only dependency to lucene-core but for example in solr, nutch and hadoop it starts to go beyond trivial. > > if that same patch included a new ant target named > something like "publish-maven" which required key access to > people.apache.org but took care of pushing the maven artifacts into the > exact right spot, that would be one less thing people would have to worry > about. > > : > 1. There are differencies when comparing to ant build jars (due to > : > release > : > policy of a.o) the built jars will contain LICENSE.txt, > : > NOTICE.txt in /META-INF. Is this a problem? > > we should under no circumstances have two differnet jars calling > themselves "lucene-core-X.Y.0.jar" with differnet md5 sums ... that's > asking for a world of pain. Fortunately there is an easy fix for this: > start putting the LICENSE.txt and NOTICE.txt files in the jar ... i think > there's already a patch for this floating arround in Jira. > > : > 2. I propose that we add additional folder level so the groupId for > : > lucene > : > java would be org.apache.lucene.java (it is now org.apache.lucene > > I don't really see the advantage of this ... Lucene Java has allways had > the *java* package org.apache.lucene, and my understanding was that > maven groupIds should attempt to match the java package structure of the > code. likewise the other java subprojects have their own java packages, > shouldn't their groupIds match their pacakge structures? I believe you are right, and I also think it makes more sense to match the package names. >.. but starting with Lucene > Java is the probably the right way to go ... if a simple solution is found > for our build file, it will probably lend itself to similar soluteions for > hte other Lucne projects that use ant. Yes that is my hoping also and the main motivation to start the discussion from lucene java (as it also is a dependency to 2 more sub projects). IMO we should however try to look at the big picture also and not only try to solve the minimal part to get it out of lucene-java hands, because I am afraid that if the minimum is done here in lucene-java there might be caps to fill in other projects and the way things are done here is not usable in other sub projects as it is. -- Sami Siren --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
