You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/09/29 12:49:12 UTC
Proposed branches
A few weeks ago, we talked about a JDK7 branch, which I would like to
create in the next few days if no one object. However there is an other
potential branch to consider.
With the recent commit of InternationalString implementations, I'm
reaching the point where I would start using the geoapi-conformance
module. This module provides tests, but also a large amount of
validation methods:
http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/Validators.html#method_summary
However a majority of tests and many of those validation methods were
developed after the geoapi-3.0.0 release. They are available only on
geoapi snapshots or milestones. According
http://www.apache.org/dev/repository-faq.html#thirdparty we could depend
on geoapi-snapshot for Apache SIS snapshots, but not for the releases.
So I would like to have the following branches, if peoples accept:
* branches/jdk-7 would be my development branch, using geoapi snapshot
or a milestone.
* trunk would be a port of branches/jdk7, still using geoapi snapshot
or milestone.
* branches/geoapi-3.0 would be the trunk with the geoapi-snapshot
dependency replaced by geoapi-3.0. This would have few impact on the
functionalities, but would lost many tests.
Later we could create branches/geoapi-3.1, branches/geoapi-3.2, etc.
since I would like to support older GeoAPI versions for users who want a
very stable API. The Apache SIS releases would be created from those
branches/geoapi-3.x lines.
We experimented those branches on Mercurial for the Geotk project for
more than one year, and it worked well so far.
What do peoples think?
Martin
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
+1 this approach sounds good to me!
When the time comes for me to try and commit some code or whatever
soon, then I'm sure I'll need your guidance again on where to commit
so I don't mess stuff up, but let's proceed! :)
Cheers,
Chris
On Sep 29, 2012, at 3:49 AM, Martin Desruisseaux wrote:
> A few weeks ago, we talked about a JDK7 branch, which I would like to create in the next few days if no one object. However there is an other potential branch to consider.
>
> With the recent commit of InternationalString implementations, I'm reaching the point where I would start using the geoapi-conformance module. This module provides tests, but also a large amount of validation methods:
>
> http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/Validators.html#method_summary
>
> However a majority of tests and many of those validation methods were developed after the geoapi-3.0.0 release. They are available only on geoapi snapshots or milestones. According http://www.apache.org/dev/repository-faq.html#thirdparty we could depend on geoapi-snapshot for Apache SIS snapshots, but not for the releases. So I would like to have the following branches, if peoples accept:
>
> * branches/jdk-7 would be my development branch, using geoapi snapshot
> or a milestone.
> * trunk would be a port of branches/jdk7, still using geoapi snapshot
> or milestone.
> * branches/geoapi-3.0 would be the trunk with the geoapi-snapshot
> dependency replaced by geoapi-3.0. This would have few impact on the
> functionalities, but would lost many tests.
>
>
> Later we could create branches/geoapi-3.1, branches/geoapi-3.2, etc. since I would like to support older GeoAPI versions for users who want a very stable API. The Apache SIS releases would be created from those branches/geoapi-3.x lines.
>
> We experimented those branches on Mercurial for the Geotk project for more than one year, and it worked well so far.
>
> What do peoples think?
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1 from me!
Cheers,
Chris
On Oct 1, 2012, at 10:19 AM, Martin Desruisseaux wrote:
> Before to apply the new proposed version number, would it be okay to take the opportunity for renaming the current "sis-core" module into "sis-referencing"? This is because most classes in "sis-core" (except maybe the QuadTree) seem related to referencing. The "sis-referencing" name would anticipate the merging of Geotk referencing framework.
>
> Martin
>
>
> Le 01/10/12 00:32, Mattmann, Chris A (388J) a écrit :
>> Hey Martin,
>>
>> +1 works for me!
>>
>> Cheers,
>> Chris
>>
>> On Sep 30, 2012, at 4:39 AM, Martin Desruisseaux wrote:
>>> One related question: would it be okay if I rename the version number, currently "0.3-SNAPSHOT", to "0.3-geoapi3.0-SNAPSHOT"? The reason is that I would like to maintains SIS releases for GeoAPI 3.0, 3.1, etc. The SIS releases would be "0.3-geoapi3.0", "0.4-geoapi3.0", "0.4-geoapi3.1", etc. This would be a little bit similar to the PostgreSQL driver, which has "9.1-901.jdbc4" and "9.1-901.jdbc3" releases.
>>>
>>> So the branches and version numbers would be:
>>>
>>> trunk : 0.3-geoapi3.0-SNAPSHOT
>>> branches/jdk6 : 0.3-jdk6-SNAPSHOT
>>> branches/jdk7 : 0.3-jdk7-SNAPSHOT
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Before to apply the new proposed version number, would it be okay to
take the opportunity for renaming the current "sis-core" module into
"sis-referencing"? This is because most classes in "sis-core" (except
maybe the QuadTree) seem related to referencing. The "sis-referencing"
name would anticipate the merging of Geotk referencing framework.
Martin
Le 01/10/12 00:32, Mattmann, Chris A (388J) a écrit :
> Hey Martin,
>
> +1 works for me!
>
> Cheers,
> Chris
>
> On Sep 30, 2012, at 4:39 AM, Martin Desruisseaux wrote:
>> One related question: would it be okay if I rename the version number, currently "0.3-SNAPSHOT", to "0.3-geoapi3.0-SNAPSHOT"? The reason is that I would like to maintains SIS releases for GeoAPI 3.0, 3.1, etc. The SIS releases would be "0.3-geoapi3.0", "0.4-geoapi3.0", "0.4-geoapi3.1", etc. This would be a little bit similar to the PostgreSQL driver, which has "9.1-901.jdbc4" and "9.1-901.jdbc3" releases.
>>
>> So the branches and version numbers would be:
>>
>> trunk : 0.3-geoapi3.0-SNAPSHOT
>> branches/jdk6 : 0.3-jdk6-SNAPSHOT
>> branches/jdk7 : 0.3-jdk7-SNAPSHOT
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
+1 works for me!
Cheers,
Chris
On Sep 30, 2012, at 4:39 AM, Martin Desruisseaux wrote:
> One related question: would it be okay if I rename the version number, currently "0.3-SNAPSHOT", to "0.3-geoapi3.0-SNAPSHOT"? The reason is that I would like to maintains SIS releases for GeoAPI 3.0, 3.1, etc. The SIS releases would be "0.3-geoapi3.0", "0.4-geoapi3.0", "0.4-geoapi3.1", etc. This would be a little bit similar to the PostgreSQL driver, which has "9.1-901.jdbc4" and "9.1-901.jdbc3" releases.
>
> So the branches and version numbers would be:
>
> trunk : 0.3-geoapi3.0-SNAPSHOT
> branches/jdk6 : 0.3-jdk6-SNAPSHOT
> branches/jdk7 : 0.3-jdk7-SNAPSHOT
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
One related question: would it be okay if I rename the version number,
currently "0.3-SNAPSHOT", to "0.3-geoapi3.0-SNAPSHOT"? The reason is
that I would like to maintains SIS releases for GeoAPI 3.0, 3.1, etc.
The SIS releases would be "0.3-geoapi3.0", "0.4-geoapi3.0",
"0.4-geoapi3.1", etc. This would be a little bit similar to the
PostgreSQL driver, which has "9.1-901.jdbc4" and "9.1-901.jdbc3" releases.
So the branches and version numbers would be:
trunk : 0.3-geoapi3.0-SNAPSHOT
branches/jdk6 : 0.3-jdk6-SNAPSHOT
branches/jdk7 : 0.3-jdk7-SNAPSHOT
Martin
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 01/10/12 02:01, Adam Estrada a écrit :
> Cool! The goal is to make this project accessible to as many developers as possible so pre-baking multiple IDE options is a great idea.
Thanks! I went ahead for NetBeans. I also added a page explaining that
(to appear after Jenkins finish its build):
https://builds.apache.org/job/sis-trunk/site/develop.html
I also added a section "Developing Apache SIS" with material adapted
from Geotk. It contains recommendations about background knowledge in
GIS, OGC/ISO, Java and mathematics. Please feel free to edit if some
text are not appropriate.
Martin
Re: Proposed branches
Posted by Adam Estrada <es...@gmail.com>.
Cool! The goal is to make this project accessible to as many developers as possible so pre-baking multiple IDE options is a great idea.
a
On Sep 30, 2012, at 12:08 PM, Mattmann, Chris A (388J) wrote:
> Hey Martin,
>
> Yeah I could potentially do one for Eclipse it just is a .project file and a .classpath file.
>
> I'll investigate it :)
>
> Cheers,
> Chris
>
> On Sep 30, 2012, at 4:27 PM, Martin Desruisseaux wrote:
>
>> Le 01/10/12 00:06, Adam Estrada a écrit :
>>> I am all for this! I use Eclipse and sometimes getting the project set up from pure Maven is a real pain. What do you suggest the best path to implement this is for NetBeans, Eclipse, Idea, etc? Are there other projects out there that do this that we can take a look at?
>>
>> For NetBeans I think that a good path is simply to commit the proposed ide-project/NetBeans directory. Users can open this project directly in NetBeans without any configuration, provided they have run "mvn install" at least once before. We did that for GeoAPI.
>>
>> For Eclipse and Idea, it would be nice if we could put all their files in ide-project/Eclipse and ide-project/Idea directories, but I don't know if those IDE allow that. I think that a few years ago, Eclipse projects were made of ".classpath" files spread in many source code directories. I don't know if it still the case today. I don't know neither how Idea projects are structured. We would need advice from Eclipse/Idea users here...
>>
>> Martin
>>
>>
>>> On Sep 29, 2012, at 11:58 PM, Martin Desruisseaux wrote:
>>>> One last question: since I work on NetBeans, I have an "ide-project/NetBeans" directory with NetBeans project configuration files. This configuration is not specific to my machine; it is designed in a way that should make it possible to anyone to open it (NetBeans stores user-specific information in a separated directory called "private"). It is not a replacement to Maven; actually Maven must be run at least once before to open the project, because the project refers to some files produced by Maven.
>>>>
>>>> While NetBeans can open natively Maven projects, NetBeans projects are faster to debug and contains information not found in Maven projects, for example the words added to the spell-checker for the SIS javadoc. Would it be okay if I commit a clean (user-neutral) "ide-project/NetBeans" directory, excluding of course the "private" sub-directory? Maybe something similar could be done in an "ide-project/Eclipse" directory if someone wish.
>>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
Yeah I could potentially do one for Eclipse it just is a .project file and a .classpath file.
I'll investigate it :)
Cheers,
Chris
On Sep 30, 2012, at 4:27 PM, Martin Desruisseaux wrote:
> Le 01/10/12 00:06, Adam Estrada a écrit :
>> I am all for this! I use Eclipse and sometimes getting the project set up from pure Maven is a real pain. What do you suggest the best path to implement this is for NetBeans, Eclipse, Idea, etc? Are there other projects out there that do this that we can take a look at?
>
> For NetBeans I think that a good path is simply to commit the proposed ide-project/NetBeans directory. Users can open this project directly in NetBeans without any configuration, provided they have run "mvn install" at least once before. We did that for GeoAPI.
>
> For Eclipse and Idea, it would be nice if we could put all their files in ide-project/Eclipse and ide-project/Idea directories, but I don't know if those IDE allow that. I think that a few years ago, Eclipse projects were made of ".classpath" files spread in many source code directories. I don't know if it still the case today. I don't know neither how Idea projects are structured. We would need advice from Eclipse/Idea users here...
>
> Martin
>
>
>> On Sep 29, 2012, at 11:58 PM, Martin Desruisseaux wrote:
>>> One last question: since I work on NetBeans, I have an "ide-project/NetBeans" directory with NetBeans project configuration files. This configuration is not specific to my machine; it is designed in a way that should make it possible to anyone to open it (NetBeans stores user-specific information in a separated directory called "private"). It is not a replacement to Maven; actually Maven must be run at least once before to open the project, because the project refers to some files produced by Maven.
>>>
>>> While NetBeans can open natively Maven projects, NetBeans projects are faster to debug and contains information not found in Maven projects, for example the words added to the spell-checker for the SIS javadoc. Would it be okay if I commit a clean (user-neutral) "ide-project/NetBeans" directory, excluding of course the "private" sub-directory? Maybe something similar could be done in an "ide-project/Eclipse" directory if someone wish.
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 01/10/12 00:06, Adam Estrada a écrit :
> I am all for this! I use Eclipse and sometimes getting the project set up from pure Maven is a real pain. What do you suggest the best path to implement this is for NetBeans, Eclipse, Idea, etc? Are there other projects out there that do this that we can take a look at?
For NetBeans I think that a good path is simply to commit the proposed
ide-project/NetBeans directory. Users can open this project directly in
NetBeans without any configuration, provided they have run "mvn install"
at least once before. We did that for GeoAPI.
For Eclipse and Idea, it would be nice if we could put all their files
in ide-project/Eclipse and ide-project/Idea directories, but I don't
know if those IDE allow that. I think that a few years ago, Eclipse
projects were made of ".classpath" files spread in many source code
directories. I don't know if it still the case today. I don't know
neither how Idea projects are structured. We would need advice from
Eclipse/Idea users here...
Martin
> On Sep 29, 2012, at 11:58 PM, Martin Desruisseaux wrote:
>> One last question: since I work on NetBeans, I have an "ide-project/NetBeans" directory with NetBeans project configuration files. This configuration is not specific to my machine; it is designed in a way that should make it possible to anyone to open it (NetBeans stores user-specific information in a separated directory called "private"). It is not a replacement to Maven; actually Maven must be run at least once before to open the project, because the project refers to some files produced by Maven.
>>
>> While NetBeans can open natively Maven projects, NetBeans projects are faster to debug and contains information not found in Maven projects, for example the words added to the spell-checker for the SIS javadoc. Would it be okay if I commit a clean (user-neutral) "ide-project/NetBeans" directory, excluding of course the "private" sub-directory? Maybe something similar could be done in an "ide-project/Eclipse" directory if someone wish.
Re: Proposed branches
Posted by Adam Estrada <es...@gmail.com>.
I am all for this! I use Eclipse and sometimes getting the project set up from pure Maven is a real pain. What do you suggest the best path to implement this is for NetBeans, Eclipse, Idea, etc? Are there other projects out there that do this that we can take a look at?
Adam
On Sep 29, 2012, at 11:58 PM, Martin Desruisseaux wrote:
> One last question: since I work on NetBeans, I have an "ide-project/NetBeans" directory with NetBeans project configuration files. This configuration is not specific to my machine; it is designed in a way that should make it possible to anyone to open it (NetBeans stores user-specific information in a separated directory called "private"). It is not a replacement to Maven; actually Maven must be run at least once before to open the project, because the project refers to some files produced by Maven.
>
> While NetBeans can open natively Maven projects, NetBeans projects are faster to debug and contains information not found in Maven projects, for example the words added to the spell-checker for the SIS javadoc. Would it be okay if I commit a clean (user-neutral) "ide-project/NetBeans" directory, excluding of course the "private" sub-directory? Maybe something similar could be done in an "ide-project/Eclipse" directory if someone wish.
>
> Martin
>
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1 works for me!
Cheers,
Chris
On Sep 30, 2012, at 4:58 AM, Martin Desruisseaux wrote:
> One last question: since I work on NetBeans, I have an "ide-project/NetBeans" directory with NetBeans project configuration files. This configuration is not specific to my machine; it is designed in a way that should make it possible to anyone to open it (NetBeans stores user-specific information in a separated directory called "private"). It is not a replacement to Maven; actually Maven must be run at least once before to open the project, because the project refers to some files produced by Maven.
>
> While NetBeans can open natively Maven projects, NetBeans projects are faster to debug and contains information not found in Maven projects, for example the words added to the spell-checker for the SIS javadoc. Would it be okay if I commit a clean (user-neutral) "ide-project/NetBeans" directory, excluding of course the "private" sub-directory? Maybe something similar could be done in an "ide-project/Eclipse" directory if someone wish.
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
One last question: since I work on NetBeans, I have an
"ide-project/NetBeans" directory with NetBeans project configuration
files. This configuration is not specific to my machine; it is designed
in a way that should make it possible to anyone to open it (NetBeans
stores user-specific information in a separated directory called
"private"). It is not a replacement to Maven; actually Maven must be run
at least once before to open the project, because the project refers to
some files produced by Maven.
While NetBeans can open natively Maven projects, NetBeans projects are
faster to debug and contains information not found in Maven projects,
for example the words added to the spell-checker for the SIS javadoc.
Would it be okay if I commit a clean (user-neutral)
"ide-project/NetBeans" directory, excluding of course the "private"
sub-directory? Maybe something similar could be done in an
"ide-project/Eclipse" directory if someone wish.
Martin
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Yes, I think it is safer to take an approach that anyone can ignore if
they wish. I will experiment that one.
Martin
Le 30/09/12 02:07, Mattmann, Chris A (388J) a écrit :
> +1, this is also fine with me and since trunk probably makes more sense as the
> default stable release branch.
>
> Cheers,
> Chris
>
> On Sep 29, 2012, at 8:14 AM, Martin Desruisseaux wrote:
>
>> An alternative could be
>>
>> * branches/jdk7 - use geoapi-snapshot
>> * branches/jdk6 - use geoapi-snapshot
>> * trunk - use latest stable geoapi release
>>
>>
>> This was would be more natural for those who are not interested about all the stuff in my previous email, and "trunk" would be the basis of SIS releases as most peoples probably expect. Inconvenient is that "trunk" would have less test coverage than "branches/jdk6", but those tests are still executed on the branches (so they are just delayed).
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1, this is also fine with me and since trunk probably makes more sense as the
default stable release branch.
Cheers,
Chris
On Sep 29, 2012, at 8:14 AM, Martin Desruisseaux wrote:
> An alternative could be
>
> * branches/jdk7 - use geoapi-snapshot
> * branches/jdk6 - use geoapi-snapshot
> * trunk - use latest stable geoapi release
>
>
> This was would be more natural for those who are not interested about all the stuff in my previous email, and "trunk" would be the basis of SIS releases as most peoples probably expect. Inconvenient is that "trunk" would have less test coverage than "branches/jdk6", but those tests are still executed on the branches (so they are just delayed).
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
An alternative could be
* branches/jdk7 - use geoapi-snapshot
* branches/jdk6 - use geoapi-snapshot
* trunk - use latest stable geoapi release
This was would be more natural for those who are not interested about
all the stuff in my previous email, and "trunk" would be the basis of
SIS releases as most peoples probably expect. Inconvenient is that
"trunk" would have less test coverage than "branches/jdk6", but those
tests are still executed on the branches (so they are just delayed).
Martin
Re: Proposed branches
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1!
Cheers,
Chris
On Sep 29, 2012, at 3:53 AM, Martin Desruisseaux wrote:
> Le 29/09/12 19:49, Martin Desruisseaux a écrit :
>> * branches/jdk-7 would be my development branch, using geoapi snapshot
>> or a milestone.
> I mean the branch where I would do my developments (not a "reserved" branch).
>
>> * trunk would be a port of branches/jdk7, still using geoapi snapshot
>> or milestone.
> I mean a port to JDK6.
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Proposed branches
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 29/09/12 19:49, Martin Desruisseaux a écrit :
> * branches/jdk-7 would be my development branch, using geoapi snapshot
> or a milestone.
I mean the branch where I would do my developments (not a "reserved"
branch).
> * trunk would be a port of branches/jdk7, still using geoapi snapshot
> or milestone.
I mean a port to JDK6.
Martin