Message-ID: <1638952293.42236.1371705150239.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_42235_1065470197.1371705150238" ------=_Part_42235_1065470197.1371705150238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The continuous integration build can be found under:
needs registr= ation
The JIRA issue tracker:http://jira.c= odehaus.org/browse/GPARS
The Git repository held at GitHub is the official m= ainline:
To work on the codebase please fork the repository on GitHub= in the usual GitHub workflow way. Keeping the master branch as a mirror of= the mainline, working on a feature branch and then sending in pull request= s based on that feature branch seems to be the best way of working.=C2=A0Pl= ease refer to the Git and GitHub documentation for any further details on u= sing Git and GitHub.
A repository that is a mirror of the GitHub repository is m= aintained at Codehaus in order to continue integration with various continu= ous integration servers (over time more of this will migrate to GitHub). Al= so this Codehaus project remains the location of the issue tracker and is t= he route for artefacts to get into the Maven repository.
You should n= ever need to clone this repository, but for completeness, the command:<= div class=3D"code panel" style=3D"border-width: 1px;">
git clon= e git://git.codehaus.org/gpars.git GPars=09=09
creates a clone of the repository in the subdirectory GPars.= =C2=A0The above URL gives read-only access to the repository. Those people = with write access to the repository should use the URL:
= Project commiters and contributors typically keep their personal clones of = the main repository for feature branches:
The gradlew script will download and setup gradle for the= project and execute the build.
gradlew = clean build=09=09
Create an IDEA or Eclipse project files through gradlew idea or
Upon start or right before buil= ding the project IDEA will prompt you for the JDK to use. Once you specify = that on the project level, you should be good to go.
GPars holds a default IDEA project file in the root of the proje= ct and is named GPars_IDEAX.ipr. This project serves as a master c= opy for the generated project files (see above) and also to configure our C= ontinuous Integraion. If you for some reason decide to use the default proj= ect file, you need to go through a few configuraion steps first.
first time you open the project you will be prompted to enter a PROJECT_JDK=
_NAME and a MAVEN_REPOSITORY variable. These are IDEA variables an=
d not system variables. The result is stored in your home directory.
= Each developer can have a unique value. For example, your MAVEN_REPOSIT= ORY may be a path on your disk, and PROJECT_JDK_NAME can be a= ny string value, e.g. "1.6". This is the name of the Global JDK d= efined defined within IDEA. You can setup a global JDK in IDEA under File-&= gt;Project Structure->SDKs. There is a little text box to fill in where = you give the JDK a name. Whatever you typed into this textbox needs is what= needs to be typed into the IDEA Environment Variable screen for PROJECT_JD= K_NAME.
The MAVEN_REPOSITORY variable should point to your l=
ocal maven repository, which IDEA will be using to keep downloadable artifa=
cts of third-party libraries that are needed to build and run GPars. You need to populate the repo first for IDEA to find the necessary artif=
acts. The best way to do so is to open the /java-demo/pom.xml file=
(provided Maven support is enabled in your IDEA installation) and ask IDEA=
to Import changes. Alternatively you can use the Ref=
resh button in the Maven tool window.
Future IDEA environment va= riables can be declared within the .ipr and .iml with the syntax $VAR_NAME$= . Anything undefined at project startup will prompt the user for entry.
If you plan to contrib= ute code to the project, please check out our brief code style guide to make sure your contribution fits sea= mlessly with the rest of the code base.
Notice the --no-ff flag when merging.=
Note that this workflow is applicable to all people whether they are= committing authors or not. =C2=A0It's just that non-committing authors hav= e to convince a committing author to do the commit. =C2=A0A consequence is = that people should not be advised to submit patches on JIRA issues, but ins= tead to specify where their feature branch is so it can be pulled. Obviousl= y patches work as well but the whole point is for everyone to publish their= feature branches so others can review them in a VCS context.
Trivial spelli= ng error fixes, extra tests that don't necessitate a change of code but jus= t extend the test coverage, and very simple (non-controversial) bug fixes w= ith their tests are currently exempt from having a review process. Discreti= on on the part of committing developers is required here. (git pull; fi= x; commit; git push) or (git pull; git checkout -b myFix; fix; com= mit; git checkout master; git pull; git merge --no-ff myFix;git push)<= /p>
In build.gradle and in doc.prop= erties set the version property
version = =3D '1.0.0'=09=09
Also update the ReleaseNotes.txt file.
Update the "What's new= " section of the user guide as well as the ReleaseNotes.txt file
Issue a full rebuild either for a snapshot
or a proper release
Make sure all demos work
Run the Release build plan on Bamboo, which will make all the = artifacts available for download.
Make sure your codehaus = credentials are in $USER_HOME/.gradle/gradle.properties
or specify your credentials directly in the uploadArchiv= es task in build.gradle and add uploadArchive task t= o the desired build task:
Check out that the artifacts have been successfully uploaded= either at https://dav.codehaus.org/snapshot= s.repository/gpars/ for snapshots or at https://da= v.codehaus.org/repository/gpars/ for proper releases. = Within a couple of hours the new proper release should be = propagated into the maven central repository at http://repo1.maven.org/maven2/org/codehaus/gpars/gpars/.
After a proper release the older snapsh= ot artifacts should be removed manually from the snapshot repository at https://dav.codehaus.org/snapshots.repository/g= pars/. Any webdav client, like e.g. AnyClient (http://= www.anyclient.com/download.html) should be capable to do so.
The generated User Guide at /build/docs/manual should = be uploaded to http://www.gpars.org/guide/ .
The javadoc an= d groovydoc folders should be copied to http://gpars.org/java= doc/index.html and http://gpars.org/groo= vydoc/index.html respectively.
After a proper release = the version in the build file has to be changed to the next version.
Proper releases should be also closed in JIRA.
People are impatiently waiting for=
the new GPars features so now it is the highest time to tell them. New
<= a href=3D"http://xircles.codehaus.org/projects/gpars" class=3D"external-lin= k" rel=3D"nofollow">http://xircles.codehaus.org/projects/gpars
Af= ter a proper release create a tag in the VCS with sources = that were used to make the release. Label the tab using the release-x.x= pattern.------=_Part_42235_1065470197.1371705150238--