Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-dev] alpha blog post and release notes
Sorry for quick reply - setting up a target platform file for SDK would be good.

After following your instructions I think I will make a video on how to migrate, and include migrate instructions in the release notes. 

I am still not sure how to swap between JAI from boot class path and JAI plugin. 

--
Jody Garnett

On Tuesday, 10 December 2013 at 7:18 am, Frank Gasdorf wrote:

I was so deeply involved creating the release that I didn't realized something could have changed for the sdk procedure.

Let me explain:

for uDig development itself we are going through the following steps:
  • download an Eclipse IDE (preferred with EMF Modeling tools)
  • download an JRE (from Refractions with JAI/Image IO and optionally with gdal natives - not available for mac osc)
  • clone the repository
  • import target project from targets folder
  • open the target file (at the time of writing ./targets/indigo/udig-indigo-target.target)
  • set as target platfrom
  • import required plugins/features from git clone
  • start developing
What do you think about doing something similar for the udig-sdk than suggesting every body else to do it in an other way

And here IMHO the procedure should look like:
  • download preferred Eclipse IDE (my one is 4.3 btw.)
  • download JRE (w/o GDAL and JAI/Image IO)
  • open a new eclipse workspace
  • setting up a new target environment:
    • add udig-sdk update site (suggestion : http://udig.refractions.net/files/update/latest/udig-sdk)
    • describing a way how to add 3rd-party dependencies:
      • eclipse (emf, gef, ...)
      • eclipse babel (i18n - if necessary)
      • eclipse babel (logging, testing, etc.)
      • refractions JAI/Image IO update site
--> we would end up in a file that content would look like our current target-definition file mentioned above (except the udig-sdk url), therefor I would like suggest
  • to download the target definition file (we could attach it to udig devel docs as a file referenced in the SDK Quickstart guide)
  • create a simple workspace project and add this target file
  • modify it and add the prefered udig-sdk update site (see above)
  • set this as new target platform
  • if the potential developer need sources for the referenced update-sites it would be pretty easy to do so: set the property includeSource like this:

    includeSource="true"

Does this make sense to you? Cool thing is, that the developer doesn't have to collect several ZIPS from difference sources (eclipse, drop-ins, udig-sdk, jre, etc), can still use its exiting preconfigured IDE, and Eclipse target resolution from target definition file does the rest ..

At the moment the udig-sdk feature has some unnecessary dependencies to eclipse source features (rcp, emf, xsd, help).

For Eclipse feature definition there is an other cool trick to resolve dependencies: define dependencies to features to make sure the version fit to required environment. For example, out bundles depending on a special version of emf, otherwise it would fail to build against eclipse core. Its possible to define the matching algorithm in feature.xml requires section (fits for the current target platform which is indigo):

   <requires>

      <import feature="org.eclipse.emf" version="2.7.0" match="equivalent"/>

   </requires>

For more details about match levels (depending from the major/minor/service version) are described right here : Feature Manifest


All in all it sounds like many many changes but these are quite a few to solve the udig-sdk quickstart. But before we change anything I would like hear what you think about. And for sure I can create a pull request that everybody can check it out, read updated docs and see whether it fits your needs

Cheers,

Frank


2013/12/8 Jody Garnett <jody.garnett@xxxxxxxxx>
Adding my IDE pug ins to the uDig 1.4.0 SDK allowed me to run. It being mac it installed JAI stuff into my home directory the first time it ran.
So I am testing correctly, no to figure out what the 2.0.0.alpha is missing ...

Jody Garnett


On Sun, Dec 8, 2013 at 5:48 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
Running this same test with uDig 1.4.0 SDK ...
- The target platform configuration and plugin validation went smoothly
- The application refuses to start - with a different error (java.lang.NoClassDefFoundError: org/eclipse/swt/SWTError).

I am afraid I am not doing something right when testing the SDK

Andrea have you previously used the 1.4.0 SDK?

Jody Garnett


On Sun, Dec 8, 2013 at 5:26 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
Afternoon Andrea:

I am trying to catch up with your testing, and see if I can fill in the gaps from your email.

DOWNLOAD

Environment: OSX 10.9, JDK 1.6.0_51-b11_457
Verdict: works for me

- started with a fresh udig project folder (since I would not expect the previous one to load)
- release notes html seemed okay
- application starts
- short cuts from welcome page to online help work correctly
- application shows both shape files and raster data (tested with data_1_3 download)
- application about shows JAI plugin included



SDK

Environment: IDE Elipse 3.7.2, Platform OSX 10.9, JDK 1.6.0_51-b11-457, set up from a completely new workspace with no previous configuration
Verdict: does not work even with extensive workarounds and experimentation

0. Set up with a completely new workspace, no previous configuration

- Set up

1. Setting up target platform

This is an "includes everything" target platform: while I expect it to include SWT I was unclear if it was going to include JAI and ImageIO.
I could not quite remember how to set this up, previously I made a new target platform and added the directory of the current eclipse and the directory of the target platform.

a) Setting Target Platform using "Features" - scans a directory for features (have not used this before)
- Mostly worked, but "Problems occurred getting the plug-ins in this container: required plug-in could not be found: org.eclipse.swt.cocoa.macosx.x86_64.source

b) Setting Target Platform using Directory - this one scans for plugins in the provided directory
- Detected 626 plugins available


2. Testing sample application

- Performed usual test, selected org.locationtech.udig from the plug-ins view and imported as source plugin
- The result built without error
- open udig.product and click "Launch an Eclipse Application" failed to start ...

java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).

at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)


This is the usual invalid dependency exception ... the only other exceptions are:

!ENTRY org.eclipse.core.runtime 4 0 2013-12-08 17:10:37.590

!MESSAGE FrameworkEvent ERROR

!STACK 0

org.osgi.framework.BundleException: The bundle "org.eclipse.core.runtime_3.7.0.v20110110 [2]" could not be resolved. Reason: Missing Constraint: Require-Bundle: org.eclipse.core.contenttype; bundle-version="[3.3.0,4.0.0)"

at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)

at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)

at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)

at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)

at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)

at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)

at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)


!ENTRY org.eclipse.equinox.p2.reconciler.dropins 4 0 2013-12-08 17:10:37.602

!MESSAGE FrameworkEvent ERROR

!STACK 0

org.osgi.framework.BundleException: The bundle "org.eclipse.equinox.p2.reconciler.dropins_1.1.100.v20110815-1419 [283]" could not be resolved. Reason: Missing Constraint: Require-Bundle: org.eclipse.equinox.p2.touchpoint.eclipse; bundle-version="1.0.0"

at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)

at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)

at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)

at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)

at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)

at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)

at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)



So hunting through the Validate Plugins list I can see we are missing a of dependencies. I am used to this list providing missing plugin dependencies. This time it was all "Missing Constraint Import-Package:"

- com.ibm.icu.text
- com.ibm.icu.util
- javax.media.jai
- javax.media.jai.iterator
- javax.media.jai.operator
- javax.media.jai.*
- javax.servlet.http
- javax.servlet.jsp
- javax.servlet.*
- and a great deal more

So our SDK release did not include enough to be a stand alone target platform.

Changing the target platform to include the hosting IDE did not help, it then showed duplicates for any of the translation plugins, and anything requiring JAI still did not load.



Jody Garnett


On Sat, Dec 7, 2013 at 12:22 AM, andrea antonello <andrea.antonello@xxxxxxxxx> wrote:
> I am confused Andrea. It should be very much usable - if not we make it
> again.
>
> If is not usable it should not be on the website.

I tried to both build it and donwload it and in both cases when I
started it up, it did definitely not look like uDig.

Am I the only one experiencing this? I should not have conflicting
workspaces but you never know.

Cheers,
Andrea



_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
https://locationtech.org/mailman/listinfo/udig-dev



Back to the top