warricksothr
/
ImageTools
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
98 Commits
1 Branch
3 Tags
7.3 MiB
Tree: 37497a0f7d
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '37497a0f7d'
${ noResults }
ImageTools/DEVLOPMENT.md

51 lines
4.8 KiB
Raw Normal View History

Added a development document
11 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Added RELEASE tag script and updated documentation
11 years ago
Added a development document
11 years ago
  1. Development Information
  2. =============
  4. Requirements
  5. ------------
  7. Java 7 JDK (Java 8 is not currently supported due to incompatabilities between it and certain libraries)
  8. Maven 3.0+
  10. NOTE:
  11. The Java 7 JDK on arm platforms are missing required javafx jar files. These files can be copied over from an x86 distribution and the project will build and test, however the binaries will still be missing, so the application will not run in GUI mode. Commandline or deamon mode should be absolutely fine however.
  13. The following files must be copied for an ARM system to compile and test the source
  14. (x86/x86_64 JDK folder)/lib/ant-javafx.jar -> $JAVA_HOME/lib/ant-javafx.jar
  15. (x86/x86_64 JDK folder)/jre/lib/jfxrt.jar -> $JAVA_HOME/jre/lib/jfxrt.jar
  17. Getting Started
  18. ------------
  20. If this is the first time compiling the project do the following
  21. (on nix* systems) run the included fixJavaFXClasspath.sh script
  22. OR
  23. (on windows) run "mvn com.zenjava:javafx-maven-plugin:2.0:fix-classpath" from the commandline in the source directory
  25. ("clean" can be removed from the follwing commands if desired)
  26. To compile the project run "mvn clean compile"
  27. To test the project run "mvn clean test"
  28. To package the project for distribution run "mvn clean jfx:jar". (The contents of the ./target/jfx/app directory may then be packaged into a zip for distribution)
  30. Debugging and Configuration
  31. ------------
  33. The app is configured from two files (three if you have already ran it once)
  34. For deployment versions the default configuration can be found in ./src/main/resources/default.properties
  35. For test versions the deafult configuration can be found in ./src/test/resources/default.properties
  36. For all versions a user.properties file is generated on first run and it will override the values in the default.properties
  37. For all versions an example log4j.properties file is included and will be read at runtime. If it does not exist, the logging will be configured internally. For the internal logging there are properties in the default file that control the level of logging. debug will write to Image-Tools.debug, info to Image-Tools.info, and error to Image-Tools.err. All of these are rolling appenders with a few hundred k file limit and a maximum of 1 previous log. Feel free to include or use your own log4j.properties file to define loggers that suit your needs.
  39. Development Methodology
  40. ------------
  42. Image Tools should be treated as a test driven application for all core features. Ideally before commiting to the main branch, all tests should run succesfull. Additionally in the interest of system compatability (be it either a nix*, OSX, or windows system) no test should use system specific features.
  44. Currently the application exists in one super jar with dependancies in an accompanying lib folder. This is not viewed as ideal and a goal in the future will be to split the engine and its functionalities from the GUI, CLI, and Daemon interfaces so that seperate artifacts may be generated for each. This will resolve the current issues of building the GUI on ARM based systems.
  46. Image Tools is a mixed language project. Java provides the interface code and support (currently JavaFX) and Scala provides the grunt work. Because of this design we are locked to the latest JDK that the dependent scala libraries are built against. (currently Java 1.7) When support for new versions or Java become available a branch will be spun off to test compatabilites and test cases. If everything passes, that upgrade can then be merged back into trunk.
  48. Limited samples should be included in version control and ideally none should be included as they massively increase the repository size. Instead all samples required to run the tests should be provided as a seperate package to be downloaded by the developer for inclusion before running the tests.
  50. Image Tools uses the Semantic Versioning scheme to represent changes within the code base. The initial version committed was v0.1.0-DEV. Tagged versions should follow this scheme. In addition to Semantic Versioning the follwing tags are used. DEV (indicates a development version, very unstable, may not pass all tests), SNAPSHOT (unstable versions, passes all tests but not all features may be ready for release), M{number} i.e. M1 (sequential milestone release for a specific version number. This build is 'expected' to be stable, but may not be completely stable. All tests pass and are consistent on known platforms.), RELEASE (Is a release version), FINAL (last supported version of a major.minor pair. No more updates will be released along this line and upgrading to a newer major.minor pair is advised. Typically used when deprecated functionality is cut off.) If no tag is included it is safe to assume it is a production version and has made it out of milestone , but has not yet reached FINAL so more revision changes may occur as bugs are fixed.