I don't particularly care one way or another if groovy files have a
semi-colon at the end. I don't even care about consistency because it is
such a minor thing.
I say remove them if they're on a line you happen to be editing, otherwise
just leave them be.
Regarding the annotations, there's
Le 13/09/2016 à 21:28, Jacques Le Roux a écrit :
OK found that the same than in Subclipse also exists in TortoiseSVN
But you need to use a command line (weird for a GUI), eg (from TortoiseSVN root
folder)
Actually wrong, simply pick a file in Windows file explorer using TortoiseSVN
context
OK found that the same than in Subclipse also exists in TortoiseSVN
But you need to use a command line (weird for a GUI), eg (from TortoiseSVN root
folder)
TortoiseProc.exe /command:blame
Le 13/09/2016 à 17:06, Rishi Solanki a écrit :
Agreed on the fact that its an pain to backport the bug fixes to releases.
Especially when we have to change something manually and it has been done
with many files in last few months i.e bulk changes with all files of xType.
I'm not sure, but what
BTW thinking about it, don't you have something similar in IntellIJ?
I found an (old) image there
https://markphip.blogspot.fr/2006/12/subclipse-live-annotations.html
Jacques
Le 13/09/2016 à 20:16, Jacques Le Roux a écrit :
Thanks Jacopo,
I found how to use it in TortoiseSVN (it starts
Thanks Jacopo,
I found how to use it in TortoiseSVN (it starts from the log view)
It's complementary to what Subclipse gives and so interesting but not
comparable.
You don't have this global view Subclipse offers with each annotation by line
from start (r1) to HEAD.
Very useful with colored
Hello Folks,
After quite a bit of work, I have a first working PoC for the plugin system
with the following highlights:
- Plugins are OFBiz components that reside in /specialpurpose (hopefully
renamed to /plugins later)
- Plugins can be published to maven repositories and retrieved from maven
Some examples:
svn blame README.md
after review you run
svn blame README.md -r 1:1757044
and then
svn blame README.md -r 1:1757042
and so on to get back in history... nothing is lost, annotations are always
there.
Jacopo
PS: I think there is some trick to do the same with TortoiseSVN but I
Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
...
Before applying a such change, I'd really like to know if everybody is
aware of what that means when it comes to svn annotations. I repeat: we
will
Agreed on the fact that its an pain to backport the bug fixes to releases.
Especially when we have to change something manually and it has been done
with many files in last few months i.e bulk changes with all files of xType.
I'm not sure, but what is the good time to do such changes (may be just
Sorry, I started this thread by asking this question:
>While committing r1760406 I wondered if I should really put semicolons at end
of Groovy files lines.
>We know it's useless in Groovy. Should we continue to put them, and if yes for
which reasons?
The question switched to "should we
On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> ...
> Before applying a such change, I'd really like to know if everybody is
> aware of what that means when it comes to svn annotations. I repeat: we
> will then lose all the svn annotations history in all
Thanks, Rishi!
Am 13.09.16 um 15:10 schrieb Rishi Solanki:
+1 Taher, until we will have complete switch to pure groovy we should keep
the semicolon as practice.
+1 Michael, for migrating to pure Groovy.
We would try to assign dev for it and log Jira ticket accordingly.
Rishi Solanki
Manager,
+1 Taher, until we will have complete switch to pure groovy we should keep
the semicolon as practice.
+1 Michael, for migrating to pure Groovy.
We would try to assign dev for it and log Jira ticket accordingly.
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
+1
Michael
Am 13.09.16 um 14:58 schrieb Taher Alkhateeb:
Okay, given the priorities and work we have at the moment, I suggest we
keep semicolons and use it as the standard unless someone volunteers to
make a full switch. WDYT?
On Tue, Sep 13, 2016 at 3:52 PM, Jacopo Cappellato <
cool, thanks
Jacopo
On Tue, Sep 13, 2016 at 2:56 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Tests passed, must have been a BuildBot quirk
>
> https://ci.apache.org/builders/ofbiz-trunk/builds/1416
>
> Jacques
>
>
>
> Le 13/09/2016 à 14:48, Jacques Le Roux a écrit :
>
>> Works
The Buildbot has detected a restored build on builder ofbiz-trunk while
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1416
Buildbot URL: https://ci.apache.org/
Buildslave for this Build: orcus_ubuntu
Build Reason: forced: by IRC user
Okay, given the priorities and work we have at the moment, I suggest we
keep semicolons and use it as the standard unless someone volunteers to
make a full switch. WDYT?
On Tue, Sep 13, 2016 at 3:52 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
> I agree with Rishi's
Good point, I hadn't thought of that!
So if we find a volunteer I would be for 1. (migrating to pure Groovy).
Michael
Am 13.09.16 um 14:52 schrieb Jacopo Cappellato:
I agree with Rishi's remarks: also, if we follow this approach then
functional changes will be buried in a bunch of
Tests passed, must have been a BuildBot quirk
https://ci.apache.org/builders/ofbiz-trunk/builds/1416
Jacques
Le 13/09/2016 à 14:48, Jacques Le Roux a écrit :
Works also locally here, I have forced a new build on BuildBot, could be a
temporary error, happens rarely but happens.
Jacques
Le
I agree with Rishi's remarks: also, if we follow this approach then
functional changes will be buried in a bunch of non-functional changes.
This could work if the two are committed into two separate commits.
Jacopo
On Tue, Sep 13, 2016 at 2:45 PM, Rishi Solanki
wrote:
Works also locally here, I have forced a new build on BuildBot, could be a
temporary error, happens rarely but happens.
Jacques
Le 13/09/2016 à 13:43, Jacopo Cappellato a écrit :
Yeah, thanks for the notification, I also saw the automatic build failure
email.
Weird, local tests are
Fix as you edit, this is something like we are working on X functionality
and to achieve that functionality if we want to edit an groovy file, then
we will also remove/add semicolon to it.
If I'm understanding it correctly, then -1 for it. As we have to ask
explicitly to every
Yeah, thanks for the notification, I also saw the automatic build failure
email.
Weird, local tests are successful and that service doesn't seem to be
related to my last commit... but I am looking into it.
Jacopo
On Tue, Sep 13, 2016 at 1:15 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com>
You have got a small issue
https://ci.apache.org/builders/ofbiz-trunk/builds/1415
https://ci.apache.org/projects/ofbiz/logs/trunk/html/
Jacques
Le 13/09/2016 à 12:55, jaco...@apache.org a écrit :
Author: jacopoc
Date: Tue Sep 13 10:55:12 2016
New Revision: 1760528
URL:
The Buildbot has detected a new failure on builder ofbiz-trunk while building .
Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1415
Buildbot URL: https://ci.apache.org/
Buildslave for this Build: orcus_ubuntu
Build Reason: The AnyBranchScheduler scheduler
Committed in rev. 1760528
Jacopo
On Fri, Sep 9, 2016 at 3:33 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
> In ContextFilter, the character encoding (aka charset) of every http
> *request* object is set using the WebAppUtil.setCharacterEncoding(...)
> method (see its
Yup +1 for option 3, fix as you edit
On Sep 13, 2016 1:16 PM, "Jacques Le Roux"
wrote:
> Le 13/09/2016 à 11:56, Michael Brohl a écrit :
>
>> Same here. I'm not even sure if we really have clean groovy in the
>> project, I assume it is mixed up with Java code in
Le 13/09/2016 à 11:56, Michael Brohl a écrit :
Same here. I'm not even sure if we really have clean groovy in the project, I
assume it is mixed up with Java code in some areas.
But I agree to have a consistent style and we should use the Groovy language as it shoul be used (even if I would
Same here. I'm not even sure if we really have clean groovy in the
project, I assume it is mixed up with Java code in some areas.
But I agree to have a consistent style and we should use the Groovy
language as it shoul be used (even if I would have get used to it and
like a a defined code
Le 13/09/2016 à 11:34, Scott Gray a écrit :
I don't want to remove existing ones (easy done in one shoot with a S/R
regexp) because it would remove the precious svn annotations (when you want
to look for reasons in the past)
Hi Jacques,
What are these precious svn annotations used for? Maybe
Jacques, do we all have to read your correspondence with TortoiseSvn? This
list is reserved for discussions related to development of OFBiz.
If you will get useful hints for OFBiz developers using your same tools you
could always put the information in the Wiki.
Jacopo
On Tue, Sep 13, 2016 at
>
> I don't want to remove existing ones (easy done in one shoot with a S/R
> regexp) because it would remove the precious svn annotations (when you want
> to look for reasons in the past)
Hi Jacques,
What are these precious svn annotations used for? Maybe I'm out of the
loop since I use
Hi Jacopo,
Thanks for your consideration!
I like the name ControlFilter. On the sequence of the filters, personally I
think it's a policy for entrance. If put the ControlFilter 1st, it's a strict
control. If put it last, it's a loose control. Anyway, we need it.
When you complete, I will try
Hi,
Is it possible to limit the length of comments commits lines? I saw a *split-lines* options but it seems to not work or at least I don't know how to
use it and could not find any help.
Thanks
Jacques
Thank you Jinghai,
I agree we should separate the concerns and split the ContextFilter into
two filters; I am going to work on this and I am planning to separate the
"controller" related concerns (like allowPaths and redirectPath functions)
into a new filter named ControlFilter.
But, shouldn't
Le 13/09/2016 à 08:40, Jacques Le Roux a écrit :
Thank you Rishi for the link to https://cwiki.apache.org/confluence/display/OFBIZ/Tips+and+Tricks+while+working+with+Groovy I did not remember of
it. I changed the title to make the URL easier to read
Jacques
BTW the Beanshell references
I was talking about consistency from now on; I was not suggesting to bulk
change everything.
Jacopo
On Tue, Sep 13, 2016 at 8:40 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Hi,
>
> Wait, I did not ask to remove them. I simply asked "Should we continue to
> put them, and if yes
Okay I missed the historical context.
Like Jacopo I also do not have a strong opinion, if it is easier and faster
to keep them, then keep them. The important thing is to take a direction
and stay with it.
On Sep 13, 2016 9:40 AM, "Jacques Le Roux"
wrote:
Hi,
Other link to keep in mind is about groovy DSL where no semicolumn are
present in code samples :
https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
If there is no performance consequences with not using semicolumn, i'm
ok with it.
Gil
Le 13/09/2016 à
Hi,
Wait, I did not ask to remove them. I simply asked "Should we continue to put them,
and if yes for which reasons? "
I don't want to remove existing ones (easy done in one shoot with a S/R regexp) because it would remove the precious svn annotations (when you want to
look for reasons in
Jacopo,
I could recall after your reply, the semicolon kept in the groovy files for
consistency only no other reason. Also, if we decide to remove it, then
only thing we should consider if somewhere semicolon used as separator.
Thanks!
--
Rishi
Rishi Solanki
Manager, Enterprise Software
I don't have a strong opinion. But it would be nice to agreed upon one
style and then implement consistently.
Jacopo
On Mon, Sep 12, 2016 at 6:56 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Hi
>
> While committing r1760406 I wondered if I should really put semicolons at
> end
43 matches
Mail list logo