Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [udig-devel] Headless build on trunk

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?

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.

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.

<rant>

Anyway, I can't say I like the idea of an application plugin trying to install stuff into my JVM, which is what the jai plugin tries to do, and this should definitely not be part of the standard udig-feature or udig_sdk-feature.

I haven't tried this but supposedly the best way to handle JVM add-ons in OSGi land is to put the required JARs into a separate bundle fragment, specifying the Fragment-Host: system.bundle.

The next thing which is an unnecessary complication in my view is the use of Scala for the headless build.

I would say that the build process is complex enough with Ant, Eclipse PDE and Maven, and I don't really see the point in adding yet another tool or even language in this case ad hoc. (And of course things did not work at all at first and I found myself trying to understand Scala sources to narrow down the problem, caused by an incorrect setting in my 
shared.properties.)

I'm using Ant+Eclipse PDE for headless builds of my own Eclipse-based projects, and from that experience I think it should be enough to have an Ant script which first calls the refresh script for our dear friend net.refractions.udig.libs and then calls the PDE Ant runner to build the udig_sdk-feature.

(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...)

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.

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?

</rant>


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. 

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.

Regards,
Harald

> -----Ursprüngliche Nachricht-----
> Von: udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx 
> [mailto:udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] Im Auftrag 
> von Jody Garnett
> Gesendet: Dienstag, 7. Oktober 2008 01:40
> An: User-friendly Desktop Internet GIS
> Betreff: Re: [udig-devel] Headless build on trunk
> 
> Wellmann, Harald wrote:
> > Does it make sense at all to use a 3.2.0 fragment for a 3.4 build?
> >
> > I removed all that extra stuff from the dropins folder. 
> After that, my interactive uDig still works (or I should say, 
> the subset of uDig that my own plugins depend on), so I'm not 
> really sure what this extras archive is needed for...
> >   
> The "nls" stuff we have was prepaired by moovida some 
> releases ago; this is a repackaging of an earlier eclipse 
> translation (since eclipse.org has not released anything for 
> a while). I am not sure if it is needed (or if we could 
> switch to the bable project?).
> > Anyway, it is probably a good idea to use a separate 
> Eclipse installation for the uDig headless build, to avoid 
> any interference with other plugins.
> >   
> Indeed.
> > But then the question remains: Should I simply take an 
> Eclipse 3.4 SDK download? Do I need to install additional 
> features or plugins?
> >   
> I am not sure; you are blazing a new trail here - please keep 
> sending emails to the list. Does using an Eclipse 3.4 SDK 
> actually work for you? 
> Are you doing a successful headless build now?
> 
> _______________________________________________
> 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.
*******************************************


Back to the top