0.4.0 Release

Author: Ext Haavisto Jukka

.gitattributes

@@ -0,0 +1,3 @@
+# https://git-scm.com/docs/gitattributes
+# unix line feeds to every file (if dos linefeeds needed can be overridden)
+* -text

.gitignore

@@ -0,0 +1,10 @@
+target
+*.html
+output.xml
+JavaFXLib-*.png
+.idea
+*.iml
+report-images
+
+# temporary pom file by shade plugin
+dependency-reduced-pom.xml

AUTHORS.txt

@@ -0,0 +1,7 @@
+Core contributors:
+Jukka Haavisto                 2017 -
+Sami Pesonen                   2017 -
+Pasi Saikkonen                 2017 -
+
+Other contributors:
+Tatu Lahtela                   Find All With Pseudo Class and Find Class keywords

BUILD.md

@@ -0,0 +1,39 @@
+## Sources
+
+Code is organized according to the Maven convention in `src/main/java` and `src/test/java`.
+
+
+## Building
+
+JavaFXLibrary uses Apache Maven as a build tool.
+
+* `mvn clean package` packages JavaFXLibrary with dependencies. There is also documentation and xml file created.
+* `mvn clean verify` run acceptance tests
+
+## Apache Maven Shade Plugin
+
+* Since JavaFXLibrary runs in the same JVM as the AUT(Application Under Test), it's possible that same dependency libraries
+  are being used by both JavaFXLibrary and the AUT. It's not uncommon that a specific version is needed for AUT and another
+  version of the same dependency is required for JavaFXLibrary(e.g. TestFX dependency for Google Guava). Not always are these
+  dependencies backwards compatible and therefore JavaFXLibrary has adopted Apache Maven Shade Plugin to cope with this issue.
+  Currently the package com.google.common  has been renamed in JavaFXLibrary as shaded.com.google.common to avoid version
+  mismatches with Google Guava dependencies.  See https://maven.apache.org/plugins/maven-shade-plugin/ for more info.
+
+
+
+## Releasing
+
+* update library version to x.x.x in pom.xml
+* run tests ``mvn clean verify``
+* ``git commit -m "version to x.x.x" pom.xml``
+* create tag ``git tag -a x.x.x``
+* push ``git push origin master`` and ``git push origin x.x.x``
+* create a new release and upload the jar file, html documentation and xml file to https://github.com/robotframework/JavaFXLibrary/releases
+* upload to Maven Repository (TBD)
+
+## Announcements
+
+* Twitter @robotframework
+* Robotframework Users and announcements mailing lists
+* Slack http://robotframework.slack.com #general and #JavaFXLibrary
+

CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# Contributing
+
+These guidelines instruct how to submit issues and contribute code to the JavaFXLibrary.
+
+## Submitting Issues
+
+Bugs and enhancements are tracked in the issue tracker. If you are unsure if something is a bug or is a feature worth implementing, you can first ask on on [Slack](http://robotframework.slack.com) #JavaFXLibrary channel. These and other similar forums, not the issue tracker, are also places where to ask general questions.
+
+Before submitting a new issue, it is always a good idea to check is the same bug or enhancement already reported. If it is, please add your comments to the existing issue instead of creating a new one.
+
+## Code Contributions
+
+On GitHub pull requests are the main mechanism to contribute code. They
+are easy to use both for the contributor and for person accepting
+the contribution, and with more complex contributions it is easy also
+for others to join the discussion. Preconditions for creating a pull
+requests are having a [GitHub account](https://github.com/),
+installing [Git](https://git-scm.com>) and forking the
+_JavaFXLibrary project_.
+
+GitHub has good articles explaining how to
+[set up Git](https://help.github.com/articles/set-up-git/),
+[fork a repository](https://help.github.com/articles/fork-a-repo/) and
+[use pull requests](https://help.github.com/articles/using-pull-requests)
+and we do not go through them in more detail. We do, however,
+recommend to create dedicated branches for pull requests instead of creating
+them based on the master branch. This is especially important if you plan to
+work on multiple pull requests at the same time.
+
+##Tests
+
+When submitting a pull request with a new feature or a fix, you should
+always include tests for your changes. These tests prove that your changes
+work, help prevent bugs in the future, and help document what your changes
+do. Depending an the change, you may need acceptance tests, unit tests
+or both.
+
+Make sure to run all of the tests before submitting a pull request to be sure
+that your changes do not break anything. 
+
+## Finalizing Pull Requests
+
+Once you have code, documentation and tests ready, it is time to finalize
+the pull request.
+
+### AUTHORS.txt
+
+If you have done any non-trivial change and would like to be credited,
+add yourself to _AUTHORS.txt_ file.
+
+### Resolving Conflicts
+
+Conflicts can occur if there are new changes to the master that touch the
+same code as your changes. In that case you should [sync your fork](https://help.github.com/articles/syncing-a-fork) and [resolve conflicts](https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line)
+to allow for an easy merge.
+
+### Squashing Commits
+
+If the pull request contains multiple commits, it is recommended that you
+squash them into a single commit before the pull request is merged.
+See [Squashing Github pull requests into a single commit](http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit)
+article for more details about why and how.
+
+Squashing is especially important if the pull request contains lots of
+temporary commits and changes that have been later reverted or redone.
+Squashing is not needed if the commit history is clean and individual
+commits are meaningful alone.

COPYRIGHT.txt

@@ -0,0 +1,14 @@
+Copyright 2017-2018   Eficode Oy
+Copyright 2018-       Robot Framework Foundation
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

README.md

@@ -1,2 +1,77 @@
-# JavaFXLibrary
-Robot Framework library for JavaFX automation based on TestFX
+#JavaFXLibrary
+
+[Robot Framework](http://robotframework.org) library for testing and connecting to a JavaFX java process and using [TestFX](https://github.com/TestFX/TestFX).
+
+This library allows you to use robot/pybot (Python version of Robot Framework) to run test cases over remote library interface although it also works if you are running with jybot (Jython version of Robot Framework). This means that you can use your other pure Python libraries in your test cases that will not work when runnin with Jython.
+
+JavaFXLibrary is tested to work with Robot Framework 3.0.2 or later.
+
+You can connect to applications running on your local machine or even on a different machine.
+
+
+##Installation
+
+1. Download latest JavaFXLibrary and documentation from https://github.com/robotframework/JavaFXLibrary/releases/
+2. Copy(if needed) JAR to desired location and run from command line using
+    ```
+    java -jar JavaFXLibrary-<version>.jar
+
+    ```
+3. JavaFXLibrary in RemoteServer mode should now be running in port [8270](http://localhost:8270)
+4. Optionally JAR can be launched with port number as an optional argument:
+    ```
+    java -jar JavaFXLibrary-<version>.jar 1234
+    ```
+5. JavaFXLibrary in RemoteServer mode should now be running in port [1234](http://localhost:1234)
+
+## Usage in Robot suite settings
+
+Import the library:
+```
+***Settings***
+Library    Remote    http://localhost:8270/    WITH NAME    JavaFXLibrary
+```
+Now the keywords can be used as usual:
+```
+Launch Javafx Application    javafxlibrary.testapps.TestClickRobot
+```
+
+In case of duplicate keywords(multiple keywords found with same name) use e.g. `JavaFXLibrary.'Keyword Name'` to get rid of warnings.
+
+## Using multiple remote libraries
+
+If you need to use the Remote library multiple times in a test suite, or just want to give it a more descriptive name, you can import it using the WITH NAME syntax.
+```
+***Settings***
+Library    Remote    http://localhost:8270/    WITH NAME    client1
+Library    Remote    http://localhost:8272/    WITH NAME    client2
+```
+
+Now the keywords can be used as `client1.List Windows` and `client2.List Windows`
+
+
+## JavaFXLibrary demo
+
+This can be also used as JavaFXLibrary demo.
+
+Generic way with Maven (in repository root):
+```
+mvn verify
+```
+
+Windows command line:
+```
+java -cp "target\JavaFXLibrary-<version>.jar"  org.robotframework.RobotFramework --include smoke src\test\robotframework/
+```
+
+Linux/OSX command line:
+```
+java -cp "target/JavaFXLibrary-<version>.jar"  org.robotframework.RobotFramework --include smoke src/test/robotframework/
+
+```
+
+## Known issues
+
+* Tests can be executed with robot/pybot/jybot! Jython can be used locally without remote interface.
+* Running tests multiple times requires starting the server again, or applications start launching behind other windows, causing tests to fail when robot is trying to interact with them.
+* At the moment there are problems with Java Objects, they might be returned as Java Strings or their methods may be unavailable.