On Mon, Apr 23, 2012 at 7:30 PM, Robert Muir <rcm...@gmail.com> wrote: > On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies <bimargul...@gmail.com> > wrote: >> On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir <rcm...@gmail.com> wrote: >>> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss >>> <dawid.we...@cs.put.poznan.pl> wrote: >>>> >>>> The issue with such poms is that once you want to publish your stuff >>>> to maven central it won't work (because all dependencies must be >>>> available and there is no "local" repository). >>>> >>> >>> This is the problem I am asking about. >>> >>> I don't care about local maven builds or any of that. I care about >>> release artifacts. >>> >>> If we have a buggy dependency, i can easily tweak ant+ivy (even ant by >>> itself) to download its source, patch it, and use it. >>> I can generate lucene-4.0-src.tgz, solr-4.0-src.tgz, lucene-4.0.zip, >>> etc etc with this. >> >> If your build and release process creates a modified version of >> xerces.jar with unmodified package names, and that jar file ends up on >> www.apache.org/dist, there will be unhappiness. You can't have such a >> thing in svn, you can't have it in your binary package, you can't have >> it in a 'convenience binary bundle.' You can auto-download it from >> non-Apache infrastructure. You could download it from Maven central, >> but you can't officially, as a committee, put it there. If have a way >> to get what you want with ant(+ivy) without breaking those rules, >> please explain it to me again, and I'll endeavor to provide the maven >> analog. >> > > Its pretty simple (for the record): for the lucene case the source > release would build this stuff, but we simply wouldnt provide any > third party jars in the binary release at all. > > Since the lucene core itself has no dependencies, it just means if you > want to use module-xyz that uses icu you need to go and get that jar > yourself: really not that bad. In fact lucene binary releases worked > this way for a very long time.
One way to read the above in the light of your previous message would be: 'just go ahead and publish Lucene stuff to Maven Central pointing at the unpatched dependencies, and leave it to the competent programmer-type users to pick up the source of the patches, build them, and use them if they care.' Works for me and simple as mud, so long as you aren't dealing with a dependency so badly broken that module-xxx doesn't work *at all* without it. In which case, I'd be trying to convince you that, whatever the build tool, you want to package-rename and incorporate the patched-up version, so as to deliver a working module. > > The complications all involve solr: because its an application that > people expect to work out of box. So its binary releases are a totally > different animal. I hope this makes sense. It makes perfect sense. Some of us do, however, embed Solr (for tests or other unrecommended reasons), or build our own Solr plugins with dependencies on the existing Solr plugins, and we would thus mourn, or have to go back to doing extra work, if you stopped publication of Solr artifacts altogether. However, you could stop publishing the full release package out there in Maven central but continued to push the bits and pieces. And those don't need to work perfectly out of the box in the sense of your comments above about Lucene. I confess that I've scripted downloading the 'real release' from Maven, but I could script downloading it from dist without any horrible loss. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
