Greetings,
Apologies for the long delay (and the top-post). I've made slow, but
steady progress building a Fedora gwt package (thanks to many others
in the Fedora community who understand Java and Java packaging).
As a recap, the Fedora packaging policy prohibits bundling software in
RPM's. As a result, I have been adjusting the gwt RPM spec file to
replace all bundled .jar files with symlinks to the installed system
versions prior to the build. This has been going well, and I'm now
attempting to build gwt from source using the symlinked jars.
Presently, building gwt from source fails due to several jdt issues (see below).
compiler.standalone:
[mkdir] Created dir: /builddir/build/BUILD/gwt-2.0.3/build/out/dev/bin
[gwt.javac] Compiling 5 source files to
/builddir/build/BUILD/gwt-2.0.3/build/out/dev/bin
[gwt.javac] Compiling 673 source files to
/builddir/build/BUILD/gwt-2.0.3/build/out/dev/bin
[gwt.javac]
/builddir/build/BUILD/gwt-2.0.3/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java:312:
warningThreshold has protected access in
org.eclipse.jdt.internal.compiler.impl.CompilerOptions
[gwt.javac] options.warningThreshold = 0;
[gwt.javac] ^
[gwt.javac]
/builddir/build/BUILD/gwt-2.0.3/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java:312:
incompatible types
[gwt.javac] found : int
[gwt.javac] required: org.eclipse.jdt.internal.compiler.impl.IrritantSet
[gwt.javac] options.warningThreshold = 0;
[gwt.javac] ^
[gwt.javac]
/builddir/build/BUILD/gwt-2.0.3/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java:343:
incompatible types
[gwt.javac] found : org.eclipse.jdt.internal.compiler.lookup.TypeBinding
[gwt.javac] required: org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding
[gwt.javac] type = BinaryTypeBinding.resolveType(type,
lookupEnvironment, true);
[gwt.javac] ^
[gwt.javac] Note: Some input files use or override a deprecated API.
[gwt.javac] Note: Recompile with -Xlint:deprecation for details.
[gwt.javac] Note: Some input files use unchecked or unsafe operations.
[gwt.javac] Note: Recompile with -Xlint:unchecked for details.
[gwt.javac] 3 errors
Based on the above failures, I could use some guidance/clarification.
1) I see use of org.eclipse.jdt.internal.*, my understanding is that
these internal objects are not guaranteed to be available in future
versions of jdt. I gather there are missing API's which required
using the internal objects? Are there any plans to remove use of
internal jdt objects?
2) Fedora currently ships jdt-3.6. Are there plans to update gwt to
support jdt-3.6?
Many thanks!
James
On Fri, Feb 5, 2010 at 11:41 AM, James Laska <[email protected]> wrote:
> On Fri, Feb 5, 2010 at 10:23 AM, John Tamplin <[email protected]> wrote:
>> On Fri, Feb 5, 2010 at 10:05 AM, James Laska <[email protected]> wrote:
>>>
>>> You noted that the modified libraries are documented, I gather this is
>>> in the README file in the same directory? Looking in 'tools/lib' for
>>> README files I see the following special handling instructions:
>>>
>>> * gwt-2.0.0/tools/lib/protobuf/protobuf-2.2.0/README
>>> * gwt-2.0.0/tools/lib/htmlunit/README
>>>
>>> Are there others to consider?
>>>
>>> Have the local library modifications been sent/accepted in the upstream
>>> project?
>>
>> I know they have in the case of HtmlUnit, though I have no idea if they have
>> been accepted. Amit Manjhi ([email protected]) would be the one to talk
>> to about HtmlUnit changes. I don't know about others.
>>
>>>
>>> Oh good to know. This shouldn't be too much trouble. I can have GWT
>>> %buildrequire a specific version of a library. If newer versions of
>>> that library are available, I should be able to provide the older
>>> library as a compatibility.
>>>
>>> Perhaps the same question as earler, is there a way to tell when GWT
>>> requires a *specific* library version? Or should I default to using
>>> the latest, and see where the build fails?
>>
>> Hopefully our tests are sufficient that an incompatible version would fail
>> tests, so I would try the newest version first.
>
> Great, I'll proceed that way first.
>
>> The build files would likely need some hacking -- right now, it expects to
>> find everything in tools under ../tools or $(GWT_TOOLS), not individually
>> located. You could have the spec file apply a patch against it, or if the
>> changes could be done such that the default behavior worked as it does now
>> but supplying -D flags to ant overrode the locations I think we could make
>> those changes directly in GWT.
>
> The strategy I've been following, as recommended by other Fedora java
> packaging gurus, is to add logic during the %prep step in the spec
> file that removes bundled JAR files and replaces them with symlinks to
> the system versions. This seems to be progressing well so far, and
> requires no downstream patching of GWT.
>
> For more details ...
> http://fedoraproject.org/wiki/Packaging:Java#Pre-built_JAR_files_.2F_Other_bundled_software
>
> Thanks,
> James
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
