Menu
▾
▴
gwt-openlayers-users — Users list. Moderately active.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
(17) |
Apr
|
May
|
Jun
(6) |
Jul
(10) |
Aug
(16) |
Sep
(4) |
Oct
(16) |
Nov
(8) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(5) |
Feb
(28) |
Mar
(35) |
Apr
(20) |
May
(13) |
Jun
(24) |
Jul
(14) |
Aug
(8) |
Sep
(19) |
Oct
(13) |
Nov
(16) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(10) |
Mar
(16) |
Apr
(14) |
May
(21) |
Jun
(20) |
Jul
(12) |
Aug
(18) |
Sep
(11) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Simon B. <sim...@gm...> - 2011-09-14 00:46:33
|
Francesco I suspect that your url is missing some details... >From the root of the url the first section should contain the context or the folder in the webapps folder of your server. The next section should be the servlet name as configured in your web.xml. The parameter looks to be correct. regards, Simon Borysiewicz ------------------------------ *From:* Francesco Izzi [mailto:fra...@ge...] *Sent:* Tuesday, 13 September 2011 11:48 PM *To:* gwt...@li... *Subject:* [Gwt-openlayers-users] gwtOpenLayersProxy servlet does not work Hi Guys, i need to test the wfs examples,but does not work. I try the Basic WFS examples but in the GWT console i get: 00:00:18,174 [WARN] 404 - POST /gwtOpenLayersProxy?targetURL=http%3A%2F% 2Fdemo.opengeo.org%2Fgeoserver%2Fwfs (127.0.0.1) 1404 bytes Suggestion ? -- Francesco IzziCNR - IMAA geoSDI Direzione Tecnologie e Sviluppo C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971427305 fax: +39 0971 427271 mob: +39 3203126609 mail: fra...@ge... skype: neofx8080 web: http://www.geosdi.org |
|
From: Francesco I. <fra...@ge...> - 2011-09-13 13:48:11
|
Hi Guys, i need to test the wfs examples,but does not work. I try the Basic WFS examples but in the GWT console i get: 00:00:18,174 [WARN] 404 - POST /gwtOpenLayersProxy?targetURL=http%3A%2F% 2Fdemo.opengeo.org%2Fgeoserver%2Fwfs (127.0.0.1) 1404 bytes Suggestion ? -- Francesco IzziCNR - IMAA geoSDI Direzione Tecnologie e Sviluppo C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971427305 fax: +39 0971 427271 mob: +39 3203126609 mail: fra...@ge... skype: neofx8080 web: http://www.geosdi.org |
|
From: Alexandre A. S. <aas...@gm...> - 2011-09-05 12:07:29
|
Hi, It seems you're forgetting to add the control to the map. Try: Navigation controlPan= new Navigation(); openLayersMap.addControl(controlPan); controlPan.activate(); Cheers, Alex. ________________________________________ De: Jan Barrera [qui...@ya...] Enviado el: lunes, 05 de septiembre de 2011 12:52 Para: gwt...@li... Asunto: [Gwt-openlayers-users] Map Controls Hi, Im trying to create an (external) tool bar with zoom in, zoom out and drag controls for my map. however, i cannot seem to attach the controls to the map. when i activate the control (ex. zoomin.activate()), nothing happens when i try click or pan through the map. any help would be appreciated. thanks, Jan ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ |
|
From: Giuseppe La S. <giu...@ge...> - 2011-09-05 10:55:22
|
Give a look here http://code.google.com/p/geo-platform/. Regards Giuseppe 2011/9/5 Jan Barrera <qui...@ya...> > Hi, > > Im trying to create an (external) tool bar with zoom in, zoom out and drag > controls for my map. however, i cannot seem to attach the controls to the > map. when i activate the control (ex. zoomin.activate()), nothing happens > when i try click or pan through the map. any help would be appreciated. > > thanks, > Jan > > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > > -- Giuseppe La Scaleia CNR - IMAA geoSDI Sviluppo Software C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971427305 fax: +39 0971 427271 mob: +39 3804697436 mail: giu...@ge... skype: glascaleia web: http://www.geosdi.org |
|
From: Jan B. <qui...@ya...> - 2011-09-05 10:52:52
|
Hi, Im trying to create an (external) tool bar with zoom in, zoom out and drag controls for my map. however, i cannot seem to attach the controls to the map. when i activate the control (ex. zoomin.activate()), nothing happens when i try click or pan through the map. any help would be appreciated. thanks,Jan |
|
From: Romain B. <bod...@gm...> - 2011-09-02 13:50:08
|
Hi everyone,
Since I'm using OpenLayers, I'm using the basic WMS URL and layers as
followed :
WMSParams wmsParams = new WMSParams();
wmsParams.setLayers("basic");
WMS wmsLayer = new WMS("WMS Layer", "http://labs.metacarta.com/wms/vmap0",
wmsParams);
But does it exists a layer and/or an URL which display place-names
(continents, countries, roads, etc...) ?
Thank you in advance.
Romain
|
|
From: Tim D. <tim...@ri...> - 2011-09-01 12:41:20
|
Thanks very much - that seems to be working.
The problem I have now is that I am using the OSM layer as my base map (it's
an EPSG:900913 projection). Is there any way to transform the
EPSG:4326 features that are returned from the KML read method before adding
them to the map? I have previously transformed individual LatLons but can't
see how to do it for Geometries...
Tim.
On 31 August 2011 16:47, Alexandre Ascasibar Sequeiros
<aas...@gm...>wrote:
> Hi Tim,
> of course I can...
>
> public void addKMLFile(String KMLContent)
> {
> //Read kml file
> KML kmlReader= new KML();
> kmlReader.getJSObject().setProperty("extractStyles", true);
> kmlReader.getJSObject().setProperty("extractAttributes",
> true);
>
> VectorFeature[] features= kmlReader.read(KMLContent);
> //loop for all artefacts in the file
> for (VectorFeature feature: features)
> {
> yourLayer.addFeature(feature);
> }
> }
>
> Cheers,
> Alex
> ________________________________________
> De: Tim Dudman [tim...@ri...]
> Enviado el: miércoles, 31 de agosto de 2011 17:20
> Para: Alexandre Ascasibar Sequeiros
> CC: gwt...@li...
> Asunto: Re: [Gwt-openlayers-users] GWT OpenLayers KML layer
>
> Thanks for the quick response Alex.
>
> Reading the file from the server using GWT is no problem. Would it be
> possible to show me an example of the GWT Openlayers API calls I need to
> make to get the KML onto the map using the KML object and VectorFeature
> array? I'm assuming it's only a few lines of code but I can't find any
> examples...
>
> Thanks again,
>
> Tim.
>
> Tim Dudman
> Principal Consultant
> RiskAware Ltd
> Tel: +44 (0) 117 9330543
> Web: www.riskaware.co.uk<http://www.riskaware.co.uk>
>
>
>
>
> On 31 August 2011 15:52, Alexandre Ascasibar Sequeiros <aas...@gm...
> <mailto:aas...@gm...>> wrote:
> Hi Tim,
>
> The method read of the object KML allows you to transform a KML content
> into an array of VectorFeature[]. If you have this KML content in a file in
> the client you have to use a GWT upload widget in order to read the file. If
> the file it's in the server you have to create a GWT RPC service in order to
> read the file.
>
> I hope it helps.
>
> Cheers,
> Alex
> ________________________________________
> De: Tim Dudman [tim...@ri...<mailto:
> tim...@ri...>]
> Enviado el: miércoles, 31 de agosto de 2011 16:01
> Para: gwt...@li...<mailto:
> gwt...@li...>
> Asunto: [Gwt-openlayers-users] GWT OpenLayers KML layer
>
> All,
>
> Is it possible to add a KML layer to GWT OpenLayers?
>
> If so, could someone show me an example of adding a KML layer based on a
> KML file URL?
>
> Thanks in advance,
>
> Tim.
>
>
> RiskAware Limited. Registered in England. Company Number: 3812608. VAT
> Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston
> Street, Bristol, BS1 4XE.
>
> The information in this email is intended solely for the addressee(s) and
> may contain privileged material. Access to this email by anyone else is
> unauthorised. Any review, retransmission, dissemination or any use of this
> information by persons or entities other than the intended recipient is
> strictly prohibited.
>
> RiskAware Ltd reserves the right to monitor all outgoing and incoming
> e-mails.
>
>
>
> ______________________
> This message including any attachments may contain confidential
> information, according to our Information Security Management System,
> and intended solely for a specific individual to whom they are addressed.
> Any unauthorised copy, disclosure or distribution of this message
> is strictly forbidden. If you have received this transmission in error,
> please notify the sender immediately and delete it.
>
> ______________________
> Este mensaje, y en su caso, cualquier fichero anexo al mismo,
> puede contener informacion clasificada por su emisor como confidencial
> en el marco de su Sistema de Gestion de Seguridad de la
> Informacion siendo para uso exclusivo del destinatario, quedando
> prohibida su divulgacion copia o distribucion a terceros sin la
> autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
> erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
> Gracias por su colaboracion.
>
> ______________________
>
>
>
> RiskAware Limited. Registered in England. Company Number: 3812608. VAT
> Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston
> Street, Bristol, BS1 4XE.
>
> The information in this email is intended solely for the addressee(s) and
> may contain privileged material. Access to this email by anyone else is
> unauthorised. Any review, retransmission, dissemination or any use of this
> information by persons or entities other than the intended recipient is
> strictly prohibited.
>
> RiskAware Ltd reserves the right to monitor all outgoing and incoming
> e-mails.
>
>
>
>
> ______________________
> This message including any attachments may contain confidential
> information, according to our Information Security Management System,
> and intended solely for a specific individual to whom they are addressed.
> Any unauthorised copy, disclosure or distribution of this message
> is strictly forbidden. If you have received this transmission in error,
> please notify the sender immediately and delete it.
>
> ______________________
> Este mensaje, y en su caso, cualquier fichero anexo al mismo,
> puede contener informacion clasificada por su emisor como confidencial
> en el marco de su Sistema de Gestion de Seguridad de la
> Informacion siendo para uso exclusivo del destinatario, quedando
> prohibida su divulgacion copia o distribucion a terceros sin la
> autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
> erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
> Gracias por su colaboracion.
>
> ______________________
>
>
RiskAware Limited. Registered in England. Company Number: 3812608. VAT Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston Street, Bristol, BS1 4XE.
The information in this email is intended solely for the addressee(s) and may contain privileged material. Access to this email by anyone else is unauthorised. Any review, retransmission, dissemination or any use of this information by persons or entities other than the intended recipient is strictly prohibited.
RiskAware Ltd reserves the right to monitor all outgoing and incoming e-mails.
|
|
From: Alexandre A. S. <aas...@gm...> - 2011-08-31 16:20:36
|
Hi Tim,
of course I can...
public void addKMLFile(String KMLContent)
{
//Read kml file
KML kmlReader= new KML();
kmlReader.getJSObject().setProperty("extractStyles", true);
kmlReader.getJSObject().setProperty("extractAttributes", true);
VectorFeature[] features= kmlReader.read(KMLContent);
//loop for all artefacts in the file
for (VectorFeature feature: features)
{
yourLayer.addFeature(feature);
}
}
Cheers,
Alex
________________________________________
De: Tim Dudman [tim...@ri...]
Enviado el: miércoles, 31 de agosto de 2011 17:20
Para: Alexandre Ascasibar Sequeiros
CC: gwt...@li...
Asunto: Re: [Gwt-openlayers-users] GWT OpenLayers KML layer
Thanks for the quick response Alex.
Reading the file from the server using GWT is no problem. Would it be possible to show me an example of the GWT Openlayers API calls I need to make to get the KML onto the map using the KML object and VectorFeature array? I'm assuming it's only a few lines of code but I can't find any examples...
Thanks again,
Tim.
Tim Dudman
Principal Consultant
RiskAware Ltd
Tel: +44 (0) 117 9330543
Web: www.riskaware.co.uk<http://www.riskaware.co.uk>
On 31 August 2011 15:52, Alexandre Ascasibar Sequeiros <aas...@gm...<mailto:aas...@gm...>> wrote:
Hi Tim,
The method read of the object KML allows you to transform a KML content into an array of VectorFeature[]. If you have this KML content in a file in the client you have to use a GWT upload widget in order to read the file. If the file it's in the server you have to create a GWT RPC service in order to read the file.
I hope it helps.
Cheers,
Alex
________________________________________
De: Tim Dudman [tim...@ri...<mailto:tim...@ri...>]
Enviado el: miércoles, 31 de agosto de 2011 16:01
Para: gwt...@li...<mailto:gwt...@li...>
Asunto: [Gwt-openlayers-users] GWT OpenLayers KML layer
All,
Is it possible to add a KML layer to GWT OpenLayers?
If so, could someone show me an example of adding a KML layer based on a KML file URL?
Thanks in advance,
Tim.
RiskAware Limited. Registered in England. Company Number: 3812608. VAT Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston Street, Bristol, BS1 4XE.
The information in this email is intended solely for the addressee(s) and may contain privileged material. Access to this email by anyone else is unauthorised. Any review, retransmission, dissemination or any use of this information by persons or entities other than the intended recipient is strictly prohibited.
RiskAware Ltd reserves the right to monitor all outgoing and incoming e-mails.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
RiskAware Limited. Registered in England. Company Number: 3812608. VAT Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston Street, Bristol, BS1 4XE.
The information in this email is intended solely for the addressee(s) and may contain privileged material. Access to this email by anyone else is unauthorised. Any review, retransmission, dissemination or any use of this information by persons or entities other than the intended recipient is strictly prohibited.
RiskAware Ltd reserves the right to monitor all outgoing and incoming e-mails.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
|
|
From: Tim D. <tim...@ri...> - 2011-08-31 15:20:37
|
Thanks for the quick response Alex. Reading the file from the server using GWT is no problem. Would it be possible to show me an example of the GWT Openlayers API calls I need to make to get the KML onto the map using the KML object and VectorFeature array? I'm assuming it's only a few lines of code but I can't find any examples... Thanks again, Tim. * Tim Dudman* *Principal Consultant* *RiskAware Ltd* *Tel: +44 (0) 117 9330543* *Web: **www.riskaware.co.uk* <http://www.riskaware.co.uk> On 31 August 2011 15:52, Alexandre Ascasibar Sequeiros <aas...@gm...>wrote: > Hi Tim, > > The method read of the object KML allows you to transform a KML content > into an array of VectorFeature[]. If you have this KML content in a file in > the client you have to use a GWT upload widget in order to read the file. If > the file it's in the server you have to create a GWT RPC service in order to > read the file. > > I hope it helps. > > Cheers, > Alex > ________________________________________ > De: Tim Dudman [tim...@ri...] > Enviado el: miércoles, 31 de agosto de 2011 16:01 > Para: gwt...@li... > Asunto: [Gwt-openlayers-users] GWT OpenLayers KML layer > > All, > > Is it possible to add a KML layer to GWT OpenLayers? > > If so, could someone show me an example of adding a KML layer based on a > KML file URL? > > Thanks in advance, > > Tim. > > > RiskAware Limited. Registered in England. Company Number: 3812608. VAT > Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston > Street, Bristol, BS1 4XE. > > The information in this email is intended solely for the addressee(s) and > may contain privileged material. Access to this email by anyone else is > unauthorised. Any review, retransmission, dissemination or any use of this > information by persons or entities other than the intended recipient is > strictly prohibited. > > RiskAware Ltd reserves the right to monitor all outgoing and incoming > e-mails. > > > > ______________________ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > > ______________________ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > > ______________________ > > RiskAware Limited. Registered in England. Company Number: 3812608. VAT Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston Street, Bristol, BS1 4XE. The information in this email is intended solely for the addressee(s) and may contain privileged material. Access to this email by anyone else is unauthorised. Any review, retransmission, dissemination or any use of this information by persons or entities other than the intended recipient is strictly prohibited. RiskAware Ltd reserves the right to monitor all outgoing and incoming e-mails. |
|
From: Alexandre A. S. <aas...@gm...> - 2011-08-31 14:55:38
|
Hi Tim, The method read of the object KML allows you to transform a KML content into an array of VectorFeature[]. If you have this KML content in a file in the client you have to use a GWT upload widget in order to read the file. If the file it's in the server you have to create a GWT RPC service in order to read the file. I hope it helps. Cheers, Alex ________________________________________ De: Tim Dudman [tim...@ri...] Enviado el: miércoles, 31 de agosto de 2011 16:01 Para: gwt...@li... Asunto: [Gwt-openlayers-users] GWT OpenLayers KML layer All, Is it possible to add a KML layer to GWT OpenLayers? If so, could someone show me an example of adding a KML layer based on a KML file URL? Thanks in advance, Tim. RiskAware Limited. Registered in England. Company Number: 3812608. VAT Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston Street, Bristol, BS1 4XE. The information in this email is intended solely for the addressee(s) and may contain privileged material. Access to this email by anyone else is unauthorised. Any review, retransmission, dissemination or any use of this information by persons or entities other than the intended recipient is strictly prohibited. RiskAware Ltd reserves the right to monitor all outgoing and incoming e-mails. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ |
|
From: Tim D. <tim...@ri...> - 2011-08-31 14:24:04
|
All, Is it possible to add a KML layer to GWT OpenLayers? If so, could someone show me an example of adding a KML layer based on a KML file URL? Thanks in advance, Tim. RiskAware Limited. Registered in England. Company Number: 3812608. VAT Number: 740 891 815. Registered Address: 9th Floor, Colston Tower, Colston Street, Bristol, BS1 4XE. The information in this email is intended solely for the addressee(s) and may contain privileged material. Access to this email by anyone else is unauthorised. Any review, retransmission, dissemination or any use of this information by persons or entities other than the intended recipient is strictly prohibited. RiskAware Ltd reserves the right to monitor all outgoing and incoming e-mails. |
|
From: Florian S. <Flo...@Op...> - 2011-08-31 10:35:07
|
Hello everyone, thanks for the kind (and quick) replies, I wouldn't have thought that it was that simple. Somehow I thought it had to be much more complicated. :-) Seems to work very fine, so thanks for the help. Regards, Flo |
|
From: Alexandre A. S. <aas...@gm...> - 2011-08-31 10:21:44
|
Hi Florian,
I've to do a kind of the same two months ago with the modificationfeature control instead of selectionfeature control. Indeed, in Js you have the method selectFeature, but in gwt you don't, so you have to call a native Js method using JSNI.
Firstly create in your code a method like this:
public static native void linkControlFeature(JSObject control, JSObject feature)/*-{
control.selectFeature(feature);
}-*/;
and where you want to select by code the feature make a call like:
linkControlFeature(controlModifyFeature.getJSObject(), feature.getJSObject());
At least for me that works for modifycontrol, so I hope it helps to you.
Cheers,
Alex.
________________________________________
De: Florian Schaetz [Flo...@Op...]
Enviado el: miércoles, 31 de agosto de 2011 11:40
Para: gwt...@li...
Asunto: [Gwt-openlayers-users] Select in Vector Layer
Hi,
I've got a little problem here with Gwt-Openlayers, perhaps someone more clever than me has a good idea:
Is there a possibility to select a VectorFeature in my Vector Layer (via code, not mouse clicking, obviously :-)? I know (read somewhere) that there is an (undocumented?) select method in the original JS OpenLayer code of SelectFeature, but the GWT OpenLayers Implementation only offers an unselect method in the SelectFeatureImpl class. I would need that method to synchronize the state of the vector layer with another widget.
Would be great if anyone had a good idea on how to do that.
Regards,
Flo
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Gwt-openlayers-users mailing list
Gwt...@li...
https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
|
|
From: Florian S. <Flo...@Op...> - 2011-08-31 09:55:08
|
Hi, I've got a little problem here with Gwt-Openlayers, perhaps someone more clever than me has a good idea: Is there a possibility to select a VectorFeature in my Vector Layer (via code, not mouse clicking, obviously :-)? I know (read somewhere) that there is an (undocumented?) select method in the original JS OpenLayer code of SelectFeature, but the GWT OpenLayers Implementation only offers an unselect method in the SelectFeatureImpl class. I would need that method to synchronize the state of the vector layer with another widget. Would be great if anyone had a good idea on how to do that. Regards, Flo |
|
From: Andrew H. <ahh...@gm...> - 2011-08-15 23:44:17
|
Hi All, Unless I have overlooked something, 100% of votes are 'YES'. So I will move to de-commission the SourceForge repository. Thanks for all your votes :) --AH On Thu, Aug 4, 2011 at 2:21 PM, Simon Borysiewicz < sim...@gm...> wrote: > YES vote. I have been working in a team that has been making additions > to the gwt-openlayers source and would like an easy way to put forward a > patch for review > > regards, > > Simon Borysiewicz > > ------------------------------ > * > * > *From:* Andrew Hughes [mailto:ahh...@gm...] > *Sent:* Monday, 1 August 2011 9:55 PM > *To:* gwt...@li...; > gwt...@li... > *Subject:* [Gwt-openlayers-users] GWT-OpenLayers : Vote on an SCM move to > BitBucket > > Hi All, > > This is for both the devel and users list. Currently the number of emails > we receive regarding contributing to the project indicates that the process > is not straight forward, not easy and not intuitive. This would no doubt > preclude a lot of "would be" contributors from contributing and something I > believe we must address. > > Goal: Make it as easy as possible for everyone to contribute > without compromising the stability and quality of the codebase. > > At this point you can read on or jump the the conclusion and vote at the > end.... > > *How Distributed Version Control Should be Used (IMHO):* > > Distributed version control should pass through a hierarchy of repositories > as it makes its way onto the stable baseline that releases are cut from > (Linus would probably call this a 'network of trust'). Believe it or not, > this is more about opening up access to source control than it is > restricting it. Why, because this way everyone has a sandbox repository to > fool around in, try things out, send them to others... do some RnD e.t.c. > This means that rather than sending an email to the mailing list about "how > can I contribute this" or "what is the process" or "here are some patches" > or "can I have access to the repository" everybody can just work with their > own repository... nice! It also means that since this is in a repository, it > can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the > next release! via 'pull requests'. > > *What's the problem with GWT-OpenLayer's and Folllowing this:* > > The fundamental problem is that its *NOT EASY* for us to adhere to such a > process with SourceForge's source repository administration. It's possible, > but certainly not easy. > -Creating a new repository for a developer involves too much manual input. > A new member needs to send a request (email), the request needs to be > granted, the repository needs be be manually created by an administrator via > shell. > -Controlling access to each repository involves too much manual input, > SourceForge's administration web ui doesn't control who can push to each > repository. Administrators have to ssh in and then edit the > gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository > permissions. Again, this takes too much manual effort. > -Promoting code is also too manually intensive, the reason is that if an > individual actually gets their own repository, then then push up some work > to it. The only want that it will be push up into the baseline repository > that we release from is by sending emails, or patches via email e.t.c and > this is often not an intuitive or inviting process. This process is not > intrinsic in SourceForge's source control hosting. > > *Addressing these Issues:* > > Rather than documenting, emailing and publishing a DIY process of making a > contribution and how to work with source control, *we should target a > hosting service where the process is intrinsic in the service it's self * :) The > sooner we can switch the better. > > *CONCLUSION* > > Some of the developers are already using bitbucket ( > https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. > This can work concurrently with SF's mercurial. However, we should really > focus on bitbucket's additional features (such as forking, pull requests > e.t.c). These features provide us with a suitable service and an easy, > intrinsic process for contribution. Using SF and bitbucket concurrently is > something I would not recommend either, it doesn't solve our problem. > > *Please vote on a move to BitBucket and decommission SF's mercurial > repository YES/NO?* > > Cheers :) > > |
|
From: Simon B. <sim...@gm...> - 2011-08-04 04:51:46
|
YES vote. I have been working in a team that has been making additions to the gwt-openlayers source and would like an easy way to put forward a patch for review regards, Simon Borysiewicz ------------------------------ * * *From:* Andrew Hughes [mailto:ahh...@gm...] *Sent:* Monday, 1 August 2011 9:55 PM *To:* gwt...@li...; gwt...@li... *Subject:* [Gwt-openlayers-users] GWT-OpenLayers : Vote on an SCM move to BitBucket Hi All, This is for both the devel and users list. Currently the number of emails we receive regarding contributing to the project indicates that the process is not straight forward, not easy and not intuitive. This would no doubt preclude a lot of "would be" contributors from contributing and something I believe we must address. Goal: Make it as easy as possible for everyone to contribute without compromising the stability and quality of the codebase. At this point you can read on or jump the the conclusion and vote at the end.... *How Distributed Version Control Should be Used (IMHO):* Distributed version control should pass through a hierarchy of repositories as it makes its way onto the stable baseline that releases are cut from (Linus would probably call this a 'network of trust'). Believe it or not, this is more about opening up access to source control than it is restricting it. Why, because this way everyone has a sandbox repository to fool around in, try things out, send them to others... do some RnD e.t.c. This means that rather than sending an email to the mailing list about "how can I contribute this" or "what is the process" or "here are some patches" or "can I have access to the repository" everybody can just work with their own repository... nice! It also means that since this is in a repository, it can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the next release! via 'pull requests'. *What's the problem with GWT-OpenLayer's and Folllowing this:* The fundamental problem is that its *NOT EASY* for us to adhere to such a process with SourceForge's source repository administration. It's possible, but certainly not easy. -Creating a new repository for a developer involves too much manual input. A new member needs to send a request (email), the request needs to be granted, the repository needs be be manually created by an administrator via shell. -Controlling access to each repository involves too much manual input, SourceForge's administration web ui doesn't control who can push to each repository. Administrators have to ssh in and then edit the gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository permissions. Again, this takes too much manual effort. -Promoting code is also too manually intensive, the reason is that if an individual actually gets their own repository, then then push up some work to it. The only want that it will be push up into the baseline repository that we release from is by sending emails, or patches via email e.t.c and this is often not an intuitive or inviting process. This process is not intrinsic in SourceForge's source control hosting. *Addressing these Issues:* Rather than documenting, emailing and publishing a DIY process of making a contribution and how to work with source control, *we should target a hosting service where the process is intrinsic in the service it's self * :) The sooner we can switch the better. *CONCLUSION* Some of the developers are already using bitbucket ( https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. This can work concurrently with SF's mercurial. However, we should really focus on bitbucket's additional features (such as forking, pull requests e.t.c). These features provide us with a suitable service and an easy, intrinsic process for contribution. Using SF and bitbucket concurrently is something I would not recommend either, it doesn't solve our problem. *Please vote on a move to BitBucket and decommission SF's mercurial repository YES/NO?* Cheers :) |
|
From: lorenzo a. <lor...@gm...> - 2011-08-02 07:15:37
|
+1 for me (YES) 2011/8/1 Andrew Hughes <ahh...@gm...> > Hi All, > > This is for both the devel and users list. Currently the number of emails > we receive regarding contributing to the project indicates that the process > is not straight forward, not easy and not intuitive. This would no doubt > preclude a lot of "would be" contributors from contributing and something I > believe we must address. > > Goal: Make it as easy as possible for everyone to contribute > without compromising the stability and quality of the codebase. > > At this point you can read on or jump the the conclusion and vote at the > end.... > > *How Distributed Version Control Should be Used (IMHO):* > > Distributed version control should pass through a hierarchy of repositories > as it makes its way onto the stable baseline that releases are cut from > (Linus would probably call this a 'network of trust'). Believe it or not, > this is more about opening up access to source control than it is > restricting it. Why, because this way everyone has a sandbox repository to > fool around in, try things out, send them to others... do some RnD e.t.c. > This means that rather than sending an email to the mailing list about "how > can I contribute this" or "what is the process" or "here are some patches" > or "can I have access to the repository" everybody can just work with their > own repository... nice! It also means that since this is in a repository, it > can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the > next release! via 'pull requests'. > > *What's the problem with GWT-OpenLayer's and Folllowing this:* > > The fundamental problem is that its *NOT EASY* for us to adhere to such a > process with SourceForge's source repository administration. It's possible, > but certainly not easy. > -Creating a new repository for a developer involves too much manual input. > A new member needs to send a request (email), the request needs to be > granted, the repository needs be be manually created by an administrator via > shell. > -Controlling access to each repository involves too much manual input, > SourceForge's administration web ui doesn't control who can push to each > repository. Administrators have to ssh in and then edit the > gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository > permissions. Again, this takes too much manual effort. > -Promoting code is also too manually intensive, the reason is that if an > individual actually gets their own repository, then then push up some work > to it. The only want that it will be push up into the baseline repository > that we release from is by sending emails, or patches via email e.t.c and > this is often not an intuitive or inviting process. This process is not > intrinsic in SourceForge's source control hosting. > > *Addressing these Issues:* > > Rather than documenting, emailing and publishing a DIY process of making a > contribution and how to work with source control, *we should target a > hosting service where the process is intrinsic in the service it's self * :) The > sooner we can switch the better. > > *CONCLUSION* > > Some of the developers are already using bitbucket ( > https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. > This can work concurrently with SF's mercurial. However, we should really > focus on bitbucket's additional features (such as forking, pull requests > e.t.c). These features provide us with a suitable service and an easy, > intrinsic process for contribution. Using SF and bitbucket concurrently is > something I would not recommend either, it doesn't solve our problem. > > *Please vote on a move to BitBucket and decommission SF's mercurial > repository YES/NO?* > > Cheers :) > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > > -- Lorenzo Amato Consiglio Nazionale delle Ricerche Istituto di Metodologie per l'Analisi Ambientale - geoSDI C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971 427 305 fax: +39 0971 427 271 mob: +39 349 28 43 992 mail: lor...@ge... skype: lorenzo.amato.skype web: www.geosdi.org |
|
From: Francesco I. <fra...@ge...> - 2011-08-01 19:03:35
|
YES +1 Il giorno 01/ago/2011 17:02, "Piotr Tracz" <pi...@cg...> ha scritto: > YES for anything better > > W dniu 2011-08-01 13:54, Andrew Hughes pisze: >> Hi All, >> >> This is for both the devel and users list. Currently the number of >> emails we receive regarding contributing to the project indicates that >> the process is not straight forward, not easy and not intuitive. This >> would no doubt preclude a lot of "would be" contributors from >> contributing and something I believe we must address. >> >> Goal: Make it as easy as possible for everyone to contribute >> without compromising the stability and quality of the codebase. >> >> At this point you can read on or jump the the conclusion and vote at >> the end.... >> >> *How Distributed Version Control Should be Used (IMHO):* >> >> Distributed version control should pass through a hierarchy of >> repositories as it makes its way onto the stable baseline that >> releases are cut from (Linus would probably call this a 'network of >> trust'). Believe it or not, this is more about opening up access to >> source control than it is restricting it. Why, because this way >> everyone has a sandbox repository to fool around in, try things out, >> send them to others... do some RnD e.t.c. This means that rather than >> sending an email to the mailing list about "how can I contribute this" >> or "what is the process" or "here are some patches" or "can I have >> access to the repository" everybody can just work with their own >> repository... nice! It also means that since this is in a repository, >> it can be easily promoted/pulled into the GWT-OpenLayers baseline >> ready for the next release! via 'pull requests'. >> >> *What's the problem with GWT-OpenLayer's and Folllowing this:* >> >> The fundamental problem is that its *NOT EASY* for us to adhere to >> such a process with SourceForge's source repository administration. >> It's possible, but certainly not easy. >> -Creating a new repository for a developer involves too much manual >> input. A new member needs to send a request (email), the request needs >> to be granted, the repository needs be be manually created by an >> administrator via shell. >> -Controlling access to each repository involves too much manual input, >> SourceForge's administration web ui doesn't control who can push to >> each repository. Administrators have to ssh in and then edit the >> gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository >> permissions. Again, this takes too much manual effort. >> -Promoting code is also too manually intensive, the reason is that if >> an individual actually gets their own repository, then then push up >> some work to it. The only want that it will be push up into the >> baseline repository that we release from is by sending emails, or >> patches via email e.t.c and this is often not an intuitive or inviting >> process. This process is not intrinsic in SourceForge's source control >> hosting. >> >> *Addressing these Issues:* >> >> Rather than documenting, emailing and publishing a DIY process of >> making a contribution and how to work with source control, *we should >> target a hosting service where the process is intrinsic in the service >> it's self * :) The sooner we can switch the better. >> >> *_CONCLUSION_* >> >> Some of the developers are already using bitbucket >> (https://bitbucket.org/gwtopenlayers) for Mercurial repository >> hosting. This can work concurrently with SF's mercurial. However, we >> should really focus on bitbucket's additional features (such as >> forking, pull requests e.t.c). These features provide us with a >> suitable service and an easy, intrinsic process for contribution. >> Using SF and bitbucket concurrently is something I would not recommend >> either, it doesn't solve our problem. >> >> *Please vote on a move to BitBucket and decommission SF's mercurial >> repository YES/NO?* >> >> Cheers :) >> >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> >> >> _______________________________________________ >> Gwt-openlayers-users mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users |
|
From: Piotr T. <pi...@cg...> - 2011-08-01 15:02:38
|
YES for anything better W dniu 2011-08-01 13:54, Andrew Hughes pisze: > Hi All, > > This is for both the devel and users list. Currently the number of > emails we receive regarding contributing to the project indicates that > the process is not straight forward, not easy and not intuitive. This > would no doubt preclude a lot of "would be" contributors from > contributing and something I believe we must address. > > Goal: Make it as easy as possible for everyone to contribute > without compromising the stability and quality of the codebase. > > At this point you can read on or jump the the conclusion and vote at > the end.... > > *How Distributed Version Control Should be Used (IMHO):* > > Distributed version control should pass through a hierarchy of > repositories as it makes its way onto the stable baseline that > releases are cut from (Linus would probably call this a 'network of > trust'). Believe it or not, this is more about opening up access to > source control than it is restricting it. Why, because this way > everyone has a sandbox repository to fool around in, try things out, > send them to others... do some RnD e.t.c. This means that rather than > sending an email to the mailing list about "how can I contribute this" > or "what is the process" or "here are some patches" or "can I have > access to the repository" everybody can just work with their own > repository... nice! It also means that since this is in a repository, > it can be easily promoted/pulled into the GWT-OpenLayers baseline > ready for the next release! via 'pull requests'. > > *What's the problem with GWT-OpenLayer's and Folllowing this:* > > The fundamental problem is that its *NOT EASY* for us to adhere to > such a process with SourceForge's source repository administration. > It's possible, but certainly not easy. > -Creating a new repository for a developer involves too much manual > input. A new member needs to send a request (email), the request needs > to be granted, the repository needs be be manually created by an > administrator via shell. > -Controlling access to each repository involves too much manual input, > SourceForge's administration web ui doesn't control who can push to > each repository. Administrators have to ssh in and then edit the > gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository > permissions. Again, this takes too much manual effort. > -Promoting code is also too manually intensive, the reason is that if > an individual actually gets their own repository, then then push up > some work to it. The only want that it will be push up into the > baseline repository that we release from is by sending emails, or > patches via email e.t.c and this is often not an intuitive or inviting > process. This process is not intrinsic in SourceForge's source control > hosting. > > *Addressing these Issues:* > > Rather than documenting, emailing and publishing a DIY process of > making a contribution and how to work with source control, *we should > target a hosting service where the process is intrinsic in the service > it's self * :) The sooner we can switch the better. > > *_CONCLUSION_* > > Some of the developers are already using bitbucket > (https://bitbucket.org/gwtopenlayers) for Mercurial repository > hosting. This can work concurrently with SF's mercurial. However, we > should really focus on bitbucket's additional features (such as > forking, pull requests e.t.c). These features provide us with a > suitable service and an easy, intrinsic process for contribution. > Using SF and bitbucket concurrently is something I would not recommend > either, it doesn't solve our problem. > > *Please vote on a move to BitBucket and decommission SF's mercurial > repository YES/NO?* > > Cheers :) > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > > > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users |
|
From: Dave P. <dav...@pi...> - 2011-08-01 13:12:51
|
YES I am in favour off anything that makes life easier for programmers and cuts down on the amount of admin for administrators. > + 1 here. > > 2011/8/1 Edwin Commandeur <com...@gm...> > >> Hi Dave, >> >> To vote just reply to the email with a YES or NO in the body. >> >> The nature of the repository will not change. The source code will >> still be in a Mercurial repository. What changes will be the address >> of the main repository. Currently the main repository (representing >> the main line of work) is hosted at SourceForge. We would like to move >> this repository to Bitbucket. >> >> Moving to Bitbucket makes things easier for committers as well as >> administrators. For committers it means: >> - Committers will have to sign up for Bitbucket (free). >> - Committers can fork the project at Bitbucket to create their own >> sandbox >> - If you are already have commit rights on SourceForge you can get >> commit rights on the main repo at BitBucket (just send an email to me) >> and pull changes from your fork into the main repo >> - If you do not have commit rights then you can send pull requests, >> so the admins can decide if they want to pull changes from your >> sandbox (probably via a sandbox of the admin). >> >> Greetings, >> Edwin >> >> On 1 August 2011 14:11, Dave Potts <dav...@pi...> wrote: >> > Hi >> > >> > 1. How does one vote? do you have some type of link that can be used? >> > 2. What happens to existing projects? >> > >> > I have an entire series of useful(?) changes (console,http,handler >> > stratgy,projection etc) They are part of my personnel codebase how >> could >> > I integrate these changes if you change the nature of the Mercurial >> > repository? >> > >> > >> > Dave. >> >> Hi All, >> >> >> >> This is for both the devel and users list. Currently the number of >> emails >> >> we >> >> receive regarding contributing to the project indicates that the >> process >> >> is >> >> not straight forward, not easy and not intuitive. This would no doubt >> >> preclude a lot of "would be" contributors from contributing and >> something >> >> I >> >> believe we must address. >> >> >> >> Goal: Make it as easy as possible for everyone to contribute >> >> without compromising the stability and quality of the codebase. >> >> >> >> At this point you can read on or jump the the conclusion and vote at >> the >> >> end.... >> >> >> >> *How Distributed Version Control Should be Used (IMHO):* >> >> >> >> Distributed version control should pass through a hierarchy of >> >> repositories >> >> as it makes its way onto the stable baseline that releases are cut >> from >> >> (Linus would probably call this a 'network of trust'). Believe it or >> not, >> >> this is more about opening up access to source control than it is >> >> restricting it. Why, because this way everyone has a sandbox >> repository >> to >> >> fool around in, try things out, send them to others... do some RnD >> e.t.c. >> >> This means that rather than sending an email to the mailing list >> about >> >> "how >> >> can I contribute this" or "what is the process" or "here are some >> patches" >> >> or "can I have access to the repository" everybody can just work with >> >> their >> >> own repository... nice! It also means that since this is in a >> repository, >> >> it >> >> can be easily promoted/pulled into the GWT-OpenLayers baseline ready >> for >> >> the >> >> next release! via 'pull requests'. >> >> >> >> *What's the problem with GWT-OpenLayer's and Folllowing this:* >> >> >> >> The fundamental problem is that its *NOT EASY* for us to adhere to >> such >> a >> >> process with SourceForge's source repository administration. It's >> >> possible, >> >> but certainly not easy. >> >> -Creating a new repository for a developer involves too much manual >> input. >> >> A >> >> new member needs to send a request (email), the request needs to be >> >> granted, >> >> the repository needs be be manually created by an administrator via >> shell. >> >> -Controlling access to each repository involves too much manual >> input, >> >> SourceForge's administration web ui doesn't control who can push to >> each >> >> repository. Administrators have to ssh in and then edit the >> >> gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository >> >> permissions. Again, this takes too much manual effort. >> >> -Promoting code is also too manually intensive, the reason is that if >> an >> >> individual actually gets their own repository, then then push up some >> work >> >> to it. The only want that it will be push up into the baseline >> repository >> >> that we release from is by sending emails, or patches via email e.t.c >> and >> >> this is often not an intuitive or inviting process. This process is >> not >> >> intrinsic in SourceForge's source control hosting. >> >> >> >> *Addressing these Issues:* >> >> >> >> Rather than documenting, emailing and publishing a DIY process of >> making >> a >> >> contribution and how to work with source control, *we should target a >> >> hosting service where the process is intrinsic in the service it's >> >> self * :) The >> >> sooner we can switch the better. >> >> >> >> *CONCLUSION* >> >> >> >> Some of the developers are already using bitbucket ( >> >> https://bitbucket.org/gwtopenlayers) for Mercurial repository >> hosting. >> >> This >> >> can work concurrently with SF's mercurial. However, we should really >> focus >> >> on bitbucket's additional features (such as forking, pull requests >> e.t.c). >> >> These features provide us with a suitable service and an easy, >> intrinsic >> >> process for contribution. Using SF and bitbucket concurrently is >> something >> >> I >> >> would not recommend either, it doesn't solve our problem. >> >> >> >> *Please vote on a move to BitBucket and decommission SF's mercurial >> >> repository YES/NO?* >> >> >> >> Cheers :) >> >> >> ------------------------------------------------------------------------------ >> >> Got Input? Slashdot Needs You. >> >> Take our quick survey online. Come on, we don't ask for help often. >> >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> >> http://p.sf.net/sfu/slashdot-survey >> >> _______________________________________________ >> >> Gwt-openlayers-users mailing list >> >> Gwt...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> >> >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Got Input? Slashdot Needs You. >> > Take our quick survey online. Come on, we don't ask for help often. >> > Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> > http://p.sf.net/sfu/slashdot-survey >> > _______________________________________________ >> > Gwt-openlayers-users mailing list >> > Gwt...@li... >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > >> >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Gwt-openlayers-users mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > > > > -- > Giuseppe La Scaleia > CNR - IMAA > geoSDI > Sviluppo Software > > C.da S. Loja > 85050 Tito Scalo - POTENZA (PZ) > Italia > > phone: +39 0971427305 > fax: +39 0971 427271 > mob: +39 3804697436 > mail: giu...@ge... > skype: glascaleia > > web: http://www.geosdi.org > |
|
From: Lukas J. <luk...@de...> - 2011-08-01 13:11:48
|
+1 sounds just fine by me. Everything to make it easier to contribute. /Lukas Från: Giuseppe La Scaleia [mailto:giu...@ge...] Skickat: den 1 augusti 2011 15:05 Till: Edwin Commandeur Kopia: gwt...@li...; gwt...@li... Ämne: Re: [Gwt-openlayers-users] GWT-OpenLayers : Vote on an SCM move to BitBucket + 1 here. 2011/8/1 Edwin Commandeur <com...@gm...<mailto:com...@gm...>> Hi Dave, To vote just reply to the email with a YES or NO in the body. The nature of the repository will not change. The source code will still be in a Mercurial repository. What changes will be the address of the main repository. Currently the main repository (representing the main line of work) is hosted at SourceForge. We would like to move this repository to Bitbucket. Moving to Bitbucket makes things easier for committers as well as administrators. For committers it means: - Committers will have to sign up for Bitbucket (free). - Committers can fork the project at Bitbucket to create their own sandbox - If you are already have commit rights on SourceForge you can get commit rights on the main repo at BitBucket (just send an email to me) and pull changes from your fork into the main repo - If you do not have commit rights then you can send pull requests, so the admins can decide if they want to pull changes from your sandbox (probably via a sandbox of the admin). Greetings, Edwin On 1 August 2011 14:11, Dave Potts <dav...@pi...<mailto:dav...@pi...>> wrote: > Hi > > 1. How does one vote? do you have some type of link that can be used? > 2. What happens to existing projects? > > I have an entire series of useful(?) changes (console,http,handler > stratgy,projection etc) They are part of my personnel codebase how could > I integrate these changes if you change the nature of the Mercurial > repository? > > > Dave. >> Hi All, >> >> This is for both the devel and users list. Currently the number of emails >> we >> receive regarding contributing to the project indicates that the process >> is >> not straight forward, not easy and not intuitive. This would no doubt >> preclude a lot of "would be" contributors from contributing and something >> I >> believe we must address. >> >> Goal: Make it as easy as possible for everyone to contribute >> without compromising the stability and quality of the codebase. >> >> At this point you can read on or jump the the conclusion and vote at the >> end.... >> >> *How Distributed Version Control Should be Used (IMHO):* >> >> Distributed version control should pass through a hierarchy of >> repositories >> as it makes its way onto the stable baseline that releases are cut from >> (Linus would probably call this a 'network of trust'). Believe it or not, >> this is more about opening up access to source control than it is >> restricting it. Why, because this way everyone has a sandbox repository to >> fool around in, try things out, send them to others... do some RnD e.t.c. >> This means that rather than sending an email to the mailing list about >> "how >> can I contribute this" or "what is the process" or "here are some patches" >> or "can I have access to the repository" everybody can just work with >> their >> own repository... nice! It also means that since this is in a repository, >> it >> can be easily promoted/pulled into the GWT-OpenLayers baseline ready for >> the >> next release! via 'pull requests'. >> >> *What's the problem with GWT-OpenLayer's and Folllowing this:* >> >> The fundamental problem is that its *NOT EASY* for us to adhere to such a >> process with SourceForge's source repository administration. It's >> possible, >> but certainly not easy. >> -Creating a new repository for a developer involves too much manual input. >> A >> new member needs to send a request (email), the request needs to be >> granted, >> the repository needs be be manually created by an administrator via shell. >> -Controlling access to each repository involves too much manual input, >> SourceForge's administration web ui doesn't control who can push to each >> repository. Administrators have to ssh in and then edit the >> gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository >> permissions. Again, this takes too much manual effort. >> -Promoting code is also too manually intensive, the reason is that if an >> individual actually gets their own repository, then then push up some work >> to it. The only want that it will be push up into the baseline repository >> that we release from is by sending emails, or patches via email e.t.c and >> this is often not an intuitive or inviting process. This process is not >> intrinsic in SourceForge's source control hosting. >> >> *Addressing these Issues:* >> >> Rather than documenting, emailing and publishing a DIY process of making a >> contribution and how to work with source control, *we should target a >> hosting service where the process is intrinsic in the service it's >> self * :) The >> sooner we can switch the better. >> >> *CONCLUSION* >> >> Some of the developers are already using bitbucket ( >> https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. >> This >> can work concurrently with SF's mercurial. However, we should really focus >> on bitbucket's additional features (such as forking, pull requests e.t.c). >> These features provide us with a suitable service and an easy, intrinsic >> process for contribution. Using SF and bitbucket concurrently is something >> I >> would not recommend either, it doesn't solve our problem. >> >> *Please vote on a move to BitBucket and decommission SF's mercurial >> repository YES/NO?* >> >> Cheers :) >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Gwt-openlayers-users mailing list >> Gwt...@li...<mailto:Gwt...@li...> >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li...<mailto:Gwt...@li...> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Gwt-openlayers-users mailing list Gwt...@li...<mailto:Gwt...@li...> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users -- Giuseppe La Scaleia CNR - IMAA geoSDI Sviluppo Software C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971427305 fax: +39 0971 427271 mob: +39 3804697436 mail: giu...@ge...<mailto:giu...@ge...> skype: glascaleia web: http://www.geosdi.org [http://www.geosdi.org/images/stories/logo.png] |
|
From: Giuseppe La S. <giu...@ge...> - 2011-08-01 13:05:21
|
+ 1 here. 2011/8/1 Edwin Commandeur <com...@gm...> > Hi Dave, > > To vote just reply to the email with a YES or NO in the body. > > The nature of the repository will not change. The source code will > still be in a Mercurial repository. What changes will be the address > of the main repository. Currently the main repository (representing > the main line of work) is hosted at SourceForge. We would like to move > this repository to Bitbucket. > > Moving to Bitbucket makes things easier for committers as well as > administrators. For committers it means: > - Committers will have to sign up for Bitbucket (free). > - Committers can fork the project at Bitbucket to create their own sandbox > - If you are already have commit rights on SourceForge you can get > commit rights on the main repo at BitBucket (just send an email to me) > and pull changes from your fork into the main repo > - If you do not have commit rights then you can send pull requests, > so the admins can decide if they want to pull changes from your > sandbox (probably via a sandbox of the admin). > > Greetings, > Edwin > > On 1 August 2011 14:11, Dave Potts <dav...@pi...> wrote: > > Hi > > > > 1. How does one vote? do you have some type of link that can be used? > > 2. What happens to existing projects? > > > > I have an entire series of useful(?) changes (console,http,handler > > stratgy,projection etc) They are part of my personnel codebase how > could > > I integrate these changes if you change the nature of the Mercurial > > repository? > > > > > > Dave. > >> Hi All, > >> > >> This is for both the devel and users list. Currently the number of > emails > >> we > >> receive regarding contributing to the project indicates that the process > >> is > >> not straight forward, not easy and not intuitive. This would no doubt > >> preclude a lot of "would be" contributors from contributing and > something > >> I > >> believe we must address. > >> > >> Goal: Make it as easy as possible for everyone to contribute > >> without compromising the stability and quality of the codebase. > >> > >> At this point you can read on or jump the the conclusion and vote at the > >> end.... > >> > >> *How Distributed Version Control Should be Used (IMHO):* > >> > >> Distributed version control should pass through a hierarchy of > >> repositories > >> as it makes its way onto the stable baseline that releases are cut from > >> (Linus would probably call this a 'network of trust'). Believe it or > not, > >> this is more about opening up access to source control than it is > >> restricting it. Why, because this way everyone has a sandbox repository > to > >> fool around in, try things out, send them to others... do some RnD > e.t.c. > >> This means that rather than sending an email to the mailing list about > >> "how > >> can I contribute this" or "what is the process" or "here are some > patches" > >> or "can I have access to the repository" everybody can just work with > >> their > >> own repository... nice! It also means that since this is in a > repository, > >> it > >> can be easily promoted/pulled into the GWT-OpenLayers baseline ready for > >> the > >> next release! via 'pull requests'. > >> > >> *What's the problem with GWT-OpenLayer's and Folllowing this:* > >> > >> The fundamental problem is that its *NOT EASY* for us to adhere to such > a > >> process with SourceForge's source repository administration. It's > >> possible, > >> but certainly not easy. > >> -Creating a new repository for a developer involves too much manual > input. > >> A > >> new member needs to send a request (email), the request needs to be > >> granted, > >> the repository needs be be manually created by an administrator via > shell. > >> -Controlling access to each repository involves too much manual input, > >> SourceForge's administration web ui doesn't control who can push to each > >> repository. Administrators have to ssh in and then edit the > >> gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository > >> permissions. Again, this takes too much manual effort. > >> -Promoting code is also too manually intensive, the reason is that if an > >> individual actually gets their own repository, then then push up some > work > >> to it. The only want that it will be push up into the baseline > repository > >> that we release from is by sending emails, or patches via email e.t.c > and > >> this is often not an intuitive or inviting process. This process is not > >> intrinsic in SourceForge's source control hosting. > >> > >> *Addressing these Issues:* > >> > >> Rather than documenting, emailing and publishing a DIY process of making > a > >> contribution and how to work with source control, *we should target a > >> hosting service where the process is intrinsic in the service it's > >> self * :) The > >> sooner we can switch the better. > >> > >> *CONCLUSION* > >> > >> Some of the developers are already using bitbucket ( > >> https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. > >> This > >> can work concurrently with SF's mercurial. However, we should really > focus > >> on bitbucket's additional features (such as forking, pull requests > e.t.c). > >> These features provide us with a suitable service and an easy, intrinsic > >> process for contribution. Using SF and bitbucket concurrently is > something > >> I > >> would not recommend either, it doesn't solve our problem. > >> > >> *Please vote on a move to BitBucket and decommission SF's mercurial > >> repository YES/NO?* > >> > >> Cheers :) > >> > ------------------------------------------------------------------------------ > >> Got Input? Slashdot Needs You. > >> Take our quick survey online. Come on, we don't ask for help often. > >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. > >> http://p.sf.net/sfu/slashdot-survey > >> _______________________________________________ > >> Gwt-openlayers-users mailing list > >> Gwt...@li... > >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > >> > > > > > > > > > ------------------------------------------------------------------------------ > > Got Input? Slashdot Needs You. > > Take our quick survey online. Come on, we don't ask for help often. > > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > > http://p.sf.net/sfu/slashdot-survey > > _______________________________________________ > > Gwt-openlayers-users mailing list > > Gwt...@li... > > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > -- Giuseppe La Scaleia CNR - IMAA geoSDI Sviluppo Software C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971427305 fax: +39 0971 427271 mob: +39 3804697436 mail: giu...@ge... skype: glascaleia web: http://www.geosdi.org |
|
From: Edwin C. <com...@gm...> - 2011-08-01 13:04:09
|
Hi Dave, To vote just reply to the email with a YES or NO in the body. The nature of the repository will not change. The source code will still be in a Mercurial repository. What changes will be the address of the main repository. Currently the main repository (representing the main line of work) is hosted at SourceForge. We would like to move this repository to Bitbucket. Moving to Bitbucket makes things easier for committers as well as administrators. For committers it means: - Committers will have to sign up for Bitbucket (free). - Committers can fork the project at Bitbucket to create their own sandbox - If you are already have commit rights on SourceForge you can get commit rights on the main repo at BitBucket (just send an email to me) and pull changes from your fork into the main repo - If you do not have commit rights then you can send pull requests, so the admins can decide if they want to pull changes from your sandbox (probably via a sandbox of the admin). Greetings, Edwin On 1 August 2011 14:11, Dave Potts <dav...@pi...> wrote: > Hi > > 1. How does one vote? do you have some type of link that can be used? > 2. What happens to existing projects? > > I have an entire series of useful(?) changes (console,http,handler > stratgy,projection etc) They are part of my personnel codebase how could > I integrate these changes if you change the nature of the Mercurial > repository? > > > Dave. >> Hi All, >> >> This is for both the devel and users list. Currently the number of emails >> we >> receive regarding contributing to the project indicates that the process >> is >> not straight forward, not easy and not intuitive. This would no doubt >> preclude a lot of "would be" contributors from contributing and something >> I >> believe we must address. >> >> Goal: Make it as easy as possible for everyone to contribute >> without compromising the stability and quality of the codebase. >> >> At this point you can read on or jump the the conclusion and vote at the >> end.... >> >> *How Distributed Version Control Should be Used (IMHO):* >> >> Distributed version control should pass through a hierarchy of >> repositories >> as it makes its way onto the stable baseline that releases are cut from >> (Linus would probably call this a 'network of trust'). Believe it or not, >> this is more about opening up access to source control than it is >> restricting it. Why, because this way everyone has a sandbox repository to >> fool around in, try things out, send them to others... do some RnD e.t.c. >> This means that rather than sending an email to the mailing list about >> "how >> can I contribute this" or "what is the process" or "here are some patches" >> or "can I have access to the repository" everybody can just work with >> their >> own repository... nice! It also means that since this is in a repository, >> it >> can be easily promoted/pulled into the GWT-OpenLayers baseline ready for >> the >> next release! via 'pull requests'. >> >> *What's the problem with GWT-OpenLayer's and Folllowing this:* >> >> The fundamental problem is that its *NOT EASY* for us to adhere to such a >> process with SourceForge's source repository administration. It's >> possible, >> but certainly not easy. >> -Creating a new repository for a developer involves too much manual input. >> A >> new member needs to send a request (email), the request needs to be >> granted, >> the repository needs be be manually created by an administrator via shell. >> -Controlling access to each repository involves too much manual input, >> SourceForge's administration web ui doesn't control who can push to each >> repository. Administrators have to ssh in and then edit the >> gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository >> permissions. Again, this takes too much manual effort. >> -Promoting code is also too manually intensive, the reason is that if an >> individual actually gets their own repository, then then push up some work >> to it. The only want that it will be push up into the baseline repository >> that we release from is by sending emails, or patches via email e.t.c and >> this is often not an intuitive or inviting process. This process is not >> intrinsic in SourceForge's source control hosting. >> >> *Addressing these Issues:* >> >> Rather than documenting, emailing and publishing a DIY process of making a >> contribution and how to work with source control, *we should target a >> hosting service where the process is intrinsic in the service it's >> self * :) The >> sooner we can switch the better. >> >> *CONCLUSION* >> >> Some of the developers are already using bitbucket ( >> https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. >> This >> can work concurrently with SF's mercurial. However, we should really focus >> on bitbucket's additional features (such as forking, pull requests e.t.c). >> These features provide us with a suitable service and an easy, intrinsic >> process for contribution. Using SF and bitbucket concurrently is something >> I >> would not recommend either, it doesn't solve our problem. >> >> *Please vote on a move to BitBucket and decommission SF's mercurial >> repository YES/NO?* >> >> Cheers :) >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Gwt-openlayers-users mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > |
|
From: Dave P. <dav...@pi...> - 2011-08-01 12:11:55
|
Hi 1. How does one vote? do you have some type of link that can be used? 2. What happens to existing projects? I have an entire series of useful(?) changes (console,http,handler stratgy,projection etc) They are part of my personnel codebase how could I integrate these changes if you change the nature of the Mercurial repository? Dave. > Hi All, > > This is for both the devel and users list. Currently the number of emails > we > receive regarding contributing to the project indicates that the process > is > not straight forward, not easy and not intuitive. This would no doubt > preclude a lot of "would be" contributors from contributing and something > I > believe we must address. > > Goal: Make it as easy as possible for everyone to contribute > without compromising the stability and quality of the codebase. > > At this point you can read on or jump the the conclusion and vote at the > end.... > > *How Distributed Version Control Should be Used (IMHO):* > > Distributed version control should pass through a hierarchy of > repositories > as it makes its way onto the stable baseline that releases are cut from > (Linus would probably call this a 'network of trust'). Believe it or not, > this is more about opening up access to source control than it is > restricting it. Why, because this way everyone has a sandbox repository to > fool around in, try things out, send them to others... do some RnD e.t.c. > This means that rather than sending an email to the mailing list about > "how > can I contribute this" or "what is the process" or "here are some patches" > or "can I have access to the repository" everybody can just work with > their > own repository... nice! It also means that since this is in a repository, > it > can be easily promoted/pulled into the GWT-OpenLayers baseline ready for > the > next release! via 'pull requests'. > > *What's the problem with GWT-OpenLayer's and Folllowing this:* > > The fundamental problem is that its *NOT EASY* for us to adhere to such a > process with SourceForge's source repository administration. It's > possible, > but certainly not easy. > -Creating a new repository for a developer involves too much manual input. > A > new member needs to send a request (email), the request needs to be > granted, > the repository needs be be manually created by an administrator via shell. > -Controlling access to each repository involves too much manual input, > SourceForge's administration web ui doesn't control who can push to each > repository. Administrators have to ssh in and then edit the > gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository > permissions. Again, this takes too much manual effort. > -Promoting code is also too manually intensive, the reason is that if an > individual actually gets their own repository, then then push up some work > to it. The only want that it will be push up into the baseline repository > that we release from is by sending emails, or patches via email e.t.c and > this is often not an intuitive or inviting process. This process is not > intrinsic in SourceForge's source control hosting. > > *Addressing these Issues:* > > Rather than documenting, emailing and publishing a DIY process of making a > contribution and how to work with source control, *we should target a > hosting service where the process is intrinsic in the service it's > self * :) The > sooner we can switch the better. > > *CONCLUSION* > > Some of the developers are already using bitbucket ( > https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. > This > can work concurrently with SF's mercurial. However, we should really focus > on bitbucket's additional features (such as forking, pull requests e.t.c). > These features provide us with a suitable service and an easy, intrinsic > process for contribution. Using SF and bitbucket concurrently is something > I > would not recommend either, it doesn't solve our problem. > > *Please vote on a move to BitBucket and decommission SF's mercurial > repository YES/NO?* > > Cheers :) > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > |
|
From: Andrew H. <ahh...@gm...> - 2011-08-01 11:55:00
|
Hi All, This is for both the devel and users list. Currently the number of emails we receive regarding contributing to the project indicates that the process is not straight forward, not easy and not intuitive. This would no doubt preclude a lot of "would be" contributors from contributing and something I believe we must address. Goal: Make it as easy as possible for everyone to contribute without compromising the stability and quality of the codebase. At this point you can read on or jump the the conclusion and vote at the end.... *How Distributed Version Control Should be Used (IMHO):* Distributed version control should pass through a hierarchy of repositories as it makes its way onto the stable baseline that releases are cut from (Linus would probably call this a 'network of trust'). Believe it or not, this is more about opening up access to source control than it is restricting it. Why, because this way everyone has a sandbox repository to fool around in, try things out, send them to others... do some RnD e.t.c. This means that rather than sending an email to the mailing list about "how can I contribute this" or "what is the process" or "here are some patches" or "can I have access to the repository" everybody can just work with their own repository... nice! It also means that since this is in a repository, it can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the next release! via 'pull requests'. *What's the problem with GWT-OpenLayer's and Folllowing this:* The fundamental problem is that its *NOT EASY* for us to adhere to such a process with SourceForge's source repository administration. It's possible, but certainly not easy. -Creating a new repository for a developer involves too much manual input. A new member needs to send a request (email), the request needs to be granted, the repository needs be be manually created by an administrator via shell. -Controlling access to each repository involves too much manual input, SourceForge's administration web ui doesn't control who can push to each repository. Administrators have to ssh in and then edit the gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository permissions. Again, this takes too much manual effort. -Promoting code is also too manually intensive, the reason is that if an individual actually gets their own repository, then then push up some work to it. The only want that it will be push up into the baseline repository that we release from is by sending emails, or patches via email e.t.c and this is often not an intuitive or inviting process. This process is not intrinsic in SourceForge's source control hosting. *Addressing these Issues:* Rather than documenting, emailing and publishing a DIY process of making a contribution and how to work with source control, *we should target a hosting service where the process is intrinsic in the service it's self * :) The sooner we can switch the better. *CONCLUSION* Some of the developers are already using bitbucket ( https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. This can work concurrently with SF's mercurial. However, we should really focus on bitbucket's additional features (such as forking, pull requests e.t.c). These features provide us with a suitable service and an easy, intrinsic process for contribution. Using SF and bitbucket concurrently is something I would not recommend either, it doesn't solve our problem. *Please vote on a move to BitBucket and decommission SF's mercurial repository YES/NO?* Cheers :) |
9 messages has been excluded from this view by a project administrator.
