I was trying to publish a new version of my plugin. After several tries (with the automatic-reply system ) by the new “publishing rules”. I have and an automatic response that can understand…
My code it’s like
module Cl3
#My includes
module cl3Loader
#My code
end
end #Cl3
But i have this response when try to publish the plugin… is not the same structure?
This is the response
All Ruby files in your extension should be contained in a top-level module. We recommend using your company abbreviation for the top level and then your application or library abbreviation in another module contained within that module. For example:
module SU
module MyCoolApp
# - code -
end #MyCoolApp
module MyLibFuncs
# - code -
end #MyLibFuncs
end #SU
Perhaps it’s something as simple as your module name NOT starting with an UPPER-case letter.
So NOT cl3Loader
Try Cl3Loader
All Classes and Module names should start with an UPPER-case letter.
Method names [def] should always start with a lower-case letter.
So should all ‘variable’ references.
Although $, @ and @@ variable references can start with either case because of the initial special character, it’s good practice to stick with lower-case too - although buit-in global $ ones often use CAPS.
Any Constants should also start with an UPPER-case letter - and it’s common [but not mandatory] that they are in all CAPS - e.g. ORIGIN.
It’s my fault write the module name in lowercase in this post when really have Upper-case in the plugin file. So sorry about that. The module name is Cl3Loader with the uppercase.
The code was working correctly until the new policies about publishing on sketchup. If I install the plugin on my version of SketchUp working properly. It’s the publishing “process” that tell’s me this problem.
All the code follow the standar like the Constants and upper case characters.
You know any other reason why publishing can be showing this message.
Unfortunately the signing-portal process is NOT [hopefully, yet] perfect.
I have had rejections stating that only one file and a subfolder of the same name are allowed in the RBZ.
But of course that’s exactly what there was in the submitted RBZ.
Some compression apps give false results when the signing-portal parses them !
Although you ought to be able to sign a simple plugin [non-extension] - if its RBZ has a matching folder to take the .hash file - it will often fail if that folder is empty - fixed by adding a spurious non-signed file like a .hash that is overwritten by the process !
The only thing I can suggest is that you to tell the guys at the signing-portal - although in my experience it is far from useful !
I have already demonstrated to them in private messaging a major security hole in the signing and load-checking process - basically, caused by SketchUp extension code loading by file-name - NOT file-name+file-type - so an unsigned [but the hash-checker does not spot it] vanilla RB, in preference to the ‘real’ signed RBS - allowing malicious content to be added to an RBZ, while retaining its signed validity !
So a idiot downloading an RBZ from a non-kosher site [i.e. one that’s NOT a ‘good’ one - e.g. EW or SketchUcation PluginStore, Smustard etc], could be fooled into thinking it was validly signed and perfectly safe - when of course it wasn’t !
Of course, a sensible user downloading an RBZ from one of the ‘good’ sites actually needs NO signing to be assured of its validity anyway.
So the whole draconian signing regime is very flawed [IMHO].
But who am I to criticize this new ‘innovation’ ?
Other opinions would be very welcome…
I looked into the last review and the issue is that the extension is defining two root level namespaces:
Module Cl3ver and Cl3.
In your root RB file cl3ver_cl3ver.rb you define module Cl3ver while in cl3ver_cl3ver/cl3ver_cl3ver_loader.rb you define module Cl3. This needs to be consistent - make sure all your RB files define the exact same root namespace. Then within your own namespace you can do whatever you want.