You don't need to to wipe out local maven repository regularly. The
Hudson continuous dev job has been running with the same maven
repository for months now. But if you start seeing unusual slowness or
failures with the build and it's not related to your code changes, first
check if Hudson jobs are passing before removing the bad artifact from
your local maven repo.
Byron Nevins wrote:
> I remember >= 1 year ago and we had to wipe out the maven repo all the
> time. Now I go for month after month w/o touching it. Is that bad?
> Should I wipe it out regularly?
>
>
> On 5/20/2010 4:59 PM, Jane Young wrote:
>> You need to do this just once. Once you have the updated artifact,
>> your build should should be fine.
>>
>>
>> Byron Nevins wrote:
>>> Thanks for the tip. I put a new line into my maven scripts, in case
>>> it is like a bad penny and keeps coming back...
>>>
>>>
>>> *rm -rf C:\mvnrepo\javax\faces\jsf-api\1.1_02
>>> *
>>> On 5/19/2010 9:10 PM, Jerome Dochez wrote:
>>>> Note : Ed, Roger and Ryan please read this through...
>>>>
>>>> I have been annoyed by a build problem that has bothered me for a long time. Today, my patience ran out and I decided to look at it.
>>>>
>>>> The problem :
>>>>
>>>> when building the glassfish admin gui package, the build get stuck for quite some time trying to download a dependency :
>>>>
>>>> [INFO] ------------------------------------------------------------------------
>>>> [INFO] Building in /Users/dochez/java/svn/v3/packager/glassfish-gui
>>>> [INFO] ------------------------------------------------------------------------
>>>> [INFO] [clean:clean {execution: auto-clean}]
>>>> [INFO] [resources:resources]
>>>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>>>> [INFO] Copying 1 resource
>>>> [INFO] [bundle:manifest {execution: bundle-manifest}]
>>>> [WARNING] Ignoring project type distribution-base-zip - supportedProjectTypes = [hk2-jar, bundle]
>>>> [INFO] [hk2:hk2-test-compile]
>>>> [INFO] No sources to compile
>>>> [INFO] [surefire:test]
>>>> [INFO] No tests to run.
>>>> [INFO] [antrun-extended:run]
>>>> [INFO] Executing tasks
>>>>
>>>> create.package:
>>>> [INFO] snapshot org.glassfish.admingui:war:3.1-SNAPSHOT: checking for updates from glassfish-repo-archive
>>>> Downloading: http://maven.glassfish.org/content/groups/glassfish/javax/servlet/jsp/jstl/jstl/1.1/jstl-1.1.pom
>>>>
>>>>
>>>> that dependency is never resolved and an attempt is made at each build which depending on your network performance can waste easily 30 seconds.
>>>>
>>>> The cause :
>>>>
>>>> the javax/faces/faces-api version 1.1_02 version I have in my local repository is indeed :
>>>>
>>>> /Users/dochez/.m2/repository/javax/faces/jsf-api/1.1_02
>>>>
>>>> and imports that dubious dependency :
>>>>
>>>> <dependency>
>>>> <groupId>javax.servlet.jsp.jstl</groupId>
>>>> <artifactId>jstl</artifactId>
>>>> <version>1.1</version>
>>>> </dependency>
>>>>
>>>> I am still at a loss why not resolving the dependency did not cause a general build failure but let's move on...
>>>>
>>>> The Solution :
>>>>
>>>> Well, I got lucky, while experimenting, I decided to remove the jsf-api directory from my local directory to see who was importing that version 1.1_02 and maybe upgrade it to 1.2.x
>>>>
>>>> so here I go :
>>>>
>>>> rm -rf /Users/dochez/.m2/repository/javax/faces/jsf-api/
>>>>
>>>> and run the build again. Oh Surprise the build does not show this attempt to download my jstl pom file. What the ?????
>>>>
>>>> The understanding :
>>>>
>>>> someone had the good idea to fix the problem (by fixing the pom) *but* had the bad idea of republishing the jsf-api jar and pom without changing the version number, so now the same pom does not have a single dependency any longer !
>>>>
>>>> The Morale :
>>>>
>>>> just manually clean up your local repo : rm -rf /Users/dochez/.m2/repository/javax/faces/jsf-api/1.1_02
>>>> and the next build will be a bit faster.
>>>>
>>>> Now, Ed, Roger and Ryan, I am not sure who of you did republish a different jar with the same version number but I hope that by now you and others have figured out how much of a bad idea this is...
>>>>
>>>> grumble.
>>>> jerome
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>
>>> --
>>> Byron Nevins - Oracle Corporation
>>> Home: 650-359-1290
>>> Cell: 650-784-4123
>>> Sierra: 209-295-2188
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
>>> additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> --
> Byron Nevins - Oracle Corporation
> Home: 650-359-1290
> Cell: 650-784-4123
> Sierra: 209-295-2188
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: dev-help_at_glassfish.dev.java.net