There are two Hudson jobs:
(1) with a clean maven repo at the start of every build
(
http://hudson.glassfish.org/job/gf-trunk-build-continuous/)
(2) using an exising maven repo in every build
(
http://hudson.glassfish.org/job/gf-trunk-build-dev/)
Both jobs are compiling fine. If there is an issue with out-of-sync
remote Maven repo, one of job would fail.
You don't really need to clean your local maven repo, unless something
is screw-up in your local workspace.
Jane
Lloyd Chambers wrote:
> Sounds like a good practice.
>
> However, the build was crashing before I blew away the repo.
>
> Lloyd
>
> On Oct 29, 2009, at 11:35 AM, Rebecca Searls wrote:
>
>> > I blew away the maven repository and it then built.
>> This is an important info point. Because you started
>> with a clean repository, it pulled in something that
>> the others are out of sync with. If the others
>> removed their local repositories and built they
>> most likely would start having the same problem.
>>
>>
>> I've had this happen on several occasions on another
>> project.
>>
>> Removing the repository and then building should be incorporated
>> into the stnd build cycle in the future as a means to catch these
>> issues. Doing it once a week or once a month would be prudent.
>>
>>
>>
>>
>> Lloyd Chambers wrote:
>>> My hardware is rock solid.
>>> I blew away the maven repository and it then built.
>>> Lloyd
>>> On Oct 29, 2009, at 9:47 AM, Jerome Dochez wrote:
>>>> passed on SL too, different machine.
>>>> maybe a hardware issue on your end...
>>>>
>>>> On Oct 29, 2009, at 9:08 AM, Lloyd Chambers wrote:
>>>>
>>>>> Sometimes it's:
>>>>>
>>>>> Running com.sun.enterprise.configapi.tests.JavaConfigSubTypesTest
>>>>> Segmentation fault
>>>>>
>>>>>
>>>>> On Oct 29, 2009, at 9:00 AM, Lloyd Chambers wrote:
>>>>>
>>>>>> Still happens after 'svn up' and 'clean'.
>>>>>>
>>>>>> llcMule-2:code llc$ mvn -version
>>>>>> Maven version: 2.0.9
>>>>>> Java version: 1.6.0_15
>>>>>> OS name: "mac os x" version: "10.6.1" arch: "x86_64" Family: "mac"
>>>>>>
>>>>>>
>>>>>> llcMule-2:code llc$ java -version
>>>>>> java version "1.6.0_15"
>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
>>>>>> llcMule-2:code llc$
>>>>>>
>>>>>> On Oct 29, 2009, at 8:58 AM, Lloyd Chambers wrote:
>>>>>>
>>>>>>> Network listener http-listener-1
>>>>>>> Network listener http-listener-2
>>>>>>> Network listener admin-listener
>>>>>>> Network listener Funky-Listener
>>>>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>>>>> 0.068 sec
>>>>>>> Running com.sun.enterprise.configapi.tests.TranslatedValuesTest
>>>>>>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>>>>> 0.001 sec
>>>>>>> Running
>>>>>>> com.sun.enterprise.configapi.tests.dvt.JdbcConnectionPoolDefaultsTest
>>>>>>>
>>>>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>>>>> 0.011 sec
>>>>>>> Running com.sun.enterprise.configapi.tests.TransactionCallBackTest
>>>>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>>>>> 0.023 sec
>>>>>>> Running
>>>>>>> com.sun.enterprise.configapi.tests.DuplicateKeyedElementTest
>>>>>>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>>>>> 0.004 sec
>>>>>>> Running com.sun.enterprise.configapi.tests.JavaConfigSubTypesTest
>>>>>>>
>>>>>>> Trace/BPT trap
>>>>>>> cp: ./target/*.jar: No such file or directory
>>>>>>> cp: */target/*.jar: No such file or directory
>>>>>>> --- Copying jars to /v3/glassfishv3/glassfish/modules ---
>>>>>>> DONE
>>>>>>>
>>>>>>
>>>>>> Lloyd Chambers
>>>>>> lloyd.chambers_at_sun.com
>>>>>> GlassFish Team
>>>>>>
>>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>