Chris Hostetter wrote: > Whatever files also need to be included along with the jars in order to > make the maven distribution complete that can't be built completley > dynamicly (ie: the md5 files) can certainly be commited into the > repository ... but if making a release requires a lot of manual upating to > those files, it's going to be a hinderane to the process ... things like > version number and date should ideally be filled in via variables to help > keep things automated.
This starts to sound like a plan that can work. I'll see if I can hack something up as a patch fow a review. Do you think poms should live in a separate dir or should they be spread across dirs (modules). > jar dependencies are another matter ... as you say, for java-lucene the > issue is trivial since there are no dependencies, but for other projects > it could get complicated. Solr (for example) ships with the versions of > it's dependencies that it expects to use, and in some cases these version > may not be official release versions that you would ever find in a maven > repository. I'm notsure how apps that want to publish to maven but depend > on apss that do not publish to maven deal with this problem, but whatever > solution they use could also be used in this case. I have seen for example a solution where artifacts are published on somewhere else but official repositories, but to be frank I don't know what's the best (or at least acceptable) solution here. > : 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. > > each project has it's own community ... even if you find a perfect > solution to every problem anyone in the world might ever encounter, > discussing it on java-dev does nothing to get your solution adopted by the > nutch, hadoop, or solr communities. I understand that there are separate communities. I am not saying that everybody must accept the solution that will (if any) adopted by lucene-java. But still I am hoping that we lucene-java won't deliberately accept a solution that won't work for others (as you said it: "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.") -- Sami Siren --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
