That's correct. I have the module in eclipse after doing a
mvn:eclipse:eclipse. My JUnit test has this error when run from eclipse
unless I remove the jaxb dependency from the metadata pom file and redo
mvn eclipse:eclipse.
Graham.
Martin Desruisseaux wrote:
> Graham Davis a écrit :
>> I jus
Graham Davis a écrit :
> I just wanted to add that I am now having issues with the mt-metadata
> jaxb stuff too. I am trying to test the parsing of my WPS module and am
> getting jaxb class signing errors. If I remove the jaxb dependency in
> the metatdata module it breaks metadata but my test
I just wanted to add that I am now having issues with the mt-metadata
jaxb stuff too. I am trying to test the parsing of my WPS module and am
getting jaxb class signing errors. If I remove the jaxb dependency in
the metatdata module it breaks metadata but my test works fine.
So is there any u
Adrian Custer a écrit :
>>> Wondering if putting jaxb dependencies at the top of the pom.xml files
>>> in the xsd modules is going to buy us the desired order...
>> Adrian tried and it worked for him.
>
> Not exactly,
I was confused, sorry.
I was thinking "putting jaxb dependencies at the top of
On Fri, 2008-05-23 at 19:00 +0200, Martin Desruisseaux wrote:
> Andrea Aime a écrit :
> > Wondering if putting jaxb dependencies at the top of the pom.xml files
> > in the xsd modules is going to buy us the desired order...
>
> Adrian tried and it worked for him.
Not exactly,
the patch attached
Andrea Aime a écrit :
> Wondering if putting jaxb dependencies at the top of the pom.xml files
> in the xsd modules is going to buy us the desired order...
Adrian tried and it worked for him.
In a little bit longuer term, I wonder if we should consider make the GeoTools
project to evoluate towar
Martin Desruisseaux ha scritto:
> Justin Deoliveira a écrit :
>> I do, one is in teh dummy module, one in the actual.
>
> I'm not familiar with Eclipse IDE, but is there anyway with Eclipse to make
> sure
> that the actual JAXB appears first in the classpath?
Manual modifications of the classpa
> Hey Justin,
>
> Not sure what xsd is, I tried with WFSParsingTest and got your error.
Its what i call the grouping of xml modules, everything under extension/xsd.
Thanks for looking into it. But manually updating the classpath is not
really an acceptable fix in my mind.
I may just try to remo
On Fri, 2008-05-23 at 08:09 -0700, Justin Deoliveira wrote:
> 1. Run mvn eclipse:eclipse
> 2. Import modules into eclipse
> 3. Run xsd tests from eclipse
Hey Justin,
Not sure what xsd is, I tried with WFSParsingTest and got your error.
Then, I "fixed" it, I think, with
Run > Open run Dialog...
Justin Deoliveira a écrit :
> I do, one is in teh dummy module, one in the actual.
I'm not familiar with Eclipse IDE, but is there anyway with Eclipse to make
sure
that the actual JAXB appears first in the classpath?
Martin
--
Jody Garnett wrote:
> Wait I think I have it; did we end up making a "dummy" jar for JaxB (so
> the code could compile when jaxb was not available?) Perhaps we are
> getting class cast exception between this dummy jar (needed by
> gt-metdata to compile) and the real thing (used by the parser).
Wait I think I have it; did we end up making a "dummy" jar for JaxB (so
the code could compile when jaxb was not available?) Perhaps we are
getting class cast exception between this dummy jar (needed by
gt-metdata to compile) and the real thing (used by the parser).
Justin can you do a search f
1. Run mvn eclipse:eclipse
2. Import modules into eclipse
3. Run xsd tests from eclipse
Jody Garnett wrote:
> So how is it not working with your IDE again? The only thing I can
> figure is if you did a maven eclipse:eclipse using Java 6 on the command
> line and then were working with another
Hey Justin, all,
Sorry this is getting under everyone's skin.
Justin, for Cedric and Martin to help you, they'd have to have a much
better idea what is going on. The little info we have so far doesn't
give us enough to diagnose the issue.
The only thing they can come up with is that your real
So how is it not working with your IDE again? The only thing I can
figure is if you did a maven eclipse:eclipse using Java 6 on the command
line and then were working with another project that also used Jaxb ...
ah I see - the xml parser.
So are we out of sync with respect to versions? Sorry ju
Hey Justin' it appears I was not clear: The Jaxb dependency for metdata
is marked provided.
If you want to use JaxB serialization for reading/writing metadata:
- you are using Java 6 (and it is included in the JRE) and provided that way
- or you are using Java 5 and you can included it in your p
Hey Justin' it appears I was not clear: The Jaxb dependency for metdata
is marked provided.
If you want to use JaxB serialization for reading/writing metadata:
- you are using Java 6 (and it is included in the JRE) and provided that way
- or you are using Java 5 and you can included it in your p
Justin Deoliveira a écrit :
>> I said "users who don't care have nothing to do".
>>
>>
>
> Ahh... ok. So i guess its ok that I cant work in my ide any more. But
> hey, at least the users who don't care having nothing to do.
>
>
No, no, of course not, it is not okay for me. And that's why i
Martin Desruisseaux ha scritto:
> Justin Deoliveira a écrit :
>> Good, can we stop using java 6 as a justification then?
>
> Not from me. This is a very strong justification in my mind.
>
>
>> Oh well... just yet another hurdle i guess for people to develop with
>> geotools... as if it was not
> I said "users who don't care have nothing to do".
>
Ahh... ok. So i guess its ok that I cant work in my ide any more. But
hey, at least the users who don't care having nothing to do.
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
--
Justin Deoliveira a écrit :
> Good, can we stop using java 6 as a justification then?
Not from me. This is a very strong justification in my mind.
> Oh well... just yet another hurdle i guess for people to develop with
> geotools... as if it was not hard enough already.
I said "users who don't
Justin Deoliveira a écrit :
> So GeoTools requires Java 6? I thought we were still on Java 5?
>
>
It is not what I said. In my previous mail, I just explain that if you
want to use JAXB, you have to build the metadata module with a JDK6.
Otherwise you won't get annotated classes in the jar gen
Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
>> So GeoTools requires Java 6? I thought we were still on Java 5?
>
> No. Geotools requires Java 5 only.
Good, can we stop using java 6 as a justification then?
>
> We have not added JAXB as a core dependency. GeoTools do not depends on J
Justin Deoliveira a écrit :
> So GeoTools requires Java 6? I thought we were still on Java 5?
No. Geotools requires Java 5 only.
If you want metadata to work with JAXB, you needs either Java 6 or put JAXB in
the "endorsed" directory, at your choice. But this is *optional*.
> I would like to re
So GeoTools requires Java 6? I thought we were still on Java 5?
Upgrading is going to be a bit of work for me... but appears i have no
choice. I would like to remind folks that when teh proposal to add jaxb
as a core dependency was brought up i was against it, but was *assured*
that "nothing wo
Jody Garnett a écrit :
> Justin you should have a different set of dependencies for Java 6; since
> jaxb is starting to get folded into Java 6 you will get security / class
> cast exception when trying to mix and match the same "class" between two
> different classloaders... the JRE gets annoyed
Justin you should have a different set of dependencies for Java 6; since
jaxb is starting to get folded into Java 6 you will get security / class
cast exception when trying to mix and match the same "class" between two
different classloaders... the JRE gets annoyed when you have classes in
your
Hi all,
I am running into problems with the jaxb module conflicting with the
version of jaxb that is depended on by the xml parser. The problem is i
get SecurityException complaining about JAXException:
java.lang.SecurityException: class "javax.xml.bind.JAXBException"'s
signer information does
28 matches
Mail list logo
