I notice a lot of dashed lines. Is it drawing dependencies to everything
in the import list? That may create a lot of visual noise. Perhaps there
is a way to control how many dependencies are represented? Also, I don't
notice "associations", which I think are being represented as dependencies
i
[EMAIL PROTECTED] wrote on 06/04/2006 06:45:28 PM:
> I believe that Bryce has a point. We can create a new GeoAPI module,
> call it "geoapi-tests" or
> something like that, and deploy them through the usual Maven 2
> mechanism. External projects like
> Geotools and Geoserver can add this depende
On Monday 05 June 2006 20:13, Bryce L Nordgren wrote:
> I notice a lot of dashed lines. Is it drawing dependencies to everything
> in the import list? That may create a lot of visual noise. Perhaps there
> is a way to control how many dependencies are represented? Also, I don't
> notice "associ
Bryce L Nordgren ha scritto:
> I notice a lot of dashed lines. Is it drawing dependencies to everything
> in the import list?
No, just from whatever appears in method signatures. There's a flag that
can enable the import list
as well, but I left it disabled.
> That may create a lot of visual no
Bryce L Nordgren ha scritto:
> ...
>
> Is there a way to supply it with a UML diagram, or some sort of UML
> connectivity information (e.g., which dependencies are associations, which
> are attributes, and which are just dependencies?)
Hum, forgot to answer that one. There are two kinds of associ
Andrea Aime ha scritto:
> Bryce L Nordgren ha scritto:
>
>> I notice a lot of dashed lines. Is it drawing dependencies to everything
>> in the import list?
>>
> No, just from whatever appears in method signatures. There's a flag that
> can enable the import list
> as well, but I left it
Andrea Aime wrote:
> Two interesting suggestion that came up during the gt2 meeting to reduce
> visual clutter:
> - reverse engineer dependencies only from public/protected methods,
> avoid private ones
> - don't depict dependencies among classes in the same package, they are
> supposed to be re
[EMAIL PROTECTED] wrote on 06/05/2006 02:01:32
PM:
> Andrea Aime ha scritto:
> If I implemented those, would you be happy of generating gt2 javadoc
> this way, maybe just as
> an option for automated builds? (I really believe the diagrams would
> help newbies a lot, and also
> developers too, ra
Bryce L Nordgren ha scritto:
> [EMAIL PROTECTED] wrote on 06/05/2006 02:01:32
> PM:
>
>
>> Andrea Aime ha scritto:
>> If I implemented those, would you be happy of generating gt2 javadoc
>> this way, maybe just as
>> an option for automated builds? (I really believe the diagrams would
>> help ne
Here's a thinker for the PMC:
The GeoAPI uses Collections interfaces to implement aggregations in the UML
from 19107. The way in which it uses them forces implementations to
provide the actual data structure to clients because this is the only way
to add component pieces (e.g. add points to a po
The main maven 2 pom lists these as dependencies, as version 2.1
(collections) and 1.2 (pool).
I upgraded them to 3.1 (collections) and 1.3 (pool) in the geometry branch
without incident. "mvn clean" and "mvn test" complete without error. Can
I code to commons-collections-3.1, or does this give
Mark Presling wrote:
> I just found this in the gt2-render-2.2.x.jar META-
> INF.maven.org.geotools.gt2-render/pom.properties
>
> #Generated by Maven
> #Tue May 09 10:26:04 PDT 2006
> version=2.2-SNAPSHOT
> groupId=org.geotools
> artifactId=gt2-render
>
> Should I be scared or what??? Th
View results here ->
http://geovista16.geog.psu.edu/cruisecontrol/buildresults/geotools_current?log=log20060605233904
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
View results here ->
http://geovista16.geog.psu.edu/cruisecontrol/buildresults/geotools_2.1.x?log=log20060605234003
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Hi Bryce,
feel free to upgrade.
Gabriel
On Tuesday 06 June 2006 02:25, Bryce L Nordgren wrote:
> The main maven 2 pom lists these as dependencies, as version 2.1
> (collections) and 1.2 (pool).
>
> I upgraded them to 3.1 (collections) and 1.3 (pool) in the geometry branch
> without incident. "mvn
View results here ->
http://geovista16.geog.psu.edu/cruisecontrol/buildresults/geotools_snapshot?log=log20060606003411
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Bryce L Nordgren wrote:
> dormant code. You can only get it from their subversion server. Lacking
> any better ideas, I exported it from their subversion server and plunked it
> into the geometry branch. So, PMC, how should we handle this? I think our
> options are:
>
> 1] Steal the code outrig
17 matches
Mail list logo
