On Tue, Mar 16, 2010 at 8:18 AM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi all, > > I don't want to be against all other developers that voted +1 for the SVN > "merge", but I am not happy with it. Most importantly for the reasons Hoss > mentioned: > >> : prime-time as the new solr trunk! Lucene and Solr need to move to a >> : common trunk for a host of reasons, including single patches that can >> : cover both, shared tags and branches, and shared test code w/o a test >> : jar. >> >> Without a clearer picture of how people envision development "overhead" >> working as we move forward, it's really hard to understand how any of >> these ideas make sense... >> 1) how should hte automated build process(es) work? >> 2) how are we going to do branching/tagging for releases? >> particularly >> in situations where one product is ready for a rlease and hte other >> isn't? >> 3) how are we going to deal with mino bug fix release tagging? >> 4) should it be possible for people to check out Lucene-Java w/o >> checking out Solr? > > That are important questions and not simply to solve! > >> (i suspect a whole lot of people who only care about the core library >> are >> going to really adamantly not want to have to check out all of Solr >> just >> to work on the core) > > Exactly! The Solr checkout is really huge because of thousands of JAR files > and so on. The badest thing we could do would be to merge all those JARs into > one general lib folder or like so. Please do not! Lucene-core should stay a > lib without any external deps. > >> : Both projects move to a new trunk: >> : /something/trunk/java, /something/trunk/solr > > This would be the only optinon we have. This new folder could simply contain > two dirs below and a build.xml in the top level that delegates and builds > first lucene, then solr. But you can do this also with separate checkouts and > a simple script downloaded from the wiki. > > The problems of this approach far overweigh the positive side: > > In the original vote, we said, Lucene can release without Solr: > Releasing (I was the last release mangaer) contains things like creating > branches and tags. In SVN, if you create a branch, you copy everything from > under trunk (or another branch) to a new folder below branches (for tags > under tags). "tags" on most SVN servers has an additional limittation, that > it is not possible to change anything under "tags" except copying. > > If we have those combined trunk folder and Lucene wants to release and > creates a branch/tag. Solr is enforced to do this too. OK, you could say, we > just branch the folder lucene and let solr where it is. But that would be a > against conventions and the branch checkout could not life alone. > > I just repeat: we wanted to merge devs and not codebase! And merging devs is > a "code change" clearly. > > And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where > Solr seems to be on 1.6 since yesterday? (Yonik added something to > common-build.xml). On my development system I have no Java 1.6 installed at > all as default build, I ever use Java 1.5 for building Lucene. If we merge > that and have both on different JVMs the same problems like with 1.4/1.5 > start. Developers use 1.6 methods because their compiler does not warn them. > So everybody working on Lucene should at least have Java 1.5 compiler and try > to compile his changes before committing. I do this (as I use 1.5 for > developing), 1.6 on some of our servers. > > So: If merge, keep both on Java 1.5 !!! > >> by gut says something like this will more the most sense, assuming >> "/something/trunk" == "/java/trunk" and "java" actually means "core" >> ... > > And that is how it looks currently and I am fine with it! > >> ie: this discussion should really be part and parcel with how contribs >> should be reorged. > > That is exactly what should be done. Not now simply copy the folders > somewhere for some "development simplification" that not really is one and > opens more problems! > > I propose another idea for now until the "module" decision is [DISCUSS]ed and > [VOTE]d: > > Lets create a new project folder with trunk and branches for combined trunk > development in SVN (this can be later the folder for the module development). > This folder simply contains a delegating build.xml (delegating the common > tasks like build and test and so on to solr and trunk).The folder simply uses > svn:external SVN props to link current solr and lucene trunk as subfolders. > So developers that want to work on both can simply checkout this folder and > SVN will resolve the externals. As this is trunk development, the externals > will be without rev numbers and relative for the http(s) problem (SVN 1.5+ > required).
+1 - as I recall correctly that is what uwe and I proposed initially on IRC when solr got copied initially. This makes a lot of sense as it does not break anybodies checkouts and enables all "Solcene" developers to move on. From a Lucene point of view Lucene should not see any Solr below its root as we do not have dependencies on it, letting them live side by side seems to be the way to go as uwe says. One more thing which I wonder about even more is that this whole merging happens so quickly for reasons I don't see right now. I don't want to keep anybody from making progress but it appears like a rush to me. Committers, start copying stuff around without discussion or having a jira issue (sry mark :) - not blaming you personally), discussions on the list are extremely short living and several people seem to be rushed somehow. I can understand the moving forward is tempting but based on all this discussion during the "vote" could we move a little slower and little more relaxed to figure out the right solutions. If my impression should be wrong or if I miss something please ignore the last paragraph. BTW: I still have the impression that if I don't follow IRC constantly I'm missing important things. simon > > For testing flex, we create a branch of this folder, still pointing to > solr-trunk, but flex branch in Lucene. > > One task of the main build.xml would be to copy all produced JAR files of > Lucene into the correct build folder in Solr. > > I hope that you all understand me, but I am against merging trunks (for now) > until we have a clear module decision. > > Uwe > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
