Well, all versions, as it is a new feature. I developed it directly
against trunk, not any of a number of older deployed versions.
I've got another change I've been working on, that I'll do this new
way. Basically, Start.java will now take over stdout/stderr, run it
through a TeeOutputStream, with output being sent do the original
stdout/stderr, and to a file, then after full startup, the original
stdout/stderr is turned off. Whenever the output file gets to be a
certain size, or midnight happens, then the file is auto-rotated, and
$last_file+1 is auto-compressed.
I wrote this against trunk as well, in response to java 1.7 running on
debian wheezy i386, but on top of xen, not working with 2G console.log
files. The key difference to this is the "on top of xen".
Without this patch, ofbiz would need to be restarted externally, and the
log rotated. With the patch(es), it stays up basically forever.
On 08/13/2014 03:21 PM, Jacques Le Roux wrote:
You can still create a Jira issue and select the concerned versions
Jacques
Le 13/08/2014 21:54, Adam Heath a écrit :
On 08/10/2014 08:19 AM, Jacques Le Roux wrote:
As mentioned Jacopo, the Jira issue creation can be done after, even
by another person.
The point is to collect changes by versions (releases)
Jacques
Le 10/08/2014 14:14, Jacques Le Roux a écrit :
Also I forgot to mention (again) that, with our new policy to
automatically grab new features or bug fixes from Jira, a direct
commit should not happen for major new features or bug fixes.
We shall first create a Jira issue, even we you don't submit a
patch (which is preferable for peers reviews), in order to fill the
version to allow creating reports like
https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12327361/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
Oops, missed this, my bad, on my recent parallelization changes.
ps: I really wish that there was some kind of git-based workflow.
