Kelly, with the check-ins I just did, the fop build should run OK.  It
would help a lot if you could update your Xalan build and give it a whirl.
You should make sure that everything else seems OK, besides the fact that
it seems to build without error.

-scott




                                                                                       
                            
                    Scott Boag                                                         
                            
                                         To:     Kelly Campbell 
<[EMAIL PROTECTED]>                            
                    06/18/2001           cc:     [EMAIL PROTECTED], 
[EMAIL PROTECTED]                  
                    11:59 PM             Subject:     RE: Gump xalan2 
failures(Document link: Scott Boag)          
                                                                                       
                            
                                                                                       
                            



Thank you for the investigation.  I've fixed the particular problem with
the key() function (haven't checked it in yet), and it runs through the
codegen without reporting an error, but there is obviously something else
wrong... build/src/org/apache/fop/fo/properties/Constants.java, for
instance, doesn't define any constants, so there are a million compilation
errors.  I've had enough fun for one night tracking the other problem down,
so I'll attack this one in the morning.

-scott




                                                                                       
                            
                    Kelly                                                              
                            
                    Campbell             To:     "'[EMAIL PROTECTED]'" 
<[EMAIL PROTECTED]>                   
                    <camk@channel        cc:     "'[EMAIL PROTECTED]'" 
<[EMAIL PROTECTED]>               
                    point.com>           Subject:     RE: Gump xalan2 failures         
                            
                                                                                       
                            
                    06/18/2001                                                         
                            
                    05:49 PM                                                           
                            
                    Please                                                             
                            
                    respond to                                                         
                            
                    fop-dev                                                            
                            
                                                                                       
                            
                                                                                       
                            




I can reproduce the same error that Gump was reporting. I've been trying to
debug it by running Xalan by hand on the properties.xsl and
foproperties.xml
that are failing and tracing that. I'm getting some inconsistent results
however. Every failure is from a recursive call to the "propclass" template
as seen in Gump, but I can get it to fail at different points in the XML
source it's processing.

I've changed the template to this:

<xsl:template name="propclass">
  <xsl:param name="prop" select="."/>
  <!-- <xsl:message>PropName: <xsl:value-of
select
="$prop/name"/></xsl:message> -->

  <xsl:variable name="prop-class-var">
  <xsl:choose>
    <xsl:when test="$prop/datatype">
      <xsl:value-of select="$prop/datatype"/><xsl:text>Property</xsl:text>
    </xsl:when>
    <xsl:when test="$prop/use-generic[@ispropclass='true']">
      <xsl:value-of select="$prop/use-generic"/>
    </xsl:when>
    <xsl:when test="$prop/use-generic">
      <!-- If no datatype child, then the prop must use the same datatype
as
           its template. -->
           <xsl:call-template name="propclass">
             <xsl:with-param name="prop"
              select="key('genericref', $prop/use-generic)"/>
        </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <!-- ERROR -->
      <xsl:message terminate="yes">
           No datatype found for property: <xsl:value-of select="name(.)"/>
      </xsl:message>
    </xsl:otherwise>
  </xsl:choose>
</xsl:variable>
<xsl:message>PropClass: <xsl:value-of
select="$prop-class-var"/></xsl:message>
 <xsl:message>PropName: <xsl:value-of select="$prop/name"/></xsl:message>
<xsl:value-of select="$prop-class-var"/>
</xsl:template>


Running Xalan with -TT, this fails on the property[@name='padding-before']
element in the source. However if I comment out the PropName message at the
end and uncomment the first one at the beginning of my modified template,
then it fails in a recursive propclass call on the
property[@name='conditional-length-template'].

My suspicion is that the nodes returned by the key function used in the
recursive call are somehow corrupted. I'm have no clue why it would error
out in different places depending on if I write a message out before or
after this template does its work. I don't have time to dig into this any
more today however. Hopefully someone on the Xalan team will be able to
look
into this.

-Kelly

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 11:48 AM
> To: Kelly Campbell
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Gump xalan2 failures
>
>
>
> I checked it out fresh... so I dunno.  I will try again in a bit.
>
> -scott
>
>
>
>
>
>
>                     Kelly
>
>                     Campbell             To:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>                     <camk@channel        cc:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>                     point.com>           Subject:     RE:
> Gump xalan2 failures
>
>
>                     06/18/01
>
>                     03:17 PM
>
>
>
>
>
>
>
>
>
> Scott,
>
> Is it possible you have an older version of FOP checked out
> and didn't do a
> "build clean"? That's about the only thing I can think of
> that might be
> causing that ambiguous class error. I will try a clean build
> using Xalan2
> from CVS and see what happens.
>
> -Kelly
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, June 17, 2001 4:38 PM
>
> > 3) I can't seem to build xml-fop:
> > compile:
> > Compiling the sources
> >     [javac] Compiling 133 source files to E:\xml-fop\build\classes
> >     [javac]
> > E:\xml-fop\build\src\org\apache\fop\image\ImageArea.java:64:
> > Ambiguo
> > us class: org.apache.fop.layout.InlineArea and
> > org.apache.fop.layout.inline.Inli
> > neArea
> >     [javac] public class ImageArea extends InlineArea {
> >     [javac]                                ^
> >     [javac] E:
> > \xml-fop\build\src\org\apache\fop\render\awt\AWTRenderer.java:26:
> > Package org.apache.batik.swing.svg not found in import.
> >     [javac] import org.apache.batik.swing.svg.*;
> >     [javac]        ^
> >     [javac] E:
> > \xml-fop\build\src\org\apache\fop\render\awt\AWTRenderer.java:27:
> > Package org.apache.batik.swing.gvt not found in import.
> >     [javac] import org.apache.batik.swing.gvt.*;
> >     [javac]        ^
> > Terminate batch job (Y/N)? y
> > I assume I'm doing something dumb...  perhaps the fop folks
> can help?
> > build codegen seems to succeed, but it is rather too fast, so
> > I fear it's
> > not doing anything.
>
>
>
>
>

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








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

Reply via email to