Nothing Special   »   [go: up one dir, main page]
Skip to content

Home

Jump to bottom Edit New page
Martin Grigorov edited this page Jan 21, 2014 · 86 revisions

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 1.4.16.1 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).

Downloading Releases

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>

Current Stable Releases

  • 1.4.20.1 tracks Wicket 1.4.20 (released April 19, 2012)
  • 1.5.7 tracks Wicket 1.5.7 (released July 3, 2012)

All releases since 1.4.7 are available through maven central and oss.sonatype.org

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>

Downloading Snapshot Releases

Presently there are three snapshot versions available:

  • 6.0-SNAPSHOT that tracks wicket 6.0-SNAPSHOT
  • 1.5-SNAPSHOT that tracks wicket 1.5-SNAPSHOT
  • 1.4-SNAPSHOT that tracks wicket 1.4-SNAPSHOT

They are available through the OSS Sonatype Snapshot Repository.

You can use them by adding the following <repository> to your own projects pom.xml:

<repository>
	<id>wicketstuff-core-snapshots</id>
	<url>https://oss.sonatype.org/content/repositories/snapshots</url>
	<snapshots>
		<enabled>true</enabled>
	</snapshots>		
</repository>

Developer Information

Reporting Issues

Issues can be entered here: https://github.com/wicketstuff/core/issues

Editing the Wiki

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.

Gaining Commit (Push) Access

Please send an email to the wicket developer mailing list with a subject of Wicket Stuff commit access and your github.com username.

Accessing the Jenkins Build Server

Any developer that has commit access to the github.com/wicketstuff/core repository can login and view the build status at http://ci.wicketstuff.org.

Due to some issues with the Jenkins Github Oauth Plugin you need to make yourself a public member in the wicketstuff organization to be able to login.

Release Message

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-1.4.17.1

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

Java Version

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.

How to contribute a new project

Create a new subdirectory in jdk-1.5-parent or jdk-1.6-parent` to contain your project artifacts. The suggested structure is:

  • /yourproject-parent with a pom packaging.
  • /yourproject-parent/yourproject with a jar packaging
  • /yourproject-parent/yourproject-examples with 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.

i.e. <artifactId>wicketstuff-datatable-autocomplete</artifactId>

Then edit the modules section of the jdk-1.5-parent/pom.xml or 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.

Code Formatting

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.

Naming convention for test cases

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.

Licensing

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.

Git Workflow

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.

Alternate Workflow

You can fork the project in github, make your changes and then create a pull request from your fork of the project.

Helpful Git Commands

Some useful git commands are located on the Helpful-Git-Commands page.

Release Process

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 1.4.9.1 which still matched wicket 1.4.9 but included wicketstuff core changes committed after 1.4.9 was released.

Participating Projects

(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)

Add a custom footer
Add a custom sidebar
Clone this wiki locally