lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: lucene and solr trunk
Date Tue, 16 Mar 2010 07:45:04 GMT
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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message