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
For instance, here is the content of my .derived file. I can add or remove as I need.
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 ;))
> 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
>>>>
>>>>
>>>
Locked
smime.p7s (5K)