[Geoserver-devel] cleaning out 2.4-SNAPSHOT on lists.refractions.net

Hi all,

Would anyone object to clearing out the 2.4 snapshot directory on lists.refractions.net. For the last few weeks we can have constantly had problems with users trying to build GEoServer from geotools snapshot jars which were are deploying nightly.

My only guess as to what is going on is perhaps switching maven versions has somehow thrown the metadata out of wack and old jars are continuing to be downloaded.

So any objections to cleaning out all the 2.4-SNAPSHOT directories?

-Justin

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

Hi all,

Would anyone object to clearing out the 2.4 snapshot directory on lists.refractions.net. For the last few weeks we can have constantly had problems with users trying to build GEoServer from geotools snapshot jars which were are deploying nightly.

My only guess as to what is going on is perhaps switching maven versions has somehow thrown the metadata out of wack and old jars are continuing to be downloaded.

So any objections to cleaning out all the 2.4-SNAPSHOT directories?

None. Yet, I'm wondering... are we the only ones to deploy jars there?
Could it be a partially broken build box somewhere that deploys
old jars there? By partially broken, I mean one that fails to "svn up"
before the build, and as a result keeps on building the same old
checkout.

Cheers
andrea

None. Yet, I'm wondering... are we the only ones to deploy jars there?
Could it be a partially broken build box somewhere that deploys
old jars there? By partially broken, I mean one that fails to "svn up"
before the build, and as a result keeps on building the same old
checkout.

Its a possibility... although the only other build box that i know of is the one at refractions. I asked cory last week and he stated that they are not uploading 2.4 snapshots. Cory can you verify this?

Cheers
andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4007,469257bc40171961014482!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira wrote:

Its a possibility... although the only other build box that i know of is the one at refractions. I asked cory last week and he stated that they are not uploading 2.4 snapshots. Cory can you verify this?

We are not deploying snapshots, but are deploying "site". I checked the "other" refractions build box, and it is not deploying either.

Will deleting stuff from the repository be beneficial? In my experiment I see the jars getting pulled off of the rackmount correctly. Is the problem intermittent?

I did a test run of the geoserver build after wiping out the geotools section of my maven repo, but ran into problems -- first with a test failure, then with versioned wfs not being able to find org.geotools.maven:gt2-xmlcodegen. Maven 2.0.6 may be responsible for the test "failure", not sure how anyone is getting past the undeployed geotools.maven dependency.

Cory.

Cory Horner wrote:

Justin Deoliveira wrote:

Its a possibility... although the only other build box that i know of is the one at refractions. I asked cory last week and he stated that they are not uploading 2.4 snapshots. Cory can you verify this?

We are not deploying snapshots, but are deploying "site". I checked the "other" refractions build box, and it is not deploying either.

Will deleting stuff from the repository be beneficial? In my experiment I see the jars getting pulled off of the rackmount correctly. Is the problem intermittent?

No idea... I am kind of just guessing on this one. My experience with maven is that sometimes anything is worth a try.

I did a test run of the geoserver build after wiping out the geotools section of my maven repo, but ran into problems -- first with a test failure, then with versioned wfs not being able to find org.geotools.maven:gt2-xmlcodegen.

Thats an issue with the geoserver pom not listing lists.refractions.net as a plugin repository as well as a normal repository.

Maven 2.0.6 may be responsible for

the test "failure", not sure how anyone is getting past the undeployed geotools.maven dependency.

Cory.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4007,469280ea120491961014482!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira wrote:

Cory Horner wrote

Will deleting stuff from the repository be beneficial? In my experiment I see the jars getting pulled off of the rackmount correctly. Is the problem intermittent?

No idea... I am kind of just guessing on this one. My experience with maven is that sometimes anything is worth a try.

Whoa... here's a thought:

maven.geotools.fr uses rsync to mirror lists.refractions.net; if a user happens to ask maven.geotools.fr for an update before it is synchronized with refractions, that *could* explain what we're seeing. Martin: what's your update cycle?

Also, I see a contradiction in the repositories section of the geoserver trunk pom: snapshots enabled = true vs false for refractions and geotools.fr, respectively. Who knows how maven really behaves under this case..?!

Cheers,
Cory.

Cory Horner wrote:

Justin Deoliveira wrote:

Cory Horner wrote

Will deleting stuff from the repository be beneficial? In my experiment I see the jars getting pulled off of the rackmount correctly. Is the problem intermittent?

No idea... I am kind of just guessing on this one. My experience with maven is that sometimes anything is worth a try.

Whoa... here's a thought:

maven.geotools.fr uses rsync to mirror lists.refractions.net; if a user happens to ask maven.geotools.fr for an update before it is synchronized with refractions, that *could* explain what we're seeing. Martin: what's your update cycle?

I thought about that... but i wiped out my geotools repo today and verified that it downlaoded the jar from the refractions repo.

Also, I see a contradiction in the repositories section of the geoserver trunk pom: snapshots enabled = true vs false for refractions and geotools.fr, respectively. Who knows how maven really behaves under this case..?!

Hmmm... yeah i guess we could enable snapshots on the mirror. But as you say depending on the update cycle this could cause stale jars to be downloaded.

Can we please just try killing the current metadata that is there and see what happens :slight_smile:

Cheers,
Cory.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,4692c7fe230951628642973!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Cory Horner a écrit :

maven.geotools.fr uses rsync to mirror lists.refractions.net; if a user happens to ask maven.geotools.fr for an update before it is synchronized with refractions, that *could* explain what we're seeing. Martin: what's your update cycle?

Manual, so irregular...

Just asked to our administrator to put that task in a crontable. I should have done this long before...

  Martin