[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] namespace policy
|
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: riccardo.rigon@xxxxxxxxxxxx
> 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
>
>
