Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Hi

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?

Thanks

Jacques

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

I remember the conversion of bsh to groovy was big one, and at that time in
a conversation decided to keep the semicolon as is. For code consistency
and for java based user of OFBiz. Even bsh/groovy help java based users to
develop/understand OFBiz better.

I tried but could not find the reference to that conversation in history.
But yes we can address this code improvement and here I find something
related on OFBiz wiki -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=6553850

So +1 for this effort and we should remove all semicolons from groovy files.

Best Regards,
--
Rishi

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Mon, Sep 12, 2016 at 10:29 PM, Taher Alkhateeb <
slidingfilaments@gmail.com> wrote:

> Agreed, I think it is better to remove semicolons for groovy files. In fact
> our gradle scripts do not have semicolons. Perhaps people put them there
> out of habit.
>
> On Sep 12, 2016 7:56 PM, "Jacques Le Roux" <ja...@les7arts.com>
> wrote:
>
> > Hi
> >
> > 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?
> >
> > Thanks
> >
> > Jacques
> >
> >
>

Re: Groovy and semicolon at EOL

[Taher Alkhateeb <sl...@gmail.com>]

Agreed, I think it is better to remove semicolons for groovy files. In fact
our gradle scripts do not have semicolons. Perhaps people put them there
out of habit.

On Sep 12, 2016 7:56 PM, "Jacques Le Roux" <ja...@les7arts.com>
wrote:

> Hi
>
> 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?
>
> Thanks
>
> Jacques
>
>

Re: Groovy and semicolon at EOL

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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.roux@les7arts.com> wrote:

> 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 the past)
>
> I just want to stop put them when we refactor/fix/etc.
>
> I know it will introduce inconsistency (and I assume you know how much I
> dislike inconsistency) but if the price to pay is to lose again the
> *precious svn annotation*, by changing almost of lines of all Groovy files,
> then I'd say it's not worth it
>
> Thank you Rishi for the link to https://cwiki.apache.org/confl
> uence/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
>
>
>
> Le 13/09/2016 à 08:23, Rishi Solanki a écrit :
>
>> 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 Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Tue, Sep 13, 2016 at 11:46 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>> 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.roux@les7arts.com> wrote:
>>>
>>> Hi
>>>>
>>>> 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?
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 I'm out of the
> loop since I use git-svn which let's me search history a million different
> ways, but I'm interested to know why the annotations would be problematic
> for bulk S/R operations.
>
> Thanks
> Scott
Hi Scott,

Sometimes I try to understand why and when a line has been committed this is mostly when the annotations are useful to me.
Also sometimes simply to find a revision number.

HTH

Jacques

Re: Groovy and semicolon at EOL

[Scott Gray <sc...@hotwaxsystems.com>]

>
> 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 git-svn which let's me search history a million different
ways, but I'm interested to know why the annotations would be problematic
for bulk S/R operations.

Thanks
Scott

On 13 September 2016 at 18:40, Jacques Le Roux <jacques.le.roux@les7arts.com
> wrote:

> 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 the past)
>
> I just want to stop put them when we refactor/fix/etc.
>
> I know it will introduce inconsistency (and I assume you know how much I
> dislike inconsistency) but if the price to pay is to lose again the
> *precious svn annotation*, by changing almost of lines of all Groovy files,
> then I'd say it's not worth it
>
> Thank you Rishi for the link to https://cwiki.apache.org/confl
> uence/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
>
>
>
> Le 13/09/2016 à 08:23, Rishi Solanki a écrit :
>
>> 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 Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Tue, Sep 13, 2016 at 11:46 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>> 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.roux@les7arts.com> wrote:
>>>
>>> Hi
>>>>
>>>> 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?
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 should be removed now. I suggest when doing so to put a link in the modified page to previous page versions in history 
and explain that to users in the link (it still true in releases and our users use releases).
Maybe not a bid deal in this case, rather a global way of doing changes in wiki for important matters

Thanks

Jacques

Re: Groovy and semicolon at EOL

[gil portenseigne <gi...@nereide.fr>]

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

Re: Groovy and semicolon at EOL

[Michael Brohl <mi...@ecomify.de>]

+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 <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
>> 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 <ri...@gmail.com>
>> wrote:
>>
>>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 is the good time to do such changes (may be just
> before the next release?). Or we should port such changes which are for
> consistency to releases. Or may be its fine to keep it as is.

I'd finally prefer to keep it as is. At least that's my opinion for now.

Jacques

>
> Thanks!
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Tue, Sep 13, 2016 at 8:15 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>> jacques.le.roux@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 the Groovy files.
>> ...
>> Jacques, are you aware that you can pass the -r argument to the
>> blame/annotate command?
>>
>> Jacopo
>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

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
before the next release?). Or we should port such changes which are for
consistency to releases. Or may be its fine to keep it as is.

Thanks!



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Sep 13, 2016 at 8:15 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
> jacques.le.roux@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 the Groovy files.
> ...
> >
>
> Jacques, are you aware that you can pass the -r argument to the
> blame/annotate command?
>
> Jacopo
>

Re: Groovy and semicolon at EOL

[Arun Patidar <ar...@hotwaxsystems.com>]

This has been committed at rev:1767764. I have also verified application by
accessing different screens of components.

Please let me know if you find any issue regarding this change.



-- 
Thanks & Regards
---
Arun Patidar
Manager,Enterprise Software Development
HotWax Mediawww.hotwaxsystems.com


On Wed, Nov 2, 2016 at 5:45 PM, Rishi Solanki <ri...@gmail.com>
wrote:

> Thank you very much Jacques.
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Wed, Nov 2, 2016 at 4:55 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > Hi Rishi,
> >
> > No need to do it by hand. I did it with regexp S/R in Eclipse and have
> > updated the patch at OFBIZ-8652, please check
> >
> > Thanks
> >
> > Jacques
> >
> >
> >
> > Le 02/11/2016 à 09:18, Rishi Solanki a écrit :
> >
> >> Yes we have noticed some semicolons, and it seems we need to replace
> them
> >> manually. Because in all groovy files we have seen the semicolon in the
> >> lincense text as well.
> >>
> >> Thank you for your help Jacques :-)
> >>
> >> Rishi Solanki
> >> Manager, Enterprise Software Development
> >> HotWax Systems Pvt. Ltd.
> >> Direct: +91-9893287847
> >> http://www.hotwaxsystems.com
> >>
> >> On Wed, Nov 2, 2016 at 2:36 AM, Jacques Le Roux <
> >> jacques.le.roux@les7arts.com> wrote:
> >>
> >> Hi Rishi,
> >>>
> >>> It's not the first time we change a *simple thing* in all the source. I
> >>> can live with that, you seem well organised :)
> >>>
> >>> BTW after appling the patch at OFBIZ-8652 I still find 57 trailing
> >>> semicolons :)
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >>> Le 01/11/2016 à 07:35, Rishi Solanki a écrit :
> >>>
> >>> Jacques,
> >>>>
> >>>> Yes we would like to commit it as whole, but before commit for the
> same
> >>>> we
> >>>> have plan to test each component after applying the changes. Like
> browse
> >>>> to
> >>>> most pages and general work flows. We will post the updates on ticket
> >>>> something like;
> >>>>
> >>>> Test the party component;
> >>>> Pages/Work Flow tested: Find Party, Create Party, View Party, My
> >>>> Communications, Visits, Classification, Security, Invitation pages
> etc.
> >>>>
> >>>> The above is an example of how we will confirm everything is working
> >>>> properly, with some basic code review. We would follow the same steps
> >>>> for
> >>>> other components.
> >>>>
> >>>> Please let us know plan looks fine to you. Also in case you think we
> >>>> should
> >>>> take care anything else to minimize the possibility of regression Or
> may
> >>>> be
> >>>> if you think committing the changes per component will help in code
> >>>> review?
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>>
> >>>> Rishi Solanki
> >>>> Manager, Enterprise Software Development
> >>>> HotWax Systems Pvt. Ltd.
> >>>> Direct: +91-9893287847
> >>>> http://www.hotwaxsystems.com
> >>>>
> >>>> On Fri, Oct 28, 2016 at 4:10 PM, Jacques Le Roux <
> >>>> jacques.le.roux@les7arts.com> wrote:
> >>>>
> >>>> Hi Rishi,
> >>>>
> >>>>> Will you commit as a whole?
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>
> >>>>>
> >>>>> Le 28/10/2016 à 12:07, Rishi Solanki a écrit :
> >>>>>
> >>>>> Started effort under - https://issues.apache.org/jira
> >>>>> /browse/OFBIZ-8652
> >>>>>
> >>>>>> Thanks to Rohit Kaushal for taking care of this. It will take 4-5
> days
> >>>>>> for
> >>>>>> testing.
> >>>>>>
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Rishi Solanki
> >>>>>> Manager, Enterprise Software Development
> >>>>>> HotWax Systems Pvt. Ltd.
> >>>>>> Direct: +91-9893287847
> >>>>>> http://www.hotwaxsystems.com
> >>>>>>
> >>>>>> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
> >>>>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>>
> >>>>>> Personally I will go this way: I will add or changes lines without
> >>>>>> putting
> >>>>>>
> >>>>>> semicolons.
> >>>>>>>
> >>>>>>> I'm in favour of bulk changing files, but I'd prefer by component
> or
> >>>>>>> webapp to ease reviews.
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>>
> >>>>>>> Le 16/09/2016 à 15:36, Rishi Solanki a écrit :
> >>>>>>>
> >>>>>>> I was saying #2 as per the comment from Taher ....
> >>>>>>>
> >>>>>>> Quick Reference:
> >>>>>>>>
> >>>>>>>> One reply from Taher ... in the same thread.
> >>>>>>>> ==========
> >>>>>>>>
> >>>>>>>> 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?
> >>>>>>>> ==========
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Rishi Solanki
> >>>>>>>> Manager, Enterprise Software Development
> >>>>>>>> HotWax Systems Pvt. Ltd.
> >>>>>>>> Direct: +91-9893287847
> >>>>>>>> http://www.hotwaxsystems.com
> >>>>>>>>
> >>>>>>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
> >>>>>>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>>
> >>>>>>>> I guess you mean 2) by file, then it's OK with me. Though I'd no
> be
> >>>>>>>>
> >>>>>>>> against having semicolon inconsistency in Groovy files, which was
> my
> >>>>>>>>
> >>>>>>>>> initial question. So no strong opinion about 2 here.
> >>>>>>>>>
> >>>>>>>>> Jacques
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
> >>>>>>>>>
> >>>>>>>>> To summarize the overall conversation;
> >>>>>>>>>
> >>>>>>>>> 1) We have decided to bulk remove semicolons from groovy.
> >>>>>>>>>
> >>>>>>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
> >>>>>>>>>> consistency.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Rishi Solanki
> >>>>>>>>>> Manager, Enterprise Software Development
> >>>>>>>>>> HotWax Systems Pvt. Ltd.
> >>>>>>>>>> Direct: +91-9893287847
> >>>>>>>>>> http://www.hotwaxsystems.com
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
> >>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that
> both
> >>>>>>>>>>
> >>>>>>>>>> Subclipse and Tortoise allow you to select a range of revisions
> >>>>>>>>>> when
> >>>>>>>>>>
> >>>>>>>>>> you
> >>>>>>>>>>> look for annotations.
> >>>>>>>>>>>
> >>>>>>>>>>> So  it's no longer an issue for me and we can bulk remove
> >>>>>>>>>>> trailing
> >>>>>>>>>>> semicolons in Groovy files if we want.
> >>>>>>>>>>>
> >>>>>>>>>>> Sorry for the confusion
> >>>>>>>>>>>
> >>>>>>>>>>> Jacques
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
> >>>>>>>>>>>
> >>>>>>>>>>> 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 plenty of ways to search
> >>>>>>>>>>>> commit
> >>>>>>>>>>>> logs
> >>>>>>>>>>>> and
> >>>>>>>>>>>> personally I've never found blame to be very useful.  I don't
> >>>>>>>>>>>> think
> >>>>>>>>>>>> it
> >>>>>>>>>>>> should be a reason to block any future bulk S/R cleanups.
> We've
> >>>>>>>>>>>> had
> >>>>>>>>>>>> plenty
> >>>>>>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
> >>>>>>>>>>>> whitespace
> >>>>>>>>>>>> removal, etc.) and we should continue to do it to keep things
> >>>>>>>>>>>> clean.
> >>>>>>>>>>>>
> >>>>>>>>>>>> For searching diffs, before using git-svn I used to use: svn
> log
> >>>>>>>>>>>> -diff
> >>>>>>>>>>>> <path/to.file> and then use the search in the terminal to find
> >>>>>>>>>>>> the
> >>>>>>>>>>>> string
> >>>>>>>>>>>> I'm looking for.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards
> >>>>>>>>>>>> Scott
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
> >>>>>>>>>>>> jacques.le.roux@les7arts.com
> >>>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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 menu, et voilà!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I confirm, totally comparable to Subclipse annotations
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> TortoiseProc.exe /command:blame
> /path:"C:\projectASF-Mars\ofbi
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> product\catalog\CatalogWorker.java"
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
> >>>>>>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-
> >>>>>>>>>>>>>> basics
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>       From the resulting UI (comparable to Subclipse) I
> guess
> >>>>>>>>>>>>>> changing
> >>>>>>>>>>>>>> all
> >>>>>>>>>>>>>> lines of a file will have the same effect.
> >>>>>>>>>>>>>> Even if indeed the annotations are not lost, they are very
> >>>>>>>>>>>>>> hard
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>> use
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>> you need to compare revision by revision.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> BTW thinking about it, don't you have something similar in
> >>>>>>>>>>>>>> IntellIJ?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 006/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 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 annotations in the same column
> than
> >>>>>>>>>>>>>>>> lines
> >>>>>>>>>>>>>>>> numbers. But it unfortunately contains only the last
> >>>>>>>>>>>>>>>> revision
> >>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>> lines
> >>>>>>>>>>>>>>>> have been modified together in that revision.
> >>>>>>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff"
> >>>>>>>>>>>>>>>> ("Revision"
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> "Combined Colors" are then default options, hovering is
> >>>>>>>>>>>>>>>> enough
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> me).
> >>>>>>>>>>>>>>>> Same than you decide to show line numbers in this
> column...
> >>>>>>>>>>>>>>>> More
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> those who are still using Eclipse...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>> can't
> >>>>>>>>>>>>>>>>> tell you the details since I don't use it
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
> >>>>>>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> jacques.le.roux@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
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> Groovy
> >>>>>>>>>>>>>>>>>>>> files.
> >>>>>>>>>>>>>>>>>>>> ...
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r
> argument
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> blame/annotate command?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Jacopo
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I must say I never use that when looking at
> annotations
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> in a
> >>>>>>>>>>>>>>>>>>> file
> >>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances,
> but
> >>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>> hardly
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> see
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> when.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> And once all the lines a file has been modified in one
> >>>>>>>>>>>>>>>>>> commit, I
> >>>>>>>>>>>>>>>>>> guess -r
> >>>>>>>>>>>>>>>>>> does not help at all, anyway you get only this
> >>>>>>>>>>>>>>>>>> information.
> >>>>>>>>>>>>>>>>>> Or
> >>>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>> miss
> >>>>>>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I
> >>>>>>>>>>>>>>>>>> rather
> >>>>>>>>>>>>>>>>>> try
> >>>>>>>>>>>>>>>>>> to know
> >>>>>>>>>>>>>>>>>> when and why a line has been changed, what are the
> reasons
> >>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> these
> >>>>>>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >
>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

Thank you very much Jacques.

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Wed, Nov 2, 2016 at 4:55 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Hi Rishi,
>
> No need to do it by hand. I did it with regexp S/R in Eclipse and have
> updated the patch at OFBIZ-8652, please check
>
> Thanks
>
> Jacques
>
>
>
> Le 02/11/2016 à 09:18, Rishi Solanki a écrit :
>
>> Yes we have noticed some semicolons, and it seems we need to replace them
>> manually. Because in all groovy files we have seen the semicolon in the
>> lincense text as well.
>>
>> Thank you for your help Jacques :-)
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Wed, Nov 2, 2016 at 2:36 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Hi Rishi,
>>>
>>> It's not the first time we change a *simple thing* in all the source. I
>>> can live with that, you seem well organised :)
>>>
>>> BTW after appling the patch at OFBIZ-8652 I still find 57 trailing
>>> semicolons :)
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 01/11/2016 à 07:35, Rishi Solanki a écrit :
>>>
>>> Jacques,
>>>>
>>>> Yes we would like to commit it as whole, but before commit for the same
>>>> we
>>>> have plan to test each component after applying the changes. Like browse
>>>> to
>>>> most pages and general work flows. We will post the updates on ticket
>>>> something like;
>>>>
>>>> Test the party component;
>>>> Pages/Work Flow tested: Find Party, Create Party, View Party, My
>>>> Communications, Visits, Classification, Security, Invitation pages etc.
>>>>
>>>> The above is an example of how we will confirm everything is working
>>>> properly, with some basic code review. We would follow the same steps
>>>> for
>>>> other components.
>>>>
>>>> Please let us know plan looks fine to you. Also in case you think we
>>>> should
>>>> take care anything else to minimize the possibility of regression Or may
>>>> be
>>>> if you think committing the changes per component will help in code
>>>> review?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> Rishi Solanki
>>>> Manager, Enterprise Software Development
>>>> HotWax Systems Pvt. Ltd.
>>>> Direct: +91-9893287847
>>>> http://www.hotwaxsystems.com
>>>>
>>>> On Fri, Oct 28, 2016 at 4:10 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Hi Rishi,
>>>>
>>>>> Will you commit as a whole?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 28/10/2016 à 12:07, Rishi Solanki a écrit :
>>>>>
>>>>> Started effort under - https://issues.apache.org/jira
>>>>> /browse/OFBIZ-8652
>>>>>
>>>>>> Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days
>>>>>> for
>>>>>> testing.
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Rishi Solanki
>>>>>> Manager, Enterprise Software Development
>>>>>> HotWax Systems Pvt. Ltd.
>>>>>> Direct: +91-9893287847
>>>>>> http://www.hotwaxsystems.com
>>>>>>
>>>>>> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> Personally I will go this way: I will add or changes lines without
>>>>>> putting
>>>>>>
>>>>>> semicolons.
>>>>>>>
>>>>>>> I'm in favour of bulk changing files, but I'd prefer by component or
>>>>>>> webapp to ease reviews.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 16/09/2016 à 15:36, Rishi Solanki a écrit :
>>>>>>>
>>>>>>> I was saying #2 as per the comment from Taher ....
>>>>>>>
>>>>>>> Quick Reference:
>>>>>>>>
>>>>>>>> One reply from Taher ... in the same thread.
>>>>>>>> ==========
>>>>>>>>
>>>>>>>> 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?
>>>>>>>> ==========
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Rishi Solanki
>>>>>>>> Manager, Enterprise Software Development
>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>> Direct: +91-9893287847
>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>
>>>>>>>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>>>>>>>
>>>>>>>> against having semicolon inconsistency in Groovy files, which was my
>>>>>>>>
>>>>>>>>> initial question. So no strong opinion about 2 here.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
>>>>>>>>>
>>>>>>>>> To summarize the overall conversation;
>>>>>>>>>
>>>>>>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>>>>>>>
>>>>>>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>>>>>>>> consistency.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rishi Solanki
>>>>>>>>>> Manager, Enterprise Software Development
>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>> Direct: +91-9893287847
>>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>>>>>>>
>>>>>>>>>> Subclipse and Tortoise allow you to select a range of revisions
>>>>>>>>>> when
>>>>>>>>>>
>>>>>>>>>> you
>>>>>>>>>>> look for annotations.
>>>>>>>>>>>
>>>>>>>>>>> So  it's no longer an issue for me and we can bulk remove
>>>>>>>>>>> trailing
>>>>>>>>>>> semicolons in Groovy files if we want.
>>>>>>>>>>>
>>>>>>>>>>> Sorry for the confusion
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>>>>>>>>>>>
>>>>>>>>>>> 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 plenty of ways to search
>>>>>>>>>>>> commit
>>>>>>>>>>>> logs
>>>>>>>>>>>> and
>>>>>>>>>>>> personally I've never found blame to be very useful.  I don't
>>>>>>>>>>>> think
>>>>>>>>>>>> it
>>>>>>>>>>>> should be a reason to block any future bulk S/R cleanups.  We've
>>>>>>>>>>>> had
>>>>>>>>>>>> plenty
>>>>>>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>>>>>>>> whitespace
>>>>>>>>>>>> removal, etc.) and we should continue to do it to keep things
>>>>>>>>>>>> clean.
>>>>>>>>>>>>
>>>>>>>>>>>> For searching diffs, before using git-svn I used to use: svn log
>>>>>>>>>>>> -diff
>>>>>>>>>>>> <path/to.file> and then use the search in the terminal to find
>>>>>>>>>>>> the
>>>>>>>>>>>> string
>>>>>>>>>>>> I'm looking for.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Scott
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>>>>>>>> jacques.le.roux@les7arts.com
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 menu, et voilà!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>>>>>>>
>>>>>>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>>>>>>>
>>>>>>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>>>>>>
>>>>>>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-
>>>>>>>>>>>>>> basics
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       From the resulting UI (comparable to Subclipse) I guess
>>>>>>>>>>>>>> changing
>>>>>>>>>>>>>> all
>>>>>>>>>>>>>> lines of a file will have the same effect.
>>>>>>>>>>>>>> Even if indeed the annotations are not lost, they are very
>>>>>>>>>>>>>> hard
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> use
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>> you need to compare revision by revision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BTW thinking about it, don't you have something similar in
>>>>>>>>>>>>>> IntellIJ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 006/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 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 annotations in the same column than
>>>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>>>> numbers. But it unfortunately contains only the last
>>>>>>>>>>>>>>>> revision
>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff"
>>>>>>>>>>>>>>>> ("Revision"
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> "Combined Colors" are then default options, hovering is
>>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> me).
>>>>>>>>>>>>>>>> Same than you decide to show line numbers in this column...
>>>>>>>>>>>>>>>> More
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> can't
>>>>>>>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> jacques.le.roux@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
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I must say I never use that when looking at annotations
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> when.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And once all the lines a file has been modified in one
>>>>>>>>>>>>>>>>>> commit, I
>>>>>>>>>>>>>>>>>> guess -r
>>>>>>>>>>>>>>>>>> does not help at all, anyway you get only this
>>>>>>>>>>>>>>>>>> information.
>>>>>>>>>>>>>>>>>> Or
>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>> miss
>>>>>>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I
>>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>>> to know
>>>>>>>>>>>>>>>>>> when and why a line has been changed, what are the reasons
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Hi Rishi,

No need to do it by hand. I did it with regexp S/R in Eclipse and have updated the patch at OFBIZ-8652, please check

Thanks

Jacques


Le 02/11/2016 � 09:18, Rishi Solanki a �crit :
> Yes we have noticed some semicolons, and it seems we need to replace them
> manually. Because in all groovy files we have seen the semicolon in the
> lincense text as well.
>
> Thank you for your help Jacques :-)
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Wed, Nov 2, 2016 at 2:36 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi Rishi,
>>
>> It's not the first time we change a *simple thing* in all the source. I
>> can live with that, you seem well organised :)
>>
>> BTW after appling the patch at OFBIZ-8652 I still find 57 trailing
>> semicolons :)
>>
>> Thanks
>>
>> Jacques
>>
>>
>>
>> Le 01/11/2016 � 07:35, Rishi Solanki a �crit :
>>
>>> Jacques,
>>>
>>> Yes we would like to commit it as whole, but before commit for the same we
>>> have plan to test each component after applying the changes. Like browse
>>> to
>>> most pages and general work flows. We will post the updates on ticket
>>> something like;
>>>
>>> Test the party component;
>>> Pages/Work Flow tested: Find Party, Create Party, View Party, My
>>> Communications, Visits, Classification, Security, Invitation pages etc.
>>>
>>> The above is an example of how we will confirm everything is working
>>> properly, with some basic code review. We would follow the same steps for
>>> other components.
>>>
>>> Please let us know plan looks fine to you. Also in case you think we
>>> should
>>> take care anything else to minimize the possibility of regression Or may
>>> be
>>> if you think committing the changes per component will help in code
>>> review?
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Systems Pvt. Ltd.
>>> Direct: +91-9893287847
>>> http://www.hotwaxsystems.com
>>>
>>> On Fri, Oct 28, 2016 at 4:10 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Hi Rishi,
>>>> Will you commit as a whole?
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 28/10/2016 � 12:07, Rishi Solanki a �crit :
>>>>
>>>> Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652
>>>>> Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days
>>>>> for
>>>>> testing.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Rishi Solanki
>>>>> Manager, Enterprise Software Development
>>>>> HotWax Systems Pvt. Ltd.
>>>>> Direct: +91-9893287847
>>>>> http://www.hotwaxsystems.com
>>>>>
>>>>> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Personally I will go this way: I will add or changes lines without
>>>>> putting
>>>>>
>>>>>> semicolons.
>>>>>>
>>>>>> I'm in favour of bulk changing files, but I'd prefer by component or
>>>>>> webapp to ease reviews.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 16/09/2016 � 15:36, Rishi Solanki a �crit :
>>>>>>
>>>>>> I was saying #2 as per the comment from Taher ....
>>>>>>
>>>>>>> Quick Reference:
>>>>>>>
>>>>>>> One reply from Taher ... in the same thread.
>>>>>>> ==========
>>>>>>>
>>>>>>> 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?
>>>>>>> ==========
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Rishi Solanki
>>>>>>> Manager, Enterprise Software Development
>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>> Direct: +91-9893287847
>>>>>>> http://www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>
>>>>>>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>>>>>>
>>>>>>> against having semicolon inconsistency in Groovy files, which was my
>>>>>>>> initial question. So no strong opinion about 2 here.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 16/09/2016 � 11:31, Rishi Solanki a �crit :
>>>>>>>>
>>>>>>>> To summarize the overall conversation;
>>>>>>>>
>>>>>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>>>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>>>>>>> consistency.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rishi Solanki
>>>>>>>>> Manager, Enterprise Software Development
>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>> Direct: +91-9893287847
>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>>>>>>
>>>>>>>>> Subclipse and Tortoise allow you to select a range of revisions when
>>>>>>>>>
>>>>>>>>>> you
>>>>>>>>>> look for annotations.
>>>>>>>>>>
>>>>>>>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>>>>>>>> semicolons in Groovy files if we want.
>>>>>>>>>>
>>>>>>>>>> Sorry for the confusion
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 14/09/2016 � 04:42, Scott Gray a �crit :
>>>>>>>>>>
>>>>>>>>>> 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 plenty of ways to search commit
>>>>>>>>>>> logs
>>>>>>>>>>> and
>>>>>>>>>>> personally I've never found blame to be very useful.  I don't
>>>>>>>>>>> think
>>>>>>>>>>> it
>>>>>>>>>>> should be a reason to block any future bulk S/R cleanups.  We've
>>>>>>>>>>> had
>>>>>>>>>>> plenty
>>>>>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>>>>>>> whitespace
>>>>>>>>>>> removal, etc.) and we should continue to do it to keep things
>>>>>>>>>>> clean.
>>>>>>>>>>>
>>>>>>>>>>> For searching diffs, before using git-svn I used to use: svn log
>>>>>>>>>>> -diff
>>>>>>>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>>>>>>>> string
>>>>>>>>>>> I'm looking for.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>>>>>>> jacques.le.roux@les7arts.com
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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 menu, et voil�!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>>>>>>
>>>>>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>>>>>>
>>>>>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-
>>>>>>>>>>>>> basics
>>>>>>>>>>>>>
>>>>>>>>>>>>>       From the resulting UI (comparable to Subclipse) I guess
>>>>>>>>>>>>> changing
>>>>>>>>>>>>> all
>>>>>>>>>>>>> lines of a file will have the same effect.
>>>>>>>>>>>>> Even if indeed the annotations are not lost, they are very hard
>>>>>>>>>>>>> to
>>>>>>>>>>>>> use
>>>>>>>>>>>>> if
>>>>>>>>>>>>> you need to compare revision by revision.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>>>>>>>>>>>>>
>>>>>>>>>>>>> BTW thinking about it, don't you have something similar in
>>>>>>>>>>>>> IntellIJ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>>>>>>
>>>>>>>>>>>>> 006/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 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 annotations in the same column than
>>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>>> numbers. But it unfortunately contains only the last revision
>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision"
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> "Combined Colors" are then default options, hovering is enough
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> me).
>>>>>>>>>>>>>>> Same than you decide to show line numbers in this column...
>>>>>>>>>>>>>>> More
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> can't
>>>>>>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> jacques.le.roux@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 the
>>>>>>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I must say I never use that when looking at annotations
>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I
>>>>>>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> when.
>>>>>>>>>>>>>>>>> And once all the lines a file has been modified in one
>>>>>>>>>>>>>>>>> commit, I
>>>>>>>>>>>>>>>>> guess -r
>>>>>>>>>>>>>>>>> does not help at all, anyway you get only this information.
>>>>>>>>>>>>>>>>> Or
>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> miss
>>>>>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I
>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>> to know
>>>>>>>>>>>>>>>>> when and why a line has been changed, what are the reasons
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

Yes we have noticed some semicolons, and it seems we need to replace them
manually. Because in all groovy files we have seen the semicolon in the
lincense text as well.

Thank you for your help Jacques :-)

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Wed, Nov 2, 2016 at 2:36 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Hi Rishi,
>
> It's not the first time we change a *simple thing* in all the source. I
> can live with that, you seem well organised :)
>
> BTW after appling the patch at OFBIZ-8652 I still find 57 trailing
> semicolons :)
>
> Thanks
>
> Jacques
>
>
>
> Le 01/11/2016 à 07:35, Rishi Solanki a écrit :
>
>> Jacques,
>>
>> Yes we would like to commit it as whole, but before commit for the same we
>> have plan to test each component after applying the changes. Like browse
>> to
>> most pages and general work flows. We will post the updates on ticket
>> something like;
>>
>> Test the party component;
>> Pages/Work Flow tested: Find Party, Create Party, View Party, My
>> Communications, Visits, Classification, Security, Invitation pages etc.
>>
>> The above is an example of how we will confirm everything is working
>> properly, with some basic code review. We would follow the same steps for
>> other components.
>>
>> Please let us know plan looks fine to you. Also in case you think we
>> should
>> take care anything else to minimize the possibility of regression Or may
>> be
>> if you think committing the changes per component will help in code
>> review?
>>
>> Thanks!
>>
>>
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Fri, Oct 28, 2016 at 4:10 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Hi Rishi,
>>>
>>> Will you commit as a whole?
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 28/10/2016 à 12:07, Rishi Solanki a écrit :
>>>
>>> Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652
>>>>
>>>> Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days
>>>> for
>>>> testing.
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> Rishi Solanki
>>>> Manager, Enterprise Software Development
>>>> HotWax Systems Pvt. Ltd.
>>>> Direct: +91-9893287847
>>>> http://www.hotwaxsystems.com
>>>>
>>>> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Personally I will go this way: I will add or changes lines without
>>>> putting
>>>>
>>>>> semicolons.
>>>>>
>>>>> I'm in favour of bulk changing files, but I'd prefer by component or
>>>>> webapp to ease reviews.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 16/09/2016 à 15:36, Rishi Solanki a écrit :
>>>>>
>>>>> I was saying #2 as per the comment from Taher ....
>>>>>
>>>>>> Quick Reference:
>>>>>>
>>>>>> One reply from Taher ... in the same thread.
>>>>>> ==========
>>>>>>
>>>>>> 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?
>>>>>> ==========
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rishi Solanki
>>>>>> Manager, Enterprise Software Development
>>>>>> HotWax Systems Pvt. Ltd.
>>>>>> Direct: +91-9893287847
>>>>>> http://www.hotwaxsystems.com
>>>>>>
>>>>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>>>>>
>>>>>> against having semicolon inconsistency in Groovy files, which was my
>>>>>>> initial question. So no strong opinion about 2 here.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
>>>>>>>
>>>>>>> To summarize the overall conversation;
>>>>>>>
>>>>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>>>>>> consistency.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Rishi Solanki
>>>>>>>> Manager, Enterprise Software Development
>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>> Direct: +91-9893287847
>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>
>>>>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>>>>>
>>>>>>>> Subclipse and Tortoise allow you to select a range of revisions when
>>>>>>>>
>>>>>>>>> you
>>>>>>>>> look for annotations.
>>>>>>>>>
>>>>>>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>>>>>>> semicolons in Groovy files if we want.
>>>>>>>>>
>>>>>>>>> Sorry for the confusion
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>>>>>>>>>
>>>>>>>>> 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 plenty of ways to search commit
>>>>>>>>>> logs
>>>>>>>>>> and
>>>>>>>>>> personally I've never found blame to be very useful.  I don't
>>>>>>>>>> think
>>>>>>>>>> it
>>>>>>>>>> should be a reason to block any future bulk S/R cleanups.  We've
>>>>>>>>>> had
>>>>>>>>>> plenty
>>>>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>>>>>> whitespace
>>>>>>>>>> removal, etc.) and we should continue to do it to keep things
>>>>>>>>>> clean.
>>>>>>>>>>
>>>>>>>>>> For searching diffs, before using git-svn I used to use: svn log
>>>>>>>>>> -diff
>>>>>>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>>>>>>> string
>>>>>>>>>> I'm looking for.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>>>>>> jacques.le.roux@les7arts.com
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> 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 menu, et voilà!
>>>>>>>>>>>>
>>>>>>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>>>>>
>>>>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>>>>>
>>>>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>>>>>
>>>>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-
>>>>>>>>>>>> basics
>>>>>>>>>>>>
>>>>>>>>>>>>      From the resulting UI (comparable to Subclipse) I guess
>>>>>>>>>>>> changing
>>>>>>>>>>>> all
>>>>>>>>>>>> lines of a file will have the same effect.
>>>>>>>>>>>> Even if indeed the annotations are not lost, they are very hard
>>>>>>>>>>>> to
>>>>>>>>>>>> use
>>>>>>>>>>>> if
>>>>>>>>>>>> you need to compare revision by revision.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>> BTW thinking about it, don't you have something similar in
>>>>>>>>>>>> IntellIJ?
>>>>>>>>>>>>
>>>>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>>>>>
>>>>>>>>>>>> 006/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 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 annotations in the same column than
>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>> numbers. But it unfortunately contains only the last revision
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>> all
>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision"
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> "Combined Colors" are then default options, hovering is enough
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> me).
>>>>>>>>>>>>>> Same than you decide to show line numbers in this column...
>>>>>>>>>>>>>> More
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> can't
>>>>>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> jacques.le.roux@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 the
>>>>>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I must say I never use that when looking at annotations
>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I
>>>>>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> when.
>>>>>>>>>>>>>>>> And once all the lines a file has been modified in one
>>>>>>>>>>>>>>>> commit, I
>>>>>>>>>>>>>>>> guess -r
>>>>>>>>>>>>>>>> does not help at all, anyway you get only this information.
>>>>>>>>>>>>>>>> Or
>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>> miss
>>>>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I
>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>> to know
>>>>>>>>>>>>>>>> when and why a line has been changed, what are the reasons
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Hi Rishi,

It's not the first time we change a *simple thing* in all the source. I can live with that, you seem well organised :)

BTW after appling the patch at OFBIZ-8652 I still find 57 trailing semicolons :)

Thanks

Jacques


Le 01/11/2016 � 07:35, Rishi Solanki a �crit :
> Jacques,
>
> Yes we would like to commit it as whole, but before commit for the same we
> have plan to test each component after applying the changes. Like browse to
> most pages and general work flows. We will post the updates on ticket
> something like;
>
> Test the party component;
> Pages/Work Flow tested: Find Party, Create Party, View Party, My
> Communications, Visits, Classification, Security, Invitation pages etc.
>
> The above is an example of how we will confirm everything is working
> properly, with some basic code review. We would follow the same steps for
> other components.
>
> Please let us know plan looks fine to you. Also in case you think we should
> take care anything else to minimize the possibility of regression Or may be
> if you think committing the changes per component will help in code review?
>
> Thanks!
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Fri, Oct 28, 2016 at 4:10 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi Rishi,
>>
>> Will you commit as a whole?
>>
>> Jacques
>>
>>
>>
>> Le 28/10/2016 � 12:07, Rishi Solanki a �crit :
>>
>>> Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652
>>>
>>> Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days for
>>> testing.
>>>
>>>
>>> Thanks!
>>>
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Systems Pvt. Ltd.
>>> Direct: +91-9893287847
>>> http://www.hotwaxsystems.com
>>>
>>> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Personally I will go this way: I will add or changes lines without putting
>>>> semicolons.
>>>>
>>>> I'm in favour of bulk changing files, but I'd prefer by component or
>>>> webapp to ease reviews.
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 16/09/2016 � 15:36, Rishi Solanki a �crit :
>>>>
>>>> I was saying #2 as per the comment from Taher ....
>>>>> Quick Reference:
>>>>>
>>>>> One reply from Taher ... in the same thread.
>>>>> ==========
>>>>>
>>>>> 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?
>>>>> ==========
>>>>>
>>>>>
>>>>>
>>>>> Rishi Solanki
>>>>> Manager, Enterprise Software Development
>>>>> HotWax Systems Pvt. Ltd.
>>>>> Direct: +91-9893287847
>>>>> http://www.hotwaxsystems.com
>>>>>
>>>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>>>>
>>>>>> against having semicolon inconsistency in Groovy files, which was my
>>>>>> initial question. So no strong opinion about 2 here.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 16/09/2016 � 11:31, Rishi Solanki a �crit :
>>>>>>
>>>>>> To summarize the overall conversation;
>>>>>>
>>>>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>>>>> consistency.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Rishi Solanki
>>>>>>> Manager, Enterprise Software Development
>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>> Direct: +91-9893287847
>>>>>>> http://www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>
>>>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>>>>
>>>>>>> Subclipse and Tortoise allow you to select a range of revisions when
>>>>>>>> you
>>>>>>>> look for annotations.
>>>>>>>>
>>>>>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>>>>>> semicolons in Groovy files if we want.
>>>>>>>>
>>>>>>>> Sorry for the confusion
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 14/09/2016 � 04:42, Scott Gray a �crit :
>>>>>>>>
>>>>>>>> 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 plenty of ways to search commit
>>>>>>>>> logs
>>>>>>>>> and
>>>>>>>>> personally I've never found blame to be very useful.  I don't think
>>>>>>>>> it
>>>>>>>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>>>>>>>> plenty
>>>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>>>>> whitespace
>>>>>>>>> removal, etc.) and we should continue to do it to keep things clean.
>>>>>>>>>
>>>>>>>>> For searching diffs, before using git-svn I used to use: svn log
>>>>>>>>> -diff
>>>>>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>>>>>> string
>>>>>>>>> I'm looking for.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>>>>> jacques.le.roux@les7arts.com
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> 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 menu, et voil�!
>>>>>>>>>>>
>>>>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>>>>
>>>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>>>>
>>>>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>>>>
>>>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>>>>>>>
>>>>>>>>>>>      From the resulting UI (comparable to Subclipse) I guess
>>>>>>>>>>> changing
>>>>>>>>>>> all
>>>>>>>>>>> lines of a file will have the same effect.
>>>>>>>>>>> Even if indeed the annotations are not lost, they are very hard to
>>>>>>>>>>> use
>>>>>>>>>>> if
>>>>>>>>>>> you need to compare revision by revision.
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>>>>>>>>>>>
>>>>>>>>>>> BTW thinking about it, don't you have something similar in
>>>>>>>>>>> IntellIJ?
>>>>>>>>>>>
>>>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>>>>
>>>>>>>>>>>> 006/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 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 annotations in the same column than
>>>>>>>>>>>>> lines
>>>>>>>>>>>>> numbers. But it unfortunately contains only the last revision if
>>>>>>>>>>>>> all
>>>>>>>>>>>>> lines
>>>>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision"
>>>>>>>>>>>>> and
>>>>>>>>>>>>> "Combined Colors" are then default options, hovering is enough
>>>>>>>>>>>>> for
>>>>>>>>>>>>> me).
>>>>>>>>>>>>> Same than you decide to show line numbers in this column... More
>>>>>>>>>>>>> for
>>>>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> can't
>>>>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> jacques.le.roux@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 the
>>>>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I must say I never use that when looking at annotations in a
>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I
>>>>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> when.
>>>>>>>>>>>>>>> And once all the lines a file has been modified in one
>>>>>>>>>>>>>>> commit, I
>>>>>>>>>>>>>>> guess -r
>>>>>>>>>>>>>>> does not help at all, anyway you get only this information. Or
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> miss
>>>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I
>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>> to know
>>>>>>>>>>>>>>> when and why a line has been changed, what are the reasons of
>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

Jacques,

Yes we would like to commit it as whole, but before commit for the same we
have plan to test each component after applying the changes. Like browse to
most pages and general work flows. We will post the updates on ticket
something like;

Test the party component;
Pages/Work Flow tested: Find Party, Create Party, View Party, My
Communications, Visits, Classification, Security, Invitation pages etc.

The above is an example of how we will confirm everything is working
properly, with some basic code review. We would follow the same steps for
other components.

Please let us know plan looks fine to you. Also in case you think we should
take care anything else to minimize the possibility of regression Or may be
if you think committing the changes per component will help in code review?

Thanks!



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Fri, Oct 28, 2016 at 4:10 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Hi Rishi,
>
> Will you commit as a whole?
>
> Jacques
>
>
>
> Le 28/10/2016 à 12:07, Rishi Solanki a écrit :
>
>> Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652
>>
>> Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days for
>> testing.
>>
>>
>> Thanks!
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Personally I will go this way: I will add or changes lines without putting
>>> semicolons.
>>>
>>> I'm in favour of bulk changing files, but I'd prefer by component or
>>> webapp to ease reviews.
>>>
>>> Jacques
>>>
>>>
>>> Le 16/09/2016 à 15:36, Rishi Solanki a écrit :
>>>
>>> I was saying #2 as per the comment from Taher ....
>>>>
>>>> Quick Reference:
>>>>
>>>> One reply from Taher ... in the same thread.
>>>> ==========
>>>>
>>>> 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?
>>>> ==========
>>>>
>>>>
>>>>
>>>> Rishi Solanki
>>>> Manager, Enterprise Software Development
>>>> HotWax Systems Pvt. Ltd.
>>>> Direct: +91-9893287847
>>>> http://www.hotwaxsystems.com
>>>>
>>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>>>
>>>>> against having semicolon inconsistency in Groovy files, which was my
>>>>> initial question. So no strong opinion about 2 here.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
>>>>>
>>>>> To summarize the overall conversation;
>>>>>
>>>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>>>> consistency.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rishi Solanki
>>>>>> Manager, Enterprise Software Development
>>>>>> HotWax Systems Pvt. Ltd.
>>>>>> Direct: +91-9893287847
>>>>>> http://www.hotwaxsystems.com
>>>>>>
>>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>>>
>>>>>> Subclipse and Tortoise allow you to select a range of revisions when
>>>>>>> you
>>>>>>> look for annotations.
>>>>>>>
>>>>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>>>>> semicolons in Groovy files if we want.
>>>>>>>
>>>>>>> Sorry for the confusion
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>>>>>>>
>>>>>>> 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 plenty of ways to search commit
>>>>>>>> logs
>>>>>>>> and
>>>>>>>> personally I've never found blame to be very useful.  I don't think
>>>>>>>> it
>>>>>>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>>>>>>> plenty
>>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>>>> whitespace
>>>>>>>> removal, etc.) and we should continue to do it to keep things clean.
>>>>>>>>
>>>>>>>> For searching diffs, before using git-svn I used to use: svn log
>>>>>>>> -diff
>>>>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>>>>> string
>>>>>>>> I'm looking for.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>>>> jacques.le.roux@les7arts.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> 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 menu, et voilà!
>>>>>>>>>>
>>>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>>>
>>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>>>
>>>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>>>
>>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>>>>>>
>>>>>>>>>>     From the resulting UI (comparable to Subclipse) I guess
>>>>>>>>>> changing
>>>>>>>>>> all
>>>>>>>>>> lines of a file will have the same effect.
>>>>>>>>>> Even if indeed the annotations are not lost, they are very hard to
>>>>>>>>>> use
>>>>>>>>>> if
>>>>>>>>>> you need to compare revision by revision.
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>>>>>>>>>
>>>>>>>>>> BTW thinking about it, don't you have something similar in
>>>>>>>>>> IntellIJ?
>>>>>>>>>>
>>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>>>
>>>>>>>>>>> 006/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 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 annotations in the same column than
>>>>>>>>>>>> lines
>>>>>>>>>>>> numbers. But it unfortunately contains only the last revision if
>>>>>>>>>>>> all
>>>>>>>>>>>> lines
>>>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision"
>>>>>>>>>>>> and
>>>>>>>>>>>> "Combined Colors" are then default options, hovering is enough
>>>>>>>>>>>> for
>>>>>>>>>>>> me).
>>>>>>>>>>>> Same than you decide to show line numbers in this column... More
>>>>>>>>>>>> for
>>>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> can't
>>>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>>>
>>>>>>>>>>>>> jacques.le.roux@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 the
>>>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I must say I never use that when looking at annotations in a
>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I
>>>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> when.
>>>>>>>>>>>>>> And once all the lines a file has been modified in one
>>>>>>>>>>>>>> commit, I
>>>>>>>>>>>>>> guess -r
>>>>>>>>>>>>>> does not help at all, anyway you get only this information. Or
>>>>>>>>>>>>>> do
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> miss
>>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I
>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>> try
>>>>>>>>>>>>>> to know
>>>>>>>>>>>>>> when and why a line has been changed, what are the reasons of
>>>>>>>>>>>>>> these
>>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Hi Rishi,

Will you commit as a whole?

Jacques


Le 28/10/2016 � 12:07, Rishi Solanki a �crit :
> Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652
>
> Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days for
> testing.
>
>
> Thanks!
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Personally I will go this way: I will add or changes lines without putting
>> semicolons.
>>
>> I'm in favour of bulk changing files, but I'd prefer by component or
>> webapp to ease reviews.
>>
>> Jacques
>>
>>
>> Le 16/09/2016 � 15:36, Rishi Solanki a �crit :
>>
>>> I was saying #2 as per the comment from Taher ....
>>>
>>> Quick Reference:
>>>
>>> One reply from Taher ... in the same thread.
>>> ==========
>>>
>>> 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?
>>> ==========
>>>
>>>
>>>
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Systems Pvt. Ltd.
>>> Direct: +91-9893287847
>>> http://www.hotwaxsystems.com
>>>
>>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>>> against having semicolon inconsistency in Groovy files, which was my
>>>> initial question. So no strong opinion about 2 here.
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 16/09/2016 � 11:31, Rishi Solanki a �crit :
>>>>
>>>> To summarize the overall conversation;
>>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>>> consistency.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Rishi Solanki
>>>>> Manager, Enterprise Software Development
>>>>> HotWax Systems Pvt. Ltd.
>>>>> Direct: +91-9893287847
>>>>> http://www.hotwaxsystems.com
>>>>>
>>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>>
>>>>>> Subclipse and Tortoise allow you to select a range of revisions when
>>>>>> you
>>>>>> look for annotations.
>>>>>>
>>>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>>>> semicolons in Groovy files if we want.
>>>>>>
>>>>>> Sorry for the confusion
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 14/09/2016 � 04:42, Scott Gray a �crit :
>>>>>>
>>>>>> 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 plenty of ways to search commit
>>>>>>> logs
>>>>>>> and
>>>>>>> personally I've never found blame to be very useful.  I don't think it
>>>>>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>>>>>> plenty
>>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>>> whitespace
>>>>>>> removal, etc.) and we should continue to do it to keep things clean.
>>>>>>>
>>>>>>> For searching diffs, before using git-svn I used to use: svn log -diff
>>>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>>>> string
>>>>>>> I'm looking for.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>>> jacques.le.roux@les7arts.com
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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 menu, et voil�!
>>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>>
>>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>>
>>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>>>>>
>>>>>>>>>     From the resulting UI (comparable to Subclipse) I guess changing
>>>>>>>>> all
>>>>>>>>> lines of a file will have the same effect.
>>>>>>>>> Even if indeed the annotations are not lost, they are very hard to
>>>>>>>>> use
>>>>>>>>> if
>>>>>>>>> you need to compare revision by revision.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>>>>>>>>>
>>>>>>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>>>>>>
>>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>>> 006/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 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 annotations in the same column than lines
>>>>>>>>>>> numbers. But it unfortunately contains only the last revision if
>>>>>>>>>>> all
>>>>>>>>>>> lines
>>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>>>>>>>> "Combined Colors" are then default options, hovering is enough for
>>>>>>>>>>> me).
>>>>>>>>>>> Same than you decide to show line numbers in this column... More
>>>>>>>>>>> for
>>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>> can't
>>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>>
>>>>>>>>>>>>> jacques.le.roux@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 the
>>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>> I must say I never use that when looking at annotations in a
>>>>>>>>>>>>>> file
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I
>>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> see
>>>>>>>>>>>>> when.
>>>>>>>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>>>>>>>> guess -r
>>>>>>>>>>>>> does not help at all, anyway you get only this information. Or
>>>>>>>>>>>>> do
>>>>>>>>>>>>> I
>>>>>>>>>>>>> miss
>>>>>>>>>>>>> something? Should I know the revision I'm looking for? I rather
>>>>>>>>>>>>> try
>>>>>>>>>>>>> to know
>>>>>>>>>>>>> when and why a line has been changed, what are the reasons of
>>>>>>>>>>>>> these
>>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652

Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days for
testing.


Thanks!

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Personally I will go this way: I will add or changes lines without putting
> semicolons.
>
> I'm in favour of bulk changing files, but I'd prefer by component or
> webapp to ease reviews.
>
> Jacques
>
>
> Le 16/09/2016 à 15:36, Rishi Solanki a écrit :
>
>> I was saying #2 as per the comment from Taher ....
>>
>> Quick Reference:
>>
>> One reply from Taher ... in the same thread.
>> ==========
>>
>> 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?
>> ==========
>>
>>
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>>> against having semicolon inconsistency in Groovy files, which was my
>>> initial question. So no strong opinion about 2 here.
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
>>>
>>> To summarize the overall conversation;
>>>> 1) We have decided to bulk remove semicolons from groovy.
>>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>>> consistency.
>>>>
>>>>
>>>>
>>>>
>>>> Rishi Solanki
>>>> Manager, Enterprise Software Development
>>>> HotWax Systems Pvt. Ltd.
>>>> Direct: +91-9893287847
>>>> http://www.hotwaxsystems.com
>>>>
>>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>>
>>>>> Subclipse and Tortoise allow you to select a range of revisions when
>>>>> you
>>>>> look for annotations.
>>>>>
>>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>>> semicolons in Groovy files if we want.
>>>>>
>>>>> Sorry for the confusion
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>>>>>
>>>>> 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 plenty of ways to search commit
>>>>>> logs
>>>>>> and
>>>>>> personally I've never found blame to be very useful.  I don't think it
>>>>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>>>>> plenty
>>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery,
>>>>>> whitespace
>>>>>> removal, etc.) and we should continue to do it to keep things clean.
>>>>>>
>>>>>> For searching diffs, before using git-svn I used to use: svn log -diff
>>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>>> string
>>>>>> I'm looking for.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> 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 menu, et voilà!
>>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>>
>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>>
>>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>>>>
>>>>>>>>    From the resulting UI (comparable to Subclipse) I guess changing
>>>>>>>> all
>>>>>>>> lines of a file will have the same effect.
>>>>>>>> Even if indeed the annotations are not lost, they are very hard to
>>>>>>>> use
>>>>>>>> if
>>>>>>>> you need to compare revision by revision.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>>>>>>>
>>>>>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>>>>>
>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>>> 006/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 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 annotations in the same column than lines
>>>>>>>>>> numbers. But it unfortunately contains only the last revision if
>>>>>>>>>> all
>>>>>>>>>> lines
>>>>>>>>>> have been modified together in that revision.
>>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>>>>>>> "Combined Colors" are then default options, hovering is enough for
>>>>>>>>>> me).
>>>>>>>>>> Same than you decide to show line numbers in this column... More
>>>>>>>>>> for
>>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>> can't
>>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>>
>>>>>>>>>>>> jacques.le.roux@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 the
>>>>>>>>>>>>>> Groovy
>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>
>>>>>>>>>>>>> I must say I never use that when looking at annotations in a
>>>>>>>>>>>>> file
>>>>>>>>>>>>> in
>>>>>>>>>>>>>
>>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I
>>>>>>>>>>>>> hardly
>>>>>>>>>>>>>
>>>>>>>>>>>>> see
>>>>>>>>>>>> when.
>>>>>>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>>>>>>> guess -r
>>>>>>>>>>>> does not help at all, anyway you get only this information. Or
>>>>>>>>>>>> do
>>>>>>>>>>>> I
>>>>>>>>>>>> miss
>>>>>>>>>>>> something? Should I know the revision I'm looking for? I rather
>>>>>>>>>>>> try
>>>>>>>>>>>> to know
>>>>>>>>>>>> when and why a line has been changed, what are the reasons of
>>>>>>>>>>>> these
>>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Personally I will go this way: I will add or changes lines without putting semicolons.

I'm in favour of bulk changing files, but I'd prefer by component or webapp to ease reviews.

Jacques


Le 16/09/2016 � 15:36, Rishi Solanki a �crit :
> I was saying #2 as per the comment from Taher ....
>
> Quick Reference:
>
> One reply from Taher ... in the same thread.
> ==========
>
> 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?
> ==========
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> I guess you mean 2) by file, then it's OK with me. Though I'd no be
>> against having semicolon inconsistency in Groovy files, which was my
>> initial question. So no strong opinion about 2 here.
>>
>> Jacques
>>
>>
>>
>> Le 16/09/2016 � 11:31, Rishi Solanki a �crit :
>>
>>> To summarize the overall conversation;
>>> 1) We have decided to bulk remove semicolons from groovy.
>>> 2) Until #1 is not complete, we would keep adding semicolon for
>>> consistency.
>>>
>>>
>>>
>>>
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Systems Pvt. Ltd.
>>> Direct: +91-9893287847
>>> http://www.hotwaxsystems.com
>>>
>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>>> Subclipse and Tortoise allow you to select a range of revisions when you
>>>> look for annotations.
>>>>
>>>> So  it's no longer an issue for me and we can bulk remove trailing
>>>> semicolons in Groovy files if we want.
>>>>
>>>> Sorry for the confusion
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 14/09/2016 � 04:42, Scott Gray a �crit :
>>>>
>>>> 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 plenty of ways to search commit logs
>>>>> and
>>>>> personally I've never found blame to be very useful.  I don't think it
>>>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>>>> plenty
>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
>>>>> removal, etc.) and we should continue to do it to keep things clean.
>>>>>
>>>>> For searching diffs, before using git-svn I used to use: svn log -diff
>>>>> <path/to.file> and then use the search in the terminal to find the
>>>>> string
>>>>> I'm looking for.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com
>>>>>
>>>>> wrote:
>>>>>> 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 menu, et voil�!
>>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>>
>>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>>> product\catalog\CatalogWorker.java"
>>>>>>>
>>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>>>
>>>>>>>    From the resulting UI (comparable to Subclipse) I guess changing all
>>>>>>> lines of a file will have the same effect.
>>>>>>> Even if indeed the annotations are not lost, they are very hard to use
>>>>>>> if
>>>>>>> you need to compare revision by revision.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>>>>>>>
>>>>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>>>>
>>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>>> 006/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 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 annotations in the same column than lines
>>>>>>>>> numbers. But it unfortunately contains only the last revision if all
>>>>>>>>> lines
>>>>>>>>> have been modified together in that revision.
>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>>>>>> "Combined Colors" are then default options, hovering is enough for
>>>>>>>>> me).
>>>>>>>>> Same than you decide to show line numbers in this column... More for
>>>>>>>>> those who are still using Eclipse...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>> can't
>>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>> jacques.le.roux@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 the Groovy
>>>>>>>>>>>>> files.
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>>>>>>>>>
>>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>> I must say I never use that when looking at annotations in a file
>>>>>>>>>>>> in
>>>>>>>>>>>>
>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly
>>>>>>>>>>>>
>>>>>>>>>>> see
>>>>>>>>>>> when.
>>>>>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>>>>>> guess -r
>>>>>>>>>>> does not help at all, anyway you get only this information. Or do
>>>>>>>>>>> I
>>>>>>>>>>> miss
>>>>>>>>>>> something? Should I know the revision I'm looking for? I rather
>>>>>>>>>>> try
>>>>>>>>>>> to know
>>>>>>>>>>> when and why a line has been changed, what are the reasons of
>>>>>>>>>>> these
>>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

I was saying #2 as per the comment from Taher ....

Quick Reference:

One reply from Taher ... in the same thread.
==========

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?
==========



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> I guess you mean 2) by file, then it's OK with me. Though I'd no be
> against having semicolon inconsistency in Groovy files, which was my
> initial question. So no strong opinion about 2 here.
>
> Jacques
>
>
>
> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
>
>> To summarize the overall conversation;
>> 1) We have decided to bulk remove semicolons from groovy.
>> 2) Until #1 is not complete, we would keep adding semicolon for
>> consistency.
>>
>>
>>
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>> Subclipse and Tortoise allow you to select a range of revisions when you
>>> look for annotations.
>>>
>>> So  it's no longer an issue for me and we can bulk remove trailing
>>> semicolons in Groovy files if we want.
>>>
>>> Sorry for the confusion
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>>>
>>> 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 plenty of ways to search commit logs
>>>> and
>>>> personally I've never found blame to be very useful.  I don't think it
>>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>>> plenty
>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
>>>> removal, etc.) and we should continue to do it to keep things clean.
>>>>
>>>> For searching diffs, before using git-svn I used to use: svn log -diff
>>>> <path/to.file> and then use the search in the terminal to find the
>>>> string
>>>> I'm looking for.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com
>>>>
>>>> wrote:
>>>>> 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 menu, et voilà!
>>>>> I confirm, totally comparable to Subclipse annotations
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>>
>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>>> product\catalog\CatalogWorker.java"
>>>>>>
>>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>>
>>>>>>   From the resulting UI (comparable to Subclipse) I guess changing all
>>>>>> lines of a file will have the same effect.
>>>>>> Even if indeed the annotations are not lost, they are very hard to use
>>>>>> if
>>>>>> you need to compare revision by revision.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>>>>>
>>>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>>>
>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>>> 006/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 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 annotations in the same column than lines
>>>>>>>> numbers. But it unfortunately contains only the last revision if all
>>>>>>>> lines
>>>>>>>> have been modified together in that revision.
>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>>>>> "Combined Colors" are then default options, hovering is enough for
>>>>>>>> me).
>>>>>>>> Same than you decide to show line numbers in this column... More for
>>>>>>>> those who are still using Eclipse...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> can't
>>>>>>>>> tell you the details since I don't use it
>>>>>>>>>
>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>>>>
>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>>
>>>>>>>>>> jacques.le.roux@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 the Groovy
>>>>>>>>>>>> files.
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>>>>>>>>
>>>>>>>>>>>> blame/annotate command?
>>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> I must say I never use that when looking at annotations in a file
>>>>>>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly
>>>>>>>>>>>
>>>>>>>>>> see
>>>>>>>>>> when.
>>>>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>>>>> guess -r
>>>>>>>>>> does not help at all, anyway you get only this information. Or do
>>>>>>>>>> I
>>>>>>>>>> miss
>>>>>>>>>> something? Should I know the revision I'm looking for? I rather
>>>>>>>>>> try
>>>>>>>>>> to know
>>>>>>>>>> when and why a line has been changed, what are the reasons of
>>>>>>>>>> these
>>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

I guess you mean 2) by file, then it's OK with me. Though I'd no be against having semicolon inconsistency in Groovy files, which was my initial 
question. So no strong opinion about 2 here.

Jacques


Le 16/09/2016 � 11:31, Rishi Solanki a �crit :
> To summarize the overall conversation;
> 1) We have decided to bulk remove semicolons from groovy.
> 2) Until #1 is not complete, we would keep adding semicolon for consistency.
>
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>> Subclipse and Tortoise allow you to select a range of revisions when you
>> look for annotations.
>>
>> So  it's no longer an issue for me and we can bulk remove trailing
>> semicolons in Groovy files if we want.
>>
>> Sorry for the confusion
>>
>> Jacques
>>
>>
>>
>> Le 14/09/2016 � 04:42, Scott Gray a �crit :
>>
>>> 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 plenty of ways to search commit logs
>>> and
>>> personally I've never found blame to be very useful.  I don't think it
>>> should be a reason to block any future bulk S/R cleanups.  We've had
>>> plenty
>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
>>> removal, etc.) and we should continue to do it to keep things clean.
>>>
>>> For searching diffs, before using git-svn I used to use: svn log -diff
>>> <path/to.file> and then use the search in the terminal to find the string
>>> I'm looking for.
>>>
>>> Regards
>>> Scott
>>>
>>> On 14 September 2016 at 07:33, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com
>>>
>>>> wrote:
>>>> 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 menu, et voil�!
>>>> I confirm, totally comparable to Subclipse annotations
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>>> product\catalog\CatalogWorker.java"
>>>>>
>>>>> All is explained here https://tortoisesvn.net/docs/r
>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>>
>>>>>   From the resulting UI (comparable to Subclipse) I guess changing all
>>>>> lines of a file will have the same effect.
>>>>> Even if indeed the annotations are not lost, they are very hard to use
>>>>> if
>>>>> you need to compare revision by revision.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>>>>>
>>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>>> 006/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 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 annotations in the same column than lines
>>>>>>> numbers. But it unfortunately contains only the last revision if all
>>>>>>> lines
>>>>>>> have been modified together in that revision.
>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>>>> "Combined Colors" are then default options, hovering is enough for
>>>>>>> me).
>>>>>>> Same than you decide to show line numbers in this column... More for
>>>>>>> those who are still using Eclipse...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>>>>>
>>>>>>> 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
>>>>>>>> can't
>>>>>>>> tell you the details since I don't use it
>>>>>>>>
>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>
>>>>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>>>>
>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>>
>>>>>>>>>> jacques.le.roux@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 the Groovy
>>>>>>>>>>> files.
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>>>>>>>
>>>>>>>>>>> blame/annotate command?
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> I must say I never use that when looking at annotations in a file
>>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly
>>>>>>>>> see
>>>>>>>>> when.
>>>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>>>> guess -r
>>>>>>>>> does not help at all, anyway you get only this information. Or do I
>>>>>>>>> miss
>>>>>>>>> something? Should I know the revision I'm looking for? I rather try
>>>>>>>>> to know
>>>>>>>>> when and why a line has been changed, what are the reasons of these
>>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

To summarize the overall conversation;
1) We have decided to bulk remove semicolons from groovy.
2) Until #1 is not complete, we would keep adding semicolon for consistency.




Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Actually I was wrong on this. Thanks to Jacopo I noticed that both
> Subclipse and Tortoise allow you to select a range of revisions when you
> look for annotations.
>
> So  it's no longer an issue for me and we can bulk remove trailing
> semicolons in Groovy files if we want.
>
> Sorry for the confusion
>
> Jacques
>
>
>
> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>
>> 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 plenty of ways to search commit logs
>> and
>> personally I've never found blame to be very useful.  I don't think it
>> should be a reason to block any future bulk S/R cleanups.  We've had
>> plenty
>> in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
>> removal, etc.) and we should continue to do it to keep things clean.
>>
>> For searching diffs, before using git-svn I used to use: svn log -diff
>> <path/to.file> and then use the search in the terminal to find the string
>> I'm looking for.
>>
>> Regards
>> Scott
>>
>> On 14 September 2016 at 07:33, Jacques Le Roux <
>> jacques.le.roux@les7arts.com
>>
>>> wrote:
>>> 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 menu, et voilà!
>>> I confirm, totally comparable to Subclipse annotations
>>>
>>> Jacques
>>>
>>>
>>>
>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>>> product\catalog\CatalogWorker.java"
>>>>
>>>> All is explained here https://tortoisesvn.net/docs/r
>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>>
>>>>  From the resulting UI (comparable to Subclipse) I guess changing all
>>>> lines of a file will have the same effect.
>>>> Even if indeed the annotations are not lost, they are very hard to use
>>>> if
>>>> you need to compare revision by revision.
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>>>
>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>>
>>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>>> 006/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 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 annotations in the same column than lines
>>>>>> numbers. But it unfortunately contains only the last revision if all
>>>>>> lines
>>>>>> have been modified together in that revision.
>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>>> "Combined Colors" are then default options, hovering is enough for
>>>>>> me).
>>>>>> Same than you decide to show line numbers in this column... More for
>>>>>> those who are still using Eclipse...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>>>
>>>>>> 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
>>>>>>> can't
>>>>>>> tell you the details since I don't use it
>>>>>>>
>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>
>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>>
>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>>
>>>>>>>>> jacques.le.roux@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 the Groovy
>>>>>>>>>> files.
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>>>>>>
>>>>>>>>>> blame/annotate command?
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> I must say I never use that when looking at annotations in a file
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly
>>>>>>>> see
>>>>>>>> when.
>>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>>> guess -r
>>>>>>>> does not help at all, anyway you get only this information. Or do I
>>>>>>>> miss
>>>>>>>> something? Should I know the revision I'm looking for? I rather try
>>>>>>>> to know
>>>>>>>> when and why a line has been changed, what are the reasons of these
>>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Actually I was wrong on this. Thanks to Jacopo I noticed that both Subclipse and Tortoise allow you to select a range of revisions when you look for 
annotations.

So  it's no longer an issue for me and we can bulk remove trailing semicolons in Groovy files if we want.

Sorry for the confusion

Jacques


Le 14/09/2016 � 04:42, Scott Gray a �crit :
> 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 plenty of ways to search commit logs and
> personally I've never found blame to be very useful.  I don't think it
> should be a reason to block any future bulk S/R cleanups.  We've had plenty
> in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
> removal, etc.) and we should continue to do it to keep things clean.
>
> For searching diffs, before using git-svn I used to use: svn log -diff
> <path/to.file> and then use the search in the terminal to find the string
> I'm looking for.
>
> Regards
> Scott
>
> On 14 September 2016 at 07:33, Jacques Le Roux <jacques.le.roux@les7arts.com
>> wrote:
>> 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 menu, et voil�!
>> I confirm, totally comparable to Subclipse annotations
>>
>> Jacques
>>
>>
>>
>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>>> z\applications\product\src\main\java\org\apache\ofbiz\
>>> product\catalog\CatalogWorker.java"
>>>
>>> All is explained here https://tortoisesvn.net/docs/r
>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>>
>>>  From the resulting UI (comparable to Subclipse) I guess changing all
>>> lines of a file will have the same effect.
>>> Even if indeed the annotations are not lost, they are very hard to use if
>>> you need to compare revision by revision.
>>>
>>> Jacques
>>>
>>>
>>> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>>>
>>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>>
>>>> I found an (old) image there https://markphip.blogspot.fr/2
>>>> 006/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 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 annotations in the same column than lines
>>>>> numbers. But it unfortunately contains only the last revision if all lines
>>>>> have been modified together in that revision.
>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>>> "Combined Colors" are then default options, hovering is enough for me).
>>>>> Same than you decide to show line numbers in this column... More for
>>>>> those who are still using Eclipse...
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>>>
>>>>>> 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
>>>>>> can't
>>>>>> tell you the details since I don't use it
>>>>>>
>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>>> jacques.le.roux@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 the Groovy
>>>>>>>>> files.
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>>>>>
>>>>>>>> blame/annotate command?
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> I must say I never use that when looking at annotations in a file in
>>>>>>>>
>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly see
>>>>>>> when.
>>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>>> guess -r
>>>>>>> does not help at all, anyway you get only this information. Or do I
>>>>>>> miss
>>>>>>> something? Should I know the revision I'm looking for? I rather try
>>>>>>> to know
>>>>>>> when and why a line has been changed, what are the reasons of these
>>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>

Re: Groovy and semicolon at EOL

[Scott Gray <sc...@hotwaxsystems.com>]

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 plenty of ways to search commit logs and
personally I've never found blame to be very useful.  I don't think it
should be a reason to block any future bulk S/R cleanups.  We've had plenty
in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
removal, etc.) and we should continue to do it to keep things clean.

For searching diffs, before using git-svn I used to use: svn log -diff
<path/to.file> and then use the search in the terminal to find the string
I'm looking for.

Regards
Scott

On 14 September 2016 at 07:33, Jacques Le Roux <jacques.le.roux@les7arts.com
> wrote:

> 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 menu, et voilà!
> I confirm, totally comparable to Subclipse annotations
>
> Jacques
>
>
>
>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>> z\applications\product\src\main\java\org\apache\ofbiz\
>> product\catalog\CatalogWorker.java"
>>
>> All is explained here https://tortoisesvn.net/docs/r
>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>
>> From the resulting UI (comparable to Subclipse) I guess changing all
>> lines of a file will have the same effect.
>> Even if indeed the annotations are not lost, they are very hard to use if
>> you need to compare revision by revision.
>>
>> Jacques
>>
>>
>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>
>>> BTW thinking about it, don't you have something similar in IntellIJ?
>>>
>>> I found an (old) image there https://markphip.blogspot.fr/2
>>> 006/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 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 annotations in the same column than lines
>>>> numbers. But it unfortunately contains only the last revision if all lines
>>>> have been modified together in that revision.
>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>>>> "Combined Colors" are then default options, hovering is enough for me).
>>>> Same than you decide to show line numbers in this column... More for
>>>> those who are still using Eclipse...
>>>>
>>>> Jacques
>>>>
>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>>>
>>>>> 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
>>>>> can't
>>>>> tell you the details since I don't use it
>>>>>
>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>>>>
>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>>> jacques.le.roux@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 the Groovy
>>>>>>>> files.
>>>>>>>> ...
>>>>>>>>
>>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>>>>
>>>>>>> blame/annotate command?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> I must say I never use that when looking at annotations in a file in
>>>>>>>
>>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly see
>>>>>> when.
>>>>>> And once all the lines a file has been modified in one commit, I
>>>>>> guess -r
>>>>>> does not help at all, anyway you get only this information. Or do I
>>>>>> miss
>>>>>> something? Should I know the revision I'm looking for? I rather try
>>>>>> to know
>>>>>> when and why a line has been changed, what are the reasons of these
>>>>>> changes, maybe to find an related Jira, etc.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 menu, et voil�!
I confirm, totally comparable to Subclipse annotations

Jacques

>
> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbiz\applications\product\src\main\java\org\apache\ofbiz\product\catalog\CatalogWorker.java"
>
> All is explained here https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>
> From the resulting UI (comparable to Subclipse) I guess changing all lines of a file will have the same effect.
> Even if indeed the annotations are not lost, they are very hard to use if you need to compare revision by revision.
>
> Jacques
>
>
> Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
>> 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 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 annotations in the same column than lines numbers. But it unfortunately contains only the last revision if all lines have 
>>> been modified together in that revision.
>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and "Combined Colors" are then default options, hovering is enough for me).
>>> Same than you decide to show line numbers in this column... More for those who are still using Eclipse...
>>>
>>> Jacques
>>>
>>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>>> 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 can't
>>>> tell you the details since I don't use it
>>>>
>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>>
>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>>> jacques.le.roux@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 the Groovy files.
>>>>>>> ...
>>>>>>>
>>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>>> blame/annotate command?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> I must say I never use that when looking at annotations in a file in
>>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly see when.
>>>>> And once all the lines a file has been modified in one commit, I guess -r
>>>>> does not help at all, anyway you get only this information. Or do I miss
>>>>> something? Should I know the revision I'm looking for? I rather try to know
>>>>> when and why a line has been changed, what are the reasons of these
>>>>> changes, maybe to find an related Jira, etc.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 /path:"C:\projectASF-Mars\ofbiz\applications\product\src\main\java\org\apache\ofbiz\product\catalog\CatalogWorker.java"

All is explained here https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics

 From the resulting UI (comparable to Subclipse) I guess changing all lines of a file will have the same effect.
Even if indeed the annotations are not lost, they are very hard to use if you need to compare revision by revision.

Jacques


Le 13/09/2016 � 20:21, Jacques Le Roux a �crit :
> 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 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 annotations in the same column than lines numbers. But it unfortunately contains only the last revision if all lines have 
>> been modified together in that revision.
>> Note: to see it you need to use "Show Quick Diff" ("Revision" and "Combined Colors" are then default options, hovering is enough for me).
>> Same than you decide to show line numbers in this column... More for those who are still using Eclipse...
>>
>> Jacques
>>
>> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>>> 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 can't
>>> tell you the details since I don't use it
>>>
>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>>
>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>>> jacques.le.roux@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 the Groovy files.
>>>>>> ...
>>>>>>
>>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>>> blame/annotate command?
>>>>>
>>>>> Jacopo
>>>>>
>>>>> I must say I never use that when looking at annotations in a file in
>>>> Eclipse. It's maybe useful in certain circumstances, but I hardly see when.
>>>> And once all the lines a file has been modified in one commit, I guess -r
>>>> does not help at all, anyway you get only this information. Or do I miss
>>>> something? Should I know the revision I'm looking for? I rather try to know
>>>> when and why a line has been changed, what are the reasons of these
>>>> changes, maybe to find an related Jira, etc.
>>>>
>>>> Jacques
>>>>
>>>>
>>
>>
>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 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 annotations in the same column than lines numbers. But it unfortunately contains only the last revision if all lines have 
> been modified together in that revision.
> Note: to see it you need to use "Show Quick Diff" ("Revision" and "Combined Colors" are then default options, hovering is enough for me).
> Same than you decide to show line numbers in this column... More for those who are still using Eclipse...
>
> Jacques
>
> Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
>> 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 can't
>> tell you the details since I don't use it
>>
>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>>
>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>>> jacques.le.roux@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 the Groovy files.
>>>>> ...
>>>>>
>>>>> Jacques, are you aware that you can pass the -r argument to the
>>>> blame/annotate command?
>>>>
>>>> Jacopo
>>>>
>>>> I must say I never use that when looking at annotations in a file in
>>> Eclipse. It's maybe useful in certain circumstances, but I hardly see when.
>>> And once all the lines a file has been modified in one commit, I guess -r
>>> does not help at all, anyway you get only this information. Or do I miss
>>> something? Should I know the revision I'm looking for? I rather try to know
>>> when and why a line has been changed, what are the reasons of these
>>> changes, maybe to find an related Jira, etc.
>>>
>>> Jacques
>>>
>>>
>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 annotations in the same column than lines numbers. But it unfortunately contains only the last revision if all lines have 
been modified together in that revision.
Note: to see it you need to use "Show Quick Diff" ("Revision" and "Combined Colors" are then default options, hovering is enough for me).
Same than you decide to show line numbers in this column... More for those who are still using Eclipse...

Jacques

Le 13/09/2016 � 17:40, Jacopo Cappellato a �crit :
> 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 can't
> tell you the details since I don't use it
>
> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
>>
>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>>> jacques.le.roux@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 the Groovy files.
>>>> ...
>>>>
>>>> Jacques, are you aware that you can pass the -r argument to the
>>> blame/annotate command?
>>>
>>> Jacopo
>>>
>>> I must say I never use that when looking at annotations in a file in
>> Eclipse. It's maybe useful in certain circumstances, but I hardly see when.
>> And once all the lines a file has been modified in one commit, I guess -r
>> does not help at all, anyway you get only this information. Or do I miss
>> something? Should I know the revision I'm looking for? I rather try to know
>> when and why a line has been changed, what are the reasons of these
>> changes, maybe to find an related Jira, etc.
>>
>> Jacques
>>
>>

Re: Groovy and semicolon at EOL

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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 can't
tell you the details since I don't use it

On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>
>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
>> jacques.le.roux@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 the Groovy files.
>>> ...
>>>
>>> Jacques, are you aware that you can pass the -r argument to the
>> blame/annotate command?
>>
>> Jacopo
>>
>> I must say I never use that when looking at annotations in a file in
> Eclipse. It's maybe useful in certain circumstances, but I hardly see when.
> And once all the lines a file has been modified in one commit, I guess -r
> does not help at all, anyway you get only this information. Or do I miss
> something? Should I know the revision I'm looking for? I rather try to know
> when and why a line has been changed, what are the reasons of these
> changes, maybe to find an related Jira, etc.
>
> Jacques
>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

Le 13/09/2016 � 16:45, Jacopo Cappellato a �crit :
> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
> jacques.le.roux@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 the Groovy files. ...
>>
> Jacques, are you aware that you can pass the -r argument to the
> blame/annotate command?
>
> Jacopo
>
I must say I never use that when looking at annotations in a file in Eclipse. It's maybe useful in certain circumstances, but I hardly see when. And 
once all the lines a file has been modified in one commit, I guess -r does not help at all, anyway you get only this information. Or do I miss 
something? Should I know the revision I'm looking for? I rather try to know when and why a line has been changed, what are the reasons of these 
changes, maybe to find an related Jira, etc.

Jacques

Re: Groovy and semicolon at EOL

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <
jacques.le.roux@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 the Groovy files. ...
>

Jacques, are you aware that you can pass the -r argument to the
blame/annotate command?

Jacopo

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 remove all the trailing semicolons from all the Groovy files"

We all know it's an easy task using a S/R regexp to remove all the trailing semicolons from all the Groovy files in one shoot. Or maybe for easier 
reviews in several shoots (by component? But who will really review these changes?)

So I don't feel we have answered my question but we rather sidetracked to a solution I did not ask about. This because of the possible end of lines 
inconsistency in Groovy files.

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 the Groovy files.
And that seems to me to be more a concern than consistency in Groovy files!

To get the idea: unrelated but close, we decided to move files around in OFBiz, OK. But now backporting bug fixes is a pain. You have to change files 
paths by hand. This is the kind of changes that must thought thorough before taking a decision.

Thanks

Jacques


Le 13/09/2016 � 16:17, Michael Brohl a �crit :
> 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, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>>
>
>

Re: Groovy and semicolon at EOL

[Michael Brohl <mi...@ecomify.de>]

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, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

+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.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Sep 13, 2016 at 6:28 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:

> 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.cappellato@hotwaxsystems.com> wrote:
>
> > 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 <ri...@gmail.com>
> > wrote:
> >
> > > 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 contributor/committer to follow this practice on
> each
> > > commit/ticket.
> > >
> > > I'm up for #1 or #2 to actively remove/add semicolon. That is do it in
> > one
> > > shot, not immediately but whenever we are ready to do it, otherwise
> with
> > > time we will have more inconsistency in groovy files on this parameter
> as
> > > semicolon.
> > >
> > > I'm not saying we must do it in one shot, but if community decides to
> > > proceed with any approach to actively add/remove semicolon then we
> (@HW)
> > > can try to assign single dev as volunteer to provide patch for all the
> > > files.
> > >
> > > Thanks!
> > >
> > > Best Regards,
> > > --
> > >
> > > Rishi Solanki
> > > Manager, Enterprise Software Development
> > > HotWax Systems Pvt. Ltd.
> > > Direct: +91-9893287847
> > > http://www.hotwaxsystems.com
> > >
> > > On Tue, Sep 13, 2016 at 3:49 PM, Taher Alkhateeb <
> > > slidingfilaments@gmail.com
> > > > wrote:
> > >
> > > > Yup +1 for option 3, fix as you edit
> > > >
> > > > On Sep 13, 2016 1:16 PM, "Jacques Le Roux" <
> > jacques.le.roux@les7arts.com
> > > >
> > > > 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 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 line ending better).
> > > > >>
> > > > >> I see the following directions:
> > > > >>
> > > > >> 1. actively migrate to pure groovy and remove the semicolons
> (where
> > > > >> applicable, it seems there are some cases where you need them, see
> > > > >> https://dzone.com/articles/groovy-sometimes-you-still)
> > > > >>
> > > > >> 2. activeley put semicolons everywhere for consistency
> > > > >>
> > > > >> 3. do 1., but only when a groovy file is edited anyway. This would
> > > > slowly
> > > > >> migrate groovy files.
> > > > >>
> > > > >> I'd be in favor for 3., as long as there are other more important
> > > things
> > > > >> to do or there is a volunteer to do it.
> > > > >>
> > > > >
> > > > > This is what I somehow suggested, thanks for clarifying Michael!
> > Better
> > > > to
> > > > > have consistent lines (with respect to semicolons) by file indeed.
> > > > >
> > > > > Jacques
> > > > >
> > > > >
> > > > >> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
> > > > >>
> > > > >>> 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.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: Groovy and semicolon at EOL

[Taher Alkhateeb <sl...@gmail.com>]

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.cappellato@hotwaxsystems.com> wrote:

> 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 <ri...@gmail.com>
> wrote:
>
> > 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 contributor/committer to follow this practice on each
> > commit/ticket.
> >
> > I'm up for #1 or #2 to actively remove/add semicolon. That is do it in
> one
> > shot, not immediately but whenever we are ready to do it, otherwise with
> > time we will have more inconsistency in groovy files on this parameter as
> > semicolon.
> >
> > I'm not saying we must do it in one shot, but if community decides to
> > proceed with any approach to actively add/remove semicolon then we (@HW)
> > can try to assign single dev as volunteer to provide patch for all the
> > files.
> >
> > Thanks!
> >
> > Best Regards,
> > --
> >
> > Rishi Solanki
> > Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: +91-9893287847
> > http://www.hotwaxsystems.com
> >
> > On Tue, Sep 13, 2016 at 3:49 PM, Taher Alkhateeb <
> > slidingfilaments@gmail.com
> > > wrote:
> >
> > > Yup +1 for option 3, fix as you edit
> > >
> > > On Sep 13, 2016 1:16 PM, "Jacques Le Roux" <
> jacques.le.roux@les7arts.com
> > >
> > > 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 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 line ending better).
> > > >>
> > > >> I see the following directions:
> > > >>
> > > >> 1. actively migrate to pure groovy and remove the semicolons (where
> > > >> applicable, it seems there are some cases where you need them, see
> > > >> https://dzone.com/articles/groovy-sometimes-you-still)
> > > >>
> > > >> 2. activeley put semicolons everywhere for consistency
> > > >>
> > > >> 3. do 1., but only when a groovy file is edited anyway. This would
> > > slowly
> > > >> migrate groovy files.
> > > >>
> > > >> I'd be in favor for 3., as long as there are other more important
> > things
> > > >> to do or there is a volunteer to do it.
> > > >>
> > > >
> > > > This is what I somehow suggested, thanks for clarifying Michael!
> Better
> > > to
> > > > have consistent lines (with respect to semicolons) by file indeed.
> > > >
> > > > Jacques
> > > >
> > > >
> > > >> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
> > > >>
> > > >>> 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.
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: Groovy and semicolon at EOL

[Michael Brohl <mi...@ecomify.de>]

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 non-functional changes.
> This could work if the two are committed into two separate commits.
>
> Jacopo
>
>

Re: Groovy and semicolon at EOL

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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 <ri...@gmail.com>
wrote:

> 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 contributor/committer to follow this practice on each
> commit/ticket.
>
> I'm up for #1 or #2 to actively remove/add semicolon. That is do it in one
> shot, not immediately but whenever we are ready to do it, otherwise with
> time we will have more inconsistency in groovy files on this parameter as
> semicolon.
>
> I'm not saying we must do it in one shot, but if community decides to
> proceed with any approach to actively add/remove semicolon then we (@HW)
> can try to assign single dev as volunteer to provide patch for all the
> files.
>
> Thanks!
>
> Best Regards,
> --
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Tue, Sep 13, 2016 at 3:49 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com
> > wrote:
>
> > Yup +1 for option 3, fix as you edit
> >
> > On Sep 13, 2016 1:16 PM, "Jacques Le Roux" <jacques.le.roux@les7arts.com
> >
> > 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 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 line ending better).
> > >>
> > >> I see the following directions:
> > >>
> > >> 1. actively migrate to pure groovy and remove the semicolons (where
> > >> applicable, it seems there are some cases where you need them, see
> > >> https://dzone.com/articles/groovy-sometimes-you-still)
> > >>
> > >> 2. activeley put semicolons everywhere for consistency
> > >>
> > >> 3. do 1., but only when a groovy file is edited anyway. This would
> > slowly
> > >> migrate groovy files.
> > >>
> > >> I'd be in favor for 3., as long as there are other more important
> things
> > >> to do or there is a volunteer to do it.
> > >>
> > >
> > > This is what I somehow suggested, thanks for clarifying Michael! Better
> > to
> > > have consistent lines (with respect to semicolons) by file indeed.
> > >
> > > Jacques
> > >
> > >
> > >> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
> > >>
> > >>> 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.
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

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 contributor/committer to follow this practice on each
commit/ticket.

I'm up for #1 or #2 to actively remove/add semicolon. That is do it in one
shot, not immediately but whenever we are ready to do it, otherwise with
time we will have more inconsistency in groovy files on this parameter as
semicolon.

I'm not saying we must do it in one shot, but if community decides to
proceed with any approach to actively add/remove semicolon then we (@HW)
can try to assign single dev as volunteer to provide patch for all the
files.

Thanks!

Best Regards,
--

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Sep 13, 2016 at 3:49 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:

> Yup +1 for option 3, fix as you edit
>
> On Sep 13, 2016 1:16 PM, "Jacques Le Roux" <ja...@les7arts.com>
> 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 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 line ending better).
> >>
> >> I see the following directions:
> >>
> >> 1. actively migrate to pure groovy and remove the semicolons (where
> >> applicable, it seems there are some cases where you need them, see
> >> https://dzone.com/articles/groovy-sometimes-you-still)
> >>
> >> 2. activeley put semicolons everywhere for consistency
> >>
> >> 3. do 1., but only when a groovy file is edited anyway. This would
> slowly
> >> migrate groovy files.
> >>
> >> I'd be in favor for 3., as long as there are other more important things
> >> to do or there is a volunteer to do it.
> >>
> >
> > This is what I somehow suggested, thanks for clarifying Michael! Better
> to
> > have consistent lines (with respect to semicolons) by file indeed.
> >
> > Jacques
> >
> >
> >> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
> >>
> >>> 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.
> >>>
> >>>
> >>>
> >>
> >>
> >
>

Re: Groovy and semicolon at EOL

[Taher Alkhateeb <sl...@gmail.com>]

Yup +1 for option 3, fix as you edit

On Sep 13, 2016 1:16 PM, "Jacques Le Roux" <ja...@les7arts.com>
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 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 line ending better).
>>
>> I see the following directions:
>>
>> 1. actively migrate to pure groovy and remove the semicolons (where
>> applicable, it seems there are some cases where you need them, see
>> https://dzone.com/articles/groovy-sometimes-you-still)
>>
>> 2. activeley put semicolons everywhere for consistency
>>
>> 3. do 1., but only when a groovy file is edited anyway. This would slowly
>> migrate groovy files.
>>
>> I'd be in favor for 3., as long as there are other more important things
>> to do or there is a volunteer to do it.
>>
>
> This is what I somehow suggested, thanks for clarifying Michael! Better to
> have consistent lines (with respect to semicolons) by file indeed.
>
> Jacques
>
>
>> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
>>
>>> 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.
>>>
>>>
>>>
>>
>>
>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 have get used to it and  like a a 
> defined code line ending better).
>
> I see the following directions:
>
> 1. actively migrate to pure groovy and remove the semicolons (where applicable, it seems there are some cases where you need them, see 
> https://dzone.com/articles/groovy-sometimes-you-still)
>
> 2. activeley put semicolons everywhere for consistency
>
> 3. do 1., but only when a groovy file is edited anyway. This would slowly migrate groovy files.
>
> I'd be in favor for 3., as long as there are other more important things to do or there is a volunteer to do it.

This is what I somehow suggested, thanks for clarifying Michael! Better to have consistent lines (with respect to semicolons) by file indeed.

Jacques

>
> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
>> 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.
>>
>>
>
>

Re: Groovy and semicolon at EOL

[Michael Brohl <mi...@ecomify.de>]

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 line ending better).

I see the following directions:

1. actively migrate to pure groovy and remove the semicolons (where 
applicable, it seems there are some cases where you need them, see 
https://dzone.com/articles/groovy-sometimes-you-still)

2. activeley put semicolons everywhere for consistency

3. do 1., but only when a groovy file is edited anyway. This would 
slowly migrate groovy files.

I'd be in favor for 3., as long as there are other more important things 
to do or there is a volunteer to do it.

Am 13.09.16 um 08:49 schrieb Taher Alkhateeb:
> 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.
>
>

Re: Groovy and semicolon at EOL

[Taher Alkhateeb <sl...@gmail.com>]

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" <ja...@les7arts.com>
wrote:

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 the past)

I just want to stop put them when we refactor/fix/etc.

I know it will introduce inconsistency (and I assume you know how much I
dislike inconsistency) but if the price to pay is to lose again the
*precious svn annotation*, by changing almost of lines of all Groovy files,
then I'd say it's not worth it

Thank you Rishi for the link to https://cwiki.apache.org/confl
uence/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



Le 13/09/2016 à 08:23, Rishi Solanki a écrit :

> 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 Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Tue, Sep 13, 2016 at 11:46 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
> 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.roux@les7arts.com> wrote:
>>
>> Hi
>>>
>>> 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?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>

Re: Groovy and semicolon at EOL

[Jacques Le Roux <ja...@les7arts.com>]

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 the past)

I just want to stop put them when we refactor/fix/etc.

I know it will introduce inconsistency (and I assume you know how much I dislike inconsistency) but if the price to pay is to lose again the *precious 
svn annotation*, by changing almost of lines of all Groovy files, then I'd say it's not worth it

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


Le 13/09/2016 � 08:23, Rishi Solanki a �crit :
> 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 Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Tue, Sep 13, 2016 at 11:46 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
>> 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.roux@les7arts.com> wrote:
>>
>>> Hi
>>>
>>> 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?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>

Re: Groovy and semicolon at EOL

[Rishi Solanki <ri...@gmail.com>]

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 Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Sep 13, 2016 at 11:46 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> 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.roux@les7arts.com> wrote:
>
> > Hi
> >
> > 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?
> >
> > Thanks
> >
> > Jacques
> >
> >
>

Re: Groovy and semicolon at EOL

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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.roux@les7arts.com> wrote:

> Hi
>
> 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?
>
> Thanks
>
> Jacques
>
>