Thanks for logging the issue Ulrich.
On your points:
- every thing in the file system is lower case, when you must use it as a reference
a) Agreed and the rule has an error in it, because it actually says use lowercase but then the examples dont use lowercase. Fixed in the next version.
- the artifact has no version nummers in the filename
b) Agreed. As the IDE hard codes library attachments by filename rather than a classpath approach, this is important as it makes it much harder otherwise to swap in new versions of libraries. The current rule has no mention of version numbers as a result.
- the naming must show min. two levels of the namespace
c) It does currently includes two through the chained rule 02009, but workspace + project. Do you mean at minimum the first 2 levels of the namespace? I'm guessing you're implying the company name as 1st part. What's the imperative to include your company name?
d) You do you use the terms "Project" and "Module". Do these equate to a JDev "Workspace" and "Project" respectively?
- you must easily answer following questions: who is the producer ?, which application need it ?, which (deployment) type is it ?
f) How does the naming scheme answer "which application needs it?" ... do you mean to say how it was intended to be consumed (such as an ADF library or WLS shared library)?
Further points down the issue text:
e) On "Module as WLS Shared Library: enpit.asap.contact.wlslib.war", presumably this rule applies to JAR files too. However are JAR or WAR files that are deployed as WLS Shared Libraries packaged in a different fashion from ordinary WAR files? What happens if you decide not to deploy them as WLS shared libraries, doesn't this require a change to the file name?
Other discussion points:
f) Have these guidelines been devised at Enpit in isolation or conjunction with build tools like Apache Ivy and Maven? Would you think the same naming schemes would be necessary if the artifacts were injected into a repository with supporting meta-data?
g) Just a general comment, it is a pain that when Oracle devised the ADF Library they didn't choose a different extension from JAR, this would have made identifying them simpler.