Grass service and netcdf service

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Grass service and netcdf service

Andrea Antonello
Hi all,
it is now a long time we have GRASS raster support in JGrass and
lately also netcdf support.

I hereby ask the PSC to get permission to add the two plugins to the
uDig distribution. I opened a ticket here:
http://jira.codehaus.org/browse/UDIG-1637

I think it is clear that in the case of addition, they will have a
hydrologis namespace and not a refraction.
I remember we were taking about ages ago, and there were different
ideas about it.

That's it, waiting for your votes,
Thanks,
Andrea
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Grass service and netcdf service

Mauricio Pazos
On Sunday 11 April 2010 11:11:53 pm andrea antonello wrote:
> Hi all,
> it is now a long time we have GRASS raster support in JGrass and
> lately also netcdf support.
>
> I hereby ask the PSC to get permission to add the two plugins to the
> uDig distribution. I opened a ticket here:
> http://jira.codehaus.org/browse/UDIG-1637
>
+1
> I think it is clear that in the case of addition, they will have a
> hydrologis namespace and not a refraction.
> I remember we were taking about ages ago, and there were different
> ideas about it.
>
I agree. I like associate the namespace with the company/organization
developer.
> That's it, waiting for your votes,
> Thanks,
> Andrea
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
cheers
--
Mauricio Pazos
www.axios.es
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Grass service and netcdf service

Jody Garnett-2
In reply to this post by Andrea Antonello
Hi Andrea:

So what we need is one of those proposals that everyone helped out on the template for (if it is some kind of strategic change); in this case are just adding in new catalog plugins? If so +1.

As for namespace; I am all in favour of company branding - but I would prefer it in the correct spot.

So namespace: -1
Reason:  I would like to keep net.refractions.udig.catalog just so the code is grouped in a useful manner.

What would I like to do for company branding?
- for your plugin list hydrologis as the provider
- Add the branding element for the hydrologis provider so the logo and link shows up in the udig about box
- it will also be associated in the about box with the plugins you contributed.

Does that sound okay?  I have not added LISAsoft as a provider yet as I have not made any new plugins while working for the company yet.

Jody

What i would like to do is you is:
On 12/04/2010, at 7:11 AM, andrea antonello wrote:

> Hi all,
> it is now a long time we have GRASS raster support in JGrass and
> lately also netcdf support.
>
> I hereby ask the PSC to get permission to add the two plugins to the
> uDig distribution. I opened a ticket here:
> http://jira.codehaus.org/browse/UDIG-1637
>
> I think it is clear that in the case of addition, they will have a
> hydrologis namespace and not a refraction.
> I remember we were taking about ages ago, and there were different
> ideas about it.
>
> That's it, waiting for your votes,
> Thanks,
> Andrea
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Grass service and netcdf service

Andrea Antonello
Hi Jody, PSC,

> So what we need is one of those proposals that everyone helped out on the template for (if it is some kind of strategic change); in this case are just adding in new catalog plugins? If so +1.

No strategic change, but you are right that the proposal might be good
to be documented. So here it goes:
http://udig.refractions.net/confluence/display/HACK/Moving+Grass+and+netcdf+services+from+JGrass+to+uDig

> As for namespace; I am all in favour of company branding - but I would prefer it in the correct spot.
>
> So namespace: -1
> Reason:  I would like to keep net.refractions.udig.catalog just so the code is grouped in a useful manner.
>
> What would I like to do for company branding?
> - for your plugin list hydrologis as the provider
> - Add the branding element for the hydrologis provider so the logo and link shows up in the udig about box
> - it will also be associated in the about box with the plugins you contributed.
>
> Does that sound okay?  I have not added LISAsoft as a provider yet as I have not made any new plugins while working for the company yet.

I do not agree here. Namespaces should be bound to the company. I
agree on the fact that it is handy to have code grouped, but it
doesn't seem to be a big issue to me (we can decide on naming
conventions).
It is well possible that companies that do things for uDig in paid
projects are forced to use a different namespace. What would you do
with those? My feeling is that different namespaces can't be avoided
at some point.

Even if I think that this is a discussion that should be taken into
IRC, I would like to hear comments from the others here.
Please let's not block development and additions to uDig just because of this.

Thanks,
Andrea



>
> Jody
>
> What i would like to do is you is:
> On 12/04/2010, at 7:11 AM, andrea antonello wrote:
>
>> Hi all,
>> it is now a long time we have GRASS raster support in JGrass and
>> lately also netcdf support.
>>
>> I hereby ask the PSC to get permission to add the two plugins to the
>> uDig distribution. I opened a ticket here:
>> http://jira.codehaus.org/browse/UDIG-1637
>>
>> I think it is clear that in the case of addition, they will have a
>> hydrologis namespace and not a refraction.
>> I remember we were taking about ages ago, and there were different
>> ideas about it.
>>
>> That's it, waiting for your votes,
>> Thanks,
>> Andrea
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Grass service and netcdf service

Riccardo Rigon
Dear Jody,

On Apr 15, 2010, at 5:15 PM, andrea antonello wrote:

Hi Jody, PSC,

So what we need is one of those proposals that everyone helped out on the template for (if it is some kind of strategic change); in this case are just adding in new catalog plugins? If so +1.

No strategic change, but you are right that the proposal might be good
to be documented. So here it goes:
http://udig.refractions.net/confluence/display/HACK/Moving+Grass+and+netcdf+services+from+JGrass+to+uDig

As for namespace; I am all in favour of company branding - but I would prefer it in the correct spot.

So namespace: -1
Reason:  I would like to keep net.refractions.udig.catalog just so the code is grouped in a useful manner.

What would I like to do for company branding?
- for your plugin list hydrologis as the provider
- Add the branding element for the hydrologis provider so the logo and link shows up in the udig about box
- it will also be associated in the about box with the plugins you contributed.

Does that sound okay?  I have not added LISAsoft as a provider yet as I have not made any new plugins while working for the company yet.

I do not agree here. Namespaces should be bound to the company. I
agree on the fact that it is handy to have code grouped, but it
doesn't seem to be a big issue to me (we can decide on naming
conventions).
It is well possible that companies that do things for uDig in paid
projects are forced to use a different namespace. What would you do
with those? My feeling is that different namespaces can't be avoided
at some point.

in fact this is the case also for Andrea himself: he did not realized when proposing his policy,  but, since part of the work he is committing, was financed by my Institution, it is required that the code origin is distinguishable, and I can refer to it precisely in my documents. So, I asked to my administration and they agreed with the solution, proposed by Andrea (different namespace).  At the same time I would also need that my company branding (CUDAM - University of Trento) appear somewhere.

riccardo rigon


Even if I think that this is a discussion that should be taken into
IRC, I would like to hear comments from the others here.
Please let's not block development and additions to uDig just because of this.

Thanks,
Andrea




Jody

What i would like to do is you is:
On 12/04/2010, at 7:11 AM, andrea antonello wrote:

Hi all,
it is now a long time we have GRASS raster support in JGrass and
lately also netcdf support.

I hereby ask the PSC to get permission to add the two plugins to the
uDig distribution. I opened a ticket here:
http://jira.codehaus.org/browse/UDIG-1637

I think it is clear that in the case of addition, they will have a
hydrologis namespace and not a refraction.
I remember we were taking about ages ago, and there were different
ideas about it.

That's it, waiting for your votes,
Thanks,
Andrea
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

________________________________________________________________        
Universita` di Trento         Dipartimento di Ingegneria Civile  e  Ambientale/CUDAM
Via Mesiano, 77, 38050  Trento      (ITALIA)                    
E-mail[hidden email]  
Ph: +390461882614-10    Fax:+390461882672
Publications according to ISI: http://www.researcherid.com/rid/B-5395-2008
JGrass (Open Source GIS): http://www.jgrass.org/
GEOtop (Open Source distributed hydrological model):  http://www.geotop.org/
_______________________________________________________________                                                   







_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Grass service and netcdf service

Andrea Antonello
[...]

>> I do not agree here. Namespaces should be bound to the company. I
>> agree on the fact that it is handy to have code grouped, but it
>> doesn't seem to be a big issue to me (we can decide on naming
>> conventions).
>> It is well possible that companies that do things for uDig in paid
>> projects are forced to use a different namespace. What would you do
>> with those? My feeling is that different namespaces can't be avoided
>> at some point.
>>
> in fact this is the case also for Andrea himself: he did not realized when proposing his policy,  but,
> since part of the work he is committing, was financed by my Institution, it is required that the code
> origin is distinguishable, and I can refer to it precisely in my documents. So, I asked to my administration and
> they agreed with the solution, proposed by Andrea (different namespace).  At the same time I would also
> need that my company branding (CUDAM - University of Trento) appear somewhere.

Thanks Riccardo for jumping in, you are describing the perfect
scenario for what I am trying to say.

Andrea




> riccardo rigon
>
> Even if I think that this is a discussion that should be taken into
> IRC, I would like to hear comments from the others here.
> Please let's not block development and additions to uDig just because of this.
>
> Thanks,
> Andrea
>
>
>
>
> Jody
>
> What i would like to do is you is:
>
> On 12/04/2010, at 7:11 AM, andrea antonello wrote:
>
> Hi all,
>
> it is now a long time we have GRASS raster support in JGrass and
>
> lately also netcdf support.
>
> I hereby ask the PSC to get permission to add the two plugins to the
>
> uDig distribution. I opened a ticket here:
>
> http://jira.codehaus.org/browse/UDIG-1637
>
> I think it is clear that in the case of addition, they will have a
>
> hydrologis namespace and not a refraction.
>
> I remember we were taking about ages ago, and there were different
>
> ideas about it.
>
> That's it, waiting for your votes,
>
> Thanks,
>
> Andrea
>
> _______________________________________________
>
> User-friendly Desktop Internet GIS (uDig)
>
> http://udig.refractions.net
>
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
>
> User-friendly Desktop Internet GIS (uDig)
>
> http://udig.refractions.net
>
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> ________________________________________________________________
> Universita` di Trento         Dipartimento di Ingegneria Civile  e  Ambientale/CUDAM
> Via Mesiano, 77, 38050  Trento      (ITALIA)
> E-mail:  [hidden email]
> Ph: +390461882614-10    Fax:+390461882672
> Web page: http://www.ing.unitn.it/dica/hp/?user=rigon
> Publications according to ISI: http://www.researcherid.com/rid/B-5395-2008
> JGrass (Open Source GIS): http://www.jgrass.org/
> GEOtop (Open Source distributed hydrological model):  http://www.geotop.org/
> _______________________________________________________________
>
>
>
>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

namespace policy

Jody Garnett-2
In reply to this post by Riccardo Rigon
This is an interesting discussion; from my standpoint I am trying to follow java naming conventions and using the package structure to indicate where the source code can be found etc..  There are also similar guidelines for the naming of plugins.

I also note we already have an outlier in the form of some book mark code that needs to be folded into the existing project.ui plugin (hopefully as part of a Navigation view?)

I would think that recognising organisations as part of the running application (and online help) is of more interest? Indeed this is where I want to recognise contributing organisations - where users can see the contribution.

The other reason I am sensitive to namespace is that I want the code base to be approachable to new developers and the current setup with *way* too many plugins is not working as the project looks much much bigger then it actually is; most "catalog" plugins only have three classes for example.

Still I am sure we can arrange for package names to indicate something; while still respecting eclipse/java naming guidelines?

An easy solution would be: *net.refractions.catalog.grass" for the plugin with contents of:
- net.refractions.catalog.grass.Activator
- net.refractions.catalog.grass.internal.hydrologis.GrassServiceExtension // for the implementation

(This approach also works if we start combining catalog plugins in uDig 1.3.x (which I strongly recommend).

Before proceeding we should review the existing naming guidelines:

I also note that we have not had significant contributions of external code; in part because the plugin mechanism is so excellent; and in part because of the time required to perform a code review etc involves a time commitment on both parties.
 
Jody

As for namespace; I am all in favour of company branding - but I would prefer it in the correct spot.

So namespace: -1
Reason:  I would like to keep net.refractions.udig.catalog just so the code is grouped in a useful manner.

What would I like to do for company branding?
- for your plugin list hydrologis as the provider
- Add the branding element for the hydrologis provider so the logo and link shows up in the udig about box
- it will also be associated in the about box with the plugins you contributed.

Does that sound okay?  I have not added LISAsoft as a provider yet as I have not made any new plugins while working for the company yet.

I do not agree here. Namespaces should be bound to the company. I
agree on the fact that it is handy to have code grouped, but it
doesn't seem to be a big issue to me (we can decide on naming
conventions).
It is well possible that companies that do things for uDig in paid
projects are forced to use a different namespace. What would you do
with those? My feeling is that different namespaces can't be avoided
at some point.

in fact this is the case also for Andrea himself: he did not realized when proposing his policy,  but, since part of the work he is committing, was financed by my Institution, it is required that the code origin is distinguishable, and I can refer to it precisely in my documents. So, I asked to my administration and they agreed with the solution, proposed by Andrea (different namespace).  At the same time I would also need that my company branding (CUDAM - University of Trento) appear somewhere.

riccardo rigon


Even if I think that this is a discussion that should be taken into
IRC, I would like to hear comments from the others here.
Please let's not block development and additions to uDig just because of this.

Thanks,
Andrea




Jody

What i would like to do is you is:
On 12/04/2010, at 7:11 AM, andrea antonello wrote:

Hi all,
it is now a long time we have GRASS raster support in JGrass and
lately also netcdf support.

I hereby ask the PSC to get permission to add the two plugins to the
uDig distribution. I opened a ticket here:
http://jira.codehaus.org/browse/UDIG-1637

I think it is clear that in the case of addition, they will have a
hydrologis namespace and not a refraction.
I remember we were taking about ages ago, and there were different
ideas about it.

That's it, waiting for your votes,
Thanks,
Andrea
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

________________________________________________________________        
Universita` di Trento         Dipartimento di Ingegneria Civile  e  Ambientale/CUDAM
Via Mesiano, 77, 38050  Trento      (ITALIA)                    
E-mail[hidden email]  
Ph: +390461882614-10    Fax:+390461882672
Publications according to ISI: http://www.researcherid.com/rid/B-5395-2008
JGrass (Open Source GIS): http://www.jgrass.org/
GEOtop (Open Source distributed hydrological model):  http://www.geotop.org/
_______________________________________________________________                                                   






_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: namespace policy

Andrea Antonello
Jody,

> This is an interesting discussion; from my standpoint I am trying to follow
> java naming conventions and using the package structure to indicate where
> the source code can be found etc..  There are also similar guidelines for
> the naming of plugins.

good. I learned as one of the first rules that namespace represent the author.

> I also note we already have an outlier in the form of some book mark code
> that needs to be folded into the existing project.ui plugin (hopefully as
> part of a Navigation view?)

ok for me.

> I would think that recognising organisations as part of the running
> application (and online help) is of more interest? Indeed this is where I
> want to recognise contributing organisations - where users can see the
> contribution.

Jody, that is the point of the discussion and you seem to not consider
what we are saying.
As professor Rigon pointed out he needs to have code to point to in
his publications. If the code starts with the name of a different
company than his, that will not work. I can understand that and I can
understand that this will be the problem also for other companies.

Also I learned exactly fom you that the uDig users are developers, not
unly gis users, since udig is an sdk. So they see what happens in the
code, not in the about of the application, which they will never open.

So I once again propose 2 things:
1) the contributor chooses the base namespace and the non-company part
follows strict guidelines
or
2) udig gets a generic namspace (I would wonder what refractions think
about it, don't think they would agree)

> The other reason I am sensitive to namespace is that I want the code base to
> be approachable to new developers and the current setup with *way* too many
> plugins is not working as the project looks much much bigger then it
> actually is; most "catalog" plugins only have three classes for example.
> Still I am sure we can arrange for package names to indicate something;
> while still respecting eclipse/java naming guidelines?
> An easy solution would be: *net.refractions.catalog.grass" for the plugin
> with contents of:
> - net.refractions.catalog.grass.Activator
> - net.refractions.catalog.grass.internal.hydrologis.GrassServiceExtension //
> for the implementation

Ok for me. But consider that I will not be allowed (apart of the fact
that I do not want) to release something funded by University of
Trento and HydroloGIS as "net.refractions.catalog.grass". That doesn't
make sense.

So before everything else I want to get clear about this.

> (This approach also works if we start combining catalog plugins in uDig
> 1.3.x (which I strongly recommend).
> Before proceeding we should review the existing naming guidelines:
> - http://udig.refractions.net/confluence/display/DEV/API+rules+of+engagement
> - API rules of engagement
> - http://udig.refractions.net/confluence/display/DEV/4+Naming+Conventions
> I also note that we have not had significant contributions of external code;
> in part because the plugin mechanism is so excellent; and in part because of
> the time required to perform a code review etc involves a time commitment on
> both parties.

And in part because everytime we talk about namespaces we get into this delay.
JGrass would like to slowly contribute pieces into udig, since they
are now tested and the move to the coverage api gives now the
possibility of having them working in udig. I am talking about tools
like raster queries and profile visualizations.

But as I said, first let's find a solution for the namespace.

Andrea



>
> Jody
>
> As for namespace; I am all in favour of company branding - but I would
> prefer it in the correct spot.
>
> So namespace: -1
>
> Reason:  I would like to keep net.refractions.udig.catalog just so the code
> is grouped in a useful manner.
>
> What would I like to do for company branding?
>
> - for your plugin list hydrologis as the provider
>
> - Add the branding element for the hydrologis provider so the logo and link
> shows up in the udig about box
>
> - it will also be associated in the about box with the plugins you
> contributed.
>
> Does that sound okay?  I have not added LISAsoft as a provider yet as I have
> not made any new plugins while working for the company yet.
>
> I do not agree here. Namespaces should be bound to the company. I
> agree on the fact that it is handy to have code grouped, but it
> doesn't seem to be a big issue to me (we can decide on naming
> conventions).
> It is well possible that companies that do things for uDig in paid
> projects are forced to use a different namespace. What would you do
> with those? My feeling is that different namespaces can't be avoided
> at some point.
>
> in fact this is the case also for Andrea himself: he did not realized when
> proposing his policy,  but, since part of the work he is committing, was
> financed by my Institution, it is required that the code origin is
> distinguishable, and I can refer to it precisely in my documents. So, I
> asked to my administration and they agreed with the solution, proposed by
> Andrea (different namespace).  At the same time I would also need that my
> company branding (CUDAM - University of Trento) appear somewhere.
> riccardo rigon
>
> Even if I think that this is a discussion that should be taken into
> IRC, I would like to hear comments from the others here.
> Please let's not block development and additions to uDig just because of
> this.
>
> Thanks,
> Andrea
>
>
>
>
> Jody
>
> What i would like to do is you is:
>
> On 12/04/2010, at 7:11 AM, andrea antonello wrote:
>
> Hi all,
>
> it is now a long time we have GRASS raster support in JGrass and
>
> lately also netcdf support.
>
> I hereby ask the PSC to get permission to add the two plugins to the
>
> uDig distribution. I opened a ticket here:
>
> http://jira.codehaus.org/browse/UDIG-1637
>
> I think it is clear that in the case of addition, they will have a
>
> hydrologis namespace and not a refraction.
>
> I remember we were taking about ages ago, and there were different
>
> ideas about it.
>
> That's it, waiting for your votes,
>
> Thanks,
>
> Andrea
>
> _______________________________________________
>
> User-friendly Desktop Internet GIS (uDig)
>
> http://udig.refractions.net
>
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
>
> User-friendly Desktop Internet GIS (uDig)
>
> http://udig.refractions.net
>
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> ________________________________________________________________
> Universita` di Trento         Dipartimento di Ingegneria Civile  e
> Ambientale/CUDAM
> Via Mesiano, 77, 38050  Trento      (ITALIA)
> E-mail:  [hidden email]
> Ph: +390461882614-10    Fax:+390461882672
> Web page: http://www.ing.unitn.it/dica/hp/?user=rigon
> Publications according to ISI: http://www.researcherid.com/rid/B-5395-2008
> JGrass (Open Source GIS): http://www.jgrass.org/
> GEOtop (Open Source distributed hydrological model):  http://www.geotop.org/
> _______________________________________________________________
>
>
>
>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: namespace policy

Jody Garnett-2

On 17/04/2010, at 5:05 PM, andrea antonello wrote:

>> I would think that recognising organisations as part of the running
>> application (and online help) is of more interest? Indeed this is where I
>> want to recognise contributing organisations - where users can see the
>> contribution.
>
> Jody, that is the point of the discussion and you seem to not consider
> what we are saying.

I did consider and understand that; indeed this conversation has come up a couple of times. Personally I do not mind what we are doing just so long as we have a reason and are consistent.

The last thing I want to do is annoy people; but I also do not want the codebase to be a tangle.

Please don't miss understand me; with respect to "net.refractions.udig" this represents where the project is held; and even when we move the codebase it it is likely to remain that way for api stability.  I expect we will will move to GIT in may with the repo Jesse is running, Refractions no longer has a member on the steering committee and I do not work for them.

Jody

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: namespace policy

Jody Garnett-2
In reply to this post by Andrea Antonello

On 17/04/2010, at 5:05 PM, andrea antonello wrote:

As professor Rigon pointed out he needs to have code to point to in
his publications. If the code starts with the name of a different
company than his, that will not work. I can understand that and I can
understand that this will be the problem also for other companies.

Thinking. Community plugin is obviously appropriate. If Dr Rigon wants to donate his code to the project and have it merged into the existing project is the only point at which matters at all. Donated code should be merged or otherwise integrated and meet the project QA guidelines.

Can you proceed in a community plugin? I am mostly concerned with merging code into existing plugins and defining the api in a consistent fashion.

Also I learned exactly fom you that the uDig users are developers, not
unly gis users, since udig is an sdk. So they see what happens in the
code, not in the about of the application, which they will never open.

Indeed; so what are the options:
- plugin name
- package name
- @author tags
- branding contributions

The "net.refractions.udig.catalog.grass" package did not make sense to you? I figured it was contributing the grass format to the catalog; here is another idea of breaking things down:

Plugin  *net.refractions.catalog.grass":
- net.refractions.catalog.grass.Activator - plugin activator
- com.hydrologis.jgrass - implementation

Still seems a bit inconsistent.

So I once again propose 2 things:
1) the contributor chooses the base namespace and the non-company part follows strict guidelines
or
2) udig gets a generic namspace (I would wonder what refractions think about it, don't think they would agree)


If you are interested in something neutral the best long term solution would be to join the eclipse foundation and use an "org.eclipse.udig" or "org.eclipse.gis.uidg" package and plugin names.

But as I said, first let's find a solution for the namespace.

If you are interested in something neutral the best long term solution would be to join the eclipse foundation and use an "org.eclipse.udig" or "org.eclipse.gis.uidg" package and plugin names.

Jody

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel