We solved this path-too-long-on-Windows problem at
the command line by generating everything into a .jar file.

My recollection is that we had problems getting this to
work in the <xmlbean> Ant task in our build.xml file
(sorry, I can't recall the details) so we generate the
class files into the folder C:\t, the shortest path we could
think of.  This won't help you with the 223 character class
name and the 44 character package name.  We were
lucky that it was short enough for us.

I think this path-too-long-on-Windows is the primary
drawback of xmlBeans.

Here is what our Ant task looks like:

      <property name="dir.temp.bin" location="${dir.temp}/${project}.bin"/>
       . . .
       <!-- Windows -->
       <condition  property="dir.temp.bin.schema"   value="C:/t" >
                 <os family="windows"/>
       </condition>
       <!-- not Windows -->
<condition property="dir.temp.bin.schema" value="${dir.temp.bin}" >
           <not>
                 <isset property="dir.temp.bin.schema"/>
           </not>
       </condition>

       <xmlbean
           srcgendir="${dir.src.java}"
           classgendir="${dir.temp.bin.schema}"
           srconly="true"
           download="true"
           source="1.4"
           verbose="${javacVerbose}"
       >


-Sam


----- Original Message ----- From: "Karr, David" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, November 07, 2005 3:12 PM
Subject: RE: Specify specific directory for "xmlbean" task to compile classes to?


From what I'm seeing, it's possible that could help, but the package
part is typically about a fifth of the entire class name.  For instance,
one class name is 223 characters long, and the package name is 44
characters.  The class name is composed of SIX nested classes.

-----Original Message-----
From: Raj Alagumalai [mailto:[EMAIL PROTECTED]

David,

You could try using the .xsdconfig file to map
targetnamespace value to a shorter value.

http://xmlbeans.apache.org/docs/2.0.0/guide/antXmlbean.html

Cheers
Raj


-----Original Message-----
From: Karr, David [mailto:[EMAIL PROTECTED]

Ok, I don't know why I didn't see this before, but I found
the "srcgendir" and "classgendir" attributes.  These work.

However, now I see a bizarre symptom that I've never seen in
Windows. The XMLBeans build process is creating file paths
that Windows cannot delete.  If I do a build, and then do a
"clean" afterwards, it fails, saying some of the file paths
are too long.  It doesn't matter whether I use those two
attributes or not.  If I don't set them, and then later try
to clear out my Windows Temp directory, it fails to delete
those files.  I found that the only way to clean out these
files is to move each directory one level up until the
resulting path to each file is "short enough" for the delete
operation to succeed.

Is there something I can do to mitigate this problem?

> -----Original Message-----
> From: Karr, David
>
> I noticed when building the samples, the "xmlbean" Ant task will
> compile intermediate classes into my Windows "Temp"
> directory.  I would have preferred to have intermediate objects all
> generated into my local "build" directory.  Is it practical
to make it

> do that?  I didn't see an attribute in the "xmlbean" task doc to do
> this.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to