#35 class files populating Freeplane's lib folder

[nnako]

Hi Henk,

this bug report concerns my personal usage of Freeplane's lib folder which can be specified using the plugins section of Freeplane's settings dialog. I use this folder as a general place where I manually put GROOVY scripts. During Freeplane's start-up these get compiled to CLASS files if there had been changes. I synchronize this lib folder accross different computers and operating systems.

Now, it seems that the GtdSync addon alters / update its private CLASS files within Freeplane's lib folder on a regular basis (maybe each Freeplane starts up), so that it gets populated with loads of CLASS files I never created myself. These "foreign" CLASS files get synchronized between my systems, causing a lot of traffic and overwriting themselves over and over again on the different systems. I myself get confused, trying to filter out "real" synchronisation contents. Please see this list of files within my lib folder:

Attributes$_addAttsVals_closure2.class
Attributes$_addNewAtts_closure1.class
Attributes$_removeDupAtts_closure8.class
Attributes$_removeDupAtts_closure9.class
Attributes$_removeDupAtts_closure9_closure10.class
Attributes$_setTableConfigWidth_closure7.class
Attributes$_setTableOptWidth_closure6.class
Attributes$_sortAttsTable_closure3.class
Attributes$_sortAttsTable_closure4.class
Attributes$_sortAttsTable_closure5.class
Config.class
Config.groovy
Config$_getConfig_closure3.class
Config$_getConfig_closure4.class
Config$_getConfigs_closure1.class
Config$_getConfigs_closure2.class
Config$_getConfigs_closure2_closure5.class
Core.class
Core.groovy
Core$_produceFontHierarchyWriter_closure3.class
Core$_produceFontHierarchyWriter_closure3_closure4.class
Core$_produceFontHierarchyWriter_closure3_closure5.class
Core$_produceFontHierarchyWriter_closure3_closure5_closure6.class
Core$_produceFontHierarchyWriter_closure3_closure5_closure6_closure7.class
Core$_produceFontHierarchyWriter_closure3_closure5_closure6_closure8.class
Core$_produceFontHierarchyWriter_closure3_closure5_closure6_closure9.class
Core$_setupCoreFontSizes_closure1.class
Core$_setupCoreFontSizes_closure2.class
Details.class
Details.groovy
Details$_setupDetails_closure1.class
Details$_setupDetails_closure1_closure5.class
Details$_setupDetails_closure1_closure6.class
Details$_setupDetails_closure1_closure6_closure7.class
Details$_setupDetails_closure2.class
Details$_setupDetails_closure3.class
Details$_setupDetails_closure4.class
Details$_setupDetails_closure4_closure8.class
Details$_setupDetails_closure4_closure9.class
Details$_setupDetails_closure4_closure9_closure10.class
Details$_setupDetails_closure4_closure9_closure11.class
Details$_setupDetails_closure4_closure9_closure11_closure12.class
Nodes.class
Nodes.groovy
Nodes$_addSubNode_closure1.class

You see all the CLASS files containing the $ sign as well as multiple "closures" within its name.

Would there be a way to avoid populating Freeplane's lib folder with these CLASS files?

Or does the responsibility lie outside of the usage and state of your GtdSync addon?

Thanks for your great work, anyway, but maybe there is a way to avoid the described effect?

[Henk van den Akker]

Hi Nnako,

This has nothing to do with GTDSync. The GTDSync lib files are precompiled and can be found in the specific add-on directory: addons\gtdSyncWithTodoTxt\lib.

What you see here is standard Freeplane behaviour. I assume you have put the uncompiled groovy classes Attributes.groovy, Config.groovy , Core.groovy, Details.groovy and Nodes.groovy yourself? Freeplane automatically (re)compiles uncompiled groovy classes in the defined lib directory/directories when starting up. The class files you see are the result of the compilation. You can check this as follows: start up Freeplane and watch that the date modified of the class files is changed to the current date and time.

So if these groovy files are really scripts, you should put them in a script folder. Scripts are compiled by Freeplane when you run them and do not leave class files in the scripts directory. If necessary you can define extra script folders in the Freeplane sessions.

If these groovy files are classes, i.e. functionality you need to call from other scripts, please let me know. I can then advise you on ways to put these in you lib folder.

Cheers,

Henk

[Henk van den Akker]

Hi Nnako,

I am closing this issue because it is a Freeplane feature and not a GTDSync bug.

To re-explain: the lib folders are meant for classes, i.e. a library of objects and methods that you can call from your scripts. In this folder you normally put compiled java classes in *.jar files. You can also put *.groovy files as a source for classes. In the earlier versions of Freeplane these classes were compiled when they were called from a script. Now they are compiled at Freeplane startup so that scripts that call these classes perform better.

The standard folder is "lib" and you can define more folders in "Script classpath: Additional directories containing classes and/or JARs" in the Plugins section of Freeplane's setting dialog.

To solve your problem you should put your groovy scripts in the "scripts" folder or any folder you define under "Script search path" in the same Plugins section.

Success!

Henk

[nnako]

Hi Henk,

thanks for your explanations and your time spent in thinking this through with me.

My point was that, as I use Freeplane's lib folder to store my own general scripts (and classes) which are called by other scripts (which I store in the scripts folder). And, in general I didn't expect other "participants" there. I will find a way to separate my own stuff from the stuff others put into the lib folder. Or I will simply exclude type ".class" files from the synchronization process.

Thanks.

[Henk van den Akker]

Hi Nnako,

If they are all called by other scripts, why don't you turn them all to classes?

I have a few alternatives for you.

The first alternative is to compile them, before putting them in the lib folder. With gtdsync I develop my groovy classes in Eclipse within the package 'gtdsync'. When they are ready I export them compiled to 'gtdsync.jar'. In that way you have just one file in stead of many class files.

The second alternative is to put the groovy source files in a folder that you sync with other systems and then make symbolic links to these files in a Freeplane lib folder that is not synced to other systems. I take a similar approach when I have to test changed groovy classes. Advantage: I do not have to export the classes as a JAR file every time and Freeplane cannot mess up my directory with compiled class files.

A point of attention is that changing the groovy source files while Freeplane is running has no effect: you first have to restart Freeplane to recompile the classes.

Cheers,

Henk