As asked in an email two days ago, and also asked a few months ago when the tag name policy change
was first proposed.
http://svn.geotools.org/geotools/tags/
The (wanted) side effect is that tags are properly ordered when displayed in
alphabetical order.
I hope that I didn't disturbed any
Bryce L Nordgren a écrit :
It may be easier to delete the branch and recreate it (possibly with
the same name), just for making
easier to track the changes done after the merge.
Ahh, but we're not merging the in-progress ISO stuff to trunk, meaning that
the ISO work would disappear with a delet
Martin Desruisseaux a écrit :
Do you get the same exception when running "mvn install" and "mvn
org.geotools:gt2-javadoc:javadoc" both on trunk?
(I mean on a fresh trunk checkout - I fixed a bug similar to this one a few
days ago).
Martin.
---
Richard Gould a écrit :
I tried a mvn install on trunk and then went to my 2.2-RC3 checkout.
Executing mvn org.geotools:gt2-javadoc:javadoc yields this exception:
[...snip...]
[DEBUG] Trace java.lang.NullPointerException
Cory Horner a écrit :
At a glance it looked like:
r19455 | rgould | 2006-05-11 13:57:44 -0700 (Thu, 11 May 2006) | 1 line
[maven-release-plugin] prepare release 2.2-RC3
was responsible... but upon review, perhaps it was:
r19418 | rgould | 2006-05-09 17:18:21 -0700 (Tue, 09 May 2006) | 1 line
[
[EMAIL PROTECTED] wrote on 05/18/2006 02:06:47 AM:
> I need to vote +0 until I see enough names on that page so that the mid
> June deadline can be met? I had an informal talk with Chris and Jesse
> about other ways in which the community can move forward. The long and
> short of it is that we m
Martin Desruisseaux wrote:
Richard Gould a écrit :
The poms are changed whenever maven release:prepare is executed, but
they do not change the formatting. I had a look at the diff for the
commit and it just changes version numbers.
Just checked. It is true that the poms are almost the same
Martin Desruisseaux <[EMAIL PROTECTED]> wrote on 05/18/2006
01:09:53 AM:
> Bryce L Nordgren a écrit :
> > Just leave the coverage branch in place when you're done merging. :)
>
> It may be easier to delete the branch and recreate it (possibly with
> the same name), just for making
> easier to tr
Yeah I checked the logw and it looks good. A good candidate for the
guinea pig datastore.
-Justin
Jesse Eichar wrote:
shapefile and indexed shapefile are both synched up with trunk.
Jesse
On 18-May-06, at 9:44 AM, Justin Deoliveira wrote:
Hi guys,
I have started a rough datastore porting
shapefile and indexed shapefile are both synched up with trunk.
Jesse
On 18-May-06, at 9:44 AM, Justin Deoliveira wrote:
Hi guys,
I have started a rough datastore porting guide for FM. Its pretty
bare right now as nothing has been ported yet :).
http://docs.codehaus.org/display/GEOTOOLS/F
Jody has been going through and creating pages for each geotools module.
I have reviewed the following pages and they look pretty good.
http://docs.codehaus.org/display/GEOTOOLS/Feature
http://docs.codehaus.org/display/GEOTOOLS/Style
http://docs.codehaus.org/display/GEOTOOLS/Filter
The followin
Hi guys,
I have started a rough datastore porting guide for FM. Its pretty bare
right now as nothing has been ported yet :).
http://docs.codehaus.org/display/GEOTOOLS/FM+DataStore+Port+Guide
The first thing I am concerned with is getting the most up-to-date
module with all the latest improve
Martin Desruisseaux wrote:
Richard Gould a écrit :
The poms are changed whenever maven release:prepare is executed, but
they do not change the formatting. I had a look at the diff for the
commit and it just changes version numbers.
Just checked. It is true that the poms are almost the same be
Martin Desruisseaux wrote:
Should we send a request to the source forge tracker (link at the
bottom of forwarded email) asking them to delete the content of
/home/groups/g/ge/geotools/ ? We are unable to delete them ourself
because we don't have the requested files ownership.
I think so, we may
Richard Gould a écrit :
The poms are changed whenever maven release:prepare is executed, but
they do not change the formatting. I had a look at the diff for the
commit and it just changes version numbers.
Just checked. It is true that the poms are almost the same between 2.2.x and 2.2-RC3. But
Richard Gould a écrit :
Can I perform the following operations there?
http://svn.geotools.org/geotools/tags/
- Delete "2.2.RC3" sinced it is replaced by "2.2-RC3".
Certainly
Done.
- Rename all tags like "2.2.M2" by "2.2-M2".
Sounds okay to me. I don't think anything points to them. But
Should we send a request to the source forge tracker (link at the bottom of forwarded email) asking
them to delete the content of /home/groups/g/ge/geotools/ ? We are unable to delete them ourself
because we don't have the requested files ownership.
Martin.
--- Begin Message ---
Greetin
Cory Horner wrote:
As per http://docs.codehaus.org/display/GEOTOOLS/Coverage+Branch+Merge
...aiming for a mid-June (16th) completion of the merge onto trunk
(2.3.x), starting now.
So Cory does that mean you have time to work on it?
I need to vote +0 until I see enough names on that page so tha
Bryce L Nordgren a écrit :
Just leave the coverage branch in place when you're done merging. :)
It may be easier to delete the branch and recreate it (possibly with the same name), just for making
easier to track the changes done after the merge.
Martin.
---
19 matches
Mail list logo
