[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [udig-devel] Headless build on trunk
|
Wellmann, Harald wrote:
Hmm, I'm a bit worried about your remark about "blazing a new trail with Eclipse 3.4"...
I was simply following the instructions in
http://udig.refractions.net/confluence/display/ADMIN/03+Eclipse+for+RCP+Developers
to set up my development environment for udig 1.2 a.k.a. trunk.
So I was assuming that everyone is using Eclipse 3.4 for the trunk - are you still on 3.3?
We are all using Eclipse 3.4 - what we are not doing is a headless build.
I took the latest and greatest Eclipse 3.4.1 and installed EMF and GMF including Source on top of it which seem to be required by the uDig source features.
We have not tried Eclipse 3.4.1 yet; indeed I asked if the community was
interested in that last week. If you can report back success it will
help us all make our decision.
I got stuck with the net.refractions.udig.jai fragment, both in the headless and the interactive builds. This fragment seems to be missing the SWT dependencies.
As a quick and dirty solution to get a uDig/Eclipse target for my own development of uDig-addons, I deleted the jai plug-in from the uDig feature and did an "Export deployable features and plugins" from the Eclipse workbench. That works for me on 3.4.1 for the time being, but I'm not really happy with that.
I am not sure about the net.refractions.udig.jai fragment; my
understanding is that it is new (and only of interest to the mac osx
platform).
(Personally, I think this Ant/Eclipse PDE stuff is also rather ugly and I would prefer to do the job with Maven and BND, but I haven't figured out the details yet. At least, even it is ugly, it does work and it is fairly easy to set up...)
You are the second developer to recommend BND to me; I am going to
assemble a short list of build technologies - but until there is a clear
winner it is hard to recommend any change.
My understanding is that Jesse enjoyed learning Scala - and was kind
enough to commit his work. Previously we have had groovy; and straight
ant scripts (with custom ant tasks).
And in any case, assuming you get a one-button headless build to work, the results will not be reproducible even if you synchronize to a given uDig trunk revision, because the libs refresh script pulls in SNAPSHOT version of Geotools, which may change at any time.
That is why for a formal tag; we tag geotools and uDig in order to make
it reproducible - you can see that Emily made just such a tag this week
for a customer.
By "reproducible" I mean that I get binary compatible results if I run the build with the same configuration at any other time on any other machine, which is simply a requirement for developing anything on top of uDig, unless you are happy working against a moving target, which I am not.
What is preventing Geotools to provide labelled milestone or release candidate builds and uDig to use these instead of floating SNAPSHOTs?
Nothing; infact we do so as projects request milestone builds. Currently
the uDig project is mostly driving the 2.6 schedule (we are finding and
fixing problems daily).
Coming back to the extras-3.4.0.zip, from your remarks I gather that this archive is in a somewhat unclear state. Localized builds a nice feature, but they tend to be incomplete or out of date, so I'm happy with uDig in English.
I have not made an extras-3.4.1.zip yet (I am waiting on enough
interested developers to make that move). The eclipse.org story about
translations has been in flux; it seems as if it has settled down with
"the babel project" being the way forward. I am not content with that
solution as it has translations for much more of eclipse then we
currently use.
All I can see in the extras is either related to localization or to cross-platform builds, which are two separate issues, and the average user may not be interested in either of them, so I would propose to update the documentation to explain that this installation step is optional, and maybe to split the extras in two or more parts with a single purpose each, and either update the localization stuff from 3.2 or simply delete it until someone who knows what they are doing can take care of correct localization for 3.4.
The extras is intended to get people through the complete udig
development experience; including releasing a custom application. As
such both these concerns are required?
We can ask moovida to update the localization stuff for 3.4.
Jody
