Hi list,
first of all, thank you very much for the Maven repo clean/unify operations.
If I’m not wrong, the snapshots on refractions and on osgeo were deployed using the uniqueVersion maven tag set to false, resulting in jars having names like as artifact-2.5-SNAPSHOT.jar
The OpenGeo repo contains instead jars with date-versioned names: (gt-coverage-2.5-20090224.051344-1.jar, gt-coverage-2.5-20090224.174133-2.jar, …, gt-coverage-2.5-20090508.060149-6.jar). I guess uniqueVersion is set to true (by default).
Is this a desired setting?
Regards,
Daniele
–
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
Hmmm... as far as I know this is not needed but I could be wrong. The only upside I see is that we can go back in time to go back to past snapshots, which i have never had to do. The downside I see is a lot of wasted space on the server :).
+1 on making uniqueVersion false unless someone has a reason for it.
-Justin
Daniele Romagnoli wrote:
Hi list,
first of all, thank you very much for the Maven repo clean/unify operations.
If I'm not wrong, the snapshots on refractions and on osgeo were deployed using the uniqueVersion maven tag set to false, resulting in jars having names like as artifact-2.5-SNAPSHOT.jar
The OpenGeo repo contains instead jars with date-versioned names: (gt-coverage-2.5-20090224.051344-1.jar, gt-coverage-2.5-20090224.174133-2.jar, ..., gt-coverage-2.5-20090508.060149-6.jar). I guess uniqueVersion is set to true (by default).
Is this a desired setting?
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
Hmmm... as far as I know this is not needed but I could be wrong. The only upside I see is that we can go back in time to go back to past snapshots, which i have never had to do. The downside I see is a lot of wasted space on the server :).
+1 on making uniqueVersion false unless someone has a reason for it.
The only reason that _might_ apply is having two maven working
at the same time, one downloading the other uploading.
Maybe the timestamped approach has less synch issues, but
I could not find anything related to this on the internet,
so it's probably just an idea of mine.
Soo... +1 to remove the timestamps
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hmmm… as far as I know this is not needed but I could be wrong. The only upside I see is that we can go back in time to go back to past snapshots, which i have never had to do. The downside I see is a lot of wasted space on the server :).
Moreover, the same “lot of jars” will be download on your local repo whenever you build geoserver 1.7.x with maven and new snapshots are available
Daniele
+1 on making uniqueVersion false unless someone has a reason for it.
-Justin
Daniele Romagnoli wrote:
Hi list,
first of all, thank you very much for the Maven repo clean/unify operations.
If I’m not wrong, the snapshots on refractions and on osgeo were deployed using the uniqueVersion maven tag set to false, resulting in jars having names like as artifact-2.5-SNAPSHOT.jar
The OpenGeo repo contains instead jars with date-versioned names: (gt-coverage-2.5-20090224.051344-1.jar, gt-coverage-2.5-20090224.174133-2.jar, …, gt-coverage-2.5-20090508.060149-6.jar). I guess uniqueVersion is set to true (by default).
Is this a desired setting?
Regards,
Daniele
–
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there’s a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you’ll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
+1 also for me (Although my vote doesn't have validity )
On Fri, May 8, 2009 at 3:59 PM, Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:
Hmmm... as far as I know this is not needed but I could be wrong.
The only upside I see is that we can go back in time to go back to
past snapshots, which i have never had to do. The downside I see is
a lot of wasted space on the server :).
Moreover, the same "lot of jars" will be download on your local repo whenever you build geoserver 1.7.x with maven and new snapshots are available
Hmmm... as far as I remember SNAPSHOT dependencies are checked on
the repo are checked once a day no matter what, even if they are not
timestamped.
Not sure what the timestamp effect is... will it force redownload
no matter what? Not sure, I usually build everything before
starting to work and afaik I'm not getting more snapshots downloaded
during the day, but it may be the result of the time the build
box generates those snapshots
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
The use of date stamped snapshots has broken the udig build (where it
grabs the jars using maven; but then references them by name after
that - since the jars no longer end in 2.6-SNAPSHOT it has to be
manually corrected each time).
Jody
On Sat, May 9, 2009 at 1:02 AM, Andrea Aime <aaime@anonymised.com> wrote:
Daniele Romagnoli ha scritto:
+1 also for me (Although my vote doesn't have validity )
On Fri, May 8, 2009 at 3:59 PM, Justin Deoliveira <jdeolive@anonymised.com
<mailto:jdeolive@anonymised.com>> wrote:
Hmmm\.\.\. as far as I know this is not needed but I could be wrong\.
The only upside I see is that we can go back in time to go back to
past snapshots, which i have never had to do\. The downside I see is
a lot of wasted space on the server :\)\.
Moreover, the same "lot of jars" will be download on your local repo
whenever you build geoserver 1.7.x with maven and new snapshots are
available
Hmmm... as far as I remember SNAPSHOT dependencies are checked on
the repo are checked once a day no matter what, even if they are not
timestamped.
Not sure what the timestamp effect is... will it force redownload
no matter what? Not sure, I usually build everything before
starting to work and afaik I'm not getting more snapshots downloaded
during the day, but it may be the result of the time the build
box generates those snapshots
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Just to confirm this issue is still very much alive.
I asked justin to kick this build again before he went to sleep.
Apparently server problems prevented it being fixed yesterday.
If anyone has word please keep geotools-devel in the loop - Day 2
without snapshots. Who do I need to talk to for http://repo.opengeo.org webdav access? I do not mind doing an deploy
from here...
Jody
On Mon, May 11, 2009 at 3:22 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
+1 (and more!)
The use of date stamped snapshots has broken the udig build (where it
grabs the jars using maven; but then references them by name after
that - since the jars no longer end in 2.6-SNAPSHOT it has to be
manually corrected each time).
Jody
On Sat, May 9, 2009 at 1:02 AM, Andrea Aime <aaime@anonymised.com> wrote:
Daniele Romagnoli ha scritto:
+1 also for me (Although my vote doesn't have validity )
On Fri, May 8, 2009 at 3:59 PM, Justin Deoliveira <jdeolive@anonymised.com
<mailto:jdeolive@anonymised.com>> wrote:
Hmmm\.\.\. as far as I know this is not needed but I could be wrong\.
The only upside I see is that we can go back in time to go back to
past snapshots, which i have never had to do\. The downside I see is
a lot of wasted space on the server :\)\.
Moreover, the same "lot of jars" will be download on your local repo
whenever you build geoserver 1.7.x with maven and new snapshots are
available
Hmmm... as far as I remember SNAPSHOT dependencies are checked on
the repo are checked once a day no matter what, even if they are not
timestamped.
Not sure what the timestamp effect is... will it force redownload
no matter what? Not sure, I usually build everything before
starting to work and afaik I'm not getting more snapshots downloaded
during the day, but it may be the result of the time the build
box generates those snapshots
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Looks like the deploy went OK last night, and I just fired another one off and looks fine. Hopefully this problem is fixed for the time being.
-Justin
Jody Garnett wrote:
Just to confirm this issue is still very much alive.
I asked justin to kick this build again before he went to sleep.
Apparently server problems prevented it being fixed yesterday.
If anyone has word please keep geotools-devel in the loop - Day 2
without snapshots. Who do I need to talk to for http://repo.opengeo.org webdav access? I do not mind doing an deploy
from here...
Jody
On Mon, May 11, 2009 at 3:22 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
+1 (and more!)
The use of date stamped snapshots has broken the udig build (where it
grabs the jars using maven; but then references them by name after
that - since the jars no longer end in 2.6-SNAPSHOT it has to be
manually corrected each time).
Jody
On Sat, May 9, 2009 at 1:02 AM, Andrea Aime <aaime@anonymised.com> wrote:
Daniele Romagnoli ha scritto:
+1 also for me (Although my vote doesn't have validity )
On Fri, May 8, 2009 at 3:59 PM, Justin Deoliveira <jdeolive@anonymised.com
<mailto:jdeolive@anonymised.com>> wrote:
Hmmm... as far as I know this is not needed but I could be wrong.
The only upside I see is that we can go back in time to go back to
past snapshots, which i have never had to do. The downside I see is
a lot of wasted space on the server :).
Moreover, the same "lot of jars" will be download on your local repo
whenever you build geoserver 1.7.x with maven and new snapshots are
available
Hmmm... as far as I remember SNAPSHOT dependencies are checked on
the repo are checked once a day no matter what, even if they are not
timestamped.
Not sure what the timestamp effect is... will it force redownload
no matter what? Not sure, I usually build everything before
starting to work and afaik I'm not getting more snapshots downloaded
during the day, but it may be the result of the time the build
box generates those snapshots
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
)