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). 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
