Any news about gvSIG maven repository?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Any news about gvSIG maven repository?

Alberto Romeu Carrasco
Hi all,

maybe I'm missing something but I've been searching on the mailing lists
and I've not found any reference of what is happening with the gvSIG
infrastructure (mailing lists, maven repository, SCM, ...).

I know for some of my colleagues at the gvSIG Team that some kind of
migration it's being done, but that's all...

I think it would have been interesting some kind of announce explaining
at least that the infrastructure will be offline for some weeks. So
anybody depending in some way on the gvSIG infrastructure could prepare
a workaround to continue working.

Please, take this as a suggestion to improve the communication with the
community :P

Best regards.

--

Alberto Romeu
---

Prodevelop SL, Valencia (España)
Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
http://www.prodevelop.es
---


Reply | Threaded
Open this post in threaded view
|

Re: Any news about gvSIG maven repository?

Cèsar Ordiñana-3
El 27/12/11 10:42, Alberto Romeu escribió:
> Hi all,
>
> maybe I'm missing something but I've been searching on the mailing
> lists and I've not found any reference of what is happening with the
> gvSIG infrastructure (mailing lists, maven repository, SCM, ...).
>
> I know for some of my colleagues at the gvSIG Team that some kind of
> migration it's being done, but that's all...

> I think it would have been interesting some kind of announce
> explaining at least that the infrastructure will be offline for some
> weeks. So anybody depending in some way on the gvSIG infrastructure
> could prepare a workaround to continue working.

Yes, after the OSOR debacle, we are now trying to migrate as soon as
posible to a new server infrastructure. We though we would have had more
time to prepare the migration, notify everyone, ... but we suddenly
found themselves with a read only forge and had to run to migrate
everything ASAP. That meant to define, prepare and configure everything
as we went along, so we were unable to send a notification beforehand
about the migration plan. Also those are very bad dates for the project.

This is a lot of work with many people involved, so I can only talk for
sure about the task I'm mainly involved, which is the maven
configuration for the gvSIG 2.0 branch and projects. I'm updating the
maven configuration to use the new maven repository
(https://devel.gvsig.org/m2repo/j2se) and we would like to be able to
prepare a new gvSIG 2.0 build in the current or next week already over
the new infrastructure.

We are also updating the related documentation, like the Maven Initial
Configuration Guide [1], as the deployment to the new maven repository
has changed from SCP to WEBDAV.

There are a lot of other services, like the main gvSIG subversion
repositories that had already been migrated (ex: the gvSIG desktop one
[2]), although I there are some projects still in the process. Also we
have a new project management service [3] based on redmine, which will
host the gvsig trackers for bugs and new features. And we have also the
download service, the addons repository, etc.

I hope we are able to start announcing the availability of those
services ASAP.

> Please, take this as a suggestion to improve the communication with
> the community :P
>
> Best regards.

Thanks Alberto!

[1]
http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/initial-configuration/initial-configuration

[2] https://devel.gvsig.org/svn/gvsig-desktop

[3] https://devel.gvsig.org/redmine/projects

Regards,

--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)


Reply | Threaded
Open this post in threaded view
|

Re: Any news about gvSIG maven repository?

Alberto Romeu Carrasco
Hi César,

thanks for your answer, I'll wait patiently :)

Regards.

--

Alberto Romeu
---

Prodevelop SL, Valencia (España)
Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
http://www.prodevelop.es
---


El 28/12/11 09:49, Cèsar Ordiñana escribió:

> El 27/12/11 10:42, Alberto Romeu escribió:
>> Hi all,
>>
>> maybe I'm missing something but I've been searching on the mailing
>> lists and I've not found any reference of what is happening with the
>> gvSIG infrastructure (mailing lists, maven repository, SCM, ...).
>>
>> I know for some of my colleagues at the gvSIG Team that some kind of
>> migration it's being done, but that's all...
>
>> I think it would have been interesting some kind of announce
>> explaining at least that the infrastructure will be offline for some
>> weeks. So anybody depending in some way on the gvSIG infrastructure
>> could prepare a workaround to continue working.
>
> Yes, after the OSOR debacle, we are now trying to migrate as soon as
> posible to a new server infrastructure. We though we would have had
> more time to prepare the migration, notify everyone, ... but we
> suddenly found themselves with a read only forge and had to run to
> migrate everything ASAP. That meant to define, prepare and configure
> everything as we went along, so we were unable to send a notification
> beforehand about the migration plan. Also those are very bad dates for
> the project.
>
> This is a lot of work with many people involved, so I can only talk
> for sure about the task I'm mainly involved, which is the maven
> configuration for the gvSIG 2.0 branch and projects. I'm updating the
> maven configuration to use the new maven repository
> (https://devel.gvsig.org/m2repo/j2se) and we would like to be able to
> prepare a new gvSIG 2.0 build in the current or next week already over
> the new infrastructure.
>
> We are also updating the related documentation, like the Maven Initial
> Configuration Guide [1], as the deployment to the new maven repository
> has changed from SCP to WEBDAV.
>
> There are a lot of other services, like the main gvSIG subversion
> repositories that had already been migrated (ex: the gvSIG desktop one
> [2]), although I there are some projects still in the process. Also we
> have a new project management service [3] based on redmine, which will
> host the gvsig trackers for bugs and new features. And we have also
> the download service, the addons repository, etc.
>
> I hope we are able to start announcing the availability of those
> services ASAP.
>
>> Please, take this as a suggestion to improve the communication with
>> the community :P
>>
>> Best regards.
>
> Thanks Alberto!
>
> [1]
> http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/initial-configuration/initial-configuration
>
> [2] https://devel.gvsig.org/svn/gvsig-desktop
>
> [3] https://devel.gvsig.org/redmine/projects
>
> Regards,
>

Reply | Threaded
Open this post in threaded view
|

Cambios en el TOC de la rama 1.x

Francisco José Peñarrubia
Hola.

Estoy revisando algunos errores que ha aparecido nuevos debidos al
cambio en el TOC de la rama 1.x.

Los cambios no me parecen mal cuando son necesarios, pero no entiendo
porqué se ha decidido cambiar el API de esa forma, rompiendo
compatibilidad con lo que había antes.
Se podría haber hecho de manera que se pueda extender el TOC (si es lo
que se pretende), pero sin hacer que cuando se cree un TOC ya tengas que
tener creado el MapContext.

El cambio que se ha hecho ha consistido en meter un
initialize(MapContext) para evitar un setMapContext() posterior.

El problema es que en BaseView hay un initialize() sin parámetros que lo
están usando otras extensiones, y no se ejecuta el código que se ha
metido en initialize(MapContext).
El resultado es que al crear vistas desde otras extensiones, el TOC
aparece sin capas, pero la vista tiene capas. Al hacer click en el toc,
salta un fallo, claro.
Por no mencionar las extensiones que ya hemos repasado para que no
salgan errores.

Creo que ya tenemos más o menos controlado dónde se usa todo, pero ha
habido que tocar en muchas extensiones (3D, Lupa Murciona, extWMS....) y
todo ese trabajo se podría haber evitado.

Hace tiempo vi un borrador en el que se especificaba los pasos a seguir
para evitar lo que ha pasado. Creo que es bueno que eso se promocione
más para que se use desde todas las partes.

Para evitar males mayores, propongo que el initialize() del baseView se
cambie, y que salga un error de compilación antes que dejar errores
escondidos. (Aunque lo mejor habría sido no tocar ese initialize).

Saludos.

Fran.

--
Fran Peñarrubia
Scolab
www.scolab.es

Asociación gvSIG
www.gvsig.com


Reply | Threaded
Open this post in threaded view
|

Re: Any news about gvSIG maven repository?

Francisco Puga
In reply to this post by Alberto Romeu Carrasco
Hi all,

I write yesterday to join-up maintainers asking if there is a way to
get a dump of the tracker of the project i admin. I told then, that i
was also involved in the gvSIG project and it will be nice if we get a
dump of this project to.

As i think that they already have a script to pull the bugs from
gforge (the migrate it to join-up), i suggest him to dump the bugs in
something like a json format. I offer myself to help them in this.

Having the bugs in a json format i think that will not be so difficult
build a "pusher" to the redmine. Migrate the bugs, the comments, the
patches, etc ... by hand seems impossible to me.

El día 28 de diciembre de 2011 11:00, Alberto Romeu
<[hidden email]> escribió:

> Hi César,
>
> thanks for your answer, I'll wait patiently :)
>
>
> Regards.
>
> --
>
> Alberto Romeu
> ---
>
> Prodevelop SL, Valencia (España)
> Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
> http://www.prodevelop.es
> ---
>
>
> El 28/12/11 09:49, Cèsar Ordiñana escribió:
>
>> El 27/12/11 10:42, Alberto Romeu escribió:
>>>
>>> Hi all,
>>>
>>> maybe I'm missing something but I've been searching on the mailing lists
>>> and I've not found any reference of what is happening with the gvSIG
>>> infrastructure (mailing lists, maven repository, SCM, ...).
>>>
>>> I know for some of my colleagues at the gvSIG Team that some kind of
>>> migration it's being done, but that's all...
>>
>>
>>> I think it would have been interesting some kind of announce explaining
>>> at least that the infrastructure will be offline for some weeks. So anybody
>>> depending in some way on the gvSIG infrastructure could prepare a workaround
>>> to continue working.
>>
>>
>> Yes, after the OSOR debacle, we are now trying to migrate as soon as
>> posible to a new server infrastructure. We though we would have had more
>> time to prepare the migration, notify everyone, ... but we suddenly found
>> themselves with a read only forge and had to run to migrate everything ASAP.
>> That meant to define, prepare and configure everything as we went along, so
>> we were unable to send a notification beforehand about the migration plan.
>> Also those are very bad dates for the project.
>>
>> This is a lot of work with many people involved, so I can only talk for
>> sure about the task I'm mainly involved, which is the maven configuration
>> for the gvSIG 2.0 branch and projects. I'm updating the maven configuration
>> to use the new maven repository (https://devel.gvsig.org/m2repo/j2se) and we
>> would like to be able to prepare a new gvSIG 2.0 build in the current or
>> next week already over the new infrastructure.
>>
>> We are also updating the related documentation, like the Maven Initial
>> Configuration Guide [1], as the deployment to the new maven repository has
>> changed from SCP to WEBDAV.
>>
>> There are a lot of other services, like the main gvSIG subversion
>> repositories that had already been migrated (ex: the gvSIG desktop one [2]),
>> although I there are some projects still in the process. Also we have a new
>> project management service [3] based on redmine, which will host the gvsig
>> trackers for bugs and new features. And we have also the download service,
>> the addons repository, etc.
>>
>> I hope we are able to start announcing the availability of those services
>> ASAP.
>>
>>> Please, take this as a suggestion to improve the communication with the
>>> community :P
>>>
>>> Best regards.
>>
>>
>> Thanks Alberto!
>>
>> [1]
>> http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/initial-configuration/initial-configuration
>>
>> [2] https://devel.gvsig.org/svn/gvsig-desktop
>>
>> [3] https://devel.gvsig.org/redmine/projects
>>
>> Regards,
>>
>



--
Francisco Puga
Grupo de Desarrollo
Cartolab - Laboratorio de Ingeniería Cartográfica.
http://www.cartolab.es

ETS Ingeniería de Caminos, Canales y Puertos
Universidade da Coruña
Campus de Elviña - 15071 A Coruña (España)
(34)981167000 ext. 5493

Reply | Threaded
Open this post in threaded view
|

Problema al leer los textos de un proyecto de la versión 1.1.2

Francisco José Peñarrubia
Hola a todos.

Me acabo de dar cuenta de un fallo muy tonto (creo).
Resulta que en la versión 1.1.2 se podía poner un etiquetado y decir que
no querías pintar las entidades gráficas que usabas para etiquetar. Es
decir, que solo quieres pintar el texto.

En las versiones modernas, no puedes indicar eso. Siempre ves lo que
etiquetas, y para no verlo, tienes que poner transparencia total al
símbolo de la entidad gráfica (workarround).
Eso provoca que se esté iterando por las entidades gráficas 2 veces, y
claro, el etiquetado es más lento.

Voy a poner esto como bug, y lo voy a arreglar, a no ser que alguien me
diga que estoy equivocado y que no es necesario.
Es algo del core, pero intentaré que los cambios sean transparentes.

Saludos.

Fran.

--
Fran Peñarrubia
Scolab
www.scolab.es

Asociación gvSIG
www.gvsig.com


Reply | Threaded
Open this post in threaded view
|

Re: Cambios en el TOC de la rama 1.x

Francisco Puga
In reply to this post by Francisco José Peñarrubia
1.- Sobre cambios en el API en general

Yo no he visto el borrador ese pero efectivamente deberían
publicitarse más. Sugerencias para esto:
 * Mínimo un mensaje a la lista de desarollo con un mensaje claro y en
mayúsculas [API CHANGE]
 * Crear un blog sobre los desarrollos en el core (no estoy seguro de
si tendría éxito)
 * Crear una lista de sólo envio de api-changes

Aunque creo que con el mensaje a la lista de developers bastaría. E
idealmente discutir los cambios en la lista del TSC o de
desarrolladores


2.- Sobre este cambio en concreto.
Creo que el cambio se introduce en:

r37338 del 18 de Noviembre "Done changes in core to make TOC replaceable"

Si es viable hacerlo sin "reducir" la API creo que sería lo mejor. No
me parece molesto añadir más métodos al API pero quitarlos es lo
peligroso.

3.-
> Para evitar males mayores, propongo que el initialize() del baseView se
> cambie, y que salga un error de compilación antes que dejar errores
> escondidos. (Aunque lo mejor habría sido no tocar ese initialize).

Estoy de acuerdo. No me gusta que exista en una clase abstracta un
método no abstracto que no hace nada. Sólo puede dar lugar a errores.
Por tanto veo varias opciones:
 * Se hace abstracto para que las clases hijas se responsabilicen. No me gusta.
 * Se elimina para que al menos de error al compilar y se pueda
detectar rápido. Me gusta a medias.
 * Si es necesario un método initialize(MapContext) el de la clase
abstracta debería tener la misma firma, y por tanto hay que cambiarlo
para que la cumpla. En todo caso, pero si se va a quedar vacio hacerlo
abstracto.

Luego, a mi personalmente, aunque entiendo que esto ya es discutible
no me gusta la idea de métodos init() publicos. Cualquier tarea de
inicialización debería realizarse en el constructor [1]. Tras llamar
al constructor el objeto siempre debería quedar en un estado usable.

[1] http://www.artima.com/designtechniques/desinit5.html
-- Francisco Puga
Grupo de Desarrollo
Cartolab - Laboratorio de Ingeniería Cartográfica.
http://www.cartolab.es

ETS Ingeniería de Caminos, Canales y Puertos
Universidade da Coruña
Campus de Elviña - 15071 A Coruña (España)
(34)981167000 ext. 5493

Reply | Threaded
Open this post in threaded view
|

Re: Any news about gvSIG maven repository?

Cèsar Ordiñana-3
In reply to this post by Francisco Puga
El 30/12/11 12:09, Francisco Puga escribió:

> Hi all,
>
> I write yesterday to join-up maintainers asking if there is a way to
> get a dump of the tracker of the project i admin. I told then, that i
> was also involved in the gvSIG project and it will be nice if we get a
> dump of this project to.
>
> As i think that they already have a script to pull the bugs from
> gforge (the migrate it to join-up), i suggest him to dump the bugs in
> something like a json format. I offer myself to help them in this.
>
> Having the bugs in a json format i think that will not be so difficult
> build a "pusher" to the redmine. Migrate the bugs, the comments, the
> patches, etc ... by hand seems impossible to me.

Thanks Francisco, that would be fantastic if we could have some way to
import all the osor trackers into the new ones.

I have no idea how much it will cost to perform the "push" into redmine.
The problem is that we are very low on resources to prepare that
process, but maybe we could use something like the redmine importer
plugin [1]. It requires to import from a CSV file, and I don't know if
it supports comments and attachments, but its better than nothing.

In any case, please keep us informed if the join-up maintainers agree on
handing us any type of export. If at least we had the export already
solved by the join-up people, so much the better.

[1] http://www.redmine.org/plugins/importer

Regards,

--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)


Reply | Threaded
Open this post in threaded view
|

Re: Any news about gvSIG maven repository?

Francisco Puga
Hi all,

I get this two files as an sql dump of the gvSIG tracker. I think that
the attaches are not included, but it seems good. I didn't review it
so much. I'm going to take a look at the importer and see how the
import can be done.

http://dl.dropbox.com/u/2131623/mig_comments_gvsig.sql.gz
http://dl.dropbox.com/u/2131623/mig_issues_gvsig.sql.gz


El día 30 de diciembre de 2011 17:21, Cèsar Ordiñana
<[hidden email]> escribió:

> El 30/12/11 12:09, Francisco Puga escribió:
>
>> Hi all,
>>
>> I write yesterday to join-up maintainers asking if there is a way to
>> get a dump of the tracker of the project i admin. I told then, that i
>> was also involved in the gvSIG project and it will be nice if we get a
>> dump of this project to.
>>
>> As i think that they already have a script to pull the bugs from
>> gforge (the migrate it to join-up), i suggest him to dump the bugs in
>> something like a json format. I offer myself to help them in this.
>>
>> Having the bugs in a json format i think that will not be so difficult
>> build a "pusher" to the redmine. Migrate the bugs, the comments, the
>> patches, etc ... by hand seems impossible to me.
>
>
> Thanks Francisco, that would be fantastic if we could have some way to
> import all the osor trackers into the new ones.
>
> I have no idea how much it will cost to perform the "push" into redmine. The
> problem is that we are very low on resources to prepare that process, but
> maybe we could use something like the redmine importer plugin [1]. It
> requires to import from a CSV file, and I don't know if it supports comments
> and attachments, but its better than nothing.
>
> In any case, please keep us informed if the join-up maintainers agree on
> handing us any type of export. If at least we had the export already solved
> by the join-up people, so much the better.
>
> [1] http://www.redmine.org/plugins/importer
>
>
> Regards,
>
> --
> Cèsar Ordiñana Navarro
> gvSIG software architect
> DiSiD Technologies (http://www.disid.com)
>
>



--
Francisco Puga
Grupo de Desarrollo
Cartolab - Laboratorio de Ingeniería Cartográfica.
http://www.cartolab.es

ETS Ingeniería de Caminos, Canales y Puertos
Universidade da Coruña
Campus de Elviña - 15071 A Coruña (España)
(34)981167000 ext. 5493