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 <
jacques.le.r...@les7arts.com> 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
