[ANNOUNCE] Apache Jackrabbit Oak 1.6.1 released
The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit Oak. The release is available for download at: http://jackrabbit.apache.org/downloads.html See the full release notes below for details about this release: Release Notes -- Apache Jackrabbit Oak -- Version 1.6.1 Introduction Jackrabbit Oak is a scalable, high-performance hierarchical content repository designed for use as the foundation of modern world-class web sites and other demanding content applications. Jackrabbit Oak 1.6.1 is a patch release that contains fixes and improvements over Oak 1.6. Jackrabbit Oak 1.6.x releases are considered stable and targeted for production use. The Oak effort is a part of the Apache Jackrabbit project. Apache Jackrabbit is a project of the Apache Software Foundation. Changes in Oak 1.6.1 - Sub-task [OAK-4648] - Improve documentation about structure of TAR files Technical task [OAK-5547] - Document TarMK design [OAK-5554] - RDB*Store: update postgresql JDBC driver reference to 9.4.1212 [OAK-] - RDB*Store: update Tomcat JDBC pool dependency to 7.0.73 [OAK-5751] - RDBDocumentStore: properly handle null values for system properties Bug [OAK-5017] - Standby test failures [OAK-5239] - Test failure: ExternalPrivateStoreIT. testSyncUpdatedBinaryProperty() [OAK-5388] - Test failure: persistentCache.BroadcastTest.broadcastTCP [OAK-5408] - Test failure: segment.standby.BrokenNetworkTest [OAK-5482] - Test failure: LdapProviderTest - Address already in use [OAK-5485] - Test failure: LdapDefaultLoginModuleTest address already in use [OAK-5536] - Facets on relative properties do not work properly [OAK-5542] - Test failure: security.authentication.ldap.LdapProviderTest (Address already in use) [OAK-5557] - incomplete diffManyChildren during commitHook evaluation in a persisted branch [OAK-5561] - TestFailure: org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndexTest.longRepExcerpt [OAK-5587] - Node counter index estimates must not be used before first async index cycle [OAK-5601] - documentMk backgroundRead should handle missing journal entries [OAK-5612] - Test failure: org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart [OAK-5619] - withIncludeAncestorsRemove reports unrelated top-level node deletion [OAK-5621] - Warn traversal queries: false positives for joins and SQL-2 queries using "or" [OAK-5626] - ChangeProcessor doesn't reset 'blocking' flag when items from queue gets removed and commit-rate-limiter is null [OAK-5636] - potential NPE in ReplicaSetInfo [OAK-5649] - Error in RefreshPolicy can lead to IndexNode lock leak [OAK-5651] - java.lang.IllegalStateException logged when migrating Segment to Document [OAK-5657] - leverage project.version in oak-examples [OAK-5668] - Test failure: observation.ObservationQueueFullWarnTest.warnOnRepeatedQueueFull [OAK-5703] - The replica set info gets invalid cluster id [OAK-5738] - Potential NPE in LargeLdapProviderTest [OAK-5773] - BlobCache does not implement Closeable [OAK-5783] - Test failure: security.authentication.ldap.LdapProviderTest.testSplitDNIntermediatePath2 [OAK-5875] - project.version in oak-example fails release-plugin Epic [OAK-4243] - Oak Segment Tar Module Improvement [OAK-5275] - The check command should accept the path to the store as a positional argument [OAK-5276] - The check command overloads the meaning of the "deep" option [OAK-5350] - Improve code coverage of oak-segment-tar [OAK-5559] - Reduce reads with overlapping previous documents [OAK-5589] - GlobbingPathFilter constructor is expensive [OAK-5594] - leaderboard of consolidated listener stats should show path as well [OAK-5595] - The check command should do deep traversals by default [OAK-5604] - The check command should accept a non-argument "bin" option for checking binaries [OAK-5654] - Improve log output with UserImporter [OAK-5666] - oak-upgrade should validate the paths [OAK-5742] - more logging when ChangeProcessor.stopAndWait fails [OAK-5784] - hashCode of RestrictionImpl doesn't include value [OAK-5873] - Improve SegmentNodeStoreService OSGi description for customBlobStore to remove default False New Feature [OAK-5210] - Ability to resolve principal name from ExternalIdentityRef without IDP roundtrip Task [OAK-4292] - Document oak-segment-tar Test [OAK-5633] - Builds on travis-ci time out [OAK-5663] - Improve LogCutomizer to allow filtering on log messages too In addition to the above-mentioned changes, this release contains all changes included up to the Apache Jackrabbit Oak 1.4.x release. For more detailed information about all the
Success at Apache: Rule of the Makers.
[this announcement is available online at https://s.apache.org/yFgQ ] By Nick Kew I started working on a range of Web applications in the 1990s, the first of them internal to my (then) workplace where it provided an operator interface to the daily processing, archiving and distribution of satellite image data; the second a forerunner of what is now called social media, and my first use of an Apache server. The release of Apache HTTPD 2.0 drew me from server user to developer: in part because I needed to re-implement some existing functions, but more excitingly because I saw tremendous potential for the server itself to become a powerful applications platform. This led me to working on the core software and interacting with the Apache community alongside releasing my own modules and documentation. In 2003 I gave my first ApacheCon presentation, and sometime after that was invited into the Foundation first as a Committer, and became a Member in 2005. Since then my interests have encompassed not just the Web server and related projects, but also the Apache community and its dynamics. I’ve been involved in mentoring several projects through the Incubator. If you were to ask me today about the single goal I’d most like to accomplish, it’s a framework for Identity management that is not merely cryptographically strong, but sufficiently straightforward for the world to use, and robust against social engineering attacks such as phishing, while at the same time free of any centralised authority (such as government) whose motives might come under suspicion. An end to identity fraud, and to password management nightmares. Much has been said and written about The Apache Way [1]. It typically focusses on the importance of community, and on the democratic and meritocratic elements of project governance. And on the role of an Apache project's formal governing body, the Project Management Committee (PMC), comprising contributors elected by the community on the basis of their track record of contributions and constructive engagement. In practice, the role of the PMC is largely reactive. The big, interesting questions like "what direction does our project go from here" are discussed in public, where inputs from the wider community are welcomed. A lot of the nitty-gritty detail is determined by the needs of the community as measured by feedback received and seen, and by the needs of individual developers. The latter is often described as "scratch your own itch". Setting aside the purely reactive, the detail of what actually happens is often determined as much by what a developer is prepared to work on than by any grand plan. If you do the work, then you control what happens. If you need something, you go ahead and make it happen. This has occasionally been described by a clumsy English-Greek hybrid word "do-ocracy". In the hope that it's not too late to nip that in the bud before it becomes as ubiquitous as the Greek/Latin hybrid of which CP Scott memorably told us no good would come [2], I shall instead call it Pratocracy. Rule of the Makers. It applies both within an Apache core team and in the broader community. So how does a Pratocratic project work? How does it avoid the chaos of a Tower of Babel? How does it remain cohesive and focussed? And if an Apache project looks like a good basis for your company's needs, how best can you work with the Pratocracy towards your goals? Taking the first question first, how does the Pratocracy work? Eric Raymond proposed the contrast of the Cathedral vs the Bazaar: the autocracy of the traditional project vs a free ecosystem. The Bazaar ecosystem is essentially Darwinian, in that the strongest projects prosper and evolve, while a Long Tail go nowhere very much and are forgotten as their authors move on to new things. The Apache processes are all about ensuring our projects are fit to be among the winners in that ecosystem. An Apache project is a graduate of an incubation process [3] that requires it to build a broad development community, with sufficient diversity to survive the loss not merely of a key individual, but even of a key company team that might have been the originators of the project. The key principle is that if the community is healthy, the software will follow. Thus the context of the Pratocracy is selective: it is the well-known Meritocracy element of Apache. Members of the core community are elected based on demonstrated commitment to the project. That means they understand the distinction between Apache work and company work, and are comfortable holding multiple allegiances and avoiding or resolving potential conflicts between them. So, to the crucial question. Suppose I have identified an Apache project that doesn't fully meet my company's needs, but is the ideal starting point for our project. How do I best work with the Pratocracy to make it happen? Let's consider some possible approaches: 1.
[ANNOUNCE] Apache Ignite 1.9.0 Released
The Apache Ignite Community is pleased to announce the release of Apache Ignite 1.9.0. Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and distributed in-memory platform for computing and transacting on large-scale data sets in real-time, orders of magnitude faster than possible with traditional disk-based or flash-based technologies. The Fabric is a collection of independent and well integrated components some of which are the following: Data Grid SQL Grid Compute Grid Streaming & CEP Service Grid In this release the community provided an integration with Kubernetes cluster manager, improved performance of core and SQL Grid components, expanded Data Modification Language support to the level of .NET and C++ API, integrated with .NET TransactionScope API and more. Learn more details from our blog post: https://blogs.apache.org/ignite/entry/apache-ignite-1-9-released The full list of the changes can be found here [2]. Please visit this page if you’re ready to try the release out: https://ignite.apache.org/download.cgi Please let us know [3] if you encounter any problems. Regards, The Apache Ignite Community [1] https://ignite.apache.org [2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt [3] https://ignite.apache.org/community/resources.html#ask
[ANNOUNCE] Apache Curator 2.12.0 and 3.3.0 released
Hello, The Apache Curator team is pleased to announce the release of versions 2.12.0 and 3.3.0. The Apache Curator Java libraries make using Apache ZooKeeper much easier and more reliable. Link to release notes: 2.12.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje ctId=12314425=12338714 3.3.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje ctId=12314425=12338713 The most recent source release can be obtained from an Apache Mirror: http://www.apache.org/dyn/closer.cgi/curator/ (mirror sync times may vary) The binary artifacts for Curator are available from Maven Central and its mirrors. For general information on Apache Curator, please visit the project website: http://curator.apache.org Regards, The Curator Team
