lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Help: SOLR-3430 and Build changes
Date Wed, 02 May 2012 17:51:38 GMT
One note:

Derby is included since JDK 6 as "JavaDB" together with the JDK:
http://www.oracle.com/technetwork/java/javadb/overview/index.html

As Lucene/Solr 4 will be using JDK 6 as minimum requirement (in contrast) to Solr 3.x (which
was JDK 5), can we not simply rely on this version shipped with JDK? That would make life
easy. And for simple tests that version should be enough...

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Wednesday, May 02, 2012 7:21 PM
> To: dev@lucene.apache.org
> Subject: Re: Help: SOLR-3430 and Build changes
> 
> On Wed, May 2, 2012 at 1:10 PM, Dyer, James
> <James.Dyer@ingrambook.com> wrote:
> > Let me apologize in advance for my (almost) complete ignorance of
> > everything build related:  Maven, Ivy, Ant, etc.  Sorry!
> >
> >
> >
> > For Solr-3430, I am introducing a dependency to derby.jar, which will
> > be needed only to run DIH tests.  So I don't want it included in the
> > Solr .war.  It just needs to be in the classpath when junit runs.
> >
> >
> >
> > 1. Where should I put the .jar/licence/notics/sha1 files?
> >
> > 2. How do I modify the build so that it will be in the classpath for
> > running tests only?
> >
> 
> one way to do it is to make a lib-test/ or whatever and put them in there. Then,
> you would modify ivy.xml to have two configurations instead of just the one
> default, and the additional configuration would be called 'test' or something
> like that. Then modify build.xml to have a different 'resolve' (see solr/example
> for something that does just what i describe) and also declare a different test-
> classpath that includes lib-test/
> 
> that shouldnt be too bad, but the bigger question is with this test-only
> dependency, is it really a unit test or more of an integration test?
> For a unit test I think a mock object would be preferred.
> 
> If we want to start having integration tests (looking at your issue title, it really
> seems thats what you are proposing), then I think it would be cleaner to just
> have an integration testing module instead?
> Otherwise I can see the tests/dependencies for various modules getting really
> complicated quickly, and I worry about wrong things getting included in
> packaging or wars or whatever.
> 
> As far as having build setup properly for integration tests, I already proposed
> such a thing here
> https://issues.apache.org/jira/browse/LUCENE-3974
> 
> --
> lucidimagination.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org


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


Mime
View raw message