Re: [eclipselink-dev] Changes to core.test...failure on junit.jar valida

[Eric Gwin <eric.gwin@xxxxxxxxxx>]

Michael,

half of those wouldn't work. There is no variable "junit.jar" my failure 
message reported the value of a non-existent variable (fixed now). 
"junit.lib" is the variable tested, and not found when the "fail" was 
triggered. both of your junit.lib definitions should work. Mine of:

extensions.depend.dir=C:/__external.lib
junit.lib=${extensions.depend.dir}/junit.jar

works.

as does the default on my machine (not that my machine is standard by 
which stability is measured).

-Eric.

Michael O'Brien wrote:
> Eric,
>    I use my own build.properties and test.properties overrides in my 
> <user-dir> for a lot of other settings as well - these override any 
> defines in SVN..
>    I already had a junit override there historically - my junit setup 
> is working fine - I am currently deferring to the property in SVN.
>    The issue I have is that any junit.jar fails validation - I used 
> sets of the following for reference - my extensions dir is outside my 
> multiple views but I tested by temporarily moving it into the expected 
> location.
>
> Historical ok
> #junit.lib=${oracle.extensions.depend.dir}/junit.jar
> tried...
> #junit.jar=C:/opt/ant171/lib/junit-4.3.1.jar
> #junit.jar=C:/opt/ant171/lib/junit.jar
> j#unit.lib=C:/opt/ant171/lib/junit.jar
>
>
>    The commented build.xml line would be temporary.
>    I'll check my 64-bit machine tomorrow but my 2 32-bit ones both 
> have this issue.
>
>    The test itself should be valid - because the persistence jar one 
> passes - I would see what the diff is between the setup of both vars is.
>
>    /michael
>
> Eric Gwin wrote:
> > Instead of commenting out the line every time you update, you could 
> > also define junit.lib in a build.properties in your user.home...
> > probably "Documents and settings\mobrien". Then the test should work.
> >
> > I put the tests there because the test builds were doing some rather 
> > unexpected things depending upon how they were invoked - getting 
> > files from unexpected locations, loading the wrong properties files.  
> > I fixed most of that with the rework. However, I wanted to make sure 
> > of the locations of the dependent files (listed in the compiler and 
> > run paths) and not make assumptions that they were present - which 
> > then led to issues of having to debug compile failures and possible 
> > path issues rather than getting an error message (in an attempt to 
> > make the tests more user friendly).
> >
> > -Eric
> >
> > Michael O'Brien wrote:
> > > Eric,
> > >    I am referencing junit 4.5 in my external ant lib dir - to verify 
> > > I used an absolute path instead of a relative one.
> > >    On another machine I am running 4.3.1 in a similar config.
> > >    The junit.jar that comes with the extension dir is there - I 
> > > don't remember where I got it.
> > >      The persistence.jar check is ok
> > >    Not a big issue as I fully build if I comment out the junit line 
> > > around 207.
> > >
> > >    /michael
> > >
> > > Eric Gwin wrote:
> > > > The failure is explicit. the error message was wrong I should be 
> > > > trying to report ${junit.lib} not ${junit.jar}. However the test is 
> > > > correct. Where is your junit jar?
> > > >
> > > > -Eric
> > > >
> > > > Michael O'Brien wrote:
> > > > > Eric,
> > > > >     eclipselink.core.test trunk build failure on new junit 
> > > > > validation after update to 5460 - missing junit.jar variable.*
> > > > >
> > > > > *    Just a heads up, I am getting a trunk build failure with the 
> > > > > new code in core.test/build.xml from SVN txn# 5460
> > > > >     My 5465 txn to enable backwards compatibility with legacy 
> > > > > machines running 2gb worked fine until I refreshed and picked up 
> > > > > 5460 - the 2 transactions are not related.
> > > > >     Nothing changed with my JUnit setup between refreshes (I am 
> > > > > running the jars from my Ant lib directory)
> > > > >     See
> > > > > http://fisheye2.atlassian.com/browse/eclipselink/trunk/foundation/eclipselink.core.test/build.xml?r=5460 
> > > > >
> > > > >
> > > > > egwin
> > > > >     5460 
> > > > > </browse/eclipselink/trunk/foundation/eclipselink.core.test/build.xml?r=5460#l206> 
> > > > >
> > > > >     206 <#l206>     <target name="compile" depends="init_paths" 
> > > > > description="compile EclipseLink core tests">
> > > > > 207 <#l207>         <fail message="Cannot find junit: 
> > > > > '${junit.jar}'." unless="junit.jar.exist"/>
> > > > >
> > > > >
> > > > > >Build before 5460
> > > > > Core LRG with override on 12GB machine
> > > > >   [junit] Tests run: 1333, Failures: 0, Errors: 0, Time elapsed: 
> > > > > 697.688 sec
> > > > >
> > > > > >Build after 5460
> > > > >
> > > > > BUILD FAILED
> > > > > C:\view_w342e\build.xml:275: The following error occurred while 
> > > > > executing this line:
> > > > > C:\view_w342e\foundation\eclipselink.core.test\build.xml:207: 
> > > > > Cannot find junit: '${junit.jar}'.
> > > > >
> > > > > Total time: 2 minutes 6 seconds
> > > > > C:\view_w342e>
> > > > >
> > > > > >Fix: We are missing a junit.jar definition in build.properties.
> > > > > There is an existing
> > > > > junit.lib=../../../extension.lib.external/junit.jar
> > > > > I added my own <user-dir>/build.properties override "junit.jar" 
> > > > > instead of "junit.lib"
> > > > > junit.jar=../../../extension.lib.external/junit.jar
> > > > > As well as hardcoding to my own JUnit libs and I am unable to get 
> > > > > past this new verification.
> > > > >
> > > > > thank you
> > > > > /michael
> > > > > Eric Gwin wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I just checked in an initial pass at reorganizing the core.test 
> > > > > > build on trunk (2.0.0). The build was successful with several 
> > > > > > test configurations, and passed the SRG. However, let me know if 
> > > > > > you encounter any problems.
> > > > > >
> > > > > > I will be incrementally checking in each test build as I complete 
> > > > > > the migration to adopt:
> > > > > > - the current build standards (original reorg was never done on 
> > > > > > the tests)
> > > > > > - detect  'product' to use for testing:  eclipselink.jar, bundles 
> > > > > > or 'classes' dirs - in that order.
> > > > > > - improve performance by isolating initialization and 
> > > > > > conditionals in an init target
> > > > > >
> > > > > > The second phase of this reorg will focus on creating generic 
> > > > > > testing artifacts to streamline the test process and remove 
> > > > > > redundant building.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > -Eric
> > > > > > _______________________________________________
> > > > > > eclipselink-dev mailing list
> > > > > > eclipselink-dev@xxxxxxxxxxx
> > > > > > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> > > > >
> > > > > ------------------------------------------------------------------------ 
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > eclipselink-dev mailing list
> > > > > eclipselink-dev@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> > > > >   
> > > > _______________________________________________
> > > > eclipselink-dev mailing list
> > > > eclipselink-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> > >
> > > _______________________________________________
> > > eclipselink-dev mailing list
> > > eclipselink-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> > _______________________________________________
> > eclipselink-dev mailing list
> > eclipselink-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev