I completely agree with Uwe and Hoss. These questions need to be
addressed first.
I still want to be able to only checkout Lucene code and run the Lucene
build independently from Solr. And Lucene needs to be able to release
without Solr and the branching/tagging needs to support that as Uwe
points out.
Michael
On 3/16/10 12:18 AM, Uwe Schindler 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).
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
