Releases: xenon-middleware/xenon
This is release 2.4.1 of Xenon.
What problem does Xenon solve?
Many applications use remote storage and compute resources. To do so, they need to include code to interact with the scheduling systems and file transfer protocols used on those remote machines.
Unfortunately, many different scheduler systems and file transfer protocols exist, often with completely different programming interfaces. This makes it hard for applications to switch to a different system or support multiple remote systems simultaneously.
Xenon solves this problem by providing a single programming interface to many different types of remote resources, allowing applications to switch without changing a single line of code.
Notable changes compared to v2.4.0:
This is release 2.4.0 of Xenon.
What problem does Xenon solve?
Many applications use remote storage and compute resources. To do so, they need to include code to interact with the scheduling systems and file transfer protocols used on those remote machines.
Unfortunately, many different scheduler systems and file transfer protocols exist, often with completely different programming interfaces. This makes it hard for applications to switch to a different system or support multiple remote systems simultaneously.
Xenon solves this problem by providing a single programming interface to many different types of remote resources, allowing applications to switch without changing a single line of code.
Notable changes compared to v2.3.0:
This is release 2.3.0 of Xenon.
What problem does Xenon solve?
Many applications use remote storage and compute resources. To do so, they need to include code to interact with the scheduling systems and file transfer protocols used on those remote machines.
Unfortunately, many different scheduler systems and file transfer protocols exist, often with completely different programming interfaces. This makes it hard for applications to switch to a different system or support multiple remote systems simultaneously.
Xenon solves this problem by providing a single programming interface to many different types of remote resources, allowing applications to switch without changing a single line of code.
Notable changes compared to v2.2.0:
- added an HDFS filesystem adaptor
- fixed bug in GridEngineSchedulers for complex configurations of number of slots per node
- various code cleanups, etc.
This is release 2.2.0 of Xenon.
What problem does Xenon solve?
Many applications use remote storage and compute resources. To do so, they need to include code to interact with the scheduling systems and file transfer protocols used on those remote machines.
Unfortunately, many different scheduler systems and file transfer protocols exist, often with completely different programming interfaces. This makes it hard for applications to switch to a different system or support multiple remote systems simultaneously.
Xenon solves this problem by providing a single programming interface to many different types of remote resources, allowing applications to switch without changing a single line of code.
Notable changes compared to v2.1.0:
- extended CredentialMap to retrieve all keys
- removed logback config from jar
- fixed bug in handling workdir of Local and TorqueSchedulers
- many small bugfixes, additional tests, etc.
This is release 2.1.0 of Xenon.
What problem does Xenon solve?
Many applications use remote storage and compute resources. To do so, they need to include code to interact with the scheduling systems and file transfer protocols used on those remote machines.
Unfortunately, many different scheduler systems and file transfer protocols exist, often with completely different programming interfaces. This makes it hard for applications to switch to a different system or support multiple remote systems simultaneously.
Xenon solves this problem by providing a single programming interface to many different types of remote resources, allowing applications to switch without changing a single line of code.
Notable changes compared to v2.0.0:
- added getCredential to Scheduler and FileSystem
- fixed a bug in equals of CredentialMap
- added proper check of supported credential types in adaptors
- many small bugfixes, additional tests, etc.
This is release 2.0.0 of Xenon.
What problem does Xenon solve?
Many applications use remote storage and compute resources. To do so, they need to include code to interact with the scheduling systems and file transfer protocols used on those remote machines.
Unfortunately, many different scheduler systems and file transfer protocols exist, often with completely different programming interfaces. This makes it hard for applications to switch to a different system or support multiple remote systems simultaneously.
Xenon solves this problem by providing a single programming interface to many different types of remote resources, allowing applications to switch without changing a single line of code.
Notable changes compared to v1.2.3:
- complete overhaul of public API, which should increase ease-of-use significantly.
- complete overhaul of integration test framework, which should improve performance and make it easier to test against different versions of the same middleware.
- complete overhaul of implementation, which should make implementing adaptors much more straightforward.
- replaced Jsch with Apache SSHD in the SSH and SFTP adaptors
- replaced Apache Jackrabbit with Sardine in the Webdav adaptor.
- added an S3 filesystem adaptor.
This is release candidate 2 of Xenon 2.0.0.
This is the first release candidate of Xenon 2.0.0
Notable changes compared to v1.2.3:
- complete overhaul of public API, which should increase ease-of-use significantly.
- complete overhaul of integration test framework, which should improve performance and make it easier to test against different versions of the same middleware.
- complete overhaul of implementation, which should make implementing adaptors much more straightforward.
- replaced Jsch with Apache SSHD in the SSH and SFTP adaptors
- replaced Apache Jackrabbit with Sardine in the Webdav adaptor.
This is release 1.2.3 of Xenon.
This is the final regular 1.x release before switching to the 2.0 branch.
No further development will be done on 1.x (although we may release additional bug-fix releases).
Bugfixes:
fixed various issues flagged by sonarqube
What's missing:
The GridFTP adaptor is not considered stable yet. It is not part of this release.
There is no adaptor writing documentation at the moment, nor is the Javadoc complete for the internals methods of the adaptor implementations.
It should be made easier to inspect at runtime which adaptors are available and what properties they support.
We can always use more adaptors, e.g, for S3, SWIFT, HDFS, YARN, Azure-Batch, Amazon-Batch etc. Many of these are in progress for 2.0.
Xenon 1.2.2
This is release 1.2.2 of Xenon.
Bugfixes:
- fixed bug in the copy engine that would ignore a copy if source and destination had exactly the same path (even on different machines).
- added timeout overflow detection in Jobs.waitUntilDone and Jobs.waitUntilRunning.
Other changes:
- we have a new logo!
- added SonarQube code for quality analysis and coverage
What's missing:
The GridFTP adaptor is not considered stable yet. It is not part of this release.
There is no adaptor writing documentation at the moment, nor is the Javadoc complete for the internals methods of the adaptor implementations.
It should be made easier to inspect at runtime which adaptors are available and what properties they support.
We can always use more adaptors, e.g, for S3, SWIFT, HDFS, YARN, Azure-Batch, Amazon-Batch etc. These are planned for 1.3 or later.
We can always use more interfaces, e.g. for clouds. This is planned for 2.0.
Xenon 1.2.1
Xenon 1.2.1
This is release 1.2.1 of Xenon.
Bugfixes:
- fixed nasty inconsistency in adaptor implementations of waiting for jobs to start or finish.
What's missing:
The GridFTP adaptor is not considered stable yet. It is not part of this release.
There is no adaptor writing documentation at the moment, nor is the Javadoc complete for the internals methods of the adaptor implementations.
It should be made easier to inspect at runtime which adaptors are available and what properties they support.
We can always use more adaptors, e.g, for S3, SWIFT, HDFS, YARN, Azure-Batch, Amazon-Batch etc. These are planned for 1.3 or later.
We can always use more interfaces, e.g. for clouds. This is planned for 2.0.