Gabriel Roldán a écrit :
> Feel free to sync up the coverage stuff!
Done.
Martin
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opin
Justin Deoliveira wrote:
> So basically you are talking about making the context a Hints instance.
> I am not sure I like this approach as it tends to spiral out of control
> with no constraint as you can add anything to the hints and it may or
> may not be regarded.
>
Fair enough - valid point
Gabriel Roldán a écrit :
> Feel free to sync up the coverage stuff!
Thanks. I will do that in one hours approximatively (I have to go for now).
Martin
-
Take Surveys. Earn Cash. Influence the Future of IT
Join Source
Build is fixed,
excuse the inconvenient Martin, I just didn't want to commit all the changes
at all but to use propper commit messages for each relate bunch changes
Feel free to sync up the coverage stuff!
Gabriel
On Friday 24 November 2006 02:29, Martin Desruisseaux wrote:
> [EMAIL PROTECTED] a
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061123204605Lbuild.81
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chanc
On Friday 24 November 2006 02:29, Martin Desruisseaux wrote:
> [EMAIL PROTECTED] a écrit :
> > View results here ->
> > http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061123
> >195915
>
> Is it related to the FilterFactory2 change in GeoAPI?
more or less, functions got broken i
[EMAIL PROTECTED] a écrit :
> View results here ->
> http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061123195915
Is it related to the FilterFactory2 change in GeoAPI? I'm ready to commit the
Geotools-GeoAPI alignment, but I need to know what is our current state. Can we
depl
Justin Deoliveira wrote:
> That is an interesting idea :). The more I think about it the more I
> agree with Jody's approach. Oh well, hind sight is 20/20 I guess.
>
Not to worry Justin the interface is good; that is the important thing
to users.
Fixing the abstract classes is not the worst th
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061123195915
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to shar
That is an interesting idea :). The more I think about it the more I
agree with Jody's approach. Oh well, hind sight is 20/20 I guess.
-Justin
Gabriel Roldán wrote:
> or if the wrapper is needed, could it be a dynamic proxy? this way is could
> adapt to the interface asked for
> (might be rantin
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061123194517Lbuild.80
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chanc
Jody Garnett wrote:
> Jody Garnett wrote:
>> Thanks Martin this is good stuff;
>>
>> Thinking about integration:
>> #1 we will need a "decimation" interface from Object -> Shape in order
>> for the renderer to function with any Geometry implementation (not
>> this is already being considered by the
or if the wrapper is needed, could it be a dynamic proxy? this way is could
adapt to the interface asked for
(might be ranting, need a nap)
On Friday 24 November 2006 01:25, Jody Garnett wrote:
> The pont of difference is because people code like:
>
> if( handle instanceof FooService){
> Foo
Jody Garnett wrote:
> Thanks Martin this is good stuff;
>
> Thinking about integration:
> #1 we will need a "decimation" interface from Object -> Shape in order
> for the renderer to function with any Geometry implementation (not this
> is already being considered by the JPOX crew as a way to let
The pont of difference is because people code like:
if( handle instanceof FooService){
FooService service = (FooService) handle;
service.hack("hack");
}
A wrapper breaks this approach :-P As in no naked FooService handles
escape into the wild from the catalog.
I would of liked code to
Gabriel Roldán a écrit :
>>> This is my ask/beg to know if it is possible to align them?
>> I'm working on that.
I'm ready to commit the aligned Geotools code. Waiting for the recent build
failure in "unsupported/jpox" to be fixed before I commit.
We need to deploy a "geoapi-nogeneric-2.1-SNAPSH
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061123182307
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to shar
It was a choice between using a wrapper so that existing implementations
could remain untouched, or modify every existing resource handle to
process the extension point.
Both ways have their benefits. Its unfortunate we didn't take the same
direction, this makes the gap between the geotools catalo
Jody Garnett wrote:
>Having a bit of fun helping someone set up trunk for mac development:
>- rendering-styling - fatal tests
>- espg-access - same
>
>I would like to set up a maven profile to at least exclude the tests if
>we are on a mac; and at most exclude the module.
>Anyone played in this a
Having a bit of fun helping someone set up trunk for mac development:
- rendering-styling - fatal tests
- espg-access - same
I would like to set up a maven profile to at least exclude the tests if
we are on a mac; and at most exclude the module.
Anyone played in this area before?
Jody
-
Well I sent this to the wrong list; but some of the stuff on
IGeoResource is of interest; although it sounds like
Justin took a different track in terms of using wrappers.
> Started page the programmers guide reference section ...
> -
> http://udig.refractions.net/confluence/display/DEV/Upgrade+f
Gabriel can I propose a more radical "fix" -- on the geotools devel list
for now.
GEOT-1038:
> In the move to the GeoAPI filter interfaces, most FunctionExpressions
> got broken by improper delegation to the new methods.
> For example, some keep storing their arguments in an Expression[]
> fiel
Bleah - please commit (this is trunk). And test cases that verify the
"fix" would be helpful.
Can I ask if GeoTools 2.3 also suffers from the same breakage? Or is
this part of the work
Justin and I did (or later that Cory did for the aggregate functions?)
Gabriel I will be on IRC all this week i
Started page the programmers guide reference section ...
- http://udig.refractions.net/confluence/display/DEV/Upgrade+from+1.0+to+1.1
Assume this can be updated as backwards incompatibilities are pointed
out. If you know
of any I missed please update the page :-)
Jody
--
Ah,
most of them are from the people cc'ed on this message, and for the bunch of
functions generated by the dblasby's spike project named
FunctionFilterWriter, I guess the best thing to do would be to modify the
code generation class in order to use the same strategy mentioned before?
And for t
Thanks Martin, seems Jody and me sent out the concern at the same time.
On Thursday 23 November 2006 22:28, Martin Desruisseaux wrote:
> Gabriel Roldán a écrit :
> > This is my ask/beg to know if it is possible to align them?
>
> I'm working on that.
>
> Martin
--
Gabriel Roldán ([EMAIL PR
Gabriel Roldán a écrit :
> This is my ask/beg to know if it is possible to align them?
I'm working on that.
Martin
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll
Hi all,
as you may see in http://jira.codehaus.org/browse/GEOT-1038, almost all
FunctionExpression implementations in trunk are broken.
I'm working on fixing it, but since it means modifying like 130 classes, I
want to ask the responsibles for direction: should I fix and commit, provided
that
Jody Garnett a écrit :
> So I think I made the mistake of working on GeoAPI trunk; which seems
> out of sync with GeoTools trunk
Yes, Geotools is out of synchronization compared to GeoAPI. I'm working on that.
Martin
-
Jody Garnett a écrit :
> So I think I made the mistake of working on GeoAPI trunk; which seems
> out of sync with GeoTools trunk
Yes, GeoAPI is out of synchronization. I'm working on that.
Martin
-
Take Surveys
Hi guys,
I need a new geoapi snapshot in order to catch up a couple fixes in
FilterFactory2 and get the new CQL module in good shape (currently I have to
cast FilterFactory to FilterFactoryImpl, and since the parser gets the
FilterFactory to use as a parameter, it might not be always the case).
So I think I made the mistake of working on GeoAPI trunk; which seems
out of sync with GeoTools trunk
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
> --
On Thursday 23 November 2006 19:21, Jody Garnett wrote:
> Thanks for making the page; your "gold start/redstar" thing is *great*
> at summing up the state of the module - way better then
> I expected :-) Thank you ...
>
cool, getting 2 or three more stars is a matter of a couple days.
Last thing t
Done;
Jody
> JIRA task for some other projects include wiki markup. Example:
>
> http://jira.codehaus.org/browse/MJAVADOC-86
>
> This is quite convenience for posting code in a JIRA task. But wiki markup
> doesn't seem to be enabled in GEOT. Does anyone know how to enable them? I
> searched in t
Thanks Martin this is good stuff;
Thinking about integration:
#1 we will need a "decimation" interface from Object -> Shape in order
for the renderer to function with any Geometry implementation (not this
is already being considered by the JPOX crew as a way to let Oracle
Geometry implementatio
I commited Sanjay Jena's work on ISO 19107 implementation:
http://svn.geotools.org/geotools/trunk/gt/modules/unsupported/geometry/
This a work in progress, and is not yet part of the Maven build. I will work on
the Maven configuration later.
Note to Sanjay: I renamed the following packages:
or
Hi Gabriel:
I am pretty set on getting rid of the old feature model as quickly as
possible - more from a standpoint of staying focused
then anything else. I really want 2.4 to be the last release with this
feature model, and to have all the work needed to
adopt the new one out of the way.
To wi
Simone Giannecchini ha scritto:
> It would be a great idea to have the same for GeoTools. I think it
> would be even more important.
Hum yes and no?
No, because we could simply deploy the jars onto maven repositories
as snapshots, something that's already happening for the 2.2.x branch
if I'm
Thanks for making the page; your "gold start/redstar" thing is *great*
at summing up the state of the module - way better then
I expected :-) Thank you ...
I will look at the module this week as I work on Pojo Expressions.
Jody
> Hi, this mail is for Gabriel Roldan, I have a look to CQL parser
>
It would be a great idea to have the same for GeoTools. I think it
would be even more important.
Simone.
On 11/22/06, Justin Deoliveira <[EMAIL PROTECTED]> wrote:
> Agreed, would be very nice to have. Wouldn't be too much work to achieve
> either. It would be easier if it was a one line command t
Jody Garnett a écrit :
> However noticing after the fact is kind of too late as far as the size
> of the svn repo goes. I wonder if we can set any triggers on svn to not
> let files over 50k be committed in any other path then **/sample-data/** ?
We could, but not all test data need to move to "
Hi all,
As I stated in my discussion with gabriel I think the approach is sound.
No matter how we do it, it will be necessary at some point to have two
feature modules around. My concern however is that this will stay the
case and we will be stuck with "two" feature models.
What I want to avoid
JIRA task for some other projects include wiki markup. Example:
http://jira.codehaus.org/browse/MJAVADOC-86
This is quite convenience for posting code in a JIRA task. But wiki markup
doesn't seem to be enabled in GEOT. Does anyone know how to enable them? I
searched in the "admin" pages and hav
:). Well min occurs > 1 is getting into multi-valued attributes which
our feature model doesn't handle, not well anyways. My question is more
of just a sanity check to make the change.
-Justin
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>> The method in question always return
Ok, so it sounds like 0 or 1 should be acceptable which will work for
me. Thanks David.
-Justin
David Zwiers wrote:
> Hmm, I'm a bit lost as to why I would force '1' to be returned, and not
> just default the value in the constructor. Probably just me getting
> sloppy at the time.
>
> For geoto
Most FunctionExpression's are broken
Key: GEOT-1038
URL: http://jira.codehaus.org/browse/GEOT-1038
Project: GeoTools
Issue Type: Bug
Components: core filter
Affects Versions: 2.4.M0
Hmm, I'm a bit lost as to why I would force '1' to be returned, and not just
default the value in the constructor. Probably just me getting sloppy at the
time.
For geotools' feature model (unless it changed), the value will ALWAYS be 0
or 1 (the maximum will always be 1).
On 11/23/06, Andrea Ai
Hi everyone, I will try to explain our motivation to maintain two models (SF
an CF) in trunk.
1) Client or users view
Current Applications: this applications can be improved or not, this is a fact
that we can not handle because it depends on external factors. If that
application can not be imp
Hi, this mail is for Gabriel Roldan, I have a look to CQL parser documentation
http://docs.codehaus.org/display/GEOTOOLS/CQL+Parser
Perhaps, this page is old because the new parser interface is FilterBuilder no
FilterExpression, additionally is important talk about the extensions that
Axios
Justin Deoliveira ha scritto:
> Hi all,
>
> The method in question always returns 1 even though the field on the
> class is mutable. I would like to change the method to return the actual
> field, however I am weary of doing so.
>
> Given our feature model I understand the feature model. But I ca
50 matches
Mail list logo
