We are asking for community input on the following: over time, our initialization mechanism (property file, system properties, properties supplied programmatically) has been polluted a bit and as a result the lookups are not always intuitive. We would like to improve this and are working on a new design proposed here. Let us know what you think!

Proposed new property lookup procedure when Atomikos starts:

1. default properties are looked up via a property file in the Atomikos jars (should always be found) 2. override with specific custom properties looked up in the jta.properties file in the classpath (like now) 3. if no jta.properties found: NO logging to System.err any more (so no need to disable that with system props either) 4. override with specific properties that are set programmatically on the UserTransactionService 5. resolve any placeholder properties (i.e., ant-style expansion of references to other props) 6. this yields the final properties to use for the init procedure

What do you think? Did we miss something important?

Thanks!

I would like to dedicate this post to all of our users who have been kind enough to give us their feedback via our online survey (you know, the one you receive by email once you register for download).

First of all, thank you very much for your feedback - this type of information is invaluable for any business, especially a start-up like us. Being agile as we are, any inconveniences found can be quickly corrected in our products and our business model.

So what are the results so far? Well, I won't keep you in suspense any longer so let me just outline the summary:

• About 90% of the respondents would feel bad about missing our products in future projects
• About 60% have recommended our products to other people

Up to you to decide if this is good or bad - but we certainly are pleased with that result! Once again, a big thank you to our community!

Hi,

The Sonatype maven staging repo for our latest build is available here

Enjoy!

2018 UPDATE: the sonatype repos have moved by now; since this concerns a very old release we will not bother to fix this page.

Our maven repository is being migrated to a new location with nexus behind it. This means that download emails no longer contain the repository location until this has been implemented…

Thanks for your understanding!

Maybe you have noticed: we have recently changed our developer access formula - based on customer feedback. Whereas the 'old' formula used to be ticket-based and expired after 1 month, the new developer access is as follows:

• There is no limit on the number of issues
• Expiry is after either 3 or 6 months (your choice) - which gives you plenty of time to experiment
• There is, however, a limit of 1 named contact at the side of the customer

Again, this is based on input we got from several customers and prospects. Thanks for your feedback!

PS yes, the old formula has been discontinued: we too experienced problems with the issue limit…

UPDATE 2018: we now only have subscriptions - where developer access is a included in the offering...