geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: openejb-builder test failure
Date Fri, 08 Sep 2006 16:15:45 GMT
Jacek Laskowski wrote:
> On 9/8/06, Joe Bohn <joe.bohn@earthlink.net> wrote:
> 
>> The pieces are all starting to come together.
> 
> 
> Great! ;-)
> 
>> I was first getting the error that Sergey referenced and which I first
>> referenced in this post:
>> http://marc.theaimsgroup.com/?l=geronimo-dev&m=115653241007061&w=2
> 
> 
> So was I.
> 
>> I was actually proposing skipping the tests to get around that error
>> because when I added the getName() method I hit the MalformedURL error
>> that Jacek mentioned (and I posted about here).
>>
>> http://marc.theaimsgroup.com/?l=geronimo-dev&m=115680051431478&w=2
>>
>> I wasn't aware that this was a known problem and changing the repository
>> path would resolve it.
> 
> 
> The first time we hit this was in OpenEJB 3 and Dave B. fixed it
> easily for it was only in one unit test. I remember Dave mentioned it
> had been fixed in OpenEJB 2, too, but seems it was not (I guess Dave
> had yanked MS Windows and installed MacOS or Linux ;-))
> 
>> Thank you Jacek for pointing me to the openejb
>> issue!  I changed my repo and now it seems that I can build successfully
>> both without the getName() method errors and without the MalformedURL
>> exceptions.
> 
> 
> Does it mean that once you set maven.repo.local to a non-spaced path
> the build worked well?

That's correct (see my actual setting further down).

> 
>> Does anybody know if there is an environment variable that I can set for
>> the m2 repo so that I don't have to modify the build scripts?
> 
> 
> You can run m2 with localRepository set in ~/.m2/settings.xml as
> described at 
> http://maven.apache.org/ref/current/maven-settings/settings.html#class_settings. 
> 
> Look at localRepository setting. It should do the trick. Give it a
> whirl and report back (so I won't have to dig into surefire plugin and
> fix the classpath issue ;-) I just can't believe it's merely us who
> experience the issue!).

I actually took a somewhat different route.  I updated my MAVEN_OPTS 
environment variable (which I had already set for the heap size) to 
include maven.repo.local.  For the most part this worked fine with one 
exception.  When you run a "bootstrap clean" it currently assumes that 
your repository is located at "${user.home}/.m2/repository" and deletes 
that directory.   With my MAVEN_OPTS setting and by manually cleaning my 
actual m2 repo location prior to running "bootstrap" or "bootstrap 
clean" everything worked fine.

For reference, my current MAVEN_OPTS is set as follows:

set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m -Dmaven.repo.local=c:/m2repo

> 
> Jacek
> 

Mime
View raw message