[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
Work ended in a state of : Failed
Elapsed: 34 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only package 
[Working Directory: /srv/gump/public/workspace/xml-fop]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xmlgraphics-commons/build/xmlgraphics-commons-05122007.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-
 
05122007/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-xml.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-script.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-parser.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-gvt.jar:/srv/gump/pub
 
lic/workspace/excalibur/framework/api/target/excalibur-framework-api-05122007.jar:/srv/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-05122007.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-05122007.jar:/srv/gump/public/workspace/apache-commons/io/build/commons-io-05122007.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-05122007.jar
-
 [xslt] Loading stylesheet 
/srv/gump/public/workspace/xml-fop/src/codegen/fonts/font-file.xsl

compile-java:
[javac] Compiling 921 source files to 
/srv/gump/public/workspace/xml-fop/build/classes
[javac] 
/srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java:53:
 warning: [deprecation] org.apache.fop.area.inline.Character in 
org.apache.fop.area.inline has been deprecated
[javac] import org.apache.fop.area.inline.Character;
[javac]   ^
[javac] 
/srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/area/AreaTreeParser.java:46:
 warning: [deprecation] org.apache.fop.area.inline.Character in 
org.apache.fop.area.inline has been deprecated
[javac] import org.apach

Re: FOP and XML Graphics Commons Maven artifacts

[Cameron McCormack]

Hi Max.

Max Berger:
> actually, this could be a very fun experiment to see if my new fop
> account is working. It should (theoretically) give me access to the
> people.apache.org server mentioned in the howto. So yes, I am
> volunteering to do it. (And provide a how-to afterwards)

Great!  Since we’re not using maven for building, do you want to have a
go at modifying fop’s and commons’ maven-artifacts ant build target to
generate the right files?

> There is no particular reason why I mixed the two compiled versions
> other than pure coincidence. Would it be reasonable to upload the 1.4
> artifacts only? Or should the 1.3 jars should also be uploaded (probly
> with something like -1.3 in the name)?

I’m no maven when it comes to maven, so I’m not sure how different Java
versions are catered for in the repository.  I’ve asked on repository@
but no reply yet:

  http://markmail.org/message/xun2cpohbevhothw

-- 
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED]  ▪  ICQ 26955922  ▪  MSN [EMAIL PROTECTED]

Re: Property Cache: Null Pointer Exception

[Andreas L Delmelle]

On Dec 5, 2007, at 15:23, Chris Bowditch wrote:


Andreas L Delmelle wrote:

On Nov 27, 2007, at 20:06, Andreas L Delmelle wrote:


Hi Andreas,



I tested on Apple JVM 1.4.2 and 1.5.0 on OS X 10.4. Both  
single-  and multi-threaded.

Heap remains stable here over hundreds of runs.
With multiple concurrent runs, my CPU usage easily reaches  
180-190%  (2 CPUs)



Just to confirm:
In the meantime, I have also run some tests with the same document  
on  Windows XP SP 2 with different versions of the Sun JVM,  
running 2  concurrent threads on a Centrino Dual Core.

Classes compiled with 1.4 compatibility.
I managed to reproduce the NPE on Java 1.4.2 and 1.5.0, at random   
intervals, always between 50 and 250 runs.


Thanks for your perservance. Glad its not me going mad :)


Yeah, I thought you'd appreciate it for this very reason... :-)

Still weird though. Logically, from a Java POV, there is no reason  
why the NPE could ever occur, or IOW: if the NPE occurs, there would  
be a problem in the JVM's implementation of WeakReferences or  
synchronized code-blocks or in the garbage-collection algorithm or  
the thread-synchronization.


If the NPE occurs at that point, either of the variables 'entry' or  
'e' would be null.
'entry' = the WeakReference that is obtained by polling the  
ReferenceQueue. The code-block in question will not be entered if  
this is null.
Possibility A: If it /becomes/ null, this would mean that the  
WeakReference /itself/ (not its referent) is removed by the garbage- 
collector while there obviously exists a strong, local reference to it.


'e' = the WeakReference that is obtained by traversing the hash- 
bucket, looking for 'entry'.
Possibility B: If this is null, this would mean that 'entry' could  
not be found. So, some other thread already cleaned up the stale  
entry, which would mean that ReferenceQueue.poll() has returned the  
same WeakReference for another call in that thread... but the only  
calls to poll() happen inside code-blocks that are synchronized on  
the CacheSegment to which the ReferenceQueue belongs. As such, they  
can never occur at the exact same instant. One always has to wait for  
the other.
Come to think of it, one thing I haven't tried, is declaring the  
ReferenceQueue as 'volatile', but I somehow doubt this would help  
much here.


You mentioned that your tests were single-threaded. The cause of the  
NPE can therefore not be MT-related, which rules out Possibility B,  
and seems to point towards a quirk in the GC and its treatment of  
WeakReferences. :/



Anyway, enough ranting done. Just glad it worked out.


Cheers

Andreas

[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
Work ended in a state of : Failed
Elapsed: 35 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only package 
[Working Directory: /srv/gump/public/workspace/xml-fop]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xmlgraphics-commons/build/xmlgraphics-commons-05122007.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-
 
05122007/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-xml.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-script.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-parser.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-05122007/lib/batik-gvt.jar:/srv/gump/pub
 
lic/workspace/excalibur/framework/api/target/excalibur-framework-api-05122007.jar:/srv/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-05122007.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-05122007.jar:/srv/gump/public/workspace/apache-commons/io/build/commons-io-05122007.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-05122007.jar
-
 [xslt] Loading stylesheet 
/srv/gump/public/workspace/xml-fop/src/codegen/fonts/font-file.xsl

compile-java:
[javac] Compiling 921 source files to 
/srv/gump/public/workspace/xml-fop/build/classes
[javac] 
/srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java:53:
 warning: [deprecation] org.apache.fop.area.inline.Character in 
org.apache.fop.area.inline has been deprecated
[javac] import org.apache.fop.area.inline.Character;
[javac]   ^
[javac] 
/srv/gump/public/workspace/xml-fop/src/java/org/apache/fop/area/AreaTreeParser.java:46:
 warning: [deprecation] org.apache.fop.area.inline.Character in 
org.apache.fop.area.inline has been d

DO NOT REPLY [Bug 44024] New: - About AFP renderer Issues when i try to using Aria Fonts which come from Mainframe

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44024

   Summary: About AFP renderer Issues when i try to using Aria Fonts
which come from Mainframe
   Product: Fop
   Version: 0.94
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: fonts
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Exception:

system properly.
java.lang.IllegalArgumentException: Transparent data is longer than 253 bytes: 
[EMAIL PROTECTED]
at 
org.apache.fop.render.afp.modca.PresentationTextData.addTransparentData
(PresentationTextData.java:213)
at org.apache.fop.render.afp.modca.PresentationTextData.createTextData
(PresentationTextData.java:348)
at 
org.apache.fop.render.afp.modca.PresentationTextObject.createTextData
(PresentationTextObject.java:128)
at org.apache.fop.render.afp.modca.AbstractPageObject.createText
(AbstractPageObject.java:221)
at org.apache.fop.render.afp.modca.AFPDataStream.createText
(AFPDataStream.java:353)
at org.apache.fop.render.afp.AFPRenderer.renderText
(AFPRenderer.java:1178)
at org.apache.fop.render.AbstractRenderer.renderInlineArea
(AbstractRenderer.java:617)
at org.apache.fop.render.AbstractRenderer.renderLineArea
(AbstractRenderer.java:606)
at org.apache.fop.render.AbstractRenderer.renderBlocks
(AbstractRenderer.java:532)
at org.apache.fop.render.AbstractRenderer.renderBlock
(AbstractRenderer.java:582)
at org.apache.fop.render.AbstractRenderer.renderBlocks
(AbstractRenderer.java:522)
at org.apache.fop.render.AbstractRenderer.renderBlock
(AbstractRenderer.java:582)
at org.apache.fop.render.AbstractRenderer.renderBlocks
(AbstractRenderer.java:522)
at org.apache.fop.render.AbstractRenderer.renderBlock
(AbstractRenderer.java:582)
at org.apache.fop.render.AbstractRenderer.renderBlocks
(AbstractRenderer.java:522)
at org.apache.fop.render.AbstractRenderer.renderFlow
(AbstractRenderer.java:427)
at org.apache.fop.render.AbstractRenderer.renderMainReference
(AbstractRenderer.java:406)
at org.apache.fop.render.AbstractRenderer.renderBodyRegion
(AbstractRenderer.java:340)
at org.apache.fop.render.afp.AFPRenderer.renderRegionViewport
(AFPRenderer.java:431)
at org.apache.fop.render.AbstractRenderer.renderPageAreas
(AbstractRenderer.java:258)
at org.apache.fop.render.afp.AFPRenderer.renderPage
(AFPRenderer.java:585)
at org.apache.fop.area.RenderPagesModel.addPage
(RenderPagesModel.java:120)
at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage
(PageSequenceLayoutManager.java:424)
at org.apache.fop.layoutmgr.PageSequenceLayoutManager.makeNewPage
(PageSequenceLayoutManager.java:377)
at org.apache.fop.layoutmgr.PageBreaker.handleBreakTrait
(PageBreaker.java:492)
at org.apache.fop.layoutmgr.PageBreaker.startPart(PageBreaker.java:398)
at org.apache.fop.layoutmgr.AbstractBreaker.addAreas
(AbstractBreaker.java:420)
at org.apache.fop.layoutmgr.AbstractBreaker.addAreas
(AbstractBreaker.java:370)
at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262)
at org.apache.fop.layoutmgr.AbstractBreaker.doLayout
(AbstractBreaker.java:345)
at org.apache.fop.layoutmgr.AbstractBreaker.doLayout
(AbstractBreaker.java:263)
at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout
(PageSequenceLayoutManager.java:144)
at org.apache.fop.area.AreaTreeHandler.endPageSequence
(AreaTreeHandler.java:233)
at org.apache.fop.fo.pagination.PageSequence.endOfNode
(PageSequence.java:145)
at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement
(FOTreeBuilder.java:378)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
at org.apache.xalan.transformer.TransformerIdentityImpl.endElement
(TransformerIdentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown 
Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement
(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher
.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.p

Re: Property Cache: Null Pointer Exception

[Chris Bowditch]

Andreas L Delmelle wrote:

On Nov 27, 2007, at 20:06, Andreas L Delmelle wrote:


Hi Andreas,



I tested on Apple JVM 1.4.2 and 1.5.0 on OS X 10.4. Both single-  and 
multi-threaded.

Heap remains stable here over hundreds of runs.
With multiple concurrent runs, my CPU usage easily reaches 180-190%  
(2 CPUs)




Just to confirm:
In the meantime, I have also run some tests with the same document on  
Windows XP SP 2 with different versions of the Sun JVM, running 2  
concurrent threads on a Centrino Dual Core.

Classes compiled with 1.4 compatibility.

I managed to reproduce the NPE on Java 1.4.2 and 1.5.0, at random  
intervals, always between 50 and 250 runs.


Thanks for your perservance. Glad its not me going mad :)



The version I just committed (http://svn.apache.org/viewvc? 
rev=600195&view=rev) resolves this problem by adding extra null  checks, 
and should now work on your end as well.


Yipee! You did it in the end. Well done.

I setup my tests and left it running for more than 24 hours in which 
time 150,000 documents were created without an error. The memory did go 
up over time, but not excessively and OOM was never thrown.


Thanks,

Chris

DO NOT REPLY [Bug 44023] - An empty fo:block artificially breaks a block-stacking constraint

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44023





--- Additional Comments From [EMAIL PROTECTED]  2007-12-05 02:45 ---
Created an attachment (id=21232)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21232&action=view)
FO file showing the problem


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 44023] New: - An empty fo:block artificially breaks a block-stacking constraint

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44023

   Summary: An empty fo:block artificially breaks a block-stacking
constraint
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


In the following fo snippet:
  Text before
  
  
Some text...
  

the two space-before should belong to the same sequence of space-specifiers and
be resolved to a single forcing space of 10pt, since the second block is empty
(no border, no padding, no content). In other words there is a block-stacking
constraint between the first and the third block.

FOP currently creates two separate sequences of space-specifiers; it stops at
the auxiliary box(w=0) generated by the empty block. I guess SpaceResolver
should check for that particular situation but it might be more complicated in
the general case.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: FOP and XML Graphics Commons Maven artifacts

[Max Berger]

Dear Fop-Devs,

actually, this could be a very fun experiment to see if my new fop
account is working. It should (theoretically) give me access to the
people.apache.org server mentioned in the howto. So yes, I am
volunteering to do it. (And provide a how-to afterwards)

There is no particular reason why I mixed the two compiled versions
other than pure coincidence. Would it be reasonable to upload the 1.4
artifacts only? Or should the 1.3 jars should also be uploaded (probly
with something like -1.3 in the name)?

Max


Am Mittwoch, den 05.12.2007, 13:31 +1100 schrieb Cameron McCormack:
> Hi Max.
> 
> Max Berger:
> > Jeremias,
> > Jason,
> > 
> > it looks like the only way to properly deploy maven bundles is to  
> > actually use maven. I have finally managed to install the bundles  
> > into a local directory for JEuclid, but the same process should apply  
> > for the apache rsync-repository [1].
> > 
> > The results can be seen at
> > http://jeuclid.sourceforge.net/m2/
> > 
> > in particular
> > http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/fop/
> > and
> > http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/xmlgraphics- 
> > commons/
> > 
> > you may just be able to take the files from there and copy then to  
> > the apache rsync-repository.
> > 
> > How this was done? If you use maven, you need to create setting for  
> > the repository in your .m2/settings.xml and then you can deploy using  
> > the maven-deploy-plugin. I have documented the whole process in [2].
> 
> It looks like you have taken the fop-0.94.jar from inside the
> fop-0.94-bin-jdk1.4.zip distribution, and the
> xmlgraphics-commons-1.2.jar from inside the
> xmlgraphics-commons-1.2-bin-jdk1.3.zip distribution.  Any reason for
> mixing the compiled versions?
> 
> That’s promising though that it’s as easy as taking the jar as already
> produced by the build script and slapping a .pom file together with it.
> 
> Anybody here against me publishing the artifacts (after Max’s answer to
> my question above)?
> 
> Thanks,
> 
> Cameron
> 


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil