Wicket Stuff is a collection of open source projects for the Apache Wicket web framework created and maintained by the Wicket community.
The core release is essentially a container into which developers place their project that ensures that regular releases are made that pair the projects to a specific wicket version.
The project acceptance criteria is very broad. So long as it is wicket related you are welcome to add in your module.
Our release process allows end users an easy way to track a project relative to the wicket release cycle.
For example, if a user sees a org.wicketstuff:someproject artifact with a version of 220.127.116.11 they can know immediately that it is based on wicket 1.4.16 and that it is the first point release (the 1.4.16 version would have been the original release).
Although all participating projects are released under the wiketstuff-core umbrella you need to specify the artifacts of interest individually (see the Participating Projects section below for information on the artifact names).
Releases are available through maven central like this:
<dependency> <groupId>org.wicketstuff</groupId> <artifactId>phonebook</artifactId> <version>1.4.19</version> </dependency>
1.5.x releases starting from 1.5-RC5.1 have renamed the artifact names to include a wicketstuff- or wicket- prefix. This avoids confusion when inspecting the jars in the classpath where the wicketstuff and upstream jars would have had the same name.
<repository> <id>wicketstuff-core-releases</id> <url>https://oss.sonatype.org/content/repositories/releases</url> <releases> <enabled>true</enabled> </releases> </repository>
Presently there are three snapshot versions available:
They are available through the OSS Sonatype Snapshot Repository.
You can use them by adding the following
<repository> to your own projects
<repository> <id>wicketstuff-core-snapshots</id> <url>https://oss.sonatype.org/content/repositories/snapshots</url> <snapshots> <enabled>true</enabled> </snapshots> </repository>
Issues can be entered here: https://github.com/wicketstuff/core/issues
Changes to pages in this wiki can be modified by any github user. Simple changes can be done using the edit and new page functionality within github.
Inserting images needs to be done by checking out the wiki git repository (you will need push access to submit changes this way). See Editing Wiki Locally for more instructions.
Please send an email to the wicket developer mailing list with a subject of Wicket Stuff commit access and your github.com username.
New build server: The current status of a build can be watched on Travis CI: https://travis-ci.org/wicketstuff/core/builds
Because the project is public there is no login required.
While Travis is automatically triggered after every change in the git repository and also deploys the snapshot-artifacts to the maven repositories there is currently as an addition a Jenkins instance running under http://18.104.22.168/jenkins/job/wicketstuff/ which builds daily the Wicketstuff master branch along with the Maven-site and different reports (like Findbugs, CPD, code coverage, etc.)
Outdated build server: http://ci.wicketstuff.org (any developer with commit access can login if the user is a public member in the wicketstuff organization.)
When the wicketstuff-core project is released there is an announce message that is sent to the wicket users mailing list. A part of this release message gives a brief summary of what has changed since the previous release.
We use the
git shortlog command that prints out the commits of interest like this:
git shortlog wicketstuff-core-1.4.17..wicketstuff-core-22.214.171.124 will show the changes between these two tags in a format like: user.name (# of commits): first line of first commit first line of the second commit ... first line of the nth commit
So the first line of your commit is important since it will appear in this listing. It should be informative about the module that is effects and a brief note about the change. If the user is interested they can lookup the full commit message and see the full details about the change.
Full documentation about releasing can be found at Wicket Stuff Core Release Process
Wicket 1.4.x and wicket 1.5.x is compiled under Java 5 so the default is to have your project in the jdk-1.5-parent sub directory.
NOTE: When building a project under jdk-1.5-parent a new environment variable needs to be setup
JAVA_5_HOME, which points to the
JDK_HOME for your java 5 installation
If you project has Java 6 dependencies then it should be placed into the jdk-1.6-parent sub directory. It is also possible to have split projects where some modules are Java 5 and others are Java 6.
The contract is that we build Java 5 modules first and then Java 6.
Wicket 6.x will be compiled using Java 6 so there will not be a jdk-1.5-parent folder but there will be a jdk-1.6-parent and jdk-1.7-parent sub directory.
Wicket 7.x will be compiled using Java 7 / Servlet 3 API so there will be a jdk-1.6-parent and jdk-1.7-parent sub directory - jdk-1.5-parent folder is dropped ot.
Create a new subdirectory in
jdk-1.5-parent or jdk-1.6-parent` to contain your project artifacts. The suggested structure is:
/yourproject-parentwith a pom packaging.
/yourproject-parent/yourprojectwith a jar packaging
/yourproject-parent/yourproject-exampleswith a war packaged web application that demonstrates your project.
The preferred naming convention for folders is to not include wicket _or _wicketstuff in the title, just a descriptive name. BUT remember to prefix the artifactId of your JAR module with wicketstuff-. If you want to prefix all of your artifacts, please do it.
i.e. not wicketstuff-datatable-autocomplete but datatable-autocomplete.
Then edit the modules section of the
jdk-1.6-parent/pom.xml to include the top level directory of your project. This is what tells the core build process to also process your module and is what will get your project included in the SNAPSHOT and release versions of wicketstuff-core.
In April 2011 the wicketstuff committers decided to unify the code formatting of the different wicketstuff projects (see the discussion and the voting if you are interested in the details). This should be applied to existing and future projects too.
The main rule is: we follow Apache Wicket style of formatting+clean up in java files. In xml, html, js, css files tab is used for indentation.
These rules are currently not enforced/checked by an automated process. The main reason behind this is that contributors can use different kind of developer environments so the repo is kept IDE independent (no IDE specific files in locations where they would be picked up automatically). Devs can provide/use IDE specific settings in the config directory of the repo.
To keep the code consistent from time to time the whole java code is reformatted. These formatting changes are committed/pushed separately without any functional change.
By default test cases for Wicket Stuff modules must have a class name ending with Test. If you need to use a different name you can specify a different name pattern in your pom with plugin maven-surefire-plugin.
Wicket is Apache licensed, but Wicket Stuff is not. Anyone is free to contribute and the various modules are licensed under whatever terms their authors choose. This enables authors to use some cool libraries that can never be used in Wicket Core or Wicket Extensions because their licenses are incompatible the ASF one. The pom.xml of your project is the place to set the license. By default your project will be licensed under the Apache 2 license (this is inherited from the root pom.xml). Override this setting in your parent pom if you want a different license.
The main git documentation is here: http://git-scm.com/documentation (If you have an hour the Linus Torvalds video is fun)
We are using the same topology that we used with subversion. There is a central server (github) that has the repository and then each developer has a local working copy where they make their changes. The difference is that in git each 'working copy' on the developers computer is a full copy of the remote repository with all of the commit, branch and tag history.
Developer Git: GitHub Local Branch (core-1.4.x) | \ / Remote Branch --> Local Branch (remotes/origin/core-1.4.x) (core-1.4.x)
From your local repository you can 'pull' changes from the GitHub Local Branch into your Remote Branch and then merge those changes into your Local Branch.
If you are a committer then you can 'push' the changes (possibly several commits) you have made on your Local Branch through to GitHub which will update both your Remote Branch (a copy of the github local branch) and the GitHub Local Branch.
Important Git has many tools for altering the commit history of a branch. While these are useful for local work they should not be used on the github published branches themselves.
This is because if you change the commit history of a branch that has been shared with others it will break all of those users the next time they pull down new changes.
You can fork the project in github, make your changes and then create a pull request from your fork of the project.
Some useful git commands are located on the Helpful-Git-Commands page.
Development proceeds along the core-1.4.x and master branches. On at least a monthly basis a release is cut on each branch.
As a developer you don't need to care about what the next release is. Once you commit changes they will be included automatically in the next release on that branch.
The release version will match the current wicket release if the wicket release is new. Otherwise it will be a point release like 126.96.36.199 which still matched wicket 1.4.9 but included wicketstuff core changes committed after 1.4.9 was released.
(This is copied from the pom.xml initially, Developers please edit this page for your project and create a better name and link to your project page)