Menu
▾
▴
gwt-openlayers-devl — Developer list. Fairly active.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
(3) |
Mar
(51) |
Apr
(8) |
May
(8) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(1) |
Feb
(21) |
Mar
(13) |
Apr
(8) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(11) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Farrukh N. <fa...@we...> - 2009-03-23 12:27:49
|
Farrukh Najmi wrote: > Edwin Commandeur wrote: > >> Hi Farrukh, >> >> MapOptions extends OptionsBase, which intentionally hides the >> setAttribute methods for non-children (see the Javadoc on >> OptionsBase). The idea behind this is that XxxOptions objects should >> only have setters for options that can actually be set on them. Also >> the setAttribute methods clutter the code suggestions by the IDE for >> the available setters (another option to prevent code suggestion >> clutter would be to have a IMapOptions interface with limited setters >> and let that be extended by a MapOptions class that extends Options). >> >> If it makes sense to support setting the Z-Index I would argue that >> there should be a public setZIndex method, but if others feel that it >> makes more sense to expose the setAttribute methods than we should >> consider making all classes that extend OptionsBase extend Options >> instead (as in GWT-OL 0.2). >> >> > > Hi Edwin, > > I agree with your rationale. > > +1 on adding setZIndex(int zIndex) and getZIndex() methods. > > I think it would be better if you could do it as you are more familiar > with code base. > > Please let me know if I can help. When its committed I will test it out. > Thanks. > > Actually, perhaps the methods should be get/setZIndexBase() since they wouldset the base for a set of zindexes. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Farrukh N. <fa...@we...> - 2009-03-23 12:26:05
|
Edwin Commandeur wrote: > Hi Farrukh, > > MapOptions extends OptionsBase, which intentionally hides the > setAttribute methods for non-children (see the Javadoc on > OptionsBase). The idea behind this is that XxxOptions objects should > only have setters for options that can actually be set on them. Also > the setAttribute methods clutter the code suggestions by the IDE for > the available setters (another option to prevent code suggestion > clutter would be to have a IMapOptions interface with limited setters > and let that be extended by a MapOptions class that extends Options). > > If it makes sense to support setting the Z-Index I would argue that > there should be a public setZIndex method, but if others feel that it > makes more sense to expose the setAttribute methods than we should > consider making all classes that extend OptionsBase extend Options > instead (as in GWT-OL 0.2). > Hi Edwin, I agree with your rationale. +1 on adding setZIndex(int zIndex) and getZIndex() methods. I think it would be better if you could do it as you are more familiar with code base. Please let me know if I can help. When its committed I will test it out. Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-03-22 12:09:35
|
Hi Farrukh,
MapOptions extends OptionsBase, which intentionally hides the setAttribute
methods for non-children (see the Javadoc on OptionsBase). The idea behind
this is that XxxOptions objects should only have setters for options that
can actually be set on them. Also the setAttribute methods clutter the code
suggestions by the IDE for the available setters (another option to prevent
code suggestion clutter would be to have a IMapOptions interface with
limited setters and let that be extended by a MapOptions class that extends
Options).
If it makes sense to support setting the Z-Index I would argue that there
should be a public setZIndex method, but if others feel that it makes more
sense to expose the setAttribute methods than we should consider making all
classes that extend OptionsBase extend Options instead (as in GWT-OL 0.2).
Greetings,
Edwin
2009/3/21 Farrukh Najmi <fa...@we...>
>
> I could not use the mapOptions.setAttribute calls as they were protected
> not public.
> Is there a good reason for not making them public or is it just an
> oversight?
>
> Attached is a suggested patch to make the methods public. Please let me
> know if it makes sense to commit it.
> Thanks.
>
> Curtis Jensen wrote:
>
>> zIndexes are how CSS defines what div blocks appear on top of overlapping
>> div blocks. It's the normal concept of 3D space coordinates, where the z
>> axis is perpendicular to the screen. The highest zIndex will be on top.
>> I'm not expert either, this is the basics of what I know.
>>
>> It's isn't difficult to change the default zIndexes of OpenLayers (but is
>> was difficult for me figure it out). It is very likely that someone else
>> knows a better way. In my case, I was actually trying to make the map go
>> lower in the z ordering. You may want yours to go higher. I used FireBug
>> (Firefox plugin) to find the zIndex of the objects that were conflicting
>> with my map. It took me a little while to find where OpenLayers was setting
>> it's z indexes. They have a set of base indexes, and then build from there.
>> If you over write the defaults, you can modify the z ordering of OpenLayers
>> objects.
>>
>> This is the code I used:
>>
>> // OpenLayers default Z bases are 1000, 250, 750, 2000
>> private native JSObject getLowerMapZBase() /*-{
>> return { BaseLayer: -1000, Overlay: -750, Popup: -500, Control: 0 };
>> }-*/;
>>
>> MapOptions mapOptions = new MapOptions();
>> mapOptions.setAttribute("Z_INDEX_BASE", getLowerMapZBase());
>>
>>
>>
>>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>
> Index: src/main/java/com/eg/gwt/openLayers/client/util/OptionsBase.java
> ===================================================================
> RCS file:
> /cvsroot/gwt-openlayers/gwt-openlayers/src/main/java/com/eg/gwt/openLayers/client/util/OptionsBase.java,v
> retrieving revision 1.1
> diff -u -r1.1 OptionsBase.java
> --- src/main/java/com/eg/gwt/openLayers/client/util/OptionsBase.java 27
> Feb 2009 08:33:08 -0000 1.1
> +++ src/main/java/com/eg/gwt/openLayers/client/util/OptionsBase.java 21
> Mar 2009 19:36:53 -0000
> @@ -43,83 +43,83 @@
> //super((JSObject) JSObject.createObject()); //should work
> }
>
> - protected void setAttribute(String attr, boolean value)
> + public void setAttribute(String attr, boolean value)
> {
> ElementHelper.setAttribute(getJSObject(), attr, value);
> }
>
> - protected void setAttribute(String attr, int value)
> + public void setAttribute(String attr, int value)
> {
> ElementHelper.setAttribute(getJSObject(), attr, value);
> }
>
> - protected void setAttribute(String attr, int[] value)
> + public void setAttribute(String attr, int[] value)
> {
> setAttribute(attr, new JIntArray(value).getJSObject());
> }
>
> - protected void setAttribute(String attr, double value)
> + public void setAttribute(String attr, double value)
> {
> ElementHelper.setAttribute(getJSObject(), attr, value);
> }
>
> - protected void setAttribute(String attr, String value)
> + public void setAttribute(String attr, String value)
> {
> ElementHelper.setAttribute(getJSObject(), attr, value);
> }
>
> - protected void setAttribute(String attr, Element value)
> + public void setAttribute(String attr, Element value)
> {
> ElementHelper.setAttribute(getJSObject(), attr, value);
> }
>
> - protected void setAttribute(String attr, JSObject value)
> + public void setAttribute(String attr, JSObject value)
> {
> ElementHelper.setAttribute(getJSObject(), attr, value);
> }
>
> - protected void setAttribute(String attr, JObjectArray value)
> + public void setAttribute(String attr, JObjectArray value)
> {
> ElementHelper.setAttribute(getJSObject(), attr,
> value.getJSObject());
> }
>
> - protected String getAttribute(String attr)
> + public String getAttribute(String attr)
> {
> return ElementHelper.getAttribute(getJSObject(), attr);
> }
>
> - protected boolean getAttributeAsBoolean(String attr)
> + public boolean getAttributeAsBoolean(String attr)
> {
> return ElementHelper.getAttributeAsBoolean(getJSObject(),
> attr);
> }
>
> - protected double getAttributeAsDouble(String attr)
> + public double getAttributeAsDouble(String attr)
> {
> return ElementHelper.getAttributeAsDouble(getJSObject(),
> attr);
> }
>
> - protected Element getAttributeAsElement(String attr)
> + public Element getAttributeAsElement(String attr)
> {
> return ElementHelper.getAttributeAsElement(getJSObject(),
> attr);
> }
>
> - protected JSObject getAttributeAsJSObject(String attr)
> + public JSObject getAttributeAsJSObject(String attr)
> {
> return ElementHelper.getAttributeAsJSObject(getJSObject(),
> attr);
> }
>
> - protected int getAttributeAsInt(String attr)
> + public int getAttributeAsInt(String attr)
> {
> return ElementHelper.getAttributeAsInt(getJSObject(), attr);
> }
>
> //TODO Perhaps move these back to helper methods
> - protected int[] getAttributeAsIntArray(String attr)
> + public int[] getAttributeAsIntArray(String attr)
> {
> return
> JIntArray.narrowToJIntArray(getAttributeAsJSObject(attr)).toArray();
> }
>
> - protected String[] getAttributes()
> + public String[] getAttributes()
> {
> JSObject attributes =
> ElementHelper.getAttributes(getJSObject());
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Gwt-openlayers-devl mailing list
> Gwt...@li...
> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl
>
>
|
|
From: Farrukh N. <fa...@we...> - 2009-03-21 20:15:25
|
I could not use the mapOptions.setAttribute calls as they were protected
not public.
Is there a good reason for not making them public or is it just an
oversight?
Attached is a suggested patch to make the methods public. Please let me
know if it makes sense to commit it.
Thanks.
Curtis Jensen wrote:
> zIndexes are how CSS defines what div blocks appear on top of
> overlapping div blocks. It's the normal concept of 3D space
> coordinates, where the z axis is perpendicular to the screen. The
> highest zIndex will be on top. I'm not expert either, this is the
> basics of what I know.
>
> It's isn't difficult to change the default zIndexes of OpenLayers (but
> is was difficult for me figure it out). It is very likely that
> someone else knows a better way. In my case, I was actually trying to
> make the map go lower in the z ordering. You may want yours to go
> higher. I used FireBug (Firefox plugin) to find the zIndex of the
> objects that were conflicting with my map. It took me a little while
> to find where OpenLayers was setting it's z indexes. They have a set
> of base indexes, and then build from there. If you over write the
> defaults, you can modify the z ordering of OpenLayers objects.
>
> This is the code I used:
>
> // OpenLayers default Z bases are 1000, 250, 750, 2000
> private native JSObject getLowerMapZBase() /*-{
> return { BaseLayer: -1000, Overlay: -750, Popup: -500, Control: 0 };
> }-*/;
>
> MapOptions mapOptions = new MapOptions();
> mapOptions.setAttribute("Z_INDEX_BASE", getLowerMapZBase());
>
>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
|
|
From: Farrukh N. <fa...@we...> - 2009-03-21 18:24:58
|
+1 on moving to GWT 1.5. Now that GWT 1.6 is almost out I do not think we need to support GWT 1.4. Please send any dissenting opinions by COB today. Barring none, I can commit proposed patch by tomorrow. Thanks. Edwin Commandeur wrote: > The reason to build against 1.4.60 is to ensure the build is backward > compatible with GWT 1.4.60 and up. > > GWT 1.5 would allow enums and generics, which I personally would be > much in favor of. I also have some unit test code that I run under GWT > 1.5 to use the GWTTestSuite. > > Personally I wouldn't mind dropping backward compatibality, since it > is only GUI code, so even if you're tied to 1.4 on the server the GUI > can be compiled against 1.5, but it can get confusing. > > For me another reason to move to 1.5 is that I think web applications > should keep up with the latest versions of the GUI frameworks they are > using, or (as I have already experienced) they end up with old > framework code where you have to solve all the quirks that may pop up > yourself and that can get very nasty. > > What do the others think? > > Greetings, > Edwin > > > 2009/3/20 Farrukh Najmi <fa...@we... > <mailto:fa...@we...>> > > > Hi Guys, > > Attached is a simple patch to align pom.xml for maven build with > GWT 1.5.3. > Please review and let me know if it is OK to commit. Thanks. > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > > ? pom-patch.txt > Index: pom.xml > =================================================================== > RCS file: /cvsroot/gwt-openlayers/gwt-openlayers/pom.xml,v > retrieving revision 1.6 > diff -u -r1.6 pom.xml > --- pom.xml 20 Mar 2009 02:27:33 -0000 1.6 > +++ pom.xml 20 Mar 2009 16:09:17 -0000 > @@ -9,9 +9,9 @@ > <url>http://maven.apache.org</url> > <dependencies> > <dependency> > - <groupId>gwt</groupId> > + <groupId>com.google.gwt</groupId> > <artifactId>gwt-user</artifactId> > - <version>1.4.60</version> > + <version>1.5.3</version> > </dependency> > > <dependency> > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Farrukh N. <fa...@we...> - 2009-03-20 16:47:40
|
Sorry I had not seen the pom earlier and was just referring to your commit email. All is well. Thanks. Edwin Commandeur wrote: > > Hi > > I am not sure I am getting this. Isn't the current name 'xx-SNAPSHOT'. > > Or are you suggesting to rename it to 'xx-snapshot'. I would be fine > with that especially if it fits maven naming conventions better. > > Greetings, > Edwin > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-03-20 16:34:23
|
Hi I am not sure I am getting this. Isn't the current name 'xx-SNAPSHOT'. Or are you suggesting to rename it to 'xx-snapshot'. I would be fine with that especially if it fits maven naming conventions better. Greetings, Edwin 2009/3/20 Farrukh Najmi <fa...@we...> > > Hi Edwin, > > Thanks for all the improvements you have been making. > > Would it make sense to use "xx-SNAPSHOT" instead of "xx-snapshot" > for release version name. It fits maven conventions better. > > Thanks for your consideration for this very minor suggestion. > > Edwin Commandeur wrote: > > Modified Files: > > JBoolean.java ElementHelper.java > > Log Message: > > Important changes: Updated version from 0.3.1-snapshot to 0.4-snapshot. > > > > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > |
|
From: Edwin C. <com...@gm...> - 2009-03-20 16:33:08
|
The reason to build against 1.4.60 is to ensure the build is backward compatible with GWT 1.4.60 and up. GWT 1.5 would allow enums and generics, which I personally would be much in favor of. I also have some unit test code that I run under GWT 1.5 to use the GWTTestSuite. Personally I wouldn't mind dropping backward compatibality, since it is only GUI code, so even if you're tied to 1.4 on the server the GUI can be compiled against 1.5, but it can get confusing. For me another reason to move to 1.5 is that I think web applications should keep up with the latest versions of the GUI frameworks they are using, or (as I have already experienced) they end up with old framework code where you have to solve all the quirks that may pop up yourself and that can get very nasty. What do the others think? Greetings, Edwin 2009/3/20 Farrukh Najmi <fa...@we...> > > Hi Guys, > > Attached is a simple patch to align pom.xml for maven build with GWT 1.5.3. > Please review and let me know if it is OK to commit. Thanks. > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > > ? pom-patch.txt > Index: pom.xml > =================================================================== > RCS file: /cvsroot/gwt-openlayers/gwt-openlayers/pom.xml,v > retrieving revision 1.6 > diff -u -r1.6 pom.xml > --- pom.xml 20 Mar 2009 02:27:33 -0000 1.6 > +++ pom.xml 20 Mar 2009 16:09:17 -0000 > @@ -9,9 +9,9 @@ > <url>http://maven.apache.org</url> > <dependencies> > <dependency> > - <groupId>gwt</groupId> > + <groupId>com.google.gwt</groupId> > <artifactId>gwt-user</artifactId> > - <version>1.4.60</version> > + <version>1.5.3</version> > </dependency> > > <dependency> > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Farrukh N. <fa...@we...> - 2009-03-20 16:11:48
|
Hi Guys, Attached is a simple patch to align pom.xml for maven build with GWT 1.5.3. Please review and let me know if it is OK to commit. Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Farrukh N. <fa...@we...> - 2009-03-20 15:05:58
|
Hi Edwin, Thanks for all the improvements you have been making. Would it make sense to use "xx-SNAPSHOT" instead of "xx-snapshot" for release version name. It fits maven conventions better. Thanks for your consideration for this very minor suggestion. Edwin Commandeur wrote: > Modified Files: > JBoolean.java ElementHelper.java > Log Message: > Important changes: Updated version from 0.3.1-snapshot to 0.4-snapshot. > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-03-16 15:43:46
|
Hi all, I cleaned up the MapWidget code and as far as I could see I cleaned up code that is not used anywhere. If you experience any problems with the present MapWidget or the fact that Map constructors are not public anymore, please report them. The gmap variable was not declared and the hidden panel was never used as far as I could see. Erdem, can you testify that the hidden panel was not necessary? Does anyone thinks it would make sense if the MapWidget would extend FocusWidget. Initially I am inclined to say it is not sensible, but possible this convenient to provide keyboard navigation for the map. Greetings, Edwin |
|
From: Erdem G. <erd...@ya...> - 2009-03-16 14:28:53
|
Hi, everybody seems to be aligned with SF Hg. that's very good news, Edwin's plan sounds good to me, kind regards, ----- Original Message ---- From: Farrukh Najmi <fa...@we...> To: Edwin Commandeur <com...@gm...> Cc: gwt...@li...; Aaron Novstrup <ano...@st...> Sent: Sunday, March 15, 2009 3:04:32 PM Subject: Re: [Gwt-openlayers-devl] SF VCS support Thats great news. I am always delighted by SF's responsiveness. BTW guys, I am unavailable for helping out for a few days due to a family commitment. If there is anything left for Hg migration when I'm back, then I will be glad to help. Thanks. Edwin Commandeur wrote: > Hi Aaron, > > That is very good news! I would favor Hg over Git, given that Hg is > more widespread in the Java ecosystem (being used for openJDK and > openSolaris), whereas Git is more widespread in the Linux ecosystem. > Since GWT is in the Java ecosystem, I see a more natural fit with > Mercurial. > > My choice for Hg would thus be mostly political. All three, Git, Hg > and Bazaar are in use for large projects, so I guess they are all > three quite mature. For Git and Hg I understand the tool support is > good on Linux as well as Windows. > > My suggestion would still be to proceed as follows: > a) keep enhancing GWT-OpenLayers 0.4 snapshot until mid april (please > help out with bringing up new milestone issues and solving existing > milestone ones). > b) change package name from com.eg.gwt.openLayers to > org.gwtxxx.openlayers or org.xxx.gwtopenlayers (where xxx is to be > determined) > c) migrate to Hg or Git > d) release GWT-OpenLayers 0.4-rc1 in mid april > e) release GWT-OpenLayers 0.4 > > That way we can all play around with Git and Hg, and hold a final poll > before mid april about which distributed VCS and which package name to > choose. > > Is everybody ok with moving the version number of GWT-OpenLayers from > 0.3.1-SNAPSHOT to 0.4-SNAPSHOT and working towared 0.4-rc1 in april? > > The path as I see it in terms of GWT-OpenLayers versions would be: > 0.4-SNAPSHOT -> 0.4-rc1 -> 0.4 -> 0.5-SNAPSHOT -> 0.5-rc1 -> 0.5 -> > 1.0-SNAPSHOT > > OpenLayers 2.8 is already at 72% completion of the tickets for that > release. > > In terms of functionality supported I see it as follows: > 0.4: GWT-OpenLayers 0.4 supports much of 2.7. > 0.5: It would be nice if we could get GWT-OpenLayers 0.5 to support > all functionality of 2.7 that does not duplicate GWT functionality > (such as XML support), with the exception of certain layer types and > some of OpenLayers 2.8 > 1.0: GWT-OpenLayers 1.0 should catch up with OpenLayers 2.8 (assuming > that 2.8 will be released before GWT-OpenLayers 1.0) > > With respect to different layers that GWT-OpenLayers supports it would > be nice if we have people under the developers or testers that > actually use that layers, so they can give feedback from using it in > practice. I mostly use WMS and Vector layers, but I am very happy that > support for Google and OSM are in. Other layers that are high on my > list to support are: WorldWind, Mapserver, and WFS (though I believe > connecting to WFS from javascript is suboptimal). Is there anybody > amongst us who would like to work on KaMap, MapGuide, MultiMap, > VirtualEarth, or Yahoo? > > Greetings, > Edwin > > > > 2009/3/15 Aaron Novstrup <ano...@st... > <mailto:ano...@st...>> > > Hi all, > > I was playing around on SF today and noticed Mercurial under the > Code menu. I thought my eyes were playing tricks on me, but, sure > enough, SF officially supports Git, Mercurial, and Bazaar as of > *yesterday*: > http://www.linuxtoday.com/news_story.php3?ltsn=2009-03-13-003-35-PR-SV. > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Gwt-openlayers-devl mailing list Gwt...@li... https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl |
|
From: Farrukh N. <fa...@we...> - 2009-03-15 13:04:57
|
Thats great news. I am always delighted by SF's responsiveness. BTW guys, I am unavailable for helping out for a few days due to a family commitment. If there is anything left for Hg migration when I'm back, then I will be glad to help. Thanks. Edwin Commandeur wrote: > Hi Aaron, > > That is very good news! I would favor Hg over Git, given that Hg is > more widespread in the Java ecosystem (being used for openJDK and > openSolaris), whereas Git is more widespread in the Linux ecosystem. > Since GWT is in the Java ecosystem, I see a more natural fit with > Mercurial. > > My choice for Hg would thus be mostly political. All three, Git, Hg > and Bazaar are in use for large projects, so I guess they are all > three quite mature. For Git and Hg I understand the tool support is > good on Linux as well as Windows. > > My suggestion would still be to proceed as follows: > a) keep enhancing GWT-OpenLayers 0.4 snapshot until mid april (please > help out with bringing up new milestone issues and solving existing > milestone ones). > b) change package name from com.eg.gwt.openLayers to > org.gwtxxx.openlayers or org.xxx.gwtopenlayers (where xxx is to be > determined) > c) migrate to Hg or Git > d) release GWT-OpenLayers 0.4-rc1 in mid april > e) release GWT-OpenLayers 0.4 > > That way we can all play around with Git and Hg, and hold a final poll > before mid april about which distributed VCS and which package name to > choose. > > Is everybody ok with moving the version number of GWT-OpenLayers from > 0.3.1-SNAPSHOT to 0.4-SNAPSHOT and working towared 0.4-rc1 in april? > > The path as I see it in terms of GWT-OpenLayers versions would be: > 0.4-SNAPSHOT -> 0.4-rc1 -> 0.4 -> 0.5-SNAPSHOT -> 0.5-rc1 -> 0.5 -> > 1.0-SNAPSHOT > > OpenLayers 2.8 is already at 72% completion of the tickets for that > release. > > In terms of functionality supported I see it as follows: > 0.4: GWT-OpenLayers 0.4 supports much of 2.7. > 0.5: It would be nice if we could get GWT-OpenLayers 0.5 to support > all functionality of 2.7 that does not duplicate GWT functionality > (such as XML support), with the exception of certain layer types and > some of OpenLayers 2.8 > 1.0: GWT-OpenLayers 1.0 should catch up with OpenLayers 2.8 (assuming > that 2.8 will be released before GWT-OpenLayers 1.0) > > With respect to different layers that GWT-OpenLayers supports it would > be nice if we have people under the developers or testers that > actually use that layers, so they can give feedback from using it in > practice. I mostly use WMS and Vector layers, but I am very happy that > support for Google and OSM are in. Other layers that are high on my > list to support are: WorldWind, Mapserver, and WFS (though I believe > connecting to WFS from javascript is suboptimal). Is there anybody > amongst us who would like to work on KaMap, MapGuide, MultiMap, > VirtualEarth, or Yahoo? > > Greetings, > Edwin > > > > 2009/3/15 Aaron Novstrup <ano...@st... > <mailto:ano...@st...>> > > Hi all, > > I was playing around on SF today and noticed Mercurial under the > Code menu. I thought my eyes were playing tricks on me, but, sure > enough, SF officially supports Git, Mercurial, and Bazaar as of > *yesterday*: > http://www.linuxtoday.com/news_story.php3?ltsn=2009-03-13-003-35-PR-SV. > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-03-15 11:27:25
|
Hi Aaron, That is very good news! I would favor Hg over Git, given that Hg is more widespread in the Java ecosystem (being used for openJDK and openSolaris), whereas Git is more widespread in the Linux ecosystem. Since GWT is in the Java ecosystem, I see a more natural fit with Mercurial. My choice for Hg would thus be mostly political. All three, Git, Hg and Bazaar are in use for large projects, so I guess they are all three quite mature. For Git and Hg I understand the tool support is good on Linux as well as Windows. My suggestion would still be to proceed as follows: a) keep enhancing GWT-OpenLayers 0.4 snapshot until mid april (please help out with bringing up new milestone issues and solving existing milestone ones). b) change package name from com.eg.gwt.openLayers to org.gwtxxx.openlayers or org.xxx.gwtopenlayers (where xxx is to be determined) c) migrate to Hg or Git d) release GWT-OpenLayers 0.4-rc1 in mid april e) release GWT-OpenLayers 0.4 That way we can all play around with Git and Hg, and hold a final poll before mid april about which distributed VCS and which package name to choose. Is everybody ok with moving the version number of GWT-OpenLayers from 0.3.1-SNAPSHOT to 0.4-SNAPSHOT and working towared 0.4-rc1 in april? The path as I see it in terms of GWT-OpenLayers versions would be: 0.4-SNAPSHOT -> 0.4-rc1 -> 0.4 -> 0.5-SNAPSHOT -> 0.5-rc1 -> 0.5 -> 1.0-SNAPSHOT OpenLayers 2.8 is already at 72% completion of the tickets for that release. In terms of functionality supported I see it as follows: 0.4: GWT-OpenLayers 0.4 supports much of 2.7. 0.5: It would be nice if we could get GWT-OpenLayers 0.5 to support all functionality of 2.7 that does not duplicate GWT functionality (such as XML support), with the exception of certain layer types and some of OpenLayers 2.8 1.0: GWT-OpenLayers 1.0 should catch up with OpenLayers 2.8 (assuming that 2.8 will be released before GWT-OpenLayers 1.0) With respect to different layers that GWT-OpenLayers supports it would be nice if we have people under the developers or testers that actually use that layers, so they can give feedback from using it in practice. I mostly use WMS and Vector layers, but I am very happy that support for Google and OSM are in. Other layers that are high on my list to support are: WorldWind, Mapserver, and WFS (though I believe connecting to WFS from javascript is suboptimal). Is there anybody amongst us who would like to work on KaMap, MapGuide, MultiMap, VirtualEarth, or Yahoo? Greetings, Edwin 2009/3/15 Aaron Novstrup <ano...@st...> > Hi all, > > I was playing around on SF today and noticed Mercurial under the Code menu. > I thought my eyes were playing tricks on me, but, sure enough, SF > officially supports Git, Mercurial, and Bazaar as of *yesterday*: > http://www.linuxtoday.com/news_story.php3?ltsn=2009-03-13-003-35-PR-SV. > > Cheers, > ~Aaron > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Aaron N. <ano...@st...> - 2009-03-14 23:02:26
|
Hi all, I was playing around on SF today and noticed Mercurial under the Code menu. I thought my eyes were playing tricks on me, but, sure enough, SF officially supports Git, Mercurial, and Bazaar as of *yesterday*: http://www.linuxtoday.com/news_story.php3?ltsn=2009-03-13-003-35-PR-SV. Cheers, ~Aaron |
|
From: Edwin C. <com...@gm...> - 2009-03-12 00:20:59
|
Hi all, Over the past few days I created a new Tracker on the GWT-OpenLayers plugin website called 'Milestone issues'. The intention behind this tracker is to assign issues to versions of GWT-OpenLayers. I saw that Curtis already commented on issues I added to the tracker. Thanks for that Curtis and great that you implemented the Framed Cloud and helped out on the KML! Issues can only be added to the Tracker 'Milestone issues' by developers. That way the milestone issues won't get clogged with non- issues. users can submit bugs and feature requests in the public Trackers, and we can evaluate these issues, categorize them and then decide whether and how to add these to the Milestone issues. The categories I have for the Milestone issues are now: -Functionality -Documentation -General -Showcase For milestone issues regarding functionality it would be convenient if the functionality is at a detailed level (about 1 OpenLayers classs) and if it is prefaced with the OL category, for example: Format:WMC read/write, Format:GML read/write, Control:DragFeature Please submit any of the features that you want to have in OpenLayers 0.4 first release candidate, so we can work towards a new release of GWT-OpenLayers. My suggestion is to compile a list of features that we want to wrap (or maybe extend upon) in GWT-OpenLayers, see what can be achieved on reasonable timescale and implement that. Just before releasing GWT-OpenLayers 0.4 rc1 we could do a rename of the package (see Milestone issues>General) and possible move to a new VCS. I saw that Mapbuilder (now end-of-life) shipped with OpenLayers already included, so it is probably legally possible to ship OpenLayers with GWT-OpenLayers and maybe it is desirable for us to do this with 0.4 rc1. The GWT-OpenLayers module xml could reference the script (just as it does with the util script). Another thing I have been looking into is testcases. With GWT 1.5 it is possible to have a TestSuite which can invoke a whole range of GWTTestCase testcases. Next to the package name, VCS, and OpenLayers inclusion, I think it's wise to decide if GWT-OpenLayers shoulde remain GWT 1.4 compatible or that we want to upgrade to 1.5 opening up possibilitys for using Enums and Generics. With respect to documentation I feel that most documentation should be on the wiki provided by SF and the website can provide links to that wiki. Concluding things, I would appreciate it if people started filling the milestone issues tracker, so we can work towards a new release of GWT-OpenLayers. I was thinking to strive for a new release in april, because the trunk already includes a lot of functionality up and above the 0.2 release (thanks again Erdem for 0.2!). The reason to go for 0.4 and skip 0.3 is to reflect that we really moved forward. Personally I like official releases to be x.y and not x.y.z or x.y.z.a, how about you? Greetings, Edwin Commandeur P.S. Gev, I finally found out that OpenStreetMap provides a js file alongside OpenLayers at " http://openstreetmap.org/openlayers/OpenStreetMap.js". If this is not just used under water by OpenLayers but contains additionaly functionality, then it is interesting to wrap. |
|
From: Farrukh N. <fa...@we...> - 2009-03-10 21:52:03
|
Curtis Jensen wrote: > Oh, one more item. There is the Gwt-openlayers-commits mailing list. > Are we suppose to send emails there when we do commits? Is there an > automated way to get SourceForge's CVS to send emails to that list > when commits are done? > We can get commit emails automatically sent to that list from any of the supported VCS on SF. I have just committed changes to our CVSROOT module to send notifications but have not seen them yet. http://apps.sourceforge.net/trac/sourceforge/wiki/CVS http://apps.sourceforge.net/trac/sourceforge/wiki/CVS%20syncmail If we move to another VCS we can do same. Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Farrukh N. <fa...@we...> - 2009-03-10 20:02:21
|
Curtis Jensen wrote: ... > On that topic: > - I agree with the sentetament to stay with SourceForge over > bitbucket. IMHO the gain isn't worth the work. If we did change > source code repository sites, Google Code (code.google.com) would be > another one to look into. It would be fitting for a GWT project. > They only support SVN, but they have said that they are working on a > distributed VCS, but hasn't said if that is Git or Hg or both or > something else. > I admin projects at googlecode and SF. SF is much better. So -1 for me on moving away from SF. > - I like SVN over CVS (branching and merging is easier; even in > Eclipse). I wouldn't mind Git over CVS, but the conversion would be > tougher; not sure it would be worth it. Also, I'm fine with staying > with CVS. I think it'll be a while before SF supports Hg. If we're > waiting for that to happen before we do anything, we'll be waiting a > long wait. > I am happy to stay with CVS for now. Its less change. I can go with svn if there is popular demand. Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Curtis J. <cur...@gm...> - 2009-03-10 19:44:11
|
Oh, one more item. There is the Gwt-openlayers-commits mailing list. Are we suppose to send emails there when we do commits? Is there an automated way to get SourceForge's CVS to send emails to that list when commits are done? -- Curtis On Tue, Mar 10, 2009 at 12:41 PM, Curtis Jensen <cur...@gm...> wrote: > I just updated the CVS repository with the changes I had. Sorry that > it has taken me a little while. I got a little swamped at work. > Edwin, you stole most of my thunder, and wrapped almost everything > that I had wrapped. I even had a vector feature listener already > done. I do agree with your deviation in the name of the > "VectorFeature" class. It's much better that way. I guess that I'll > have to be faster at committing my changes next time. > > I don't know if there is anyone else we're waiting on to merge in > their changes. If not, and we're still considering a VCS migration, > then we may be free to do the temporary code freeze and do the > conversion. > > On that topic: > - I agree with the sentetament to stay with SourceForge over > bitbucket. IMHO the gain isn't worth the work. If we did change > source code repository sites, Google Code (code.google.com) would be > another one to look into. It would be fitting for a GWT project. > They only support SVN, but they have said that they are working on a > distributed VCS, but hasn't said if that is Git or Hg or both or > something else. > > - I like SVN over CVS (branching and merging is easier; even in > Eclipse). I wouldn't mind Git over CVS, but the conversion would be > tougher; not sure it would be worth it. Also, I'm fine with staying > with CVS. I think it'll be a while before SF supports Hg. If we're > waiting for that to happen before we do anything, we'll be waiting a > long wait. > > Thanks, > Curtis > > > > > > > On Fri, Mar 6, 2009 at 1:31 AM, Erdem Gunay <erd...@ya...> wrote: >> Hi all, >> >> since I have no experience with the disctributed VCS so far, I was not in >> favor of that, but always, I take your considerations into account, >> >> I will have a look at Git and Hg, and then see if and how SourceForge >> supports that, then we can decide how to proceed with that, >> >> best regards, >> >> Erdem >> >> ________________________________ >> From: Edwin Commandeur <com...@gm...> >> To: gwt...@li... >> Sent: Tuesday, March 3, 2009 12:07:23 AM >> Subject: Re: [Gwt-openlayers-devl] Devl mailing list >> >> Hi all, >> >> I agree with Farrukh that it would be best to migrate to a distributed VCS >> directly, instead of first migrating to SVN first and then to a distributed >> VCS second. If we want a distributed VCS it's better to dive into it now, so >> we can get experienced with it. Also, Git is supported by SF (unlike Hg, as >> I am now aware). >> >> That said, I still have worries about Git on Windows, since my work laptop >> is a Windows machine. >> >> Does Farrukh or anyone else has experience with Git command line clients on >> windows? I would like to be able to interact with Git outside of Eclipse. >> The msysGit project looks promising, so I will definitely download that and >> give it a testdrive. >> >> If anyone has experience with Git on Windows, and can testify it works, then >> I would be all for Git. How about Erdem, and the others? >> >> I have good faith that all the major IDEs will be supporting Git, since >> Eclipse and IntelliJ already do. >> >> Should we however decide on SVN then I would be willing to do the migration. >> >> Greetings, >> Edwin >> >> >> 2009/3/2 Farrukh Najmi <fa...@we...> >>> >>> Just to be clear. You opt for migrating from CVS to svn then perhaps >>> later to git or hg? >>> Why not just stay with cvs until we go to git or hg? Why migrate twice? >>> >>> IMHO svn's advantages over cvs are modest. >>> >>> That said I will be fine with going to svn if that is a popular option >>> and if someone else does the migration. >>> >>> Thanks. >>> >>> Erdem Gunay wrote: >>> > First of all, thanks to Farrukh for letting us communicate through dev >>> > mailing list, >>> > >>> > at the moment, I prefer to stay with SVN, in the future once it is >>> > officially supported and many developers are used to git, or hg, we can move >>> > to that one, >>> > >>> > best regards, >>> > >>> > Erdem, >>> > >>> > >>> > >>> > ----- Original Message ---- >>> > From: Farrukh Najmi <fa...@we...> >>> > To: gwt...@li... >>> > Sent: Sunday, March 1, 2009 3:30:46 PM >>> > Subject: Re: [Gwt-openlayers-devl] Devl mailing list >>> > >>> > >>> > Unfortunately, as Curtis reminded me, hg is not offered by SF. >>> > >>> > So the choice is between svn and git. I have used git enough to know >>> > that it does work out of the box with a minor learning curve. I would >>> > prefer git but like most of us I can live with svn. >>> > >>> > Are there other folks who would prefer to stay with svn rather than >>> > learning git? >>> > >>> > Note that with IDE support for NetBeans and eclipse the learning curve >>> > should not be that much of an issue. >>> > >>> > Thanks. >>> > >>> > Edwin Commandeur wrote: >>> > >>> >> Hi there, >>> >> >>> >> I am perfectly happy with SVN, which I think would already be a major >>> >> improvement over CVS and would suit our needs fine, but I would also >>> >> agree with using Hg. >>> >> >>> >> I have more confidence in Hg than in Git, because to my mind a VCS >>> >> tool should just work, and not be so open ended as Git. >>> >> >>> >> Also, as a Java Developer I think about projects as Open JDK for which >>> >> they are also using Hg, so I would be interested to learn about Hg >>> >> more than about Git. >>> >> >>> >> Having not used any of the distributed VCS tools, I cannot talk from >>> >> experience, but on the Git vs Mercurial comparison it is stated that >>> >> "migrating from Subversion/CVS to git requires a lot of work. Linus >>> >> has made it clear that he disagrees with the fundamental ideas behind >>> >> Subversion/CVS" >>> >> >>> >> I have no idea if migrating from CVS to Mercurial is any easier, but >>> >> that could also be a consideration to take into account. >>> >> >>> >> Greetings, >>> >> Edwin >>> >> >>> >> >>> >> gwt...@li... >>> >> <mailto:gwt...@li...> >>> >> >>> >> 2009/3/1 Farrukh Najmi <fa...@we... >>> >> <mailto:fa...@we...>> >>> >> >>> >> >>> >> I have not used hg and have used git a little so can't say I have a >>> >> strong opinion between the two DVCS tools. Here is a good blog >>> >> comparing >>> >> the two: >>> >> >>> >> <http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/> >>> >> >>> >> High order bit decision is whether we should do a more modern >>> >> distributed version control system like git or hg instead of svn. >>> >> So far >>> >> it sounds like the opinions are in the YES camp. >>> >> >>> >> I can go with either hg or git. Lets see what others feel. Thanks. >>> >> >>> >> Aaron Novstrup wrote: >>> >> > If you're going to switch to a DVCS, I'd recommend hg since >>> >> AFAIK it's >>> >> > better than git for cross-platform development. No strong >>> >> preference, >>> >> > though, just my two cents. >>> >> > >>> >> > Farrukh Najmi wrote: >>> >> >> Dear team mates, >>> >> >> >>> >> >> Here is our list for the dev team to communicate. I will set us >>> >> up on >>> >> >> the other two lists (users, commits) shortly. >>> >> >> >>> >> >> I noticed that SF now offers git as a version control system >>> >> (VCS). >>> >> >> git was created by Linus of Linux fame and is used by projects >>> >> like >>> >> >> Linux. Its is better than svn and one of the best VCS available. >>> >> >> >>> >> >> What do folks think of using git instead of svn? The main >>> >> advantage >>> >> >> svn has is one of familiarity. However git has many advanced >>> >> features >>> >> >> beyond svn (distributed VCS being an important one). >>> >> >> >>> >> >> Here is a useful resource: >>> >> >> >>> >> >> <http://git.or.cz/gitwiki/GitSvnComparsion> >>> >> >> >>> >> >> Please share your thoughts on this. Thanks. >>> >> >> >>> >> >> >>> >> > >>> >> >>> >> >>> > >>> > >>> > >>> >>> >>> -- >>> Regards, >>> Farrukh >>> >>> Web: http://www.wellfleetsoftware.com >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>> CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source code: >>> SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Gwt-openlayers-devl mailing list >>> Gwt...@li... >>> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Gwt-openlayers-devl mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl >> >> > |
|
From: Curtis J. <cur...@gm...> - 2009-03-10 19:41:26
|
I just updated the CVS repository with the changes I had. Sorry that it has taken me a little while. I got a little swamped at work. Edwin, you stole most of my thunder, and wrapped almost everything that I had wrapped. I even had a vector feature listener already done. I do agree with your deviation in the name of the "VectorFeature" class. It's much better that way. I guess that I'll have to be faster at committing my changes next time. I don't know if there is anyone else we're waiting on to merge in their changes. If not, and we're still considering a VCS migration, then we may be free to do the temporary code freeze and do the conversion. On that topic: - I agree with the sentetament to stay with SourceForge over bitbucket. IMHO the gain isn't worth the work. If we did change source code repository sites, Google Code (code.google.com) would be another one to look into. It would be fitting for a GWT project. They only support SVN, but they have said that they are working on a distributed VCS, but hasn't said if that is Git or Hg or both or something else. - I like SVN over CVS (branching and merging is easier; even in Eclipse). I wouldn't mind Git over CVS, but the conversion would be tougher; not sure it would be worth it. Also, I'm fine with staying with CVS. I think it'll be a while before SF supports Hg. If we're waiting for that to happen before we do anything, we'll be waiting a long wait. Thanks, Curtis On Fri, Mar 6, 2009 at 1:31 AM, Erdem Gunay <erd...@ya...> wrote: > Hi all, > > since I have no experience with the disctributed VCS so far, I was not in > favor of that, but always, I take your considerations into account, > > I will have a look at Git and Hg, and then see if and how SourceForge > supports that, then we can decide how to proceed with that, > > best regards, > > Erdem > > ________________________________ > From: Edwin Commandeur <com...@gm...> > To: gwt...@li... > Sent: Tuesday, March 3, 2009 12:07:23 AM > Subject: Re: [Gwt-openlayers-devl] Devl mailing list > > Hi all, > > I agree with Farrukh that it would be best to migrate to a distributed VCS > directly, instead of first migrating to SVN first and then to a distributed > VCS second. If we want a distributed VCS it's better to dive into it now, so > we can get experienced with it. Also, Git is supported by SF (unlike Hg, as > I am now aware). > > That said, I still have worries about Git on Windows, since my work laptop > is a Windows machine. > > Does Farrukh or anyone else has experience with Git command line clients on > windows? I would like to be able to interact with Git outside of Eclipse. > The msysGit project looks promising, so I will definitely download that and > give it a testdrive. > > If anyone has experience with Git on Windows, and can testify it works, then > I would be all for Git. How about Erdem, and the others? > > I have good faith that all the major IDEs will be supporting Git, since > Eclipse and IntelliJ already do. > > Should we however decide on SVN then I would be willing to do the migration. > > Greetings, > Edwin > > > 2009/3/2 Farrukh Najmi <fa...@we...> >> >> Just to be clear. You opt for migrating from CVS to svn then perhaps >> later to git or hg? >> Why not just stay with cvs until we go to git or hg? Why migrate twice? >> >> IMHO svn's advantages over cvs are modest. >> >> That said I will be fine with going to svn if that is a popular option >> and if someone else does the migration. >> >> Thanks. >> >> Erdem Gunay wrote: >> > First of all, thanks to Farrukh for letting us communicate through dev >> > mailing list, >> > >> > at the moment, I prefer to stay with SVN, in the future once it is >> > officially supported and many developers are used to git, or hg, we can move >> > to that one, >> > >> > best regards, >> > >> > Erdem, >> > >> > >> > >> > ----- Original Message ---- >> > From: Farrukh Najmi <fa...@we...> >> > To: gwt...@li... >> > Sent: Sunday, March 1, 2009 3:30:46 PM >> > Subject: Re: [Gwt-openlayers-devl] Devl mailing list >> > >> > >> > Unfortunately, as Curtis reminded me, hg is not offered by SF. >> > >> > So the choice is between svn and git. I have used git enough to know >> > that it does work out of the box with a minor learning curve. I would >> > prefer git but like most of us I can live with svn. >> > >> > Are there other folks who would prefer to stay with svn rather than >> > learning git? >> > >> > Note that with IDE support for NetBeans and eclipse the learning curve >> > should not be that much of an issue. >> > >> > Thanks. >> > >> > Edwin Commandeur wrote: >> > >> >> Hi there, >> >> >> >> I am perfectly happy with SVN, which I think would already be a major >> >> improvement over CVS and would suit our needs fine, but I would also >> >> agree with using Hg. >> >> >> >> I have more confidence in Hg than in Git, because to my mind a VCS >> >> tool should just work, and not be so open ended as Git. >> >> >> >> Also, as a Java Developer I think about projects as Open JDK for which >> >> they are also using Hg, so I would be interested to learn about Hg >> >> more than about Git. >> >> >> >> Having not used any of the distributed VCS tools, I cannot talk from >> >> experience, but on the Git vs Mercurial comparison it is stated that >> >> "migrating from Subversion/CVS to git requires a lot of work. Linus >> >> has made it clear that he disagrees with the fundamental ideas behind >> >> Subversion/CVS" >> >> >> >> I have no idea if migrating from CVS to Mercurial is any easier, but >> >> that could also be a consideration to take into account. >> >> >> >> Greetings, >> >> Edwin >> >> >> >> >> >> gwt...@li... >> >> <mailto:gwt...@li...> >> >> >> >> 2009/3/1 Farrukh Najmi <fa...@we... >> >> <mailto:fa...@we...>> >> >> >> >> >> >> I have not used hg and have used git a little so can't say I have a >> >> strong opinion between the two DVCS tools. Here is a good blog >> >> comparing >> >> the two: >> >> >> >> <http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/> >> >> >> >> High order bit decision is whether we should do a more modern >> >> distributed version control system like git or hg instead of svn. >> >> So far >> >> it sounds like the opinions are in the YES camp. >> >> >> >> I can go with either hg or git. Lets see what others feel. Thanks. >> >> >> >> Aaron Novstrup wrote: >> >> > If you're going to switch to a DVCS, I'd recommend hg since >> >> AFAIK it's >> >> > better than git for cross-platform development. No strong >> >> preference, >> >> > though, just my two cents. >> >> > >> >> > Farrukh Najmi wrote: >> >> >> Dear team mates, >> >> >> >> >> >> Here is our list for the dev team to communicate. I will set us >> >> up on >> >> >> the other two lists (users, commits) shortly. >> >> >> >> >> >> I noticed that SF now offers git as a version control system >> >> (VCS). >> >> >> git was created by Linus of Linux fame and is used by projects >> >> like >> >> >> Linux. Its is better than svn and one of the best VCS available. >> >> >> >> >> >> What do folks think of using git instead of svn? The main >> >> advantage >> >> >> svn has is one of familiarity. However git has many advanced >> >> features >> >> >> beyond svn (distributed VCS being an important one). >> >> >> >> >> >> Here is a useful resource: >> >> >> >> >> >> <http://git.or.cz/gitwiki/GitSvnComparsion> >> >> >> >> >> >> Please share your thoughts on this. Thanks. >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> > >> > >> >> >> -- >> Regards, >> Farrukh >> >> Web: http://www.wellfleetsoftware.com >> >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Gwt-openlayers-devl mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Edwin C. <com...@gm...> - 2009-03-07 08:02:22
|
Hi, I have been trying out msysgit (Git on windows) and it installed and run without problems. I did saw that there are some commands that are not supported on windows, but I could clone a repository from GitHub without any problems. It was amazed that it was quite slow, but maybe that's just the first time clone. Nice that Aaron now also has Hg repository up to play with. Greetz, Edwin 2009/3/7 Farrukh Najmi <fa...@we...> > > You make all good points Aaron. The distributed VCS model encourages > cloning of repos and syncing with clones for specific patches. > Sorry for my false alarm and thanks for your valuable contribution. > > Aaron Novstrup wrote: > > Hi Farrukh, > > > > I appreciate your candor, and hopefully I can clear up the > > misunderstanding. My intent was simply to create an hg clone of the > > repository to allow members of the team to experiment with it if they > > choose, not to create a parallel universe outside of SF. The clone is > > my own personal development repository and is clearly marked as such. > > This is the CVS/SVN equivalent of making a public read-only copy of my > > working directory. > > > > One of the advantages of distributed version control is that it is > > easy to make clones of the repository (in fact, you make a new clone > > whenever you check out a project) and to move the clones from place to > > place. If/when SF supports hg, if the team decides to use hg, it > > would be easy to clone my repository to SF. With slightly more > > effort, of course, we could just create a new clone directly from the > > CVS repository. It took me less than half an hour to figure out how > > to do the conversion and run it. > > > > I should probably also clarify that I don't have a strong opinion > > about which VCS we use. Both git and hg are excellent systems and > > have major advantages over CVS/SVN, especially for open-source > > projects. I slightly favor hg for this project, mainly because it's a > > cross-platform project and git may prevent Windows-users from > > contributing. Considering Edwin's major contributions to the project > > thus far, I think that's a very real concern. > > > > I hope that my clone will help the team make an informed choice. I > > probably should have made all this clear in my previous email, and I > > apologize for any confusion. > > > > Thanks, > > ~Aaron > > > > Farrukh Najmi wrote: > >> > >> Hi Aaron, > >> > >> Respectfully, I think creating another repo unilaterally is at best > >> going to create confusion and at worst create issues for the team. > >> For starters, I will assume that repo is not integrated with the SF > >> authentication mechanism. Please lets not create a parrallel universe > >> outside of the SF project. > >> > >> At the end of the day this VCS debate is not what the project is > >> about. I for one would be happy with any VCS as long as it is hosted > >> at sourceforge, integrated with SF identity management and is > >> supported and backed up by SF. That choice presently is cvs, svn and > >> git. > >> As I said, SF willlikely have hg very soon. I am happy to wait for hg > >> at SF and stay with CVS. I am also happy to move to git now. I am > >> happy to move to svn if we do not plan to move again to hg or git. I > >> am most unhappy moving out of SF. > >> > >> Just my 2 cents. > >> > >> Thanks and I hope you do not mind me speaking frankly and with > >> complete respect for you. > >> > >> Aaron Novstrup wrote: > >>> In case anyone's interested in toying with hg, I've created a clone > >>> of the gwt-openlayers repository here: > >>> http://bitbucket.org/anovstrup/gwt-openlayers/ > >>> > >>> I didn't take the time to check how the conversion went, so let me > >>> know if you notice any weirdness. > >>> > >> > >> > > > > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > |
|
From: Farrukh N. <fa...@we...> - 2009-03-07 02:11:52
|
You make all good points Aaron. The distributed VCS model encourages cloning of repos and syncing with clones for specific patches. Sorry for my false alarm and thanks for your valuable contribution. Aaron Novstrup wrote: > Hi Farrukh, > > I appreciate your candor, and hopefully I can clear up the > misunderstanding. My intent was simply to create an hg clone of the > repository to allow members of the team to experiment with it if they > choose, not to create a parallel universe outside of SF. The clone is > my own personal development repository and is clearly marked as such. > This is the CVS/SVN equivalent of making a public read-only copy of my > working directory. > > One of the advantages of distributed version control is that it is > easy to make clones of the repository (in fact, you make a new clone > whenever you check out a project) and to move the clones from place to > place. If/when SF supports hg, if the team decides to use hg, it > would be easy to clone my repository to SF. With slightly more > effort, of course, we could just create a new clone directly from the > CVS repository. It took me less than half an hour to figure out how > to do the conversion and run it. > > I should probably also clarify that I don't have a strong opinion > about which VCS we use. Both git and hg are excellent systems and > have major advantages over CVS/SVN, especially for open-source > projects. I slightly favor hg for this project, mainly because it's a > cross-platform project and git may prevent Windows-users from > contributing. Considering Edwin's major contributions to the project > thus far, I think that's a very real concern. > > I hope that my clone will help the team make an informed choice. I > probably should have made all this clear in my previous email, and I > apologize for any confusion. > > Thanks, > ~Aaron > > Farrukh Najmi wrote: >> >> Hi Aaron, >> >> Respectfully, I think creating another repo unilaterally is at best >> going to create confusion and at worst create issues for the team. >> For starters, I will assume that repo is not integrated with the SF >> authentication mechanism. Please lets not create a parrallel universe >> outside of the SF project. >> >> At the end of the day this VCS debate is not what the project is >> about. I for one would be happy with any VCS as long as it is hosted >> at sourceforge, integrated with SF identity management and is >> supported and backed up by SF. That choice presently is cvs, svn and >> git. >> As I said, SF willlikely have hg very soon. I am happy to wait for hg >> at SF and stay with CVS. I am also happy to move to git now. I am >> happy to move to svn if we do not plan to move again to hg or git. I >> am most unhappy moving out of SF. >> >> Just my 2 cents. >> >> Thanks and I hope you do not mind me speaking frankly and with >> complete respect for you. >> >> Aaron Novstrup wrote: >>> In case anyone's interested in toying with hg, I've created a clone >>> of the gwt-openlayers repository here: >>> http://bitbucket.org/anovstrup/gwt-openlayers/ >>> >>> I didn't take the time to check how the conversion went, so let me >>> know if you notice any weirdness. >>> >> >> > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Aaron N. <ano...@st...> - 2009-03-07 01:50:56
|
Hi Farrukh, I appreciate your candor, and hopefully I can clear up the misunderstanding. My intent was simply to create an hg clone of the repository to allow members of the team to experiment with it if they choose, not to create a parallel universe outside of SF. The clone is my own personal development repository and is clearly marked as such. This is the CVS/SVN equivalent of making a public read-only copy of my working directory. One of the advantages of distributed version control is that it is easy to make clones of the repository (in fact, you make a new clone whenever you check out a project) and to move the clones from place to place. If/when SF supports hg, if the team decides to use hg, it would be easy to clone my repository to SF. With slightly more effort, of course, we could just create a new clone directly from the CVS repository. It took me less than half an hour to figure out how to do the conversion and run it. I should probably also clarify that I don't have a strong opinion about which VCS we use. Both git and hg are excellent systems and have major advantages over CVS/SVN, especially for open-source projects. I slightly favor hg for this project, mainly because it's a cross-platform project and git may prevent Windows-users from contributing. Considering Edwin's major contributions to the project thus far, I think that's a very real concern. I hope that my clone will help the team make an informed choice. I probably should have made all this clear in my previous email, and I apologize for any confusion. Thanks, ~Aaron Farrukh Najmi wrote: > > Hi Aaron, > > Respectfully, I think creating another repo unilaterally is at best > going to create confusion and at worst create issues for the team. > For starters, I will assume that repo is not integrated with the SF > authentication mechanism. Please lets not create a parrallel universe > outside of the SF project. > > At the end of the day this VCS debate is not what the project is > about. I for one would be happy with any VCS as long as it is hosted > at sourceforge, integrated with SF identity management and is > supported and backed up by SF. That choice presently is cvs, svn and git. > As I said, SF willlikely have hg very soon. I am happy to wait for hg > at SF and stay with CVS. I am also happy to move to git now. I am > happy to move to svn if we do not plan to move again to hg or git. I > am most unhappy moving out of SF. > > Just my 2 cents. > > Thanks and I hope you do not mind me speaking frankly and with > complete respect for you. > > Aaron Novstrup wrote: >> In case anyone's interested in toying with hg, I've created a clone >> of the gwt-openlayers repository here: >> http://bitbucket.org/anovstrup/gwt-openlayers/ >> >> I didn't take the time to check how the conversion went, so let me >> know if you notice any weirdness. >> > > |
|
From: Farrukh N. <fa...@we...> - 2009-03-07 00:51:14
|
Hi Aaron, Respectfully, I think creating another repo unilaterally is at best going to create confusion and at worst create issues for the team. For starters, I will assume that repo is not integrated with the SF authentication mechanism. Please lets not create a parrallel universe outside of the SF project. At the end of the day this VCS debate is not what the project is about. I for one would be happy with any VCS as long as it is hosted at sourceforge, integrated with SF identity management and is supported and backed up by SF. That choice presently is cvs, svn and git. As I said, SF willlikely have hg very soon. I am happy to wait for hg at SF and stay with CVS. I am also happy to move to git now. I am happy to move to svn if we do not plan to move again to hg or git. I am most unhappy moving out of SF. Just my 2 cents. Thanks and I hope you do not mind me speaking frankly and with complete respect for you. Aaron Novstrup wrote: > In case anyone's interested in toying with hg, I've created a clone of > the gwt-openlayers repository here: > http://bitbucket.org/anovstrup/gwt-openlayers/ > > I didn't take the time to check how the conversion went, so let me > know if you notice any weirdness. > -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Aaron N. <ano...@st...> - 2009-03-06 23:33:18
|
In case anyone's interested in toying with hg, I've created a clone of the gwt-openlayers repository here: http://bitbucket.org/anovstrup/gwt-openlayers/ I didn't take the time to check how the conversion went, so let me know if you notice any weirdness. Thanks, ~Aaron |
8 messages has been excluded from this view by a project administrator.
