On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> Thus, I claim that this debate is fundamentally about package > renaming, not publication. > > Shall I be maximally annoying and mention OSGi again? > Its not really a debate, its 'how do we do this'. (I can argue your claim is wrong, but i won't, ive said it before and I stick with what I've said)... The current problem is for releases, how to handle this stuff is currently confusing. There are a few ideas here, and some of them maybe are possible, but we need to come to some sort of agreement on how to handle these kind of situations. Currently we have no patched jars, magically, but since we depend on over 100 of them, the probability of this situation staying the same for any length of time is very low. I don't really care what we do, but i just want: * a process for dealing with patched dependencies (that doesn't involve illegal publication of other people's stuff in maven under our name) * a process for dealing with dependencies that aren't in maven (that doesn't involve illegal publication of other people's stuff in maven under our name) * the two processes to not be the release manager's job to deal with. * the two processes to be easy enough to understand to pmc members so they actually understand WTF is going on with our releases without it being a huge mystery. One implication of what I want is that 'for development' (whats committed to trunk) is the same as 'for releases'. Because anything else is just a big 'RM, you go deal with fixing this later'. So I don't think we should let trunk get all kinds of screwy dependencies and leave it to release managers to fix up the mess. Another is that even if we work and figure all this out, its still so crazy complicated that a bunch of people here just say 'this isnt worth it, as a PMC member i dont understand all this, this is supposed to be a search engine project' (I'm not trying to call out Mike on this, but his email maybe alludes that some people could possibly feel this way about maven). And as a side note: Uwe's ideas bring up a nice potential compromise for simplification: maybe just lucene (as an API) should be in maven and not solr (as an application?). Its worth thinking about: solr has many many more third-party dependencies. Dependencies are really really expensive. -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
