I am using FOP (version 2.3.0). When I try to compile the Spanish patterns I downloaded from OFFO running ant jar-hyphenation, I get next error:
compile-hyphenation:
[java] Processing /home/pf/MEGA/prg/java/fop/trunk/fop/hyph/es.xml
[java] Exception in thread "main" java.lang.StackOverflowError
[java] at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:180)
[java] at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
And the last line of output is repeated a zillion of times.
Other patterns are compiled without problems, but when I include the Spanish ones, the build process crashes. Just to be sure the file was not corrupted, I downloaded a more recent version of es.xml but ant is still crashing.
On https://issues.apache.org/jira/browse/FOP-2569, I found the solution:
The recursion at
org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) is
correct, but it requires more stack size. Fix:
>diff build.xml~ build.xml
184c184
< <property name="hyph.stacksize" value="512k"/>
—
> <property name="hyph.stacksize" value="1M"/>
The build process just needed a bigger stack. The build.xml file to be modified resides in the parent directory of the hyph directory. I increased the stack and was just able to compile everything.
Related
Attempting to sbt compile a branch of my project ENSIME (experiment if you're interested) under Java 6 is giving a bizarre compiler warning:
[info] Compiling 48 Scala sources to /home/fommil/Projects/ensime-server/target/scala-2.11/classes...
[error] Class java.lang.invoke.MethodHandle not found - continuing with a stub.
[error] two errors found
[error] (compile:compile) Compilation failed
[error] Total time: 18 s, completed 03-Sep-2014 22:57:44
It works under Java 7.
Calling last reveals nothing more than the classpath of the compile (this would be equivalent to setting --debug level).
I've removed all the plugins from the project, and the problem still shows.
If I remove all my code - leaving just the build system and dependencies - with some stub scala entry points then there is no problem.
However, I can't exactly bisect my source code file because then it doesn't compile.
When the code is compiled, a grep (including binaries) of MethodHandle doesn't give any hits (although there is a jdk8 file in the tests resources, it is not relevant because the problem appears if it is removed).
It is only one (big) patch that has caused the problem (the previous commit compiles ok).
How can I debug this further in sbt? it doesn't want to give any more info
is this a known problem, or can anyone make an informed guess what is going on?
It turns out that this was caused by pulling in Lucene, which requires Java 7.
A bit of an epic message fail from sbt: there doesn't appear to be any way to get it to output anything sensible.
I'm having this exception with some stubs generateds by Axis2:
"The type org.apache.axiom.om.OMElement cannot be resolved. It is
indirectly referenced from required .class files"
I've been reading many posts, and trying to find a solution. What I've found so far is to add the apache tomcat 5.5 library to the build path. It removed the error in the java file, but then, when I to execute any java program inside the project, I got this error:
'Launching myApp' has encountered a problem Exception occurred
executing command line. Cannot run program "C:\Program
Files\Java\jdk1.5.0_22\bin\javaw.exe" (in directory
"D:\Digicel\workspace\Digicel\myClassSample"): CreateProcess error=87,
The parameter is incorrect
then if I remove the apache tomcat library from the build path, I can run the other java programs, but not the one mentioned initially.
Any thoughts about it?
Okay, I've found the cause of the problem with the help of a friend :)
The thing is that Eclipse is aware that one of my dependencies, depends of another library, and Eclipse is checking for it when it tries to build the code.
So, what I've done is try to check which jar file contains this library: " org.apache.axiom.om.OMElement".
I've googled it and found that it is "axiom-api-1.2.10.jar" and finally my file compiled with 0 errors.
He also explained to me that my original solution of adding the apache tomcat server library is adding all the jars that cames with apache tomcat (which is a big list), and probably there may have been a version conflict with my current list of added jars.
So, the fix was to find the appropriate jar and add it to the project.
This error can also occur when a indirect dependency has a corrupt jar file. This may be caused by problems at the public maven repository.
If this is the case removing the local maven repository to download fresh jar files will fix your problem:
rm -Rf ~/.m2/repository/{enter/path/to/broken/stuff}
Goto Maven >Update Maven project>checkmark the Force update >Then Run
..That error Will gone....
I've been battling with this bug for 3 hours.
I have checked the build path and classpath and they are the same, this is quite a large webapp, running on Tomcat & Geronimo, it has a build file for each component & then one main once that binds them all together, but I've gone over the ant build files & compared them to others in working components that rely on 3rd party libraries and I don't see an differences.
<fileset dir="${home.dir}/component/lib" includes="*.jar"/>
It all seems to be in order.
If I call this method from a JUnit test, run from within eclipse, is passes no problem, if I run the server I get this exception.
Also I have two other libraries that this component uses & I just added it as a user library in eclipse & in the components lib referenced in the build.xml and it works without a problem. I've tried moving jars around resorting to trial and error when logic seemed to fail me & no luck yet.
To make matters even stranger, I remember now, I had this issue with some code I wrote myself that wasn't even in a library. java.lang.NoSuchMethodError, since eclipse does occasionally do random things I just changed the method name and did a clean & it worked.
I've tried cleaning and rebuilding the whole web app several times with no change.
I'd like some advice about how to get closer to the problem so I can try find the bug, how does one debug classpath issues is there anywhere else the classpath is defened besides the build file?
Any suggestions on how to pin point the problem would be appreciated.
Exception: java.lang.NoSuchMethodError
[java] Message: com.google.common.collect.ImmutableMultimap.of()Lcom/google/common/collect/ImmutableMultimap;
[java] ---- stack trace ---------------------------------------------------------------
[java] java.lang.NoSuchMethodError: com.google.common.collect.ImmutableMultimap.of()Lcom/google/common/collect/ImmutableMultimap;
[java] com.google.gdata.util.common.net.UriParameterMap.<clinit>(UriParameterMap.java:78)
[java] com.google.gdata.client.Service.computeQueryMap(Service.java:2190)
[java] com.google.gdata.client.Service.access$000(Service.java:94)
[java] com.google.gdata.client.Service$ClientStreamProperties.<init>(Service.java:1839)
[java] com.google.gdata.client.Service$ClientOutputProperties.<init>(Service.java:1986)
[java] com.google.gdata.client.Service.writeRequestData(Service.java:2029)
[java] com.google.gdata.client.Service.insert(Service.java:1408)
[java] com.google.gdata.client.GoogleService.insert(GoogleService.java:599)
[java] com.google.gdata.client.appsforyourdomain.AppsForYourDomainService.insert(AppsForYourDomainService.java:100)
[java] za.co.venturenet.api.googleapps.GoogleAppsServices.createUser(GoogleAppsServices.java:437)
[java] za.co.venturenet.api.googleapps.GoogleAppsServices.createUser(GoogleAppsServices.java:336)
[java] za.co.venturenet.api.googleapps.GoogleAppsFacade.createNewVenturenetUser(GoogleAppsFacade.java:158)
NoSuchMethodError means that the class was found, but a referenced method in that class is not found. The most typical cause of this is accessing a wrong version of class/library. Since your problem only manifests when running on the server, I would look at your server's configuration. Perhaps a different version this library is wired into server's system classloader (which would be ahead of whatever is bundled in your webapp).
>since eclipse does occasionally do random things I just changed the method name and did a clean & it worked.
I've had the same error, and have tried the same solution: change method name, or add an empty line to the java file, rebuild. It usually works one time. But upon second server start, the NoSuchMethodError returns for the same method identifier.
My eclipse environment builds a "target/classes" folder, which gets a copy of the web-inf classes.
Removal of that folder seems to have cured my problems with random NoSuchMethodError, which were probably caused by inability to resolve which instance to load.
Your mileage may vary.
Our Eclipse RCP application has a headless PDE Build setup from Eclipse 3.2 that's been working for years. We recently updated both the instance of Eclipse we use to do the headless PDE Build and our target platform to 3.6 (principally to be able to create hyperlinks "into" our application), and the headless PDE Build now fails with:
...
[java] generateFeature:
[java]
[java] fetch:
[java]
[java] generateFeature:
[java]
[java] BUILD FAILED
[java] C:\Projects\[...]\PDE Build\plugins\org.eclipse.pde.build_3.6.2.R36x_20110203\scripts\productBuild\productBuild.xml:39: The following error occurred while executing this line:
[java] C:\Projects\[...]\PDE Build\plugins\org.eclipse.pde.build_3.6.2.R36x_20110203\scripts\productBuild\productBuild.xml:69: java.lang.NullPointerException
[java]
[java] Total time: 0 seconds
[java] An error has occurred. See the log file
[java] C:\Projects\[...a separate area dedicated to making builds...]\workspace\.metadata\.log.
The relevant part of the stack trace in the log file would seem to be:
java.lang.NullPointerException
at org.eclipse.pde.internal.build.BundleHelper.getProvisioningAgent(BundleHelper.java:104)
at org.eclipse.pde.internal.build.AbstractScriptGenerator.getAssociatedRepositories(AbstractScriptGenerator.java:625)
at org.eclipse.pde.internal.build.AbstractScriptGenerator.getSite(AbstractScriptGenerator.java:332)
at org.eclipse.pde.internal.build.FeatureGenerator.createFeature(FeatureGenerator.java:339)
at org.eclipse.pde.internal.build.FeatureGenerator.generate(FeatureGenerator.java:161)
at org.eclipse.pde.internal.build.tasks.FeatureGeneratorTask.run(FeatureGeneratorTask.java:54)
at org.eclipse.pde.internal.build.tasks.FeatureGeneratorTask.execute(FeatureGeneratorTask.java:36)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
...
The PDE Build Eclipse instance was created according to this process. We tried to produce as clean a target platform as we could, but (in the absence of clear instructions or early success) resorted to unzipping eclipse-rcp-helios-SR2-win32.zip into a directory then unzipping eclipse-3.6.2-delta-pack.zip on top of it.
How can we restore our PDE Build process to working order?
Perhaps our build.properties is too old (from 3.2's template, probably), or perhaps we constructed our target platform improperly, but thanks to a blog post by Kai Tödter, one of the many potential remedies we tried in desperation was (according to Kai's "Trick 1") deleting everything out of our target platform directory except the plugins and features directories. That at least stopped PDE Build mysteriously choking, and error messages then guided us to the rest of the fixups we had to do. (In our case, those fixups consisted almost entirely of updating a secondary (tests) product definition's list of required plugins by clicking "Add Required Plug-ins" and removing a reference to the org.eclipse.ant.optional.junit4 fragment.)
Indeed, it appears that merely deleting either one of the following lines from the target platform's configuration/config.ini is sufficient to unstick PDE Build:
eclipse.p2.profile=epp.package.rcp
(or)
eclipse.p2.data.area=#config.dir/../p2
...though we have preferred to just strip out everything but plugins and fragments lest there be other magical beings hiding in the target platform that could potentially trip us up.
(We don't understand why deleting one of those lines would placate PDE Build . . . but we're back in business.)
I've installed the plugin from this article by Peter
http://www.cacoethes.co.uk/blog/groovyandgrails/the-command-pattern-w....
While compile time its not able to find the module file which is
present in the plugin. Since there are no jar files for the module,
can you tell me what I'm missing here..
The stack trace is as follows:
[java] Loading inherited module 'grails.plugins.gwt.Grails'
[java] [ERROR] Unable to find 'grails/plugins/gwt/Grails.gwt.xml' on your classpath; could be a typo, or maybe you forgot to incl
ude a classpath entry for source?
[java] [ERROR] Line 12: Unexpected exception while processing element 'inherits'
[java] com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
Hey Satya, I've had similar problems with classpath errors working with other grails plugins.
I've found sometimes it's necessary to manually copy artifacts from (user-home directory)/.grails/(grails-version)/plugins/(plugin-name) into the lib/ directory inside my grails project.
In this case, you might try copying src/gwt (from the grails-gwt-0.5-SNAPSHOT.zip) into lib/gwt? or maybe try to copy it to match grails/plugins/gwt/Grails.gwt.xml?