GRAL

I've just imported the code of GRAL to Github: ​https://github.com/eseifert/gral All further development will continue there and new issues for GRAL should be created on Github. I hope this will attract more contributors and ensure a more active ... [More] development. This Trac environment including the wiki, the bug tracker, and code browsing will stay online until the migration is complete. However, registration of new Trac accounts will be disabled. [Less]

I've just imported the code of GRAL to Github: ​https://github.com/eseifert/gral All further development will continue there and new issues for GRAL should be created on Github. I hope this will attract more contributors and ensure a more active ... [More] development. This Trac environment including the wiki, the bug tracker, and code browsing will stay online until the migration is complete. However, registration of new Trac accounts will be disabled. [Less]

Together with ticket #79, GRAL's version numbers changed slightly. The versioning scheme for a release was <major>-<minor> or, if applicable, <major>-<minor>-<revision> and remains unchanged. However, the versioning ... [More] scheme for a development version which used to be <major>-<minor>-SNAPSHOT is no longer in use. The new version string for development versions consists of <tag name>-<number of commits since tag>-<short hash of last commit>, which is identical to the output of git describe --tags (see man git-describe). The name of the tag is the name of the last release, i.e. <major>-<minor>. Example Version of the 0.10 release: "0.10" Version of GRAL that introduces new commit numbers: "0.10-23-g2b5403c" We thought that this versioning scheme is more meaningful, because it allows to depend on a specific version of GRAL, even if is a development version. [Less]

Together with ticket #79, GRAL's version numbers changed slightly. The versioning scheme for a release was <major>-<minor> or, if applicable, -- and remains unchanged. However, the versioning scheme for a development version which used ... [More] to be --SNAPSHOT is no longer in use. The new version string for development versions consists of --, which is identical to the output of git describe --tags (see man git-describe). The name of the tag is the name of the last release, i.e. -. Example Version of the 0.10 release: "0.10" Version of GRAL that introduces new commit numbers: "0.10-23-g2b5403c" We thought that this versioning scheme is more meaningful, because it allows to depend on a specific version of GRAL, even if is a development version. [Less]

Together with ticket #79, GRAL's version numbers changed slightly. The versioning scheme for a release was <major>-<minor> or, if applicable, <major>-<minor>-<revision> and remains unchanged. However, the versioning ... [More] scheme for a development version which used to be <major>-<minor>-SNAPSHOT is no longer in use. The new version string for development versions consists of <tag name>-<number of commits since tag>-<short hash of last commit>, which is identical to the output of git describe --tags (see man git-describe). The name of the tag is the name of the last release, i.e. <major>-<minor>. Example Version of the 0.10 release: "0.10" Version of GRAL that introduces new commit numbers: "0.10-23-g2b5403c" We thought that this versioning scheme is more meaningful, because it allows to depend on a specific version of GRAL, even if is a development version. [Less]

I'm very happy to announce the release of GRAL 0.10! Although this version doesn't bring many new features, it contains a lot of behind-the-scene changes: API Changes A lot of calls have changed as we migrated all the plot settings to regular ... [More] Java properties. The changes will break existing code, but the new names in the API are usually easy to adopt. Version Control System Behind the scenes we migrated the version control system from ​Subversion to ​git. This brings many advantages for developers and it will help keeping GRAL more active. Build System We also changed the build system from ​Maven to ​Gradle. This simplifies the build process and the configuration will be easier to maintain than with Maven. Just compare the new build.gradle and the old pom.xml to see the difference. See the previous blog entries for more details on the changes. Get GRAL 0.10 on the download page. [Less]

I'm very happy to announce the release of GRAL 0.10! Although this version doesn't bring many new features, it contains a lot of behind-the-scene changes: API Changes A lot of calls have changed as we migrated all the plot settings to regular ... [More] Java properties. The changes will break existing code, but the new names in the API are usually easy to adopt. Version Control System Behind the scenes we migrated the version control system from ​Subversion to ​git. This brings many advantages for developers and it will help keeping GRAL more active. Build System We also changed the build system from ​Maven to ​Gradle. This simplifies the build process and the configuration will be easier to maintain than with Maven. Just compare the new build.gradle and the old pom.xml to see the difference. See the previous blog entries for more details on the changes. Get GRAL 0.10 on the download page. [Less]

We decided to change GRAL's build system from ​Maven to ​Gradle (see ticket #66). As a GRAL user, you should not notice any differences. GRAL will still be available in the Maven repository and it will still be possible to include the library into ... [More] Maven builds. Why change? While Maven can be expanded by lots and lots of plugins for different purposes, we found that changing the XML configuration files to include the plugins is cumbersome. Gradle addresses this issue by providing configuration files that use a Groovy based DSL. Contrary to Maven, you are not bound to a specific application lifecycle, but rely on e.g. naming conventions for the build tasks. The wiki pages that are about building GRAL from source will be updated soon. [Less]

We decided to change GRAL's build system from ​Maven to ​Gradle (see ticket #66). As a GRAL user, you should not notice any differences. GRAL will still be available in the Maven repository and it will still be possible to include the library into ... [More] Maven builds. Why change? While Maven can be expanded by lots and lots of plugins for different purposes, we found that changing the XML configuration files to include the plugins is cumbersome. Gradle addresses this issue by providing configuration files that use a Groovy based DSL. Contrary to Maven, you are not bound to a specific application lifecycle, but rely on e.g. naming conventions for the build tasks. The wiki pages that are about building GRAL from source will be updated soon. [Less]

We decided to change GRAL's build system from ​Maven to ​Gradle (see ticket #66). As a GRAL user, you should not notice any differences. GRAL will still be available in the Maven repository and it will still be possible to include the library into ... [More] Maven builds. Why change? While Maven can be expanded by lots and lots of plugins for different purposes, we found that changing the XML configuration files to include the plugins is cumbersome. Gradle addresses this issue by providing configuration files that use a Groovy based DSL. Contrary to Maven, you are not bound to a specific application lifecycle, but rely on e.g. naming conventions for the build tasks. The wiki pages that are about building GRAL from source will be updated soon. [Less]