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: u...@thetaphi.de > -----Original Message----- > From: Robert Muir [mailto:rcm...@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.d...@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-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
