ruct a SchemaTypeLoader union
in
the right order, being sure to put the compiled schemas we want to
use
first before the ones from a parent classloader.
david jencks
On Saturday, February 21, 2004, at 06:25 AM, Aaron Mulder wrote:
Jeremy,
Do you think there's some way to tell XMLBeans to load
eing sure to put the compiled schemas we want to use
first before the ones from a parent classloader.
david jencks
On Saturday, February 21, 2004, at 06:25 AM, Aaron Mulder wrote:
Jeremy,
Do you think there's some way to tell XMLBeans to load a document,
and let the only references to that s
; the right order, being sure to put the compiled schemas we want to use
> first before the ones from a parent classloader.
>
> david jencks
>
> On Saturday, February 21, 2004, at 06:25 AM, Aaron Mulder wrote:
>
> > Jeremy,
> > Do you think there's so
n Saturday, February 21, 2004, at 06:25 AM, Aaron Mulder wrote:
Jeremy,
Do you think there's some way to tell XMLBeans to load a document,
and let the only references to that schema type be assigned to the
loaded
elements? In other words, the XMLBeans infrastructure should "load and
forget"
Jeremy,
Do you think there's some way to tell XMLBeans to load a document,
and let the only references to that schema type be assigned to the loaded
elements? In other words, the XMLBeans infrastructure should "load and
forget"? If so, you still have to expect, in the gen
I guess my hope would be that in the example below, the n1 prefix
would be inherited by the children, so in essence it was legal to refer to
the first child with either "n1" or "n2" and the second child with either
"n1" or "n3". I wouldn't expect that to be the case if the URIs were
di
David Jencks wrote:
BTW, I was thinking some more about the requirement that the plugin
supply xpaths including the prefixes representing the namespaces used by
the j2ee dd. There might be an additional problem there beyond the
peculiar requirement that the root / ddbean report on the attribute
think if you wish to write a tool using xmlbeans you need to ensure
that the tools schema type system is loaded by a classloader
inaccessible to any plugins classloader. The copy of xmlbeans should be
sharable, just not the binary schema .xsb files.
Does this make sense?
We cannot assume that the
write a tool using xmlbeans you need to ensure
that the tools schema type system is loaded by a classloader
inaccessible to any plugins classloader. The copy of xmlbeans should
be sharable, just not the binary schema .xsb files.
Does this make sense?
BTW, I was thinking some more about the
Aaron Mulder wrote:
So I'm trying to run a JSR-88 tool that uses XMLBeans for the J2EE
DDs against the Geronimo (connector) JSR-88 plugin that also uses XMLBeans
for the J2EE namespace. Problem is, the tool doesn't use the same package
names that the Geronimo plugin does. And
So I'm trying to run a JSR-88 tool that uses XMLBeans for the J2EE
DDs against the Geronimo (connector) JSR-88 plugin that also uses XMLBeans
for the J2EE namespace. Problem is, the tool doesn't use the same package
names that the Geronimo plugin does. And apparently there
I've updated the xmlbeans plugin to not generate classes that are
already generated in another module. To avoid problems you should do
a clean build.
I suggest
maven clean;maven plugins;maven
I had some problems convincing the build system that the new plugin
version was actually ther
Hi everyone:
I get warning messages while I build the
"maven-xmlbeans-plugin" using newest version
plugin:deploy:
[mkdir]
Created dir:
/root/.maven/plugins/geronimo-maven-xmlbeans-plugin-DEV
[unzip] Expanding:
/root/incubator-geronimo/mod
It seems that the xmlbeans plugin does not regenerate the classes if the
schema is changed - you need to clean/build.
Can we fix this please so that a simple
cvs update ; maven
works.
--
Jeremy
Due to one bug fix in the xmlbeans plugin but lack of resolution of the
plugin dependencies problem you should rebuild the xmlbeans plugin
explicitly before building all of geronimo.
cd modules/maven-xmlbeans-plugin
maven rebuild
cd ../..
maven
thanks
david jencks
thanks.
now it works.
Kristian
[EMAIL PROTECTED] wrote:
djencks 2004/02/03 08:41:59
Modified:modules/deployment project.xml
modules/maven-xmlbeans-plugin maven.xml
Log:
remove attempt to build plugin first since it doesn't work
Revision ChangesPath
XML Schema
> Quality Checker from IBM.
>
> Let me know what we can do for you,
>
> Arnaud
>
> > -Original Message-
> > From: Jacek Laskowski [mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 13, 2003 1:16 PM
> > To: [EMAIL PROTECTED]
> > Subjec
Python and XML Schema
Quality Checker from IBM.
Let me know what we can do for you,
Arnaud
> -Original Message-
> From: Jacek Laskowski [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2003 1:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: XML POJO Update (XMLBeans)
>
I can certainly drive this decision.
On this note, does anyone know of an authoritative yet free way to
validate a schema? I'm trying to revise our Geronimo schemas to get out
of the J2EE namespace. I'm at a point where Sun's "multi schema
validator" think my worki
namespace. I'm at a point where Sun's "multi schema
> validator" think my working Geronimo schema is valid but XMLBeans thinks
> its not. I have no idea "who's right".
>
> As far as Castor goes,
used.
I can certainly drive this decision.
On this note, does anyone know of an authoritative yet free way to
validate a schema? I'm trying to revise our Geronimo schemas to get out
of the J2EE namespace. I'm at a point where Sun's "multi schema
validator" think
Bruce Snyder wrote:
Jacek,
Some very good points, Jacek. Just today both Arnaud and Keith from
the Castor Project (committers and architects for Castor XML) have
joined the geronimo-dev list.
Excellent! Welcome on board, guys.
Each of them told me that Castor XML supports the full XML Schema
as wel
This one time, at band camp, Jacek Laskowski said:
JL>Aaron Mulder wrote:
JL>
JL>>My sense is that none of the tools is a "perfect fit" out of the
JL>> box, so it's just a matter of working through the necessary
JL>> customizations. I think I'm qui
Aaron Mulder wrote:
My sense is that none of the tools is a "perfect fit" out of the
box, so it's just a matter of working through the necessary
customizations. I think I'm quite close to being satisfied with XMLBeans
-- I suspect I just need to straighten out our Geronim
According to Commerce One, one of the benefits of XGen is that you ~cannot~ configure the binding process. They argue that since there is only one non-configurable way for XGen to generate Java from XML, you can better guarantee what comes out of the binding process. I don't know how valid that
I spoke to Arnaud Blandin (committer for Castor XML (because I only
work on Castor JDO)) about this review, and he said that the reason the
reviewer states that Castor XML doesn't support feature X is because
she did not configure Castor XML at all.
I thought it was that Castor XML does not support
This one time, at band camp, Andy Barnett said:
AB>How about XGen from CommerceOne for a XML-Java Binding tool?
AB>http://www.commerceone.com/developers/docsoapxdk/xgen.html
I had no idea that Commerce One is still around.
AB>There's even a comparison already done for you among XGen, Castor, Su
My sense is that none of the tools is a "perfect fit" out of the
box, so it's just a matter of working through the necessary
customizations. I think I'm quite close to being satisfied with XMLBeans
-- I suspect I just need to straighten out our Geronimo namespace an
Wed, 2003-10-08 at 16:17, Jacek Laskowski wrote:
Bruce Snyder wrote:
> Have we considered the use of JiBx (http://jibx.sourceforge.net/)? I'm
> seeing small reservations from everyone who looks at XMLBeans. Why not
> consider other tools that are very well suited to the job?
That&#x
Bruce Snyder wrote:
Have we considered the use of JiBx (http://jibx.sourceforge.net/)? I'm
seeing small reservations from everyone who looks at XMLBeans. Why not
consider other tools that are very well suited to the job?
That's then the first cadidate or the second assuming XMLBeans was
> -Original Message-
> From: Aaron Mulder [mailto:[EMAIL PROTECTED]
>
> XMLBeans is now in Apache, and I've gotten the Apache
> version to
> generate, read, and write POJOs for the DDs. The JAR I built
> from the
> Apache source is about the
e. In fact, we need to continually check ourselves so that we're
not pervasive with the 'Not Built Here' attitude.
Have we considered the use of JiBx (http://jibx.sourceforge.net/)? I'm
seeing small reservations from everyone who looks at XMLBeans. Why not
consider other tools
Aaron Mulder wrote:
I have the highest hopes for XMLBeans out of all of the options,
which is why I am pursuing it now. But I'm still not totally convinced
that it can be made to work the way we want.
Hi,
Pursuing it even further, let's write down our expectations of what the
tool o
l be significant growth here).
> What about picking up one (e.g. XMLBeans) and dealing with its pros and
> cons or just create a service that does the job for us, i.e. reads the
> DDs (or any other XMLs) and provides POJOs? I don't have any idea how
> long it would take, but i
. Would it be changed in the future? When? I doubt if we keep
writing the code ourselves nobody will ever want to rewrite them to use
the tool.
What about picking up one (e.g. XMLBeans) and dealing with its pros and
cons or just create a service that does the job for us, i.e. reads the
DDs (or any
XMLBeans is now in Apache, and I've gotten the Apache version to
generate, read, and write POJOs for the DDs. The JAR I built from the
Apache source is about the same size as Castor, which is not great, but
1/2 of the pre-Apache version.
On the down side, it's ve
On Sat, 30 Aug 2003, Jason Dillon wrote:
> waiting to see how the xmlbeans incubation comes along.
There was a holdup while BEA reviewed the contributor's agreement, but
that's been worked out and we should see the code soon (e.g. next week).
I think someone said the code's alre
It's just a bad day for me and XML tools, I guess. I'm trying out
the xbeans module, and when I try to load a DD using code like this, I get
the results below. It seems to be looking for an xsb file, which as far
as I can tell is not produced by the build. Any advice would be
appreci
I think we have not decided on castor or xmlbeans yet. xmlbeans seems
to handle schemas better, but has some dependency issues which are not
so nice.
waiting to see how the xmlbeans incubation comes along.
--jason
On Saturday, August 30, 2003, at 09:26 AM, Aaron Mulder wrote:
Why'
e's a good reason to avoid
it.
Thanks,
Aaron
On Wed, 27 Aug 2003, James Strachan wrote:
> Its already in the incubator project & has an apache mail list...
>
> http://nagoya.apache.org/eyebrowse/SummarizeList?listId=151
>
> though the code hasn't been imported into
On Saturday, August 16, 2003, at 04:45 pm, toby cabot wrote:
On Sat, Aug 16, 2003 at 03:01:28PM +0100, James Strachan wrote:
I'm just focussing right now on 1 use case - to find an XML binding
tool to handle all the various J2ee schemas. Today the only solution
that works is XMLBeans
Ther
On Sat, Aug 16, 2003 at 03:01:28PM +0100, James Strachan wrote:
> I'm just focussing right now on 1 use case - to find an XML binding
> tool to handle all the various J2ee schemas. Today the only solution
> that works is XMLBeans
There's a tool called Skaringa on sourceforge.
It sounds like this is possible with XMLBeans, though it would still
be better IMO if it XML was not a dependency, so for embedded
solutions which do not need or want any XML processing we could drop
those dependencies to provide a smaller footprint.
Am not sure its that big a deal right now
l to handle all the various J2ee schemas. Today the only solution
that works is XMLBeans
Take for example if there was a WAR deployer which took one of these
objects (not a URL to an XML file or whatever), then you could
programatically install web-apps with out having to deal with XML at
all.
ically install web-apps with out having to deal with XML at
all.
It sounds like this is possible with XMLBeans, though it would still be
better IMO if it XML was not a dependency, so for embedded solutions
which do not need or want any XML processing we could drop those
dependencies to pro
will code that expects xpath
stuff still function? Same goes for code what expects the raw xml to
still be accessible?
Yes.
Second, it looks like XMLBeans requires XML libs to function, even if
XML is not used.
Its dependent on xmlbeans.jar yes. It doesn't mean you need to use an
XML file th
I still don't fully understand what you mean by 'XML not there'. The
generated beans from XMLBeans can be used as beans - though there is
an interface / impl separation - I'd be OK with just generating beans
rather than an interface + impl but I guess it gives some flexibili
the usage of xpath,
when constructing an object with out xml will code that expects xpath
stuff still function? Same goes for code what expects the raw xml to
still be accessible?
Second, it looks like XMLBeans requires XML libs to function, even if
XML is not used. Consider an embedded server
Is this possible?
Absolutely - this is the point of XMLBeans :)
If so, are there any problems which might arise from doing so?
Not that I'm aware of.
James
---
http://radio.weblogs.com/0112098/
ML code in them. (Granted, the
separate set of XXXDescriptor objects *do* have the XML stuff.)
That said, I haven't seen what XMLBeans generates, so I don't know
how it compares.
The main differences as far as I can see are
Castor
* makes beans + separate Descriptor classes
* beans have
Um, why?
In accordance with the licence - since its reusing the xmlbeans name.
I didn't want the name of the module to be the name of an existing
open source project.
Got it.
--jason
On Saturday, August 16, 2003, at 09:47 am, Jason Dillon wrote:
in the xmlbeans module (which will be renamed to xbeans soon to not
clash with the XMLBeans project name)
Um, why?
In accordance with the licence - since its reusing the xmlbeans name. I
didn't want the name of the module to b
n XML file, but the
actual objects have no particular XML code in them. (Granted, the
separate set of XXXDescriptor objects *do* have the XML stuff.)
That said, I haven't seen what XMLBeans generates, so I don't know
how it compares.
Aaron
On Sat, 16 Aug 2003, James Strachan wr
in the xmlbeans module (which will be renamed to xbeans soon to not
clash with the XMLBeans project name)
Um, why?
--jason
objects have no particular XML code in them. (Granted, the
separate set of XXXDescriptor objects *do* have the XML stuff.)
That said, I haven't seen what XMLBeans generates, so I don't know
how it compares.
The main differences as far as I can see are
Castor
* makes beans + separate Descri
separate set of XXXDescriptor objects *do* have the XML stuff.)
That said, I haven't seen what XMLBeans generates, so I don't know
how it compares.
Aaron
On Sat, 16 Aug 2003, James Strachan wrote:
> On Friday, August 15, 2003, at 07:49 pm, Jason Dillon wrote:
>
> > Just l
On Friday, August 15, 2003, at 07:49 pm, Jason Dillon wrote:
Just looked at the generated sources and it does not appear that
XMLBeans generated bits are intended to function in a non-XML
environment.
What do you mean? That the generated beans depend on XMLBeans? Thats
true of Castor generated
ts all there in CVS if any Castor folks fancy having a play to get it
to work...
maven generate:castor
in the xmlbeans module (which will be renamed to xbeans soon to not
clash with the XMLBeans project name)
James
---
http://radio.weblogs.com/0112098/
This one time, at band camp, Jason Dillon said:
JD>BTW, is there any word on when/if Castor will have richer XML schema
JD>support?
I'd recommend asking Arnaud and Keith about that. Either post to the
castor-dev list or send me your questions and I'll forward them along.
I didn't dig any furthe
Just looked at the generated sources and it does not appear that
XMLBeans generated bits are intended to function in a non-XML
environment. For example, if someone wanted to construct a bean just
using APIs it looks like they may have to put in some dummy XML fluff,
which is sorta silly IMO
James Strachan wrote:
I'd fixed the build system to do this before I checked it in. Though
then the build system got refactored a bit and my original change to
ignore xmlbeans got zapped. I've put it back again now so it is ignored.
None needs to build this stuff.
Sure. Fwiw, if y
As soon as XMLBeans enters Apache's
CVS repo its a total non issue.
James
---
http://radio.weblogs.com/0112098/
On Thursday, August 14, 2003, at 11:23 pm, Ou, Rong wrote:
I played around a little with BEA's XMLBeans
(http://dev2dev.bea.com/technologies/xmlbeans/) and it seemed to work
better than JAXB. They do claim 100% XML Schema support :). Not sure
about licensing compatibility.
The licence
On Friday, August 15, 2003, at 09:13 am, Alex Blewitt wrote:
On Friday, Aug 15, 2003, at 06:38 Europe/London, Bruce Snyder wrote:
Isn't there a way we can comment this module out and not have it as a
build? That way, people who are working on the xmlbeans part can build
it, but people wh
On Friday, Aug 15, 2003, at 06:38 Europe/London, Bruce Snyder wrote:
This one time, at band camp, Bill de hÓra said:
Bdh>Tim Urberg wrote:
Bdh>
Bdh>> I tried going to
Bdh>> http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-1.0.jar and
got a
Bdh>> 404 NOT FOUND erro
On Friday, August 15, 2003, at 03:47 am, Jan Bartel wrote:
James,
I've just committed an experimental module called xmlbeans (but kept
it out of the main build).
Ahem, so if it is out of the main build, why when do a cvs update -P -d
and do a build (ie just type "maven"), I ge
actually run it themselves (since its static code generated from XML
Schema documents).
Anyways this won't be for long. As soon as XMLBeans enters Apache's CVS
repo its a total non issue.
James
---
http://radio.weblogs.com/0112098/
ote:
>
>> Tim Urberg wrote:
>>
>>> I tried going to
>>> http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-1.0.jar and got a
>>> 404 NOT FOUND error, how should I fix this?
>>
>> It's BEA code. The module readme -
>>
>> [[[
>
I am not really happy with a build system that requires such user
interaction to function.
--jason
On Friday, August 15, 2003, at 09:18 AM, Bill de hÓra wrote:
Tim Urberg wrote:
I tried going to
http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-1.0.jar and got a
404 NOT FOUND error, how
On Friday, August 15, 2003, at 03:18 am, Bill de hÓra wrote:
Tim Urberg wrote:
I tried going to
http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-1.0.jar and got a
404 NOT FOUND error, how should I fix this?
It's BEA code. The module readme -
[[[
To build me you need to download the x
This one time, at band camp, Bill de hÓra said:
Bdh>Tim Urberg wrote:
Bdh>
Bdh>> I tried going to
Bdh>> http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-1.0.jar and got a
Bdh>> 404 NOT FOUND error, how should I fix this?
...
Bdh>in the hope it contains xmlbeans 1.0
The other thing you could try, which may or may not work, is to put an
empty file in the maven repository as the jar file eg
touch $HOME/.maven/repository/xmlbeans/jars/xmlbeans-1.0.jar
It seems to work for me, but then again, the build might not have got as
far as the xmlbeans stuff, as it is
James,
I've just committed an experimental module called xmlbeans (but kept it
out of the main build).
Ahem, so if it is out of the main build, why when do a cvs update -P -d
and do a build (ie just type "maven"), I get the following error:
+-
Tim Urberg wrote:
I tried going to
http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-1.0.jar and got a
404 NOT FOUND error, how should I fix this?
It's BEA code. The module readme -
[[[
To build me you need to download the xbeans jar from BEA and then do
this
cp xbeans.jar ~/.
Hello everyone,
When I tried to do a maven build I got this error:
+
| Executing (default): Geronimo :: XmlBeans
| Memory: 29M/43M
+
Attempting to download xmlbeans-1.0.jar.
Error retrieving artifact from
[http
XMLBeans looks pretty good at first look - it took me about 30 minutes
to get it installed and working. It had trouble with the Sun copy of
the schemas I was using, but using the BEA copies of the J2EE schemas
it worked fine. (I'm assuming XSDs are free to distribute here - surely
they
On Thursday, August 14, 2003, at 11:26 pm, James Strachan wrote:
On Thursday, August 14, 2003, at 11:23 pm, Ou, Rong wrote:
I played around a little with BEA's XMLBeans
(http://dev2dev.bea.com/technologies/xmlbeans/) and it seemed to work
better than JAXB. They do claim 100% XML Schema su
On Thursday, August 14, 2003, at 11:23 pm, Ou, Rong wrote:
I played around a little with BEA's XMLBeans
(http://dev2dev.bea.com/technologies/xmlbeans/) and it seemed to work
better than JAXB. They do claim 100% XML Schema support :). Not sure
about licensing compatibility.
Its definitely
On Thursday, August 14, 2003, at 11:21 pm, Jason Dillon wrote:
We could extend / hack JAXB to make simpler beans with less
dependencies. Or there's other tools to try yet - like XMLBeans or
Zeus. Or we could do XSLT on the schema documents to take the stuff
out of them that breaks Castor.
I played around a little with BEA's XMLBeans
(http://dev2dev.bea.com/technologies/xmlbeans/) and it seemed to work better
than JAXB. They do claim 100% XML Schema support :). Not sure about licensing
compatibility.
Rong
> -Original Message-
> From: James Strachan [ma
We could extend / hack JAXB to make simpler beans with less
dependencies. Or there's other tools to try yet - like XMLBeans or
Zeus. Or we could do XSLT on the schema documents to take the stuff
out of them that breaks Castor.
What is breaking castor specifically?
--jason
I've just committed an experimental module called xmlbeans (but kept it
out of the main build). What its meant to be is a set of auto-generated
Java Beans that represent the various J2EE config files in XML.
(web.xml, ejb-jar.xml, application.xml and so forth). There's quite a
few
82 matches
Mail list logo
