http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/_posts/2013-04-28-qi4j-2.0.md ---------------------------------------------------------------------- diff --git a/src/_posts/2013-04-28-qi4j-2.0.md b/src/_posts/2013-04-28-qi4j-2.0.md new file mode 100644 index 0000000..4854874 --- /dev/null +++ b/src/_posts/2013-04-28-qi4j-2.0.md @@ -0,0 +1,81 @@ +--- +layout: posts +title: Qi4j SDK Release 2.0 +--- +## Qi4j SDK Release 2.0 + +28 Apr 2013 - Montpellier/France & Shanghai/China - Qi4j Release 2.0 + +After nearly 2 years of hard work, the Qi4j Community today launched +its second generation Composite Oriented Programming framework. + +Qi4j is Composite Oriented Programming for the Java platform. It is a +top-down approach to write business applications in a maintainable +and efficient manner. Qi4j let you focus on the business domain, +removing most impedance mismatches in software development, such as +object-relation mapping, overlapping concerns and testability. + +Qi4j's main areas of excellence are its enforcement of application +layering and modularization, the typed and generic AOP approach, +affinity based dependency injection, persistence management, indexing +and query subsystems, but there are much more. + +The 2.0 release is practically a re-write of the entire runtime, +according to co-founder Niclas Hedhman; "Although we are breaking +compatibility in many select areas, most 1.4 applications can be +converted with relatively few changes.". He continues; "These changes +are necessary for the next set of planned features, including full +Scala integration, the upcoming JDK8 and Event Sourcing integrated +into the persistence model." + +"It has been a bumpy ride to get this release out the door.", said +Paul Merlin, the 2.0 Release Manager, "but we are determined that +Qi4j represents the best technological platform for Java to create +applications with high business value." +Not only has the community re-crafted a remarkable codebase, but also +created a brand new website, fully integrated with the new Gradle +build process. + +"The new website keeps the documentation in sync with the releases.", +Paul added. "All the samples in documentation are actual code being +executed in our test suite. I am very proud of the work that has gone +into the new site." + +We asked Niclas, "The community calls the Release 2.0 "Reductionism". +What does that mean?" + +"We wanted to make all the necessary changes, which breaks +compatibility, as quickly as possible and get the leanest possible +Qi4j out the door. Many advanced features that are planned had to +wait. We simply wanted the base platform to be available first.", +says Niclas on the topic. + +So what is really New? + +"Everything", says Niclas. "For Qi4j Core, the most important change +is the introduction of functional paradigm in the internal runtime. +This creates cleaner code, and we'll be able to leverage JDK8 very +effectively when it will be available. +The second big thing is to reduce the Qi4j Core and increase the +Extensions concept to more areas than persistence and indexing. We +have now added metrics and value serialization, others to come." + +And what is Next? + +"Our main focus will be developper productivity. We have things such +as TimeSeries, Event Sourcing support in Core, easier Assembly of +Application Stacks in sight for future releases.We aim at constantly +enriching the whole SDK (libraries, extensions, samples and tools) +and its documentation. Another objective is to grow the core +community through more open participation.", says Paul. "Yes, there +is much visionary work ahead.", adds Niclas. + +Find more information at http://qi4j.org and http://qi4j.org/java/2.0/ + +The Qi4j Community is a set of loosely coupled developers working +hard to create the most exciting domain oriented application +framework for the Java platform. Qi4j is licensed under the very +liberal Apache License 2.0. + +-- Qi4j Core Team +
http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/_posts/2015-07-31-apache-zest-java-2.1.md ---------------------------------------------------------------------- diff --git a/src/_posts/2015-07-31-apache-zest-java-2.1.md b/src/_posts/2015-07-31-apache-zest-java-2.1.md new file mode 100644 index 0000000..440fbe6 --- /dev/null +++ b/src/_posts/2015-07-31-apache-zest-java-2.1.md @@ -0,0 +1,77 @@ +--- +layout: posts +title: Apache Zest⢠(Java Edition) Release 2.1 +date: 20150731 +--- + +## Apache Zest⢠(Java Edition) Release 2.1 + +### Release-notes + +[ZEST-40](https://issues.apache.org/jira/browse/ZEST-40) - Rename "Qi4j" to "Apache Zest (Java Edition)" + +> Apache Zest Java Edition 2.1 is the first release of the Qi4j codebase under the Apache Software Foundation umbrella. +> To keep backward compatiblity, this version still use org.qi4j.* Java packages and Maven coordinates. +> Please note that this will change in 3.0. + + +#### Bug + +- [ZEST-38](https://issues.apache.org/jira/browse/ZEST-38) - Scheduler throws NPE +- [ZEST-41](https://issues.apache.org/jira/browse/ZEST-41) - FileEntityStore doesn't work on Windows +- [ZEST-55](https://issues.apache.org/jira/browse/ZEST-55) - Type and naming collisions +- [ZEST-56](https://issues.apache.org/jira/browse/ZEST-56) - Intermittent failures of ElasticSearch indexing on startup +- [ZEST-57](https://issues.apache.org/jira/browse/ZEST-57) - ElasticSearch Query engine generate immense term queries on "large" associations +- [ZEST-58](https://issues.apache.org/jira/browse/ZEST-58) - ElasticSearch do not support MatchesSpecification (regexp queries) +- [ZEST-59](https://issues.apache.org/jira/browse/ZEST-59) - MixinsModels.primaryType() return wrong type on Java 8 +- [ZEST-61](https://issues.apache.org/jira/browse/ZEST-61) - In Lifecycle.create(), @This can't be used in EntityBuilder's to set non-Optional values. +- [ZEST-62](https://issues.apache.org/jira/browse/ZEST-62) - If same Identity is used twice within the same UnitOfWork, it is not detected. +- [ZEST-64](https://issues.apache.org/jira/browse/ZEST-64) - Extensions assemblies assemble config entities even if no config module is specified +- [ZEST-68](https://issues.apache.org/jira/browse/ZEST-68) - Query DSL templateFor( .. ) fails to build template for ManyAssociations +- [ZEST-70](https://issues.apache.org/jira/browse/ZEST-70) - ElasticSearch do not support NeSpecification +- [ZEST-73](https://issues.apache.org/jira/browse/ZEST-73) - Redis EntityStore silently squash entities with an existing identity +- [ZEST-74](https://issues.apache.org/jira/browse/ZEST-74) - SideEffects being executed more than once +- [ZEST-78](https://issues.apache.org/jira/browse/ZEST-78) - File EntityStore silently squash entities with an existing identity +- [ZEST-107](https://issues.apache.org/jira/browse/ZEST-107) - Entity SPI: JSONEntityState cloning logic is flawed + + +#### Improvement + +- [ZEST-42](https://issues.apache.org/jira/browse/ZEST-42) - Changes to Directory naming in FileEntityStore +- [ZEST-60](https://issues.apache.org/jira/browse/ZEST-60) - Better error message when an Entity can not be found. +- [ZEST-65](https://issues.apache.org/jira/browse/ZEST-65) - PassivationException should use Java 7 "suppressed exceptions" to gather all failures stacktraces +- [ZEST-66](https://issues.apache.org/jira/browse/ZEST-66) - UnitOfWork should leverage Java 7 AutoCloseable and try-with-resources +- [ZEST-67](https://issues.apache.org/jira/browse/ZEST-67) - Make Activators injectables +- [ZEST-75](https://issues.apache.org/jira/browse/ZEST-75) - Create/Update Entity from Value in Conversion Library +- [ZEST-77](https://issues.apache.org/jira/browse/ZEST-77) - Adding ability to set MetaInfo on Module +- [ZEST-79](https://issues.apache.org/jira/browse/ZEST-79) - Better error message when Mixin is missing. +- [ZEST-82](https://issues.apache.org/jira/browse/ZEST-82) - Add possibility to get EntityReferences from Associations without loading the Entities +- [ZEST-83](https://issues.apache.org/jira/browse/ZEST-83) - Remove serialization on ValueComposite creation +- [ZEST-89](https://issues.apache.org/jira/browse/ZEST-89) - Introduce ModuleSpi as an injectable entry point +- [ZEST-90](https://issues.apache.org/jira/browse/ZEST-90) - Better error message when an Entity type can not be found + + +#### New Feature + +- [ZEST-22](https://issues.apache.org/jira/browse/ZEST-22) - Add toValue() and toEntity() methods to the Qi4j API. +- [ZEST-47](https://issues.apache.org/jira/browse/ZEST-47) - Complex Configuration Types +- [ZEST-63](https://issues.apache.org/jira/browse/ZEST-63) - ApplicationBuilder for easier assembly with JSON support +- [ZEST-69](https://issues.apache.org/jira/browse/ZEST-69) - NamedAssociations +- [ZEST-71](https://issues.apache.org/jira/browse/ZEST-71) - Memcache based Cache Extension +- [ZEST-72](https://issues.apache.org/jira/browse/ZEST-72) - Assembler adapters for common use cases (visibility, identity, configuration) +- [ZEST-88](https://issues.apache.org/jira/browse/ZEST-88) - Layered Assemblies Helpers + + +#### Task + +- [ZEST-24](https://issues.apache.org/jira/browse/ZEST-24) - Release 2.1 +- [ZEST-76](https://issues.apache.org/jira/browse/ZEST-76) - Drop SLF4J dependency in core +- [ZEST-80](https://issues.apache.org/jira/browse/ZEST-80) - Remove Google AppEngine EntityStore +- [ZEST-81](https://issues.apache.org/jira/browse/ZEST-81) - Remove Neo4j Library and EntityStore +- [ZEST-84](https://issues.apache.org/jira/browse/ZEST-84) - Remove EntityViewer Tool +- [ZEST-85](https://issues.apache.org/jira/browse/ZEST-85) - Remove JRuby Scripting Library +- [ZEST-86](https://issues.apache.org/jira/browse/ZEST-86) - Remove Beanshell Scripting Library +- [ZEST-87](https://issues.apache.org/jira/browse/ZEST-87) - Remove CXF Library +- [ZEST-91](https://issues.apache.org/jira/browse/ZEST-91) - Remove Struts Library and Sample +- [ZEST-92](https://issues.apache.org/jira/browse/ZEST-92) - Remove SQL C3P0 Library +- [ZEST-104](https://issues.apache.org/jira/browse/ZEST-104) - Remove Voldemort EntityStore http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/asf_proposal.md ---------------------------------------------------------------------- diff --git a/src/asf_proposal.md b/src/asf_proposal.md new file mode 100644 index 0000000..74c57e6 --- /dev/null +++ b/src/asf_proposal.md @@ -0,0 +1,299 @@ +--- +title: ASF Proposal +layout: default +--- + +# Abstract + + qi4j = new Energy4Java(); + +That is how to create the Qi4j runtime, and it captures the essence of its spirit. +Qi4j is a platform to develop Composite Oriented Programming applications in Java in a new, exciting and productive manner. + + +# Governance of Provisional Top Level Project + +Provisional Top Level Project is a new idea at the ASF, and the Qi4j community is willing to try the idea, instead of simply debating it. If it doesn't work, Qi4j will re-enter via the Incubator. + +In addition of regular Top Level Projects, we are making the following self-imposed suggestions to the Governance of this Provisional TLP; + +1. The initial PMC consists only of Apache Members, to ensure a solid foundation of understanding The Apache Way. + +2. On top of being an ASF Member, the PMC Chair is an active contributor to the project, and has a vested interest in its success. + +3. Raising the consensus of Releases from 3 +1 votes to 5 +1 votes. + +4. Disclaimer on website and releases, marked with "Provisional" and links to the pTLP status at the ASF. + +5. Maturity of project into a regular Top Level Project is decided separately by the Board, with input from PMC and ComDev. + + +# Project Naming + +Apache Zest is the proposed project name, as we have learned that "4j" in names might ultimately limit the future direction of the project. +Additionally, Qi4j will remain as the Java implementation of the composite oriented programming platform. There is also a literal port to .NET, which may be migrated to ASF as well. + + +# Project Description + +Qi4j is a platform that combines Aspects, Composition, Dependency Injection, Validation, Storage/UnitOfWork handling, Indexing/Search abstraction, Architectural enforcement and much more, in a holistic top-down approach, primarily for Domain-rich applications, even explicitly supportive of Domain Driven Design. + +Composite oriented programming is a term coined in the early days of Qi4j, to capture the notion of using another paradigm for creating applications, than the prevalent object oriented programming one. +It comprises of the ability to write smaller parts of code than regular classes, and compose these so called fragments into a larger "Composite". It is similar to aspect-oriented programming, but we take it one step further, there is no base class. The Composite consists of fragments, but no fragment has higher significance than any other fragment. However, there are explicit types of fragments, namely Composite Types, Constraints, Mixins, Concerns and Side-effects, to clearly communicate "Intent". The macro level composition takes the form of Applications has Layers which contains Modules in which the Composite Types are declared. + +Qi4j also evangelizes strong typing, so the equivalent of Around-Advice in AOP, which is called Concerns, can be made type-safe or like AOP be generic (using `java.lang.reflect.InvocationHandler` interface). Composites can either be hard coded using annotations, or assembled dynamically during the bootstrap phase. + +Qi4j is a whole new way to write Java applications, where focus lies on structures and interfaces, where classes are 'mere' implementation details. + +Qi4j boldly challenges bad practices head-on, such as "What is a Property?", "Why are null arguments allowed by default?" and "Is the structural assembly of the application actually the same as configuration values?" + + +# Background + +Java is NOT an object-oriented language. Neither is C# or C++. IF they were, how come an Object is DERIVED FROM a Class? A true object-oriented language should for sure have Class(es) assigned to Objects (or a similar construct), which are created 'clean', like stem cells can take on practically any cell's role of the body. + +Additionally, in real life, most objects have different properties and behaviors depending on the context. In front of the computer, I am primarily a 'programmer', but in the jungle I am primarily 'scared prey'. Modeling this in Java (and many other languages) requires the introduction of additional Object abstractions, often resulting in many similar classes representing the same underlying entity, again reinforcing our view that Java is a Class Oriented language. + +Many problems in software engineering can be attributed to (lack of) cohesion and (too tight) coupling. The original promise was that we write a Class once and we can re-use it in many different applications, subsystems and modules. In reality, the Class often contains "too much" for the next use-case. The granularity is too coarse, causing too much coupling to other parts. This have resulted in libraries being the smallest granularity that is practical, and solutions like OSGi, Spring and others have emerged to tackle the many issues that may arise from this, from dependency injection to configuration to assembly to runtime resolution of versioning. + +But we often wish that we could have smaller fragments and COMPOSE objects from these fragments. This also makes it easier to replace parts of implementations, instead of fragile overloading, library extension (assuming the library author provides that) and the famous monkey patching approach. + +Aspect Oriented Programming is a concept to capture cross-cutting concerns in one place. Classic cases are Logging and Authentication. This is an excellent concept, but we claim that AspectJ/AspectWerkz and others fail in the implementations, as most rely on naming conventions and declarations separated from the code itself. It is therefor often difficult to know what aspects are in effect at a given point in the code. The code weaving involved sometimes interferes with debugging and/or classloading in environments like OSGi. AOP is often only used by frameworks to "enhance" code supplied by a third-party developer, and less often being part of the downstream developer's daily life. + +Many people have architecture/design drawings, often with layers in the application, with modules within those layers. We call this Worditecture, as those layers and modules only exist in Word documents and if the code is inspected, more often than not, it is impossible to relate the code to such drawings. In Qi4j, we set out to enforce the Application Structure. Entities, Values and Services must be declared inside one or more Modules, and Modules belong inside Layers, and Layers are stacked on top of each other. The Entities, Values and Services have Visibility of either 'within Module', 'within Layer' or 'to Layer directly above'. This leads to less configuration and inability to mess up the codebase completely. + + +# History + +The principles of composite oriented programming are the brain child of Rickard Ãberg going back to ~2003. In early 2007, Niclas Hedhman convinced Rickard to start a new open source project around this, and Qi4j was born. First announced at Oredev conference in November 2007. + +Over the years, 28 people have contributed source to the project and many others have chimed in on mailing lists around direction, concepts and design. When Qi4j had the attention of media and others, we were not able to build long-term community around the project, and we have seen activity declined, as fewer itches to scratch and fewer people willing to make larger changes. + + +# Rationale for migrating to ASF + +Qi4j community sees direct productivity gains from using the platform, although the initial learning curve is quite overwhelming, like learning a new language. The Qi4j community recognizes that it has not been able to communicate the benefits well enough, to achieve a large user and developer community. We are confident of Qi4j's technical merit, and would like to draw on ASF's community merit to build a larger, sustainable and successful community around this exciting technology. + +The technical merit stems from that Qi4j has a strong model for programming in a more strict, yet more productive environment. A platform where fragments can be leveraged, where aspects are declared on the interfaces, where null values are not allowed by default, and where persistence is integrated yet pluggable at boot time. Qi4j enforces the use of modules and layers, the infrastructure layer can not access layers above it, and presentation layers at the top can't bypass service layers to directly access data stores. +All these restrictions are there to provide more guidance to the programmer, reducing the length of the rope and the number of trees to hang oneself in. + +"Common things should be quick and easy, while anything should be possible", has been the mantra since the inception. And thanks to this foresight, Qi4j can be deeply integrated with many (but not all) existing Java technologies, to provide for migration paths. + +Qi4j internally contains a lot of functional structures, and the community is currently migrating Qi4j to Java 8, reducing a chunk of the codebase in the process, and will likely discover new ways of simplicity. Many argue that Qi4j should become its own programming language, but our position has always been that the refactoring tools available in Java are so powerful and should not be under-estimated. It would take endless amount of effort to even get close to that, something that many other language platforms are still struggling with. + + +# Initial Goals + +Qi4j is already on version 2.0, and striving towards both a 2.1 release as well as a Java 8 specific 3.0 release. This will be one of the first "Java 8"-only projects at the ASF, and hopefully a lot of people find this in itself attractive and exciting. + +Qi4j's user base is relatively small, but we are convinced of its remarkable properties as a productivity enhancing platform, and there is still much to do to reach its full potential. There are a lot of low hanging fruit (more extensions and libraries) as well as serious design challenges, such as reloadable Modules via OSGi and Jigsaw integration in Java 9. + +As mentioned above, the small agreeable user base also means that Qi4j can be much more aggressive in adopting newer Java versions, and currently an effort is on the way to leverage Java 8. The Stream API and closures are implemented separately in Qi4j, and we are now converting all the internal code to those features supplied in Java 8, to reduce the total code size of Qi4j Core. + + +# Meritocracy + +Qi4j has been developed under heavy influence of ASF principles and guidelines. The barrier to entry has been at the lowest possible level. A rather aggressive Commit-then-Review process has been in place, but people have in general been encouraged to do larger changes in publicly visible feature branches. The low barrier hasn't created any major problems yet, as reverting mistakes are relatively cheap, and it has been much more important to capture the long-tail of contributions than to avoid occasional bad commits. + +Qi4j is not operated by any organization, and all licensing is directly from developer to the user. We will engage the legal committee to ensure the IP rights are in full order. + +Qi4j's release process has not been nearly as stringent as the one at ASF, and will be the biggest change to the community. We will work closely with willing "Overseers" (see below), change our Gradle-based build system and use available tools, such as Rat, to ensure the highest quality releases possible. + + +# Community + +The current Qi4j developer community is rather small, but passionate individuals who are all convinced of Qi4j's merit and potential. We also think that some of the past developers will re-join the effort, once we are at ASF and some traction is attained. + +Over the years there has been 28 code contributors in total, of which 8 have been considered Core Developers, i.e. allowed to make changes on the Core runtime on trunk without hand-holding. No access control was in place to enforce that, and a social contract worked very well. + +We are probably not the best of community builders, and would welcome members from ASF projects, who think Qi4j is promising, to assist in the community building effort needed. + + +# Active Developers + +All the active developers are independent of each other. No two developers work for the same employer, and no employer pays anyone for working full-time on Qi4j. We consider the following developers 'active' at the moment, one way or the other. It is a very diverse group; + +Niclas Hedhman is an ASF Member, previous long-term member of the Incubator PMC and mentor of 5-10 projects. Freelancing consultant and founder of Bright Things UN Ltd + +Marcel Offermans is an ASF Member, PMC Chair of Apache ACE and on Celix, Felix and Incubator PMC, mentor of several podlings. Day time he runs Luminis Technologies in Holland. + +Rickard Oberg is one of the founders of JBoss, created Xdoclet and WebWork (now Apache Struts2). He now works at Neo Technology Inc, creators of Neo4j. + +Paul Merlin is working at his own company CodeArtisans and a volunteer stone mason of antique walls and buildings. + +Stanislav Muhametsin is working at Cometa Solutions Oy. Stan has also ported Qi4j verbatim to C# as the Qi4CS project on GitHub. + +Tibor Mlynarik works at ADLER iTech. + +Edward Yakop technical architect at ABB Malaysia. + +Marc Grue is a professional musician, but has strong interest in computer science abstractions. + +Kent Sølvsten is working with energy systems at Arosii A/S in Denmark... + +Philippe van Dyck is in the banking industry and works at BNP Paribas + +Jiri Jetmar - Independent consultant + +Jaydatt Desai - Logicom Solutions + +Additional important contributions over the years have come from; + +* Alex Schneyderman - Voalté +* Alin Dreghiciu - Sonatype +* Arvid Huss - Jayway +* Michael Hunger - Neo Technology Inc +* Tonny Kohar - independent Apache Batik and SVG consultant + + +# Alignment + +Apache is a natural option for any Java project, as ASF has an overwhelming percentage of Java projects. +But for Qi4j, we think that our choice to challenge every notion, not based on popularity but on technical merit, should be inspiring to existing ASF projects at large. And by doing so, we hope symbiotic relationships can be established with a variety of other projects at ASF. + +Qi4j is not "finished" and a lot of work in the Big Data space is still needed. We would like to see HBase and Cassandra use-cases to be "Tackled Qi4j Style" and practical conventions to emerge. There are several other ASF projects which Qi4j could support 'better', if we get a little help from those communities, incl Struts, Camel, ActiveMQ, Cayenne, Karaf and others. + + +# Known Risks + +## Orphaned products + +Qi4j is not a company product and never was. It was started by two individuals who have a long and strong community involvement dating back to 1998, also the time when they first learned to know each other. + +If the community can't be built at ASF, then we think that there must be something about Qi4j that is inherently alien to developers, and Qi4j has no broader appeal, beyond those who have both seen the advantages as well as gotten the opportunity to work with it and see for themselves the benefits. We will work hard to ensure the long-term sustainability of the project, because we think that Qi4j represents an important step towards a paradigm shift in software development. + +## Inexperience with Open Source + +Not only does Qi4j have a rather long running history of an independent open source project, 6 major releases, and a track record of operating well as such, but Niclas Hedhman was a long time member of the Incubator PMC, serving on the Legal Committee and have plenty of experience of what is required of Apache projects, as does Marcel Offermans. We wouldn't have proposed to move Qi4j to Apache, unless we thought that the larger Qi4j community will work well at the ASF, with a little bit of initial legal and community assistance from friends at ASF. + +All of Qi4j's history, except the initial 2-3 months, were done on open mailing lists and public repositories. The practice of full discourse and discussion on asynchronous mailing lists has been respected to the fullest extent possible, and at no time has other means of communication been regular. + +Full source code history may not exist, as we went from Subversion at OPS4J to GIT at OPS4J to finally GitHub, initially with sub-repositories (which didn't work well) to finally the qi4j-sdk repository at GitHub. History has probably broken at some point. + +Just like early Apache project's mailing list history, Qi4j's might be incomplete in public archives, but we should be able to restore that, from GMail archives and other mailboxes. We intend to restore the mail archive, as there are many worth-while nuggets in there. + +## Homogenous Developers + +The only homogeneity of Qi4j is the individuals' desire to go beyond the current status quo, to challenge things we do from habit, to criticize 'good practices' and offer radically different solutions to so called mainstream developers and accepted practices. + +The contributors have a vast diversity in their backgrounds and interests, even a non-developer making large contributions. + +The group came together at Qi4j, drawn by its uniqueness and different way to address common concerns. We consider this to be a non-issue. + +## Reliance on Salaried Developers + +As far as we know, no one is currently paid to work on Qi4j itself. This has been a factor in the slow down of activity in the last two years, but we think that the bottom has been reached and that we will see an uptick during 2015, as some of the core members are coming back to write applications using Qi4j. + +## Relationships with Other Apache Products + +Qi4j is such a unique and radically different platform that there is no direct alignment in Qi4j Core with other Apache (or any other for that matter) projects. We have also kept the dependencies to a minimum by choice. +But Qi4j also defines Extension mechanisms, such as storage, indexing, serialization and metrics, and we have implemented extensions for Apache Cassandra and Apache Solr. We also have libraries that integrate other technology into the Qi4j world, such as Apache Shiro, Apache Struts and Apache CXF. We expect that additional Apache projects will be used in future Extensions as well as Libraries, especially in the Big Data space, where we see great opportunities for a Qi4j approach. + +## Excessive Fascination with the Apache Brand + +There is no doubt that the Apache brand is strong, no one can deny that. But our primary 'fascination' is around the possibility to build a stronger community at the ASF, than we otherwise seem to be able to do. Apache is a natural water cooler, where open development people can share ideas and work together. We hope to inspire other Apache projects to do greater things after being exposed to Qi4j's unique approach to many technical challenges. + + +# Documentation + +- Website; [http://qi4j.org](http://qi4j.org) +- Source Repository; [http://github.com/Qi4j/qi4j-sdk](http://github.com/Qi4j/qi4j-sdk) +- Current Mailing list; [https://groups.google.com/forum/#!forum/qi4j-dev](https://groups.google.com/forum/#!forum/qi4j-dev) + + +# Initial Source + +As mentioned earlier, Qi4j started out at OPS4J community, and the codebase was initially on Subversion, then moved to OPS4J operated GIT repositories and finally we moved to GitHub. We tried to preserve history the best we could, with reasonable effort. +So, `https://github.com/Qi4j` contains the repositories that are relevant for the Incubator. In practice, only the `qi4j-sdk` is current. We suggest that the `qi4j-core`, `qi4j-libraries` and `qi4j-extensions` are imported but made read-only. `qi4j-sandbox` is imported. `qi4j.github.com` contains the current website, but the sources for that resides primarily inside the `qi4j-sdk` repository. + + +# Source and Intellectual Property Submission Plan + +There are no issues that we know of. Source code is available openly and online. All code has originated directly from Qi4j contributors, marked as Apache Licensed contributions and to the best of our knowledge there is no encumbered IP issues. +As Qi4j was never a legal entity, all contributions were directly licensed (Apache License 2.0) by the developer to the public. There is no problem reaching out to all of the authors of an overwhelming part (if not all) of the codebase and ask for paperwork, if this is necessary. + + +# External Dependencies + +Qi4j has few dependencies, and all dependencies in all non-optional code is ASLv2 compatible. The required dependencies are; + + * ASM + * SLF4J (To be revised) + * org.json + +There are optional libraries and extensions that have dependencies on projects with other licenses. +One very notable case, the Neo4j entity store extension, is worth mentioning here. At the time this extension was created, Neo4j was under the AGPL license. It is now under GPL, yet the Qi4j Neo4j extension is licensed under Apache License v2. Are we not violating the license requirements of Neo4j? No, we think not, as the contribution itself was made by Neo Technology under the Apache license. Neo Technology argued that they had the right to provide the extension under ALv2, yet whoever ran a Qi4j application with the Neo4j storage extension, would be subjected to the AGPL (now GPL) requirements. Further discussion with Legal committee is expected to follow. + + +# Cryptography + +Qi4j optionally depends on projects that use cryptography. As Qi4j isn't an organization, and most developers live in Europe, we have not followed the US trade restrictions on Cryptography. +Without an extensive check of all 100+ optional dependencies, Apache Shiro stands out. We need to get feedback from legal@ on what the exact requirements are, and conduct a full review. + + +# Required Resources + +## Mailing lists + + [email protected] + [email protected] + [email protected] + +## Git Repositories + +We understand that Apache operates its own Git repositories, as well as having a large number of read-only mirrors at GitHub under Apache organization. + + https://git-wip-us.apache.org/repos/asf/qi4j.git + https://git-wip-us.apache.org/repos/asf/qi4j-legacy-core.git + https://git-wip-us.apache.org/repos/asf/qi4j-legacy-libraries.git + https://git-wip-us.apache.org/repos/asf/qi4j-legacy-extensions.git + https://git-wip-us.apache.org/repos/asf/qi4j-sandbox.git + +## Issue Tracking + +We also have Jira issues we wish to import from Atlassian operated `https://ops4j1.jira.com/browse/QI`, if possible, to + + https://issues.apache.org/jira/browse/ZEST + + +# Initial PMC + +* Alex Karasulu - [email protected] +* James Carman - [email protected] +* Jeff Genender - [email protected] +* Marcel Offermans - [email protected] +* Chris Mattmann - [email protected] +* Niclas Hedhman - [email protected] +* Roman Shaposhnik - [email protected] + + +# Committers + +* Edward Yakop - [email protected] +* Jaydatt Desai - [email protected] +* Jiri Jetmar - [email protected] +* Kent Sølvsten - [email protected] +* Marc Grue - [email protected] +* Paul Merlin - [email protected] +* Phillipe van Dyck - [email protected] +* Rickard Ãberg - [email protected] +* Stanislav Muhametsin - [email protected] +* Tibor Mlynarik - [email protected] + + +# Affiliations + +* Edward Yakop - ABB Malaysia +* Jaydatt Desai - Logicom Solutions +* Jiri Jetmar - Independent consultant +* Kent Sølvsten - Arosii A/S +* Marc Grue - Musician +* Marcel Offermanns - Luminis Technologies +* Niclas Hedhman - Bright Things UN Ltd +* Paul Merlin - CodeArtisans +* Phillipe van Dyck - BNP Paribas +* Rickard Ãberg - Neo Technology AB +* Stanislav Muhametsin - Cometa Solutions Oy +* Tibor Mlynarik - ADLER iTech s.r.o. + + http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/atom.xml ---------------------------------------------------------------------- diff --git a/src/atom.xml b/src/atom.xml new file mode 100644 index 0000000..9f9870d --- /dev/null +++ b/src/atom.xml @@ -0,0 +1,28 @@ +--- +title : Apache Polygene Atom Feed +--- +<?xml version="1.0" encoding="utf-8"?> +<feed xmlns="http://www.w3.org/2005/Atom";> + + <title>{{ site.title }}</title> + <link href="{{ site.production_url }}/atom.xml" rel="self"/> + <link href="{{ site.production_url }}"/> + <updated>{{ site.time | date_to_xmlschema }}</updated> + <id>{{ site.production_url }}</id> + <author> + <name>{{ site.author.name }}</name> + <email>{{ site.author.email }}</email> + </author> + + {% for post in site.posts %} + <entry> + <title>{{ post.title }}</title> + <link href="{{ site.production_url }}{{ post.url }}"/> + <updated>{{ post.date | date_to_xmlschema }}</updated> + <id>{{ site.production_url }}{{ post.url }}</id> + <content type="html">{{ post.content | xml_escape }}</content> + </entry> + {% endfor %} + +</feed> + http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/codebase.html ---------------------------------------------------------------------- diff --git a/src/community/codebase.html b/src/community/codebase.html new file mode 100644 index 0000000..1225133 --- /dev/null +++ b/src/community/codebase.html @@ -0,0 +1,314 @@ +--- +title: Apache Polygene⢠Codebase +layout: default +--- +<div class="page-header"> + <h1>Codebase</h1> + <p class="lead">Apache Polygene⢠codebase is hosted at the Apache Software Foundation and follow the git-flow development model.</p> +</div> +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + <div class="row-fluid"> + <div class="span6"> + <script type="text/javascript" src="//www.ohloh.net/p/13150/widgets/project_basic_stats.js"></script> + </div> + <div class="span6"> + <script type="text/javascript" src="//www.ohloh.net/p/13150/widgets/project_factoids.js"></script> + </div> + </div> + <p> + After the first 3 years of depending on the + <a href="http://team.ops4j.org"; title="Open Participation for Java">OPS4J</a> project, then 5 years on + <a href="https://github.com/qi4j";>Github</a>, the Qi4j community finally moved to the + <a href="https://www.apache.org/";>Apache Software Foundation</a> (ASF) on March 2015. + The codebase history is kept in <a href="https://git-scm.com/";>Git</a> repositories, mirrored to the + <a href="https://github.com/apache?query=polygene";>ASF Github organization</a>. + This should simplify the learning, as not only does developers have plenty of experience with Git, and + tools around it, but also there are endless amount of documentation and user forums to support each + individual, off-loading some of that burden from us. + This page only contain rudimentary information. + </p> + <h2>Public Access Repository</h2> + <p> + Apache Polygene⢠differs slightly from the regular project, due to our specific needs and style of development. the main + differences are; + </p> + <ul> + <li> + Apache Polygene⢠uses the <code>develop</code> branch for the day to day changes to the project. The + <code>master</code> branch is used for the latest releases. See below about the 'Git Development Model'. + </li> + <li> + Apache Polygene⢠uses a social contract to limit access to different areas of the project, instead of ACLs. The + driving point is to relax the contribution criteria in less critical parts, to encourage a wider + participation that otherwise would not be possible. + </li> + </ul> + <p> + Apache Polygene⢠used to have many repositories to accommodate for the authorization issue above, but eventually + settled with a single Git repository, and now only have 2 repositories; + </p> + <ul> + <li><code>polygene-java</code></li> + <li><code>polygene-sandbox</code></li> + </ul> + <p> + The sandbox is where experimental code goes, and modules that are not ready to be shipped, or can not be + shipped due to licensing restrictions (e.g. Oracle doesn't provide Coherence as automatic download for our + testing, so can't really ship the coherence extension). The sandbox is a normal Git repository available + to clone as; <code>git clone https://git-wip-us.apache.org/repos/asf/polygene-sandbox.git</code> + </p> + <p> + The Apache Polygene⢠(Java Edition) is the main development codebase, and to start working with it you simply clone it; + <code>git clone https://git-wip-us.apache.org/repos/asf/polygene-java.git</code> + </p> + + <h2>Web Access</h2> + <p> + The two repositories can be browsed on the mirrors on the ASF Github organization; + </p> + <ul> + <li><a href="https://github.com/apache/polygene-java";>https://github.com/apache/polygene-java</a></li> + <li><a href="https://github.com/apache/polygene-sandbox";>https://github.com/apache/polygene-sandbox</a></li> + </ul> + + <h2>Committer Access</h2> + <p class="lead"> + Apache Polygene⢠has a 3 level committer access system. The groups are "Core", "Platform" and "Community" and the roles + are very clear. + </p> + + <h3>Core Developers</h3> + <p> + These are the guardians and stewards of the core technology and ultimate rulers of what is going on. The + hope is that a small group of benevolent dictators will manage to make Apache Polygene⢠the best platform out there, + and not listen in on the voices of features and changes that derails the vision and principles of Apache Polygeneâ¢. + </p> + <div class="well"> + <p> + Over the course of Apache Polygeneâ¢'s history, there have been several occasions where brilliant developers got + caught up in 'feature improvements' which went against the fibers of Apache Polygene⢠philosophy and technological + direction. IF we would have had an 'open door' policy to changes in Core, these 'improvements' would + have degraded the excellence of Apache Polygeneâ¢, and we are not likely to invite anyone to the Core Developer + team, unless the individual shows remarkable understanding of the inner workings of Apache Polygeneâ¢, the + philosophy that drives Apache Polygene⢠and prudence in working on highly sensitive codebases. In return we will + strive for making the Apache Polygene⢠Core as small as possible, having most features in libraries and extensions. + We welcome any suggestions that breaks out pluggable functionality. + </p> + <p> + We apologize in advance if this comes across as elitist, but the purpose is to ensure a high quality + Apache Polygene⢠Runtime, stable over time and not bloating with unnecessary features. Thanks for understanding. + </p> + </div> + + <h3>Platform Developers</h3> + <p> + These form the work force of Apache Polygeneâ¢. They will work on the Extensions and Libraries, which eventually will + make Apache Polygene⢠the most efficient way of programming in Java. + </p> + + <h3>Community Developers</h3> + <p> + Any person who is interested in helping out with Apache Polygene⢠will be granted access to Sandbox, Tests, IDE + support, Tutorials, Samples, HowTos, documentation and other (i.e. not Core, Libraries and Extensions). + This will gauge their abilities and commitment to the project, with an aim to make them Platform Developers. + </p> + + <h3>Independents</h3> + <p> + Of course, Git's distributed nature also allows anyone to fork our repositories, and have the patches find + their way back to Apache Polygeneâ¢'s official repository. And GitHub's pull-request system makes the management of this + a lot easier, and something that we encourage. + </p> + + <h3>How to Join?</h3> + <p> + To become a Community Developer, just subscribe to the + <a href="mailto:[email protected]";>[email protected]</a> mailing list and participate, + nothing more than a desire to help is required. + </p> + <p> + Community Developers who are active and keep contributing feedback, patches and/or documentation are likely + to be invited as Platform Developers, who has access to everything except the delicate Core, which we + intend to keep a lot more clean and stable than a free-for-all repository has a tendency to become over + time. + </p> + + <h2>Commit Policy</h2> + <p class="lead"> + Apache Polygene⢠generally uses a Commit-Then-Review policy on most changes. This allows a reasonable high velocity of + development. + </p> + <p> + Commits are visible in Git history and at GitHub. Active contributors should review all incoming commits to + ensure quality of contributions and avoidance of mistakes. + </p> + <p> + For any given commit, any member of the community may raise concern(s) on the <code>dev@</code> mailing + list. We encourage as many people as possible to review the changes that are occurring. "With enough + eyeballs every bug is shallow." wrote Eric S. Raymond in "The Cathedral and The Bazaar" about open source. + </p> + <p> + Special rules applies to changes in the Core Test suite. Adding new tests are CTR, but modifying existing + tests, either to accommodate for code changes in Core or to tighten the constraints of them, MUST be + discussed on the <code>dev@</code> mailing list, prior to committing them to the 'develop' branch. We + recommend that a different branch is used for these changes, unless simply codesnippets are pasted to mail. + This exists to ensure that we have a stable evolution of Apache Polygene⢠(Java Edition) Runtime, and no surprises will occur in + existing applications with new versions. + </p> + + <h2>Git Development Model</h2> + <p> + Courtesy of Vincent Driessen, we borrowed the Git branching model from this web page; + <a href="http://nvie.com/posts/a-successful-git-branching-model/";>http://nvie.com/posts/a-successful-git-branching-model/</a> + </p> + <p style="text-align: center"> + <img src="../landing-resources/img/git-model.png"/> + </p> + <p> + The most important part of that excellent article can be found below. + </p> + + <h3>Git Branching Model used at Apache Polygeneâ¢</h3> + <p> + It looks more complicated than it is. Here are the guidelines; + </p> + <ul> + <li>Never commit to the 'master' branch while developing!!</li> + <li>The 'develop' branch is the equivalent of trunk in subversion.</li> + <li>Any changes that are not trivial, start a feature branch.</li> + <li> + The following names are reserved for not feature branches; <code>master</code>, <code>develop</code>, + <code>hotfix/*</code>, <code>release/*</code> + </li> + </ul> + <p> + Day-to-day development revolves around the develop branch and it is this branch that you typically clone + from our repository if you intend to contribute to Apache Polygene⢠itself. If you create a new feature, or make some + larger piece of refactoring, then please create a 'feature branch' (see article for details). + </p> + <p> + Please try to remember the <code>--no-fast-forward</code> option during merge, so the feature branch is + preserved in one piece and can be rolled back easily if needed. + </p> + <p> + The <code>release/*</code> and <code>hotfix/*</code> branches are for release management only, and doesn't + affect most contributors from a commit perspective. Release Managers - Check the article for the details. + </p> + <p> + For convenience you should install and use the gitflow git extension that implement this branching model + by adding git commands. See the gitflow web page; + <a href="https://github.com/nvie/gitflow";>https://github.com/nvie/gitflow</a> + </p> + + <h3>What happened to the <code>master</code> branch?</h3> + <p> + In case you missed it above, check the model that we used for development. The intent is that the + <code>master</code> branch is always in a good state and the <code>HEAD</code> is at a formal release + (and has a tag for that). + </p> + <p> + Patches only enters the 'master' branch either from a <code>hotfix/*</code> or a <code>release/*</code> + branch, never directly from <code>develop</code> or <code>feature/*</code> branches. + </p> + + <h2>How do I do my first commit?</h2> + <p class="lead"> + We strongly encourage people to read up on Git basics at <a href="http://git-scm.com/";>git-scm.com</a>. + </p> + <p> + But some basic commands are discussed here. + </p> + <pre><code>git status</code></pre> + <p> + shows you what has not been committed. + </p> + <pre><code>git add <filename></code></pre> + <p> + all files(!) must be added. Directories are not considered and generally ignored. You can add with + wildcards, even if some files have already been added. + </p> + <pre><code>git commit -a -m "<some message>"</code></pre> + <p> + This commits the current branch to the local repository. The <code>-a</code> means commit all files, and + not only the ones that are explicitly mentioned on this command. The message should be informative as it + will follow the patch 'forever'. + </p> + <pre><code>git push origin develop</code></pre> + <p> + Pushes the local commits back to the <code>origin</code>, i.e. the place the clone came from, or to the + location that you have moved the <code>origin</code> to be instead (see above). + </p> + <pre><code>git pull origin develop</code></pre> + <p> + Pulls/downloads the changes of the <code>develop</code> branch from the <code>origin</code> of your local + clone. In subversion terms, this roughly corresponds to a <code>svn update</code> of the trunk. + </p> + <pre><code>git branch</code></pre> + <p> + Shows which branch we are working on. + </p> + <pre><code>git checkout -b feature/my_new_feature_branch</code></pre> + <p> + Creates a new branch with the given name, unless one already exist, and make the 'current' branch to be the + <code>feature/my_new_feature_branch</code>. + </p> + <p> + When you do a checkout of a branch, the local changes in the current branch that are not committed are not + lost, but are also 'moved along' to the new branch. And if those changes are then committed in the + <code>feature/my_new_feature_branch</code> and one switch back the changes are not there, now sitting in + the <code>feature/my_new_feature_branch</code> only. This is very handy if one forgets to create and move + to a branch before modifying the <code>develop</code> branch. + </p> + + <h3>Using Github Pull Requests</h3> + <p> + Pull requests let you tell others about changes you've pushed to a GitHub repository. Once a pull request + is sent, interested parties can review the set of changes, discuss potential modifications, and even push + follow-up commits if necessary. + </p> + <p> + Github's guide to Pull Requests walks through the process of sending a hypothetical pull request and using + the various code review and management tools to take the change to completion. This guide can be found here; + <a href="https://help.github.com/articles/using-pull-requests";>https://help.github.com/articles/using-pull-requests</a> + That article assume that we have direct control of the GitHub repository, but we don't. Instead we need to + pull the Pull Request to our local machine, merge it in and then push it back via the Apache GIT server. + </p> + <p> + The infrastructure team is working on Pull Request support on the GitHub servers directly, but it is not + available by default yet. + </p> + <p> + Example, for pull request 42, you would need to do the following; +<pre><code> +# You need to have a "remote" defined in your git configuration +# This is only needed once +git remote add github https://github.com/apache/polygene-java.git + +# Fetch the commit +git fetch github pull/42/head:merge-pr-42 + +# These next two steps are optional. +# If you choose to rebase, then the Pull Request is not automatically closed. +git checkout merge-pr-42 +git rebase develop + +# Check out 'develop' branch +git checkout develop + +# Merge the PR +git merge merge-pr-42 + +# Remove the PR branch +git branch -D merge-pr-42 + +# Push the result +git push origin develop + +</code></pre> + </p> + </div> + <div class="span2"></div> +</div> + http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/contributors.html ---------------------------------------------------------------------- diff --git a/src/community/contributors.html b/src/community/contributors.html new file mode 100644 index 0000000..c8302dc --- /dev/null +++ b/src/community/contributors.html @@ -0,0 +1,97 @@ +--- +title: People behind Apache Polygene⢠+layout: default +--- +<div class="page-header"> + <h1>People behind Apache Polygeneâ¢</h1> + <p class="lead"> + Qi4j was started in 2007 by Niclas Hedhman and Rickard Öberg, a.k.a "The Founders". + <br/> + In 2015, Qi4j came to the Apache Software Foundation, and is run as an Apache project named Apache Polygeneâ¢. + </p> +</div> +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + + <p> + There are many types of contributors to open source projects, this one included, and we urge you to take a look at + <a href="http://www.oss-watch.ac.uk/resources/rolesinopensource.xml";>http://www.oss-watch.ac.uk/resources/rolesinopensource.xml</a> + to see how you can contribute, even if you don't have the expertise or time required for the source code evolution. + </p> + + <h2>Project Management Committee</h2> + <p> + The Project Management Committee (PMC) are the people who has shown significant commitment towards the project and + act as the stewards of the project. The PMC is responsible for decision making, brand policy, legal compliance, release + management, security responses and all other aspects of the maintenance and evolvution of the codebase under its care. + The following people are currently PMC. + </p> + <ul> + <li>Niclas Hedhman (Chair)</li> + <li>Alex Karasulu</li> + <li>James Carman</li> + <li>Jeff Genender</li> + <li>Jiri Jetmar</li> + <li>Marcel Offermans</li> + <li>Paul Merlin</li> + <li>Roman Shaposhnik</li> + <li>Sandro Martini</li> + </ul> + + <h2>Contributors</h2> + <p> + There has been numerous contributors to the Polygene/Zest/Qi4j project over the years, and with risk of missing someone, + we try to maintain this list to show our appreciation of these contributions. + </p> + <h3>Rickard Öberg</h3> + <p> + Rickard requires special mention, as a majority of the Core runtime implementation is written by him, + and done so more than once (3 or 4 total re-writes) as our understanding for the problem space has improved. + </p> + <p> + Rickard's achievements here and elsewhere (JBoss, XDoclet, Struts2), can not be understated. This project + wouldn't exist without his spearheading insights and innovative thinking. Many of the core concepts, Mixins, + Concerns and Constraints in particular, existed in his tool box long before Qi4j was formed. + </p> + <p> + Rickard has moved on, working at Neo Technologies, helping out on the Neo4j project. But we are eternally + grateful for his efforts here, and hope to see him come back one day in the future. + </p> + <h3>Others</h3> + <p> + The list below includes all past and present contributors to the Polygene/Zest/Qi4j project. There + might be omissions, and that is purely a mistake. So if you find anyone, incl yourself, + missing from the list, please contact the Polygene developer list, [email protected] + </p> + <ul> + <li>Alex Shneyderman</li> + <li>Alin Dreghiciu</li> + <li>Arvid Huss</li> + <li>Chris Chapman</li> + <li>David Leangen</li> + <li>Edward Yakop</li> + <li>Georg Ragaller</li> + <li>Jan Kronquist</li> + <li>Jaydatt Desai</li> + <li>Johan Svensson</li> + <li>Lan Boon Ping</li> + <li>Marc Grue</li> + <li>Michael Hunger</li> + <li>Muhd Kamil bin Mohd Baki</li> + <li>Nino Saturnino Martinez Vazquez Wael</li> + <li>Phillippe van Dyck</li> + <li>Peter Neubauer</li> + <li>Richard Wallace</li> + <li>Sianny Halim</li> + <li>Sonny Gill</li> + <li>Stanislav Muhametisn</li> + <li>Tao Wen</li> + <li>Tibor Mlynarik</li> + <li>Tobias Ivarsson</li> + <li>Tonny Kohar</li> + </ul> + + </div> + <div class="span2"></div> +</div> http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/get_help.html ---------------------------------------------------------------------- diff --git a/src/community/get_help.html b/src/community/get_help.html new file mode 100644 index 0000000..3e44453 --- /dev/null +++ b/src/community/get_help.html @@ -0,0 +1,47 @@ +--- +title: Apache Polygene⢠- Get Help +layout: default +--- +<div class="page-header"> + <h1>Get Help</h1> + <p class="lead">Join the mailing list to discuss and get help, or help others on Stackoverflow.</p> +</div> +<div class="row-fluid"> + <div class="span4"> + <h2> + Discussion + <img src="../landing-resources/img/feather.png" class="pull-right" style="height: 2em" /> + </h2> + <p> + To discuss with the Apache Polygene⢠community, it is easiest to do so at the + <code>[email protected]</code> + mailing list. + </p> + <p class="lead"> + To subscribe simply send an email to + <br/> + <a href="mailto:[email protected]";>[email protected]</a>. + </p> + <p>Read the browsable and searchable <a href="https://lists.apache.org/[email protected]";>archives</a>.</p> + <p>Also review general information about many <a href="https://www.apache.org/foundation/mailinglists.html";>other Apache mailing lists</a></p> + </div> + <div class="span4"> + <h2> + Questions & Answers + <img src="../landing-resources/img/logo-stackoverflow.png" class="pull-right" style="height: 2em" /> + </h2> + <p> + To post question to and get answers from the Apache Polygene⢠community, go to + <a href="http://stackoverflow.com/questions/tagged/apache-polygene";>StackOverflow</a>. + </p> + </div> + <div class="span4"> + <h2> + Found a bug? + <img src="../landing-resources/img/logo-jira.png" class="pull-right" style="height: 2em" /> + </h2> + <p> + If you found a bug or want to request a new feature, use the <a href="https://issues.apache.org/jira/browse/POLYGENE";>issue tracker</a>. + </p> + </div> +</div> http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/index.html ---------------------------------------------------------------------- diff --git a/src/community/index.html b/src/community/index.html new file mode 100644 index 0000000..961d33e --- /dev/null +++ b/src/community/index.html @@ -0,0 +1,35 @@ +--- +title: Apache Polygene⢠Community +layout: default +--- +<div class="page-header"> + <h1>Apache Polygene⢠Community</h1> + <p class="lead"> + Apache Polygene⢠is an open development community effort with an Apache ver 2.0 open source license. + </p> +</div> +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + + <h2>What does this really mean?</h2> + <p> + First of all, we work together to achieve the visions of Apache Polygeneâ¢, based on technical merits alone in an open and + friendly manner, mostly via the [email protected] mailing list. It means that everyone in the community are stake + holders in the resulting codebase, and noone can claim it is mine. + </p> + <p> + Secondly, all source code, artwork and documentation produced in Apache Polygene⢠are licensed very liberally under the Apache + License ver 2.0. This allows you to use our efforts in your own projects, whether they are open sourced, commercial + or any other arrangement you like, subject to a few terms like "Must re-distribute a Notice that your product + contains Apache Polygene⢠and such. See the License text for exact details, and please consult with IP rights lawyers about + this and other Open Source licenses. + </p> + <p> + Thirdly, Apache Polygene⢠invites everyone to participate. There are many ways to participate, not only by writing code. See + list in the <a href="participate.html">Participation</a> section. + </p> + + </div> + <div class="span2"></div> +</div> http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/licensing_faq.html ---------------------------------------------------------------------- diff --git a/src/community/licensing_faq.html b/src/community/licensing_faq.html new file mode 100644 index 0000000..72ca1fa --- /dev/null +++ b/src/community/licensing_faq.html @@ -0,0 +1,41 @@ +--- +title: Apache Polygene⢠Licensing FAQ +layout: default +--- +<div class="page-header"> + <h1>Licensing FAQ</h1> +</div> + +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + + <h2>Combined & Derived Work</h2> + <dl> + + <dt class="lead"> + <strong>Q</strong>: Can I use Apache Polygene⢠Core in my commercial applications under a closed-source, proprietary license? + </dt> + <dd> + <strong>A</strong>: Yes. The Apache License is very business-friendly. Please observe the obligations on your part, + especially regarding notices, trademarks and patent licensing terms. + </dd> + + </dl> + + <h2>Trademarks</h2> + <dl> + + <dt class="lead"> + <strong>Q</strong>: My company has invested a lot of time to learn and understand the Apache Polygene⢠platform, and we think we + are really good at writing Apache Polygene⢠applications and would like to start training others. Can we advertise that we are + "Apache Polygene⢠experts" or that we conduct "Advanced Apache Polygene⢠training"? + </dt> + <dd> + <strong>A</strong>: The Apache Software Foundation has a unified <a href="http://www.apache.org/foundation/marks/";>trademarks and branding policy</a>, which covers this question. This is somewhat more strict than the pre-ASF policy in the Apache Polygene⢠project, and if you have any doubts, please contact the Apache Polygene project for clarification. The intent of the Project Management Committee is to lean towards "permissible" rather than "exclusionary", as long as credit is given where credit is due. <strong>Also</strong> be aware that all references to "Polygene" MUST be "Apache Polygeneâ¢". + </dd> + </dl> + + </div> + <div class="span2"></div> +</div> http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/maturity.html ---------------------------------------------------------------------- diff --git a/src/community/maturity.html b/src/community/maturity.html new file mode 100644 index 0000000..14201f4 --- /dev/null +++ b/src/community/maturity.html @@ -0,0 +1,216 @@ +--- +title: Apache Polygene⢠Maturity Model +layout: default +--- +<div class="page-header"> + <h1>Maturity Model</h1> + <p class="lead">Apache Polygene⢠is hosted at the Apache Software Foundation and this is the + <a href="https://community.apache.org/apache-way/apache-project-maturity-model.html";>Apache + Maturity Model</a> self-declaration of its compliance..</p> +</div> +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + <div class="row-fluid"> + <div class="span6"> + <script type="text/javascript" src="//www.ohloh.net/p/13150/widgets/project_basic_stats.js"></script> + </div> + <div class="span6"> + <script type="text/javascript" src="//www.ohloh.net/p/13150/widgets/project_factoids.js"></script> + </div> + </div> + + <h2>Code</h2> + <dl> + <dt>CD10 <i class="icon-ok text-success"></i></dt> + <dd> + The project produces Open Source software, for distribution to the public at no charge. + </dd> + <dt>CD20 <i class="icon-ok text-success"></i></dt> + <dd> + The project's code is easily discoverable and publicly accessible. + </dd> + <dt>CD30 <i class="icon-ok text-success"></i></dt> + <dd> + The code can be built in a reproducible way using widely available standard tools. + </dd> + <dt>CD40 <i class="icon-ok text-success"></i></dt> + <dd> + The full history of the project's code is available via a source code control system, + in a way that allows any released version to be recreated. + </dd> + <dt>CD50 <i class="icon-ok text-success"></i></dt> + <dd> + The provenance of each line of code is established via the source code control + system, in a reliable way based on strong authentication of the committer. When + third-party contributions are committed, commit messages provide reliable information + about the code provenance. + </dd> + </dl> + + <h2>Licenses and Copyright</h2> + <dl> + <dt>LC10 <i class="icon-ok text-success"></i></dt> + <dd> + The code is released under the Apache License, version 2.0. + </dd> + <dt>LC20 <i class="icon-ok text-success"></i></dt> + <dd> + Libraries that are mandatory dependencies of the project's code do not create more + restrictions than the Apache License does. + </dd> + <dt>LC30 <i class="icon-ok text-success"></i></dt> + <dd> + The libraries mentioned in LC20 are available as Open Source software. + </dd> + <dt>LC40 <i class="icon-ok text-success"></i></dt> + <dd> + Committers are bound by an Individual Contributor Agreement (the "Apache iCLA") that + defines which code they are allowed to commit and how they need to identify code that + is not their own. + </dd> + <dt>LC50 <i class="icon-ok text-success"></i></dt> + <dd> + The copyright ownership of everything that the project produces is clearly defined and + documented. + </dd> + </dl> + + <h2>Releases</h2> + <dl> + <dt>RE10 <i class="icon-ok text-success"></i></dt> + <dd> + Releases consist of source code, distributed using standard and open archive formats that + are expected to stay readable in the long term. + </dd> + <dt>RE20 <i class="icon-ok text-success"></i></dt> + <dd> + Releases are approved by the project's PMC (see CS10), in order to make them an act of + the Foundation. + </dd> + <dt>RE30 <i class="icon-ok text-success"></i></dt> + <dd> + Releases are signed and/or distributed along with digests that can be reliably used to + validate the downloaded archives. + </dd> + <dt>RE40 <i class="icon-ok text-success"></i></dt> + <dd> + Convenience binaries can be distributed alongside source code but they are not Apache + Releases -- they are just a convenience provided with no guarantee. + </dd> + </dl> + + <h2>Quality</h2> + <dl> + <dt>QU10 <i class="icon-ok text-success"></i></dt> + <dd> + The project is open and honest about the quality of its code. Various levels of quality + and maturity for various modules are natural and acceptable as long as they are clearly + communicated. + </dd> + <dt>QU20 <i class="icon-ok text-success"></i></dt> + <dd> + The project puts a very high priority on producing secure software. + </dd> + <dt>QU30 <i class="icon-remove text-error"></i></dt> + <dd> + The project provides a well-documented channel to report security issues, along with a + documented way of responding to them. + </dd> + <dt>QU40 <i class="icon-remove text-error"></i></dt> + <dd> + The project puts a high priority on backwards compatibility and aims to document any + incompatible changes and provide tools and documentation to help users transition to new + features. + </dd> + <dt>QU50 <i class="icon-ok text-success"></i></dt> + <dd> + The project strives to respond to documented bug reports in a timely manner. + </dd> + </dl> + + <h2>Community</h2> + <dl> + <dt>CO10 <i class="icon-remove text-error"></i></dt> + <dd> + The project has a well-known homepage that points to all the information required to operate + according to this maturity model. + </dd> + <dt>CO20 <i class="icon-ok text-success"></i></dt> + <dd> + The community welcomes contributions from anyone who acts in good faith and in a respectful + manner and adds value to the project. + </dd> + <dt>CO30 <i class="icon-ok text-success"></i></dt> + <dd> + Contributions include not only source code, but also documentation, constructive bug + reports, constructive discussions, marketing and generally anything that adds value to the + project. + </dd> + <dt>CO40 <i class="icon-ok text-success"></i></dt> + <dd> + The community is meritocratic and over time aims to give more rights and responsibilities + to contributors who add value to the project. + </dd> + <dt>CO50 <i class="icon-ok text-success"></i></dt> + <dd> + The way in which contributors can be granted more rights such as commit access or decision + power is clearly documented and is the same for all contributors. + </dd> + <dt>CO60 <i class="icon-ok text-success"></i></dt> + <dd> + The community operates based on consensus of its members (see CS10) who have decision power. + Dictators, benevolent or not, are not welcome in Apache projects. + </dd> + <dt>CO70 <i class="icon-ok text-success"></i></dt> + <dd> + The project strives to answer user questions in a timely manner. + </dd> + </dl> + + <h2>Consensus Building</h2> + <dl> + <dt>CS10 <i class="icon-remove text-error"></i></dt> + <dd> + The project maintains a public list of its contributors who have decision power -- the + project's PMC (Project Management Committee) consists of those contributors. + </dd> + <dt>CS20 <i class="icon-ok text-success"></i></dt> + <dd> + Decisions are made by consensus among PMC members and are documented on the project's main + communications channel. Community opinions are taken into account but the PMC has the final + word if needed. + </dd> + <dt>CS30 <i class="icon-remove text-error"></i></dt> + <dd> + Documented voting rules are used to build consensus when discussion is not sufficient. + </dd> + <dt>CS40 <i class="icon-ok text-success"></i></dt> + <dd> + In Apache projects, vetoes are only valid for code commits and are justified by a technical + explanation, as per the Apache voting rules defined in CS30. + </dd> + <dt>CS50 <i class="icon-ok text-success"></i></dt> + <dd> + All "important" discussions happen asynchronously in written form on the project's main + communications channel. Offline, face-to-face or private discussions that affect the + project are also documented on that channel. + </dd> + </dl> + + <h2>Independence</h2> + <dl> + <dt>IN10 <i class="icon-ok text-success"></i></dt> + <dd> + The project is independent from any corporate or organizational influence. + </dd> + <dt>IN20 <i class="icon-ok text-success"></i></dt> + <dd> + Contributors act as themselves as opposed to representatives of a corporation or organization. + </dd> + </dl> + + </div> + <div class="span2"></div> +</div> + http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/participate.html ---------------------------------------------------------------------- diff --git a/src/community/participate.html b/src/community/participate.html new file mode 100644 index 0000000..0e6acc0 --- /dev/null +++ b/src/community/participate.html @@ -0,0 +1,66 @@ +--- +title: Participate to Apache Polygene⢠+layout: default +--- +<div class="page-header"> + <h1>Participate</h1> + <p class="lead">Apache Polygene⢠is a community based on open development principles</p> +</div> + +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + + <p> + The Apache Polygene⢠community is an open source community centered around software and components for Composite Oriented + Programming on Java/Scala, and related design methodologies that are enhanced by using Apache Polygeneâ¢, like Domain Driven + Design, DCI (Data, Context, Interaction) and HATEOAS REST. + </p> + <p> + The Apache Polygene⢠community is an open community, in so far as it welcomes any member that accepts the basic criteria of + contribution and adheres to the community's Code of Conduct. + </p> + <p> + Note that you can contribute to Apache Polygene⢠also by contributing documentation or giving feedback on the current documentation. + Basically, at all the places where you can get help, there's also room for contributions. + </p> + + <div class="well"> + <h4>[email protected] mailing list</h4> + <p> + To discuss with the Apache Polygene⢠community, it is easiest to do so at the + <a href="http://mail-archives.apache.org/mod_mbox/polygene-dev/"; target="_blank">[email protected]</a> mailing list. This list is open to everyone and regular open source forum etiquette applies. Failure to be respectful may cause the poster to be + expelled. The forum is a light and friendly one, where we are all friends working on a marvelous way of writing Java + code. + </p> + </div> + + <hr/> + + <h2>Principles of Participation <small>(not enforced yet)</small></h2> + <p> + We borrow a lot of our principles in community building from OPS4J, as OPS4J was the initial home of Apache Polygene, called + Qi4j back then. OPS4J is unique that it allows everyone to participate and modify the codebase + without being voted into the community. We want to retain the spirit of this openness and low-barrier of entry, but need + some structure to organize ourselves. + </p> + <p> + There is a social agreement among the community members that we should try to communicate our intent as much as possible, + but not be held back from doing things, just to get approval for the changes. Reverting changes are easy in GIT, so a + Commit-Then-Review policy is in effect. Individual changes can be vetoed, and the veto comes with a motivation to be valid, + and for additional features or bug fixes, the veto needs to provide an alternative solution within two weeks. The veto stands + either until the person who cast the veto withdraws it, or for two weeks and no alternative solution has been presented. We + think this strikes a good balance between progress and avoidance of catastrophic changes. + </p> + + <h2>I want to help, what do I do?</h2> + <p> + First of all, subscribe to [email protected] and introduce yourself. Secondly, take a look at the outstanding JIRA issues + and see if there is anything that you are capable of working on. Communicate that with the community. If there is no issues, + that you can manage, consider creating your own JIRAs, such as working on the Getting Started guide or more test cases. + </p> + </div> + <div class="span2"></div> +</div> + + http://git-wip-us.apache.org/repos/asf/polygene-website/blob/8334a62f/src/community/playing_field.html ---------------------------------------------------------------------- diff --git a/src/community/playing_field.html b/src/community/playing_field.html new file mode 100644 index 0000000..eff52d8 --- /dev/null +++ b/src/community/playing_field.html @@ -0,0 +1,102 @@ +--- +title: Playing field +layout: default +--- +<div class="page-header"> + <h1>Playing field</h1> + <p class="lead"> + <a href="http://mail-archives.apache.org/mod_mbox/polygene-dev/"; target="_blank">[email protected]</a> mailing list is a collaborative effort of open development, and we need to have some rules in place to make that work. + <br/> + Below is an evolving list of rules and guidelines that we try to follow. + </p> +</div> + +<div class="row-fluid"> + <div class="span2"></div> + <div class="span8"> + + + <h2>Coding Standard</h2> + <p> + The coding standard at Apache Polygene⢠promotes whitespace to aid in reading the code. Opening braces are placed on new lines, + spaces are between operators and so forth. We are following the OPS4J coding standards, as they have IDEA, Eclipse and + Checkstyle templates prepared or in the works. These are slowly evolving, and it is likely we will evolve with them. + The coding standards can be found in + <a href="https://github.com/apache/polygene-java/tree/develop/etc";>https://github.com/apache/polygene-java/tree/develop/etc</a>. + </p> + + <h2>Design and Implementation work</h2> + <p> + We want all discussions around the design and implementation to happen on the [email protected] mailing list. + But we also recognize that instant messaging, voice and face-2-face are important tools to + increase productivity. The participants are expected to convey in a comprehensible format (not just a copy/paste of + the IM log) any new development, ideas and progress that occur during those sessions. The decisions for any multiple + choices should be made on the [email protected] mailing list only. + </p> + <h2>Community Structure</h2> + <h3>Committers</h3> + <p> + rights to the codebase. Committers are invited by other committers, typically after some contribution via JIRA (Pull Requests + The term "committer" is often used in open development efforts, and in Apache Polygene⢠it refers to the individuals who has commit + are not yet fully supported by the Apache infrastructure, but may change in the future. ) + </p> + + <h3>Project Management Committee</h3> + <p> + Apache has a concept called <i>Project Management Committee</i> (or PMC for short), which is the stewards of the codebase/project. + It is up to each PMC to define the rules for the project, who gets invited, the workflow for changes and evrything else + that is not required from the Foundation itself, such as Licensing, Releases, Branding and source control management. + </p> + <p> + At Apache Polygeneâ¢, we want to see all active committers to be part of the PMC. To have a voice of the future of the project. + Committers that are inactive are encouraged to resign from the PMC, but will retain the committer status and invited back + to the PMC again, once activity picks up. This will not be enforced, but purely on voluntary basis. + </p> + <h3>PMC Chair & VP of Apache Polygeneâ¢</h3> + The PMC Chair is an appointment by the Board, and acts as the link between the project and the Board, primarily for so called + <i>oversight</i>, i.e. that the Board has knowledge of any community issues in a project. The PMC Chair is an <i>Officer</i> + of the Foundation, but in reality the Chair is a glorified secretary, responsible for providing a short report once every + quarter and answer any questions that the Board may have. + + <h2>Votes on releases</h2> + <p> + All committers agree that all releases should be voted upon before the release is made. Releases should happen early + and often, to shorten the feedback loop. All committers of the subproject being released has a binding vote. Everyone + else has a vote of recommendation. Releases can be vetoed for two reasons; Incompatibility and Legal. + </p> + <p> + Incompatibility is not a reason within the 0.x series and not a reason between major versions, such as 1.3 -> 2.0. + </p> + + <h2>Reverts of commits</h2> + <p> + There are cases when we need to revert commits made by people. Common sense should rule, but the above cases of + incompatibility and legal reasons are two obvious examples. Sabotage, misunderstandings and mistakes are others. + When such cause arises, the issue should be brought to the [email protected] mailing list, explained why the + commit should be reverted, and if noone objects within 48 hours, the commit can be reverted. If the concern results + in a debate, then the issue is resolved in a simple majority vote among the committers. + </p> + + <h2>Infrastructure issues</h2> + <p> + Any infrastructure requests or problems, should be directed to the [email protected] mailing list. + </p> + + <h2>Trademarks, Patents and Licenses</h2> + <p> + Apache Polygene⢠is licensed under the Apache License version 2.0. All committers agree that all their contributions are licensed + under this license to Apache Polygeneâ¢, other committers and the general public. The Copyright of each contribution is held by the + contributor, and no Copyright assigns are required. + </p> + <p> + All committers assert that no patents are hidden within their contributions or that if such patent exists then such + patent is freely licensed to Apache Polygeneâ¢, other committers and the general public. + </p> + <p> + All contributors agree that the Apache Polygene⢠project may change to a later version of the Apache License, if/when such license + becomes available and the Core Dev Team at that time finds it appropriate. + </p> + + </div> + <div class="span2"></div> +</div>
