[SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

Jacques Le Roux
Administrator
Hi,

I know we don't all use Eclipse but I though want to make a suggestion.

2 years ago I put this tip at https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches :


            <<Hide folders from searches and hide some files when opening a file.

    Most of the time you don't want to look into some folders because there is nothing interesting there and they sometimes annoy you because of
    search errors (triste)
    It's also annoying to see *.class files when you look for a similarly named Java source.
    Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
    <https://nodj.github.io/AutoDeriv/>

As it's convenient, I suggest now to put the .derived file and its content (maybe updated) into the svn repo as we have .xmlcatalog.xml which is also
Eclipse specific.

Can I get a consensus about that?

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

Paul Foxworthy
Would it be possible to organise any Eclipse-specific files into a .eclipse
directory so it's easy for anyone else to ignore?

Cheers

Paul Foxworthy

On Tue, 18 Dec 2018 at 00:13, Jacques Le Roux <[hidden email]>
wrote:

> Hi,
>
> I know we don't all use Eclipse but I though want to make a suggestion.
>
> 2 years ago I put this tip at
> https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches
> :
>
>
>             <<Hide folders from searches and hide some files when opening
> a file.
>
>     Most of the time you don't want to look into some folders because
> there is nothing interesting there and they sometimes annoy you because of
>     search errors (triste)
>     It's also annoying to see *.class files when you look for a similarly
> named Java source.
>     Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
>     <https://nodj.github.io/AutoDeriv/>
>
> As it's convenient, I suggest now to put the .derived file and its content
> (maybe updated) into the svn repo as we have .xmlcatalog.xml which is also
> Eclipse specific.
>
> Can I get a consensus about that?
>
> Jacques
>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

Michael Brohl-3
In reply to this post by Jacques Le Roux
Hi Jacques,

who is going to decide which files you want to see and which you don't
want so see? People have different taste on that and so you would be
struggling with different settings checked in to the code repository.

I'm not in favor of putting these files into the repository. I think
these are specific for each developer and it's no problem to keep them
locally.

For your specific examples: I don't see any .class files when searching,
that must be a configuration problem on your side. For searching, you
can also set up filters which provide an efficient mechanism to search
(or don't search) specific files.

Thanks,

Michael


Am 17.12.18 um 14:11 schrieb Jacques Le Roux:

> Hi,
>
> I know we don't all use Eclipse but I though want to make a suggestion.
>
> 2 years ago I put this tip at
> https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches 
> :
>
>
>            <<Hide folders from searches and hide some files when
> opening a file.
>
>    Most of the time you don't want to look into some folders because
> there is nothing interesting there and they sometimes annoy you
> because of
>    search errors (triste)
>    It's also annoying to see *.class files when you look for a
> similarly named Java source.
>    Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
>    <https://nodj.github.io/AutoDeriv/>
>
> As it's convenient, I suggest now to put the .derived file and its
> content (maybe updated) into the svn repo as we have .xmlcatalog.xml
> which is also Eclipse specific.
>
> Can I get a consensus about that?
>
> Jacques
>
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

Jacques Le Roux
Administrator
Hi Michael,

I asked because so far when you updated Eclipse you were losing your plugins and their configurations. I recently updated to Photon and it's no longer
the case. So it's no longer an issue for me :). At least as long as the repos locations don't change. I'd then lose my local .derived file and would
surely I'd forget about it :/. But this should not happen before a long time...

About the .class files showing when using Ctrl+Shift+R (opening a ressource). It's not a configuration problem on my side.

I guess when you speak about filters you think about what is explained in the second answer of
https://stackoverflow.com/questions/443169/exclude-folders-from-eclipse-search.

As you can see in comments there both options (derived and filters) have advantages and drawbacks. I personally prefer using derived ("the *quick* and
dirty way", very handy). But, as explained in stackoverflow, you face an Eclipse bug. That's why AutoDeriv exists.

So what's the problem for me? When you use the clean task, Gradle removes the build dir. So also the dir where the .class files are (build\classes).
And then you lose the derived properties for these dirs :/

Since to hide these files from opening or searching you need to set them as derived, each time you use clean (I do it a lot) you loose this config.
That's why I use, and suggest to use as in wiki, the AutoDeriv plugin.

Anyway as I said it's no longer a trivial but irritating concern for me and I don't want to shoehorn anybody with my solutions :)

Thanks for answering

Happy holidays

Jacques

Le 18/12/2018 à 07:44, Michael Brohl a écrit :

> Hi Jacques,
>
> who is going to decide which files you want to see and which you don't want so see? People have different taste on that and so you would be
> struggling with different settings checked in to the code repository.
>
> I'm not in favor of putting these files into the repository. I think these are specific for each developer and it's no problem to keep them locally.
>
> For your specific examples: I don't see any .class files when searching, that must be a configuration problem on your side. For searching, you can
> also set up filters which provide an efficient mechanism to search (or don't search) specific files.
>
> Thanks,
>
> Michael
>
>
> Am 17.12.18 um 14:11 schrieb Jacques Le Roux:
>> Hi,
>>
>> I know we don't all use Eclipse but I though want to make a suggestion.
>>
>> 2 years ago I put this tip at https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches :
>>
>>
>>            <<Hide folders from searches and hide some files when opening a file.
>>
>>    Most of the time you don't want to look into some folders because there is nothing interesting there and they sometimes annoy you because of
>>    search errors (triste)
>>    It's also annoying to see *.class files when you look for a similarly named Java source.
>>    Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
>>    <https://nodj.github.io/AutoDeriv/>
>>
>> As it's convenient, I suggest now to put the .derived file and its content (maybe updated) into the svn repo as we have .xmlcatalog.xml which is
>> also Eclipse specific.
>>
>> Can I get a consensus about that?
>>
>> Jacques
>>
>>
>
>
grv
Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

grv
Hi Jacques

Following two settings help me not facing the issue you're facing. I, too,
ran into this issue when I initially set up OFBiz on eclipse.


   1. Uncheck Show Derived Resources when you do CTRL+Shift+R, such that
   only Show Status Line is checked. I am sure you have it correctly, but just
   in case.
   2. This does the trick mostly for me. By default, eclipse sets "bin"
   directly as the output folder for the compiled files. I have it as
   "build/classes". I think eclipse does not include resources present in the
   output folder as part of search result, so setting the default output
   folder as gradle's output folder i.e. *build/classes* does the trick for
   me. I am unsure if that's what you're looking for.


So even if the derived setting is gone after clean task is run, if the
output folder is set to *build/classes*, your search results should not
include .class files.

Also, when I am using eclipse for the development, almost always I rely on
eclipse for compiling the sources. I have not used gradle clean task for a
while. But with the about setting (changing default output folder), gradle
clean task does not affect my search results i.e. it does not include
.class files.

Based on what I understood, I think above should help. Please let me know
if that's not the case.

Best,
Girish



On Wed, Dec 26, 2018 at 9:06 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi Michael,
>
> I asked because so far when you updated Eclipse you were losing your
> plugins and their configurations. I recently updated to Photon and it's no
> longer
> the case. So it's no longer an issue for me :). At least as long as the
> repos locations don't change. I'd then lose my local .derived file and
> would
> surely I'd forget about it :/. But this should not happen before a long
> time...
>
> About the .class files showing when using Ctrl+Shift+R (opening a
> ressource). It's not a configuration problem on my side.
>
> I guess when you speak about filters you think about what is explained in
> the second answer of
>
> https://stackoverflow.com/questions/443169/exclude-folders-from-eclipse-search
> .
>
> As you can see in comments there both options (derived and filters) have
> advantages and drawbacks. I personally prefer using derived ("the *quick*
> and
> dirty way", very handy). But, as explained in stackoverflow, you face an
> Eclipse bug. That's why AutoDeriv exists.
>
> So what's the problem for me? When you use the clean task, Gradle removes
> the build dir. So also the dir where the .class files are (build\classes).
> And then you lose the derived properties for these dirs :/
>
> Since to hide these files from opening or searching you need to set them
> as derived, each time you use clean (I do it a lot) you loose this config.
> That's why I use, and suggest to use as in wiki, the AutoDeriv plugin.
>
> Anyway as I said it's no longer a trivial but irritating concern for me
> and I don't want to shoehorn anybody with my solutions :)
>
> Thanks for answering
>
> Happy holidays
>
> Jacques
>
> Le 18/12/2018 à 07:44, Michael Brohl a écrit :
> > Hi Jacques,
> >
> > who is going to decide which files you want to see and which you don't
> want so see? People have different taste on that and so you would be
> > struggling with different settings checked in to the code repository.
> >
> > I'm not in favor of putting these files into the repository. I think
> these are specific for each developer and it's no problem to keep them
> locally.
> >
> > For your specific examples: I don't see any .class files when searching,
> that must be a configuration problem on your side. For searching, you can
> > also set up filters which provide an efficient mechanism to search (or
> don't search) specific files.
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 17.12.18 um 14:11 schrieb Jacques Le Roux:
> >> Hi,
> >>
> >> I know we don't all use Eclipse but I though want to make a suggestion.
> >>
> >> 2 years ago I put this tip at
> https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches
> :
> >>
> >>
> >>            <<Hide folders from searches and hide some files when
> opening a file.
> >>
> >>    Most of the time you don't want to look into some folders because
> there is nothing interesting there and they sometimes annoy you because of
> >>    search errors (triste)
> >>    It's also annoying to see *.class files when you look for a
> similarly named Java source.
> >>    Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
> >>    <https://nodj.github.io/AutoDeriv/>
> >>
> >> As it's convenient, I suggest now to put the .derived file and its
> content (maybe updated) into the svn repo as we have .xmlcatalog.xml which
> is
> >> also Eclipse specific.
> >>
> >> Can I get a consensus about that?
> >>
> >> Jacques
> >>
> >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

Jacques Le Roux
Administrator
Hi Girish,

Yes I'm aware of point 1 :)

Your point 2 is an interesting trick. With Autoderiv I can hide more than the build dir. Notably some dirs in runtime (not all of theml), w/o
limitation actually.

For instance, here is the content of my .derived file. I can add or remove as I need.

.settings
bin
build
gradle
lib
runtime/indexes
runtime/catalina
runtime/data
runtime/logs/birt
runtime/output
runtime/tempfiles
runtime/tmp
runtime/uploads

FTW for the .class file it's more when opening than searching that I need to hide.

For clean, it's used by cleanAll and I need that when I run the integration tests with: "cleanAll eclipse loadAll testIntegration" (I do that often).

To be sure to have all things clean (devil is in the details, I got bitten more than once by not cleaned data ;))

Thanks for sharing

Jacques

Le 27/12/2018 à 10:34, Girish Vasmatkar a écrit :

> Hi Jacques
>
> Following two settings help me not facing the issue you're facing. I, too,
> ran into this issue when I initially set up OFBiz on eclipse.
>
>
>     1. Uncheck Show Derived Resources when you do CTRL+Shift+R, such that
>     only Show Status Line is checked. I am sure you have it correctly, but just
>     in case.
>     2. This does the trick mostly for me. By default, eclipse sets "bin"
>     directly as the output folder for the compiled files. I have it as
>     "build/classes". I think eclipse does not include resources present in the
>     output folder as part of search result, so setting the default output
>     folder as gradle's output folder i.e. *build/classes* does the trick for
>     me. I am unsure if that's what you're looking for.
>
>
> So even if the derived setting is gone after clean task is run, if the
> output folder is set to *build/classes*, your search results should not
> include .class files.
>
> Also, when I am using eclipse for the development, almost always I rely on
> eclipse for compiling the sources. I have not used gradle clean task for a
> while. But with the about setting (changing default output folder), gradle
> clean task does not affect my search results i.e. it does not include
> .class files.
>
> Based on what I understood, I think above should help. Please let me know
> if that's not the case.
>
> Best,
> Girish
>
>
>
> On Wed, Dec 26, 2018 at 9:06 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Hi Michael,
>>
>> I asked because so far when you updated Eclipse you were losing your
>> plugins and their configurations. I recently updated to Photon and it's no
>> longer
>> the case. So it's no longer an issue for me :). At least as long as the
>> repos locations don't change. I'd then lose my local .derived file and
>> would
>> surely I'd forget about it :/. But this should not happen before a long
>> time...
>>
>> About the .class files showing when using Ctrl+Shift+R (opening a
>> ressource). It's not a configuration problem on my side.
>>
>> I guess when you speak about filters you think about what is explained in
>> the second answer of
>>
>> https://stackoverflow.com/questions/443169/exclude-folders-from-eclipse-search
>> .
>>
>> As you can see in comments there both options (derived and filters) have
>> advantages and drawbacks. I personally prefer using derived ("the *quick*
>> and
>> dirty way", very handy). But, as explained in stackoverflow, you face an
>> Eclipse bug. That's why AutoDeriv exists.
>>
>> So what's the problem for me? When you use the clean task, Gradle removes
>> the build dir. So also the dir where the .class files are (build\classes).
>> And then you lose the derived properties for these dirs :/
>>
>> Since to hide these files from opening or searching you need to set them
>> as derived, each time you use clean (I do it a lot) you loose this config.
>> That's why I use, and suggest to use as in wiki, the AutoDeriv plugin.
>>
>> Anyway as I said it's no longer a trivial but irritating concern for me
>> and I don't want to shoehorn anybody with my solutions :)
>>
>> Thanks for answering
>>
>> Happy holidays
>>
>> Jacques
>>
>> Le 18/12/2018 à 07:44, Michael Brohl a écrit :
>>> Hi Jacques,
>>>
>>> who is going to decide which files you want to see and which you don't
>> want so see? People have different taste on that and so you would be
>>> struggling with different settings checked in to the code repository.
>>>
>>> I'm not in favor of putting these files into the repository. I think
>> these are specific for each developer and it's no problem to keep them
>> locally.
>>> For your specific examples: I don't see any .class files when searching,
>> that must be a configuration problem on your side. For searching, you can
>>> also set up filters which provide an efficient mechanism to search (or
>> don't search) specific files.
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> Am 17.12.18 um 14:11 schrieb Jacques Le Roux:
>>>> Hi,
>>>>
>>>> I know we don't all use Eclipse but I though want to make a suggestion.
>>>>
>>>> 2 years ago I put this tip at
>> https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches
>> :
>>>>
>>>>             <<Hide folders from searches and hide some files when
>> opening a file.
>>>>     Most of the time you don't want to look into some folders because
>> there is nothing interesting there and they sometimes annoy you because of
>>>>     search errors (triste)
>>>>     It's also annoying to see *.class files when you look for a
>> similarly named Java source.
>>>>     Then you tool of choice is https://nodj.github.io/AutoDeriv/>>
>>>>     <https://nodj.github.io/AutoDeriv/>
>>>>
>>>> As it's convenient, I suggest now to put the .derived file and its
>> content (maybe updated) into the svn repo as we have .xmlcatalog.xml which
>> is
>>>> also Eclipse specific.
>>>>
>>>> Can I get a consensus about that?
>>>>
>>>> Jacques
>>>>
>>>>
>>>