@jmaassen jmaassen released this Jun 11, 2018 · 125 commits to master since this release

Assets 2

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.6.1:

  • added support for temp space in JobDescription.
  • added support stdout, stderr and stdin to Torque.
  • fixed several unit tests that failed on OSX

@jmaassen jmaassen released this Mar 16, 2018 · 133 commits to master since this release

Assets 2

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.6.0:

  • fixed hashCode and equals of JobDescription

@jmaassen jmaassen released this Mar 8, 2018 · 139 commits to master since this release

Assets 2

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.5.0:

  • added support for scheduler specific arguments to JobDescription
  • fixed specification of runtime limit in gridengine adaptor

@jmaassen jmaassen released this Mar 3, 2018 · 146 commits to master since this release

Assets 2

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.1:

  • added equals to KeytabCredential (#615)
  • added getSupportedCrenentials to AdaptorDescription (#595)
  • clarified description of JobState.getState (#596)

@jmaassen jmaassen released this Feb 27, 2018 · 156 commits to master since this release

Assets 2

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:

  • fixed JobDescription equals, hashCode and toString (#612)
  • fixed slurm adaptors status retrieval of finished jobs (#613)
  • fixed slurm adaptors parsing of scontrol output on pre 17 slurm versions

@jmaassen jmaassen released this Feb 23, 2018 · 161 commits to master since this release

Assets 2

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:

  • added name to job description and job status (#609)
  • added max memory to job description (#562)
  • added threads per process to job description

@jmaassen jmaassen released this Jan 30, 2018 · 184 commits to master since this release

Assets 2

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.

@jmaassen jmaassen released this Nov 6, 2017 · 223 commits to master since this release

Assets 2

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.

@jmaassen jmaassen released this Nov 1, 2017 · 239 commits to master since this release

Assets 2

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.

@jmaassen jmaassen released this Oct 25, 2017 · 258 commits to master since this release

Assets 2

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.