Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 5 Apr 2012 23:00:23 +0000 (UTC)
From: "Hoss Man (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1802087089.20259.1333666824000.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1909947376.20155.1333664664806.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (LUCENE-3961) don't build and rebuild jar files
 for dependencies in tests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247801#comment-13247801 ] 

Hoss Man commented on LUCENE-3961:
----------------------------------

bq. We currently don't generally use jars as the actual classpath for testing though

understood, #1 is just an argument i've seen as to why it would be better to do so -- otherwise we never actually know when testing that our jars are useful -- someone could accidentally put "excludes="*.class" on a jar task and you'd never notice because all the tests would still pass.

bq. by never creating a jar in the first place your #2 doesn't happen at all really.

note step #a ... the point is if someone does whatever officially blessed step there is to build the jars ("ant", "ant jar", "ant whatever") and then decides they want to change the behavior of those jars -- they may never run "ant clean" and it may not occur to then to  re-run whatever that official way to build jars is and they may not notice that the jar's aren't rebuilt when they do "ant test" -- because they can already see the new code was "compiled" and running based on the test output.

bq. Also, if we were to go with your logic, really we should be rebuilding the solr.war everytime

correct, a war is just a jar with a special structure

bq. (I'm just pointing out why i think its infeasible). ... I think we need to keep this stuff fast so that compile-test-debug lifecycle is as fast as possible

agreed ... like i said, i don't have a strong opinion about it, but since we're discussing it i just wanted to point out the arguments i've heard over and over when having this discussion in the past on other projects.

I think in an ideal world, devs could run fast tests against ../*/classes/ directories, but jenkins would run all those same tests against fully build jars to ensure they aren't missing anything ... but that would probably be an anoying build.xml to maintain

                
> don't build and rebuild jar files for dependencies in tests
> -----------------------------------------------------------
>
>                 Key: LUCENE-3961
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3961
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Robert Muir
>             Fix For: 4.0
>
>
> Hossman's comments about when jars are built had me thinking,
> its not really great how dependencies are managed currently.
> say i have contrib/hamburger that depends on contrib/cheese
> if I do 'ant test' in contrib/hamburger, you end out with a situation
> where you have no hamburger.jar but you have a cheese.jar.
> The reason for this: i think is how we implement the contrib-uptodate,
> via .jar files. I think instead contrib-uptodate shouldnt use actual
> jar files (cheese.jar) but a simple file we 'touch' like cheese.compiled.
> This will make the build faster, especially I think the solr tests
> which uses these dependencies across a lot of lucene modules. we won't
> constantly jar their stuff.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

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