maven + solr

[Ryan McKinley <ry...@gmail.com>]

Hello!  Hope you all are having nice holidays.  let me lob another idea 
out there and see if you think I'm crazy...

How do you all feel about changing the directory layout so it plays 
nicely with maven?  While we are at it, how do you feel about switching 
to maven for the primary build system?

My reasons to suggest this are:
1. working with maven artifacts makes plugin/app development loads easier.
2. maintaining multiple build systems simultaneously seems like a pain 
(I can't quite figure out how the lucene maven stuff works... it seems 
overly complicated though)
3. For SOLR-303, solr-core needs to depend on solrj -- we can do this 
with a simple change to build.xml, but it leaves us with a directory 
structure that does not reflect the real dependencies.  It seems like a 
restructuring is called for regardless of the build system.
4. Using maven, we can quickly add other nice build features like 
clover, pmd, eclipse, and idea support.
5. Assuming we stick with cwiki for the the site release, we need to 
figure out how to include the auto-export in our distribution.


The concerns I have heard about maven are:
1. past experience was awful, lets not go there
2. solr sometimes depends on snapshot builds

#1, I can't really argue with - My past experience with maven (a long 
time ago) was terrible too.  All my recent work with maven2 has been 
incredibly smooth.

#2, with maven, we can still put in hand built jar files, it is just not 
the best practice.  Currently, the only dependency that we can't pull 
from a standard repository is: commons-csv-0.1-SNAPSHOT.jar


In SOLR-19, I just uploaded a proof of concept layout/pom structure with 
4 artifacts:
    1. solr-common (jar)
    2. solr-client (jar)
    3. solr-core (jar)
    4. solr-server (war)
The one thing that is strange about our dependency graph is that many of 
the tests for 'solr-client' depend on 'solr-server' and 'solr-core', so 
they would probably be in that package.

Is this something worth pursuing?  Would we rather stick with ant and 
either have maven build unofficial artifacts or jump through lucene 
style hoops?

ryan

Re: maven + solr

[Chris Hostetter <ho...@fucit.org>]

I'm a big fan of the lucene-java way of integration maven ... not because 
i understand it, but because as a non-maven user i didn't even notice when 
the change happened, but all the maven users i know say "it's so great 
that we have maven support now." ... that sounds like a win/win to me.

I'm aggressively ambivilent about using maven as a build system for Solr 
... if someone else does the work, and the commands for building/testing 
are just as easy as ant -- then i'm certainly not going to complain.

My main concern with going the maven route is client code .... we want to 
make sure it's easy for new clients in new languages to be added so they 
can be built easily as part of the main Solr build (not that we do this 
much now ... but i know i saw Erik start a thread on this ... can't 
remember if it got any traction) ... my gut says that an ant based 
approach similar to lucene-java contribs where the contract is "the main 
system will use subant to call 'ant compile', 'ant test' and 'ant dist' in 
each client dir." will give client code the most flexibility to have stub 
build.xml files to call the Rakefile/Makefile/BoBakefile based build files 
that make sense for that language ...but if that's just as easy with maven 
then that concern is moot.


-Hoss

Re: maven + solr

[Ryan McKinley <ry...@gmail.com>]

>>
>> * I wouldn't be in favor of changing the build to rely on Maven2. We 
>> use Maven internally at Krugle, and sometimes it works well, and other 
>> times it's a royal pain in the butt. So having it as an option would 
>> be nice, and handy for me personally, but I'd hate to foist Maven on 
>> everybody else.
> 
> 
> Again, +1.  If it ain't broke, don't fix it.  Keep the ANT build and 
> publish the Jars on the Maven repo is my vote.
> 

This all sounds good to me -- I don't quite understand how the lucene 
poms work, so someone else will need to take the first step here ;)

ryan

Re: maven + solr

[Grant Ingersoll <gs...@apache.org>]

On Dec 28, 2007, at 5:50 PM, Ken Krugler wrote:

>> Hello!  Hope you all are having nice holidays.  let me lob another  
>> idea out there and see if you think I'm crazy...
>>
>> How do you all feel about changing the directory layout so it plays  
>> nicely with maven?  While we are at it, how do you feel about  
>> switching to maven for the primary build system?
>>
>> My reasons to suggest this are:
>> 1. working with maven artifacts makes plugin/app development loads  
>> easier.
>> 2. maintaining multiple build systems simultaneously seems like a  
>> pain (I can't quite figure out how the lucene maven stuff works...  
>> it seems overly complicated though)
>> 3. For SOLR-303, solr-core needs to depend on solrj -- we can do  
>> this with a simple change to build.xml, but it leaves us with a  
>> directory structure that does not reflect the real dependencies.   
>> It seems like a restructuring is called for regardless of the build  
>> system.
>> 4. Using maven, we can quickly add other nice build features like  
>> clover, pmd, eclipse, and idea support.
>> 5. Assuming we stick with cwiki for the the site release, we need  
>> to figure out how to include the auto-export in our distribution.
>>
>>
>> The concerns I have heard about maven are:
>> 1. past experience was awful, lets not go there
>> 2. solr sometimes depends on snapshot builds
>>
>> #1, I can't really argue with - My past experience with maven (a  
>> long time ago) was terrible too.  All my recent work with maven2  
>> has been incredibly smooth.
>>
>> #2, with maven, we can still put in hand built jar files, it is  
>> just not the best practice.  Currently, the only dependency that we  
>> can't pull from a standard repository is: commons-csv-0.1- 
>> SNAPSHOT.jar
>>
>>
>> In SOLR-19, I just uploaded a proof of concept layout/pom structure  
>> with 4 artifacts:
>>   1. solr-common (jar)
>>   2. solr-client (jar)
>>   3. solr-core (jar)
>>   4. solr-server (war)
>> The one thing that is strange about our dependency graph is that  
>> many of the tests for 'solr-client' depend on 'solr-server' and  
>> 'solr-core', so they would probably be in that package.
>>
>> Is this something worth pursuing?  Would we rather stick with ant  
>> and either have maven build unofficial artifacts or jump through  
>> lucene style hoops?
>
> My input on this...
>
> * Providing a Maven2 build would be useful for us. Currently when we  
> modify Solr, we do an Ant build and then manually push the resulting  
> jar to our in-house Maven repo, which works but isn't all that clean.

+1  I like the M2 repository and M2 conventions, but am less enamored  
w/ M2 as a tool to actually execute targets/goals, and I have used it  
fairly extensively.  I tend to favor how Lucene does it these days.

>
>
> * So I'd be in favor of changing the directory layout, but only for  
> my own selfish reasons :)

+1.  I do like the way the M2 "standardizes" directories.

>
>
> * I wouldn't be in favor of changing the build to rely on Maven2. We  
> use Maven internally at Krugle, and sometimes it works well, and  
> other times it's a royal pain in the butt. So having it as an option  
> would be nice, and handy for me personally, but I'd hate to foist  
> Maven on everybody else.


Again, +1.  If it ain't broke, don't fix it.  Keep the ANT build and  
publish the Jars on the Maven repo is my vote.

Re: maven + solr

[Ken Krugler <kk...@transpac.com>]

>Hello!  Hope you all are having nice holidays.  let me lob another 
>idea out there and see if you think I'm crazy...
>
>How do you all feel about changing the directory layout so it plays 
>nicely with maven?  While we are at it, how do you feel about 
>switching to maven for the primary build system?
>
>My reasons to suggest this are:
>1. working with maven artifacts makes plugin/app development loads easier.
>2. maintaining multiple build systems simultaneously seems like a 
>pain (I can't quite figure out how the lucene maven stuff works... 
>it seems overly complicated though)
>3. For SOLR-303, solr-core needs to depend on solrj -- we can do 
>this with a simple change to build.xml, but it leaves us with a 
>directory structure that does not reflect the real dependencies.  It 
>seems like a restructuring is called for regardless of the build 
>system.
>4. Using maven, we can quickly add other nice build features like 
>clover, pmd, eclipse, and idea support.
>5. Assuming we stick with cwiki for the the site release, we need to 
>figure out how to include the auto-export in our distribution.
>
>
>The concerns I have heard about maven are:
>1. past experience was awful, lets not go there
>2. solr sometimes depends on snapshot builds
>
>#1, I can't really argue with - My past experience with maven (a 
>long time ago) was terrible too.  All my recent work with maven2 has 
>been incredibly smooth.
>
>#2, with maven, we can still put in hand built jar files, it is just 
>not the best practice.  Currently, the only dependency that we can't 
>pull from a standard repository is: commons-csv-0.1-SNAPSHOT.jar
>
>
>In SOLR-19, I just uploaded a proof of concept layout/pom structure 
>with 4 artifacts:
>    1. solr-common (jar)
>    2. solr-client (jar)
>    3. solr-core (jar)
>    4. solr-server (war)
>The one thing that is strange about our dependency graph is that 
>many of the tests for 'solr-client' depend on 'solr-server' and 
>'solr-core', so they would probably be in that package.
>
>Is this something worth pursuing?  Would we rather stick with ant 
>and either have maven build unofficial artifacts or jump through 
>lucene style hoops?

My input on this...

* Providing a Maven2 build would be useful for us. Currently when we 
modify Solr, we do an Ant build and then manually push the resulting 
jar to our in-house Maven repo, which works but isn't all that clean.

* So I'd be in favor of changing the directory layout, but only for 
my own selfish reasons :)

* I wouldn't be in favor of changing the build to rely on Maven2. We 
use Maven internally at Krugle, and sometimes it works well, and 
other times it's a royal pain in the butt. So having it as an option 
would be nice, and handy for me personally, but I'd hate to foist 
Maven on everybody else.

-- Ken
-- 
Ken Krugler
Krugle, Inc.
+1 530-210-6378
"If you can't find it, you can't fix it"