Re include after exclude not working.

[Rouche]

Very nice project! Just a little issue. I have this configuration:

# set the 'root' folder as NOT derived
# by doing this, all resources of the project are NOT derived by default.
!/
# symlinks is derived. (and in svn:ignore)
symlinks.js
target
# all modules are derived
src/main/webapp
# except this project
!src/main/webapp/my_project
# but the js and map inside are
src/main/webapp/my_project/*.js
src/main/webapp/my_project/*.map

Everything seems to be ok, files inside other than js / map are not derived. But eclipse complain when i try to edit a .source for example.

Ouch its worse, i just tested something and it does not see the files as "modified" when i commit.

[nodj]

Hello Rouche, First of all, thank you for the compliment and for your feedback ! As a indie developer on that project, it's means a lot. Can you join your .derived file to this issue ? On the screenshot you give, I can't see the green square on the file, so I interpret this as a not derived file... But it doesn't match the pop up error of course... I don't understand that well.

Did you try to turn if off and on again ? I mean, restarting eclipse, refreshing the full project doesn't helps ?

Thank you very much and sorry for the inconvenience...

[Rouche]

Hi again, ok trying to explaion better.

i updated 1st comment, now i use proper formatting. It is the .derived file. im on Eclipse Mars.1 Refreshing / Restart / Close Open project same behavior.

The file, is in fact colored like normal. (Not derived by AutoDerived) and right clicking properties->Resource on it. No check boxes are on. All good so far. The bug happens when you try to modify the file, the Derived test by eclipse fires up. I am guessing because of this rule : src/main/webapp on the parent folder. And popups the warning window. Trying to commit in SVN1, even if there is changes in file (clicking yes on the popup and editing + save) does not see the file. probably because of the same derived computation.

Maybe there is a check in eclipse for those 2 cases handled differently than the label decorator. The label decorator and flags on resources are all perfect.

Here is the project structure to better understand what i want to do:

my_project (rule 1 nothing derived)
      |- target (dir derived)
      |- symlink.js (file derived)
      |- src
          |- main
              |- java (dir normal)
              |- webapp (dir derived and everything inside by the rule 4)
                   |-module x  (inherit parent)
                   |-module y  (inherit parent)
                   |-my_project (dir normal by the rule 5) 
                   |        |- *.js and *.map (Type scrypt compiled files, derived, by the last 2 rules)
                   |-module z (inherit parent (webapp))

[nodj]

Hello again, and thank you very much for your new inputs and previous post formatting =) I must say it's been a long time since I last worked on AutoDeriv... Nevertheless, I think you're perfectly right on your analysis of the issue. Eclipse promptly assumes that the content of a derived folder is also derived... It's a great optimisation, but sadly it's not really compatible with the rules you wrote...

You should try to mark only the content of folder as derived, not the folder itself, for each folder in the tree. I think the problematic rule is src/main/webapp. Try something like src/main/webapp/*.* or even src/main/webapp/* instead so that eclipse doesn't face any derived folder when a not derived file is in it.

It should be automatic, written in the plugin itself. Unfortunately, I don't have my dev machine for now. I don't even have an eclipse instance to test my solution...

Can you keep me updated on what rules works for your situation? Although I'm confident you will find a good set of rules, I'm not sure at all about the one I wrote just before...

Sorry for this weird answer... Not the support you'd expect :s

[Rouche]

Hi, Of course i can do it for each folder separatelly in webapps.

I always think long term when i do something, so my rules were done ina way that if someone add a new module, it will be automatically derived without even having to veify config, rules y, etc. etc.

I got another idea sleeping, and im sure it will work every cases. Each lines might become a comma separated list of rules. Each must be true for it to work. The line would then become src/main/webapp, !src/main/webapp/my_project

Worst case, I might fork and ask for a pull request :)

[nodj]

Your rules are perfectly crafted :) In fact I think it's a limitation of my own algorithm. The missing part is the following:

If a file is derived, mark all parent folder as not derived.

I think that will do the trick, without modifying the script syntax. Also, it's quite logical and follows more accurately the eclipse logic. I should have my dev plateform in a few weeks from now. I'll try to update this, and other reported bugs.

[Rouche]

You mean: If a file or folder is NOT derived, mark all parents folder as not derived. ?

Well this will affect the natural traversal order. I dont think you can go back up folders because of a file rule deeper, it will have unwanted effects. Here is an example:

root
   |-folder 1 (derived)
        |-sub folder1 (not derived because of overriding rule)
                 |-sub folder 1.1 (derived files *.xxx)
                 |-my_file.yyy (not derived -> flag back)
        |-sub folder2 (derived inherit parent)

I might be wrong but, If you underive parents to fix eclipse problem, it will underive sub folder2 (because you have to underive folder1) when you continue traversal. Of course i dont know your traversal Algo. I did not check yet.

EDIT: Forget everything, i made it work while i was thinking about a solution LOL. I told myself maybe /* include folders! And fortunatelly it does! Ill do some more tests but it seems all good with eclipse!

# set the 'root' folder as NOT derived
# by doing this, all resources of the project are NOT derived by default.
!/
# symlinks is derived. (and in svn:ignore)
symlinks.js
target
# YES! all webapp modules are derived. Not webapp itself because i know theres a folder inside that is not!!!
src/main/webapp/*
# except this one
!src/main/webapp/folder
# but the js and map inside are
src/main/webapp/folder/*.js
src/main/webapp/folder/*.map

[nodj]

Hello again :) Of course I meant If a file or folder is NOT derived, mark all parents folder as not derived.. Thank you for being atentive and correcting me :)

In your example (copy/pasted for clarity)

 root
   |-folder 1 (derived)
        |-sub folder1 (not derived because of overriding rule)
                 |-sub folder 1.1 (derived files *.xxx)
                 |-my_file.yyy (not derived -> flag back)
        |-sub folder2 (derived inherit parent)

sub folder 2 should not be affected by the underivation of my_file.yyy. I imagine a script like that:

!/         #clear all the flags (rule 1)
/folder1/*   #folder1 and all it's children are now derived (rule 2)
!*.yyy        # my_file.yyy matches the filted, marked as NOT derived (rule 3)
# The previous filter will also cause the following:
# Parents folders of my_file.yyy (hence `root`, `root/folder 1`, 
# and `root/folder 1/subfolder 1`) will be underived if derived.

result should be:

 root                                    [NOT derived, rule 1]
   |-folder 1                            [NOT derived, rule 3]
        |-sub folder1                    [NOT derived, rule 3]
              |-sub folder 1.1           [derived, rule 2]
                     | anything.in.here  [derived, rule 2]
              |-my_file.yyy              [NOT derived, rule 3]
        |-sub folder2                    [derived, rule 2]

Well, this is what I would expect with the given script. There is some work to do, for instance

• rule 2 as written should, or should not affect folder 1 ?
• if rule 2 was written as folder 1, should the children be affected ?

There is some design decisions to take, I'll see that the next week, or the one after that, I hope :)

[Rouche]

Hi again, i have put an edit.

I have it working perfectly with this rule combination: Since writing it this way does not affect the webapp folder. Only its childrens so it fixes eclipse problem.

!/ src/main/webapp/* #all webapp folder. !src/main/webapp/myfolder #except this one

[image: ResoluTech] Jean-Francois Larouche Architecture de Solutions TI [image: Cell] 514-965-9224 | [image: Email] contact@resolutech.com[image: Web] http://www.resolutech.com http://ca.linkedin.com/pub/jean-francois-larouche/1/b84/530

On Mon, Nov 23, 2015 at 9:55 AM, johan notifications@github.com wrote:

Hello again :) Of course I meant If a file or folder is NOT derived, mark all parents folder as not derived.. Thank you for being atentive and correcting me :)

In your example (copy/pasted for clarity)

root |-folder 1 (derived) |-sub folder1 (not derived because of overriding rule) |-sub folder 1.1 (derived files *.xxx) |-my_file.yyy (not derived -> flag back) |-sub folder2 (derived inherit parent)

sub folder 2 should not be affected by the underivation of my_file.yyy. I imagine a script like that:

!/ #clear all the flags (rule 1) /folder1/* #folder1 and all it's children are now derived (rule 2) !*.yyy # my_file.yyy matches the filted, marked as NOT derived (rule 3)

The previous filter will also cause the following:

Parents folders of my_file.yyy (hence root, root/folder 1,

and root/folder 1/subfolder 1) will be underived if derived.

result should be:

root [NOT derived, rule 1] |-folder 1 [NOT derived, rule 3] |-sub folder1 [NOT derived, rule 3] |-sub folder 1.1 [derived, rule 2] | anything.in.here [derived, rule 2] |-my_file.yyy [NOT derived, rule 3] |-sub folder2 [derived, rule 2]

Well, this is what I would expect with the given script. There is some work to do, for instance

• rule 2 as written should, or should not affect folder 1 ?
• if rule 2 was written as folder 1, should the children be affected ?

There is some design decisions to take, I'll see that the next week, or the one after that, I hope :)

— Reply to this email directly or view it on GitHub https://github.com/nodj/AutoDeriv/issues/6#issuecomment-158959467.