Date: Thu, 28 Mar 2024 19:57:22 +0000 (UTC)
Message-ID: <1098206357.67.1711655842887@c07068646a9f>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_66_153209176.1711655842886"
------=_Part_66_153209176.1711655842886
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Introduction
This is a set of best practices for IzPack developers and contributors.<=
/p>
It tries to be normative without putting too much bureaucracy in the pro=
cesses.
General recommendat=
ions
- Be friendly. The IzPack community has always been like that and we don'=
t want that to change!
- A new feature must always be documented, else there is no point in addi=
ng it!
- Any idea or code change must be reported in an issue from our =
JIRA instance.
This helps us to have an overview what's going on, to plan releases as well=
as generating complete and meaningful release notes.
Please keep in mind that most IzPack developers are volunteers that are =
not paid for developing it. We do it for fun on our free time, so please do=
n't expect the same level of support as if we were a company (but we're doi=
ng our best to be as close to that as possible ).
Recommendatio=
ns for developers
General recommend=
ations
- Always create a JIRA issue.
- Use meaningful comments when doing a commit/push/pull request.
- Always mention the JIRA issue that is related to your commit (e.g., "Fix for JIRA-123").
Especially use the JIRA issue ID(s) in the title of the pull request - in t=
his case there is automatically created a link to your pull request in the =
according JIRA issue(s).
- When doing a commit based on a patch from a contributor, make sure to m=
ention the contributor name in the comment (e.g. "Fix for JIRA=
-123. (Contributor name)" ).
- Never commit incomplete changes (GIT is not a backup system).
- Use a Git branch per issue, best with a JIRA issue ID as branch name.
This allows you to easily send updates to pull requests, for instance if yo=
u get errors in the connected CI builders.
- Don't maintain Versions.txt anymore, we will extract release n=
otes from JIRA starting from IzPack 4.0 and beyond.
- Subscribe to the developer mailing=
list to follow IzPack development conversations.
- Do not hesitate to pick new JIRA issues=
a>: both the other developers and the issue submitter will thank you for th=
e work!
- When you start working on an issue, don't forget to mark it as in p=
rogress so that we know that you're solving it!
- For developing workflow will be: Open -> In progress -> Resol=
ution -> Resolved -> Closed
- For language file update: Open -> Resolved -> Closed
- For more information about an issue please visit: What is an Issue?
Reporting issues and improving the documentation
- Always create a JIRA issue in case of b=
ug, improvement or new feature. You can follow progress of your issue there=
.
- In case you located a necessary change in the code, don't send bigger p=
atches, try to fork the master repository at Github and=
create a pull request instead.
If you can't send a pull request for some reason and you have a patch, then=
attach it to the JIRA issue.
Make sure you send a real diff-generated patch, not whole files or ZIP=
s with the modified files... (Several programs will generate this, for exam=
ple: IntelliJ, Eclipse, Netbeans, TortoiseSVN,...)
Anyway, sending pull requests most probably decreases the waiting time for =
your change to be merged, because it costs us less effort to handle it!&nbs=
p;
- Do not hesitate to attach screenshots and stack traces.<=
/li>
- In case of a new feature proposal make sure to attach documentatio=
n to an according JIRA issue.
- Subscribe to the develop=
er mailing list if you want to follow IzPack development conversat=
ions.
Avoid sending patches or copying code parts with patches to the mailing lis=
ts - this blows up discussion threads and probably nobody will be able to h=
andle this, thus, it will be probably ignored. If you have particular sugge=
stions, send it as pull request for an easy reviewed by everyone.
- Respect code format styles! Otherwise we have a hard time trying t=
o merge your code.
Code reviews
Before merging a pull request or a patch submitted by an external contri=
butor, developers are expected to make a simple code review.
- Look at the code carefuly to ensure that it is of good quality
- Obviously... test it
- Attach your review to the related JIRA issue
- Send your review to the dev mailing-list if needed.
In case no other developer makes a comment after a few days, you can act=
as you decided: accept or reject it!
The src folder in the IzPack source code contains code =
style settings for Eclipse and IntelliJ IDEA.
Everyone has its own preferences, so to make everyone comfortable, here =
are a few things to respect.
The preferred style is ANSI-style, i.e., we prefer:
if (i =
=3D=3D 0)
{
doThis();
}
else
{
doThat();
andThat();
}
over:
if (i =
=3D=3D 0) {
doThis();
} else {
doThat();
andThat();
}
of even this:
if (i =
=3D=3D 0) doThis();
else {
doThat();
andThat();
}
You may prefer putting braces on end of lines rather than on new lines, =
but in this case please don't be feel offended when we run code formatting =
from times to times
Taking the project from version repository you will have Eclipse setting=
s for the IDE and code formatting.
You should avoid long width lines. 80 characters is probably short nowad=
ays. 100-120 characters looks like to be a good limit.
As of IzPack 5.0 we guarantee to provide at least Java 6 compatibility for installer execution, use it as the language s=
ource and target version.
Using 3rd-party li=
braries
- Please try to use built-in 3rd-party libraries in favor of implementing=
your own solutions.
During coding, if you find code parts which might be replaced by patterns p=
rovided by existing 3rd-party libraries replace it.
For example, Apache commons-io should be used for copying files or assembli=
ng filenames independently from the OS instead of accessing java.io and str=
eams directly.
- Do not add new 3rd-party libraries which have to be merged by default t=
o the resulting installer without a discussion (mailing lists, JIRA).
The reason is not blowing up the installer size without a good reason.
------=_Part_66_153209176.1711655842886
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Location: file:///C:/7b09ab1071aa5ecee8f7e1cb29086d03d978ef61f719644c974646cb9b91976e
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAALGPC/xhBQAAACBjSFJN
AAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACXBIWXMAAKfwAACn8AG1cEgF
AAABWWlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpu
czptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9
Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp0aWZmPSJodHRwOi8v
bnMuYWRvYmUuY29tL3RpZmYvMS4wLyI+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8L3Rp
ZmY6T3JpZW50YXRpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv
eDp4bXBtZXRhPgpMwidZAAACNElEQVQ4EY1TTY9MURA9dV/3vCZh0JJJzCxELNg1C2Jhg4iQFktr
EsO/mH/BLFhb+oogTCIWE9+9QyKGZJpMaGYiae/N63fLqXpamghucm9uquqc+hbwqM4EkZno/86J
PYh6itKDVGyFQhBkge8cJFyU1pVHoxgZgtUMn7fPoxam0UiAbyVQOCdQD8AayjLKBpjFrqvnREhv
jis2gjvH72B87JD2ckOVNCACRPqJdEA0EmmmASurd9G6dthIKgPz7OAsl5qIpEmdxkOwMQSTmU57
WW62Hi0VopZz0Ieaxyh1kd6nTF68+YJ9rQkkVYAoo2K+s4Sd2zaiubmhWqhKGgKi7A3UnvacGTb5
5PaDd9h/5jFeLSyD9fBrf5OZzmz4lI5hsQOzP+AFq3Km7j+O2VqR2SmJT9oDUiYsEpgjer0Mf02h
2YAO2DKLQzAQfdou2Oua+XWSxOh4hy00hR1rZalQXgebjARMQd66EiyJsbJgJLS6m0l17G8y6n6A
o2OIDVTM2ZB4n1m0Dx/7uD+/iH6/oL06n/1NZjorrNvaYEHu/dpGxhNLlcs3X+PGrZeYmhr3CLqL
Kzh2ZAdOHt2OkHB4I3620ePUZ+0L2JBO6+c8l4AxhCDd91/RXaJHnsmJtZjcso4pMKaIVdmUpljO
Z2X39bMVge3ByCgzz5I5Jky4mkaDFYxN/zDK1TKxEpxtZ7UJW1+vUxI0H8Cu/U3m00fPwz0YWSZu
1b/WmQVjZy79vs7fAdlwN9BZNtNNAAAAAElFTkSuQmCC
------=_Part_66_153209176.1711655842886
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Location: file:///C:/a189c8b76350f30f718cb751c084a77375f1bbeb0cdede9618e08e244d8b54ab
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAALGPC/xhBQAAACBjSFJN
AAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACXBIWXMAAKfwAACn8AG1cEgF
AAABWWlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpu
czptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9
Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp0aWZmPSJodHRwOi8v
bnMuYWRvYmUuY29tL3RpZmYvMS4wLyI+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8L3Rp
ZmY6T3JpZW50YXRpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv
eDp4bXBtZXRhPgpMwidZAAAC1klEQVQ4EV1TS08TURT+zp1HHyAPaYgNLmpCYnSFGjExrqRhZUF/
AC7YVP0BRne4IS5Y6EKRGI2JK+PGR4wJARYGQ8BQ0OjCUGMMQgkRaK2lnencez130IjM887M+b7z
nW/OIfCm9ZAgGlLhevF8N5QcBKiHP6SgQRD0la9TIPGAup7N7cbQX7DmQJnLjFqulUXcBip1wA85
AUcAMQuoSSDAGI49v0zE9CbxDhtIL/SNU3s0rdeq6sdWVbY2RS3bJqGZg4MNk1RKWyIRFSj5E+h6
0WtImBpQnNmAP02veiP3c/T09RdnuxYIg+QDXIKARY6I24Si76HJSWOhf9RgyX93rttpdGffvllW
UzPf6MpAF7UlYkDdpGbVnsSTV3mUKx5SB1uQPt2hozFHQ/Cu6ZRwLGsQDqEh7sir2ZPU2uRia6Nm
srK7gG0JZHpSuHjhCPY3RzB8d45KJTajgX1is0nn+pZYXidrVQiUuPP4Az4vFXDz2lnEYxzEBKVi
DbPv13G0s5WdYz8jtkok40J7Ki+g9KFQri9FrRZgKV9AbsJD8acHuBY2N6u4/WgBuY9rGBmbQaVa
R+JAXKjtgCvUKdLzmTpLtQ0zsUcT09+xXChjoP8wbFvgV8U3lWAfy5fsR6nsh6UYA5kh+FdCXZlf
FToPJgrtD/iVxWvjhzFVMZV5lvxzHSH4nuciaZKbpBN1LbkzBHG/rKyU2fU6ku3x0MjV9W00Nbro
SDZAMymRkIxheXLSZvaH3GFZjrRMY/BO0YiN68NTWF8JhaK9A7h1ozd8CGM4NuxKxrIehuYy99AS
yWLT85jBJduijY0qpucLIejMiSTa2mKcXWpuLTYhEkHRG6PjLy/tEJiBWewbR7ObZhLFhkqyhRU2
i6FQXH2gJGe3GPx/K+8MEwvn3jascIWgZscxYO1LmNOsw3f8LYz5Mwe7hmlozzhrHmf9/zgbs03N
e8b5N97yXqEQUVj4AAAAAElFTkSuQmCC
------=_Part_66_153209176.1711655842886--