Sunday, July 28, 2013

Build Instructions for locationtech_ip branch



Update: the original post was getting to big, so I have taken these build instructions into their own post. This will also serve as build instructions until we migrate our developers guide.

Command Line build using Maven

0. Here is the branch, check it out, or fork as you see fit.

https://github.com/uDig/udig-platform/tree/locationtech_ip

1. Download stuff (using maven and wget)

mvn clean install -f pom-libs.xml

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8:05.291s

2) Build Online Help

cd docs
ant help-deploy

help-deploy:
     [copy] Copying 1078 files to /Volumes/Fiore/jody/java/udig/jive/plugins/net.refractions.udig.help/EN

BUILD SUCCESSFUL
Total time: 13 seconds


3) Tycho Build

mvn clean install -Pproduct,sdk

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12:44.827s

4) Packaging, branding and installers

cd deploy
./all.sh

..snip..
Releasing linux64
Creating ./build/linux64/udig
Building ./build/udig-1.5-SNAPSHOT.linux.gtk.x86_64.zip ...
Extracting ./../features/net.refractions.udig-product/target/products/net.refractions.udig-product-linux.gtk.x86_64.zip
Preparing ./build/linux64 with ./jre/jre1.6.0_25.lin64_gdal_ecw
Looking for ./jre/jre1.6.0_25.lin64_gdal_ecw.tar.gz
Extracting ./jre/jre1.6.0_25.lin64_gdal_ecw.tar.gz
Preparing ./build/linux64 with start up scripts and html files
Assemble ./build/udig-1.5-SNAPSHOT.linux.gtk.x86_64.zip

5) Upload to website

See results at http://udig.refractions.net/download/unstable/ there should be a 1.5-SNAPSHOT by the time you read this.

Eclipse Build

uDig makes use of a target platform, in order to download and reference bundles from:
  • Eclipse Rich Client Platform (we are using Indigo)
  • Babel Project (providing translations)
  • Orbit (open source components that have been checked by the Eclipse legal team)
Here is how to set that up:

0. Here is the branch, check it out, or fork as you see fit.

https://github.com/uDig/udig-platform/tree/locationtech_ip

1. Download stuff (using maven and wget)

mvn clean install -f pom-libs.xml

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8:05.291s

2. Import the eu.udig.targets.indgo project.
3. Open up udig-indigo-target.target and click on Set as Target Platform
Target Definition with Indigo, Babel and Orbit
4. Once that is done you can import the remaining uDig projects and run as normal

Thanks to Frank for figuring out how to do this!

Friday, July 26, 2013

Migration update - does it build?


A lot of work has been going into the locationtech_ip branch of uDig:

There are two streams to the incubation process for uDig.
  • Preliminary Approval (done) - this is a review of the initial code contribution (i.e. the source code the team is working from). Once it has been reviewed the codebase can be hosted on Eclipse infrastructure - allowing the team to collaborate while to the dependencies are checked.
  • Legal Review (in progress): The IP review is extensive and goes through and double checks the dependencies that are used by uDig. Both dependencies (such as GeoTools) that are distributed with the uDig download, and also those required to build the project (such as Sphinx).
Diagram adapted from wiki page on Parallel IP Process

Status Update

Here is a quick update:
  • Initial Code Contribution: ready to check-in when we are - yay!
  • Infrastructure: moving shop
    • Email List: We have successfully migrated to udig-dev@locationtech.org email list - thanks to Denis and Jeff for making that happen.Although this is a small change, having a dev list cuts down on the number of communication channels the uDig team has to watch. Anything important can be CCed to the udig-dev list.
    • Build Farm: with our Initial Code Contribution approved we have now been introduced to Thanh from the Eclipse build team. The conversation has given us a lot to look forward to in the coming weeks.
  • Dependencies: This is the one to watch, not all the dependencies are submitted yet.
    • Contribution Queries: Each open source project uDig makes use of needs to go through a quick legal review to confirm it is actually open source, and the team responsible has decent procedures in place to check they are allowed to distribute the code.
      Thus far each community we have contacted has been very helpful with respect to questions. I will post a GeoTools blog next week with thanks to a few authors we have had to track down.
    • Build Dependencies: We have also started submitting "build dependencies" for open source projects we use to create uDig - but do not need to distribute as part of the uDig download. As an example Frank has submitted Sphinx which we use to build our docs and online help.
  • Build Scripts: Looks to be working.
    May need to update this when we migrate to build farm.
  • Release Bundle and Scripts: Frank has updated the plugin descriptions and hit a snag. We have a dual BSD + EPL license, but the plugin description only accepts a single URL for the license field - we may have to stand up a single page with both licenses on it.
    We will need to revisit this with the NSIS Installer and NSIS Plugins are through the IP review. 
  • Branding and Headers: This is going to be one of the last things we do.
    Once the headers are updated (to say the project is distributed by Eclipse Foundation) we have to wait for the Legal review before we can issue a release.
    This will also involve a refactor to the org.locationtech.udig package, so we want to handle this step very careful.

Dependencies

I have split out our two dependency activities in the above chart, in order to highlight the difference between creating the request for the legal team, vs submitting the source code (so there is something to review).


You can also see where the action is at the moment - reviewing a very large dependency called GeoTools.

It should be noted that the LegalReview process is developer friendly, making use of Bugzilla for each request, and attaching source code to each ticket in the same manner you would a patch.