Confusion about projects in the source tree like common-common

[Jeff Berkowitz]

I pulled the tip of the trunk again today.  After fixing the source code problems in cspoker_src/ai/experiments/src/main/java/org/cspoker/ai/bots/BotRunner.java, I can get mvn:compile to complete successfully.  

When I try mvn assembly:assembly in any one of the executable projects, however, I get missing artifact errors.  The "missing" artifacts are things that exist in the source tree, like common-common, server-rmi, and the like.

During the build, Maven tries to find these things at http://cspoker.org:8080/nexus/content/groups/public/ but they aren't there.  It's not that the server is down, they just aren't there.  And that makes sense, because they are in the source tree.  I don't want the build picking up the ones from your server, I want the build to pick up mine in case I modify them.

I found that I can build these things one at a time by incanting "mvn assembly:assembly" in the appropriate module directory (e.g. cspoker_src/common/common) and then installing the jar from the target directory like Maven suggests, e.g.

mvn install:install-file -DgroupId=org.cspoker -DartifactId=common-common -Dversion=0.1-SNAPSHOT -Dpackaging=jar -Dfile=.../cspoker_src/common/common/target/common-common-0.1-SNAPSHOT.jar

But it seems silly to do this for every individual module and then have to remember to do it again any time I modify one of the jars.

I am not very familiar with Mavn.  I must be missing something?  What?

Thanks for your help,

Jeff

[Guy Van den Broeck]

Maybe because a buch of test cases fail, maven fails to put these jars in the local repository.

2010/8/26 Jeff Berkowitz <pdx...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "cspoker-discuss" group.
To post to this group, send email to cspoker...@googlegroups.com.
To unsubscribe from this group, send email to cspoker-discu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cspoker-discuss?hl=en.

[Jeff Berkowitz]

I see, the idea being Maven was *supposed* to automagically install those jars locally, but it wasn't getting that far because it thinks the jars are bad.  Good thought.  I will have another whack at it tonight and let the list know.

Oh, one other thing.  I didn't mention that the tests were failing, yet you knew - which means they must be failing everywhere, for known reasons?  Is this correct?  Should I try to fix them or just disable the tests?

Jeff

[Guy Van den Broeck]

2010/8/26 Jeff Berkowitz <pdx...@gmail.com>

Oh, one other thing.  I didn't mention that the tests were failing, yet you knew - which means they must be failing everywhere, for known reasons?  Is this correct?  Should I try to fix them or just disable the tests?

I've noticed this recently, yes. I don't know at what point it went wrong; they used to succeed. I haven't had the time to fix them, so feel free to give it a shot.

[Jeff Berkowitz]

Two things.

1. The Maven issue: I found that I had to do "mvn install" after "mvn compile" and before "mvn assembly:assembly".  Is it just me?  The "Maven Guide" page in the Wiki doesn't mention this.

2. The unit tests fail like this:

java.io.FileNotFoundException: C:\Poker\cspoker_src\common\common\target\common-common-0.1-SNAPSHOT.jar..\..\src\main\resources\org\cspoker\common\elements\hand\handRanks.txt (The system cannot find the path specified)

        at java.io.FileInputStream.open(Native Method)

        at java.io.FileInputStream.<init>(FileInputStream.java:106)

        at java.io.FileInputStream.<init>(FileInputStream.java:66)

        at org.cspoker.common.elements.hand.HandRanks.loadHandRanks(HandRanks.java:87)

        at org.cspoker.common.elements.hand.HandRanks.<init>(HandRanks.java:52)

        at org.cspoker.common.elements.hand.HandRanks.<clinit>(HandRanks.java:43)

the problem is here in HandRanks.loadHandRanks():

FileInputStream fstream = new FileInputStream(getClass().getProtectionDomain().

getCodeSource().getLocation().getPath().replace("%20"," ") +

"../../src/main/resources/org/cspoker/common/elements/hand/handRanks.txt");

There are at least two problems with this.  First, the getPath() returns a jar file name (a String ending in .jar) to which the "../../src/..." path is appended.  So the path comes out looking something like "...\target\common-common-0.1-SNAPSHOT.jar..\..\src\..." as you can see.  Second, when Maven instruments the code for Cobertura (coverage) and re-runs the tests, the getCodeSource().getLocation() is different because it includes "...\generated-classes\..." so the appended path will need more "..\" in it.

I haven't tried to fix this.  In order to make it work in the Cobertura context it would need some nasty tricks.  Instead there should probably be a better way to get at handRanks.txt.

Jeff

--

[Guy Van den Broeck]

Thanks for looking into it.

I think the problem was introduced in r1382 by laurent.verbruggen on May 13, 2010. The previous version of the code used 

getResourceAsStream from the classloader to load the file.

Laurent, can you comment on why you needed this change?

2010/8/29 Jeff Berkowitz <pdx...@gmail.com>

[Laurent Verbruggen]

Hi,

I already forgot I changed that bit of code, but if I remember correctly I changed it because the getResourceAsStream couldn't find the correct file. So as a temporary solution I made it an absolute path instead of relative. After a while I forgot I had to change it back. If I have some time I will correct this.

Laurent

2010/8/29 Guy Van den Broeck <guy.vand...@cs.kuleuven.be>

[Jeff Berkowitz]

This seemed to fix the tests for me:

private void loadHandRanks() {

try {

// FileInputStream fstream = new FileInputStream(getClass().getProtectionDomain().

// getCodeSource().getLocation().getPath().replace("%20"," ") +

// "../../src/main/resources/org/cspoker/common/elements/hand/handRanks.txt");

//    DataInputStream in = new DataInputStream(fstream);

InputStream in = getClass().getResourceAsStream("/org/cspoker/common/elements/hand/handRanks.txt");

. . . 

YMMV.

Jeff

[Guy Van den Broeck]

Fixed in r1394 and r1395. All tests succeed now on my machine.

2010/8/30 Jeff Berkowitz <pdx...@gmail.com>