[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: AW: [udig-devel] Headless build on trunk
|
Thanks for the update harald
First point is that the net.refractions.udig.jai shouldn't be part of
the features because it is only for projects that do not ship a JRE
with their product. uDig doesn't need this plugin so it should be
removed from the features. I probably added it as a reflex.
Second point is that scala does not do the libs syncing. Part of what
scala does is trigger an ant build. Checkout build.xml for the rough
ant script. Scala also builds the packaged application, which is not
necessary for the sdk. Most important for the SDK scala does some
autoconfiguration of the properties files so that you don't have to
keep updating the plugin versions in the properties file used by the
ant script. This is handy because otherwise you have to change the
properties file everytime you use a different version of eclipse and
in a shared build like this is can be a nightmare.
As for autobuild I can't setup a server that does a build every commit
but I can probably set up a nightly build system eventually. So we
will at least know each day that the build was broken. Possibly even
a bi-daily build.
Jesse
On 26-Oct-08, at 8:30 PM, Wellmann, Harald wrote:
Headless builds are working now (for me...) after a couple of
changes, tested both on win32 and linux-gtk-x86_64.
1) Get an Eclipse target to build against.
I started with an Eclipse 3.4.1 SDK, added the Delta Pack and then
used the Update Manager to install EMF, GEF and XSD, including the
corresponding SDKs.
Actually, it took me a while to find out it was the missing delta
pack which caused the following mysterious error message in the
final assembly:
[java] d:\temp\udig-sdk\builds
\1.2
\assemble
.org.eclipse.pde.build.container.feature.win32.win32.x86.xml:341:
java.io.EOFException
2) Follow the instructions in extras/headlessbuild/README.
The build process itself is ok, but it is currently broken due to a
number of problems in the uDig sources and config files and due to
what looks like a bug in the Eclipse PDE internals.
There were a couple of references to non-existing source directories
in some build.properties files which caused the build to fail.
A not-so-trivial issue was an incorrect feature-to-plugin
dependency. Plugin net.refractions.udig.catalog.wms depends on
net.refractions.udig.project.
Feature net.refractions.udig_platform-feature contains
net.refractions.udig.catalog.wms but does not contain or reference
net.refractions.udig.project, which cause the platform build to fail.
I solved this by moving n.r.u.catalog.wms from the platform feature
to the application feature, just as a workaround, but I'd like to
hear a guru's opinion on that, maybe it's better to move
n.r.u.project down to platform or to eliminate the use of
n.r.u.project in n.r.u.catalog.wms.
The suspected PDE bug occurs with net.refractions.udig.jai: For some
reason, the compiler complains about a missing package
org.eclipse.swt.widgets.
n.r.udig.jai is a fragment hosted by n.r.udig.core which reexports
its dependency on org.eclipse.swt, so the SWT stuff should be
visible to n.r.udig.jai. The point is that the org.swt.widgets
package is contained in a fragment, and the build.xml generated by
PDE for n.r.udig.jai references the bundle org.eclipse.swt, but not
the fragment org.eclipse.swt.win32.win32.x86.
The only workaround I could find was adding
extra.. = C:/eclipse/3.4.1/plugins/
org.eclipse.swt.win32.win32.x86_3.4.1.v3449c.jar
to the build.properties of n.r.u.jai. Yes, that's ugly! (Even when
you replace the hardcoded Eclipse location by ${base}).
That's about all. I can provide more details, send a patchfile or
commit the changes myself, if I get commit access to the uDig
repository.
As an aside, I still do not really understand what all that Scala
stuff does on top of the PDE builds, but I can see it is doing
things I would like to avoid, like resyncing the n.r.udig.libs
dependencies every time you run the build. This is rather annoying
when you are trying to locate a problem in the build - an option to
suppress that step would be helpful.
For simply building a udig or udig.sdk product, the following also
works:
- Set up your Eclipse target as described above
- Sync the trunk
- Run refresh.xml in n.r.u.libs once to get the external libraries.
- Write a simple Ant file as explained in the Eclipse PDE help
invoking the Eclipse antRunner with productBuild.xml.
Regards,
Harald
-----Ursprüngliche Nachricht-----
Von: udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx im Auftrag von
Wellmann, Harald
Gesendet: Do 23.10.2008 19:33
An: User-friendly Desktop Internet GIS
Cc:
Betreff: AW:[udig-devel] Headless build on trunk
Thanks for all the feedback on this issue and sorry for being out of
touch; I was busy with my own project (also spending some time on
batch builds....).
I hope I'll be able to catch up with the uDig trunk some time next
week, and once I've got something working, I'll be happy to share
any results.
One more thing: Rather than spending time on creating SDKs manually
once in a while, it would be great to have a Continuous Integration
server to do the job. We have been using Hudson in our team for a
couple of months now, and it's really useful to get your fingers
slapped immediately when you break a build or forget to commit a new
source file...
And it also provides URLs like http://hudson.udig/jobs/udig/latestStableBuild
for grabbing the results of a build.
Does anybody have a webserver with some CPU time to spare? If so,
I'm offering to spend some time on setting up Hudson for uDig.
(I'm sorry I cannnot offer any webspace myself - corporate IT
policies, as always.... As things are, I could not even set up
Hudson for uDig in our company network. I cannot access the uDig and
geotools repositories, as long as they use http only and not https,
since our web proxy blocks the PROPFIND requests used by Subversion.)
Cheers,
Harald
-----Ursprüngliche Nachricht-----
Von: udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx im Auftrag von Jody
Garnett
Gesendet: Do 09.10.2008 18:46
An: User-friendly Desktop Internet GIS
Cc:
Betreff: Re: [udig-devel] Headless build on trunk
Ugo Taddei wrote:
Thanks a lot!
It's not that don't have time to build, I honestly don't think I
can actually do that. I'm new to plugin programming and it's all
still a lot of magic for me.
Fair enough; I also do not understand the headless build (which
would be
required to automatically build and SDK every night).
Besides, an SDK from you guys makes it a lot easier for people to
start with udig.
It is true; but we only get to make an SDK when we have time/money.
Sad
truth of open source development .. on the bright side we do have the
source code available; and the instructions for building the source
code
are working out well.
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
*******************************************
innovative systems GmbH Navigation-Multimedia
Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot
Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-
mail. Any unauthorized copying, disclosure or distribution of the
contents in this e-mail is strictly forbidden.
*******************************************
<winmail.dat>_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel