PMD Module for Salesforce Metadata #4877
Replies: 4 comments 6 replies
-
|
First thing's first...I'm on the fence as to the namespace. It's going to be either:
The second option ties in with the unified salesforce namespace (see #3846.) The first, well, I'm not crazy about using a platform acronym in a namespace. It goes against my nature to be even a little opaque in that regard. I would love input on this sooner than later, as it's going to inform my first steps in creating this module. Tagging @codefriar as I think he's interested in following this. The old quote applies here: "The two hardest things in programming are cache invalidation and naming things." - ? |
Beta Was this translation helpful? Give feedback.
-
I'm assuming this will be under the
I'd not do this at the time being. Moving Apex / Visualforce to a different artifact to get them all together would be a breaking change (big no-no for non-major releases). Moreover, if we wanted to do something like this, we could use a meta-module (ie: a pom shipping |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure, how far you are with your experiments. But one different way would be, to develop a separate module completely outside of the PMD source tree. That is, you add pmd-core and pmd-xml as dependencies. Once this is working, we can think about, how and where we want to place it inside PMD. Just a suggestion from my side. Regarding the namespace question: If it goes into the module "pmd-xml", then it must be prefixed with
Yes, we should do it step by step and not unify something that doesn't exist yet. Let's first have the pieces that we want to unify. Only then, we can see, how and if it makes sense to unify this at all. I agree with what @jsotuyod said: "It's more a distribution issue". |
Beta Was this translation helpful? Give feedback.
-
|
I think pulling core and xml into a separate module and working from there is sound advice, thanks. |
Beta Was this translation helpful? Give feedback.
-
|
This will of course create a bit more effort, when we want to integrate it into the main PMD repository. But it's easier, to try and develop rules that way. I came to my mind, that you essentially are creating custom rules. We have this e.g. https://github.com/pmd/pmd-examples - which gives a starting point for writing custom rules for java. But it should be easily adaptable for custom rules for XML. You additionally get the ability, to create a custom distribution which contains PMD + your custom rule - this might make it easier for any potential users to use it right away. |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking about that as the examples repo is pretty bare bones right now, and I'd love to flesh that out further for the project.
I see what you are saying about creating custom rules. In a sense, that is true. Howewer... The one thing that is sticking in my craw though is that the way Salesforce metadata XML is constructed is very domain specific. Some things define schemas (custom fields, custom objects), some things define access control (which is essentially a schema with a different suit on), and some things define behavior (like flows...it's not uncommon to have the formula meta-language in there). What would truly add value to the community would be a language module that treats all of those things in a systematic, formal manner. Meaning I almost think that flows (for example, as a first pass) could benefit with the structure of an AST-based visitor traversal. With all that comes certain benefits:
I also see the hard part:
Flows would be a good place to start, because it's pretty easy to hack together XML rules for some of the other objects that are less "computational" tasks and more schema definitions.
And if I'm not mistaken, my proposal to create an true AST-vistor-based module for (at the beginning) flows makes it even more complicated :) Does that make sense? Sorry for the wall of text! Trying to make sure I'm being as clear as possible. Justin |
Beta Was this translation helpful? Give feedback.
-
|
Replying to myself here, but I was thinking...
In the spirit of keeping PMD (at its core) as objective as possible (assuming that is one of the goals of the overall project), it occurs to me that the domain-specific nature of Salesforce Metadata almost cries out for an independent module. |
Beta Was this translation helpful? Give feedback.
-
|
Collecting already existing issues, that are related here: |
Beta Was this translation helpful? Give feedback.
-
|
Hey @adangel and @jsotuyod . I'm still looking at this as a contribution. I've been busy with work, but much of that will inform me moving forward. Most importantly, I've had the opportunity to work with PMD 7 in the wild and leverage node streams in an HTML context. I'm starting to think that the way the HTML (or even VisualForce) language module is built might better reflect the nuances of Salesforce metadata. Although processing XML-as-XML is great, I find the context switching between the AST structure and the DOM method to be cumbersome compared to a unified approach. I've always leaned towards consistency, so that's where I get that from. |
Beta Was this translation helpful? Give feedback.
-
Hello all.
I've opened this discussion for feedback, ideas, and general updates. I'm working on contributing a language module for Salesforce metadata. I will primarily be working on this off-hours (weekends, etc.) but I have the time and the motivation.
The goal here is not to cover every possible type at the outset; rather, I want to start with the obvious: flows, and reports. Both have some easy hits (elements that require descriptions longer than n characters, etc.) As other types are brought into focus, they can be added later.
The structure I am proposing is as follows (this is rough as to namespaces, so bear with me):
I know there has been some chatter about a unified Salesforce namespace, but I wanted to get the ball rolling and get something out there for comment. I think we can unify everything when it seems feasible, but that unification comes at a cost: it will break existing code and there is wide adoption in that community.
Please share your thoughts, ideas, snide remarks, etc.! I'm excited to put something together. I've already hacked together some XML-based rules for a current project, so I'm comfortable working on something more permanent.
Incidentally this would put PMD on par (as it's own, standalone solution) with Autorabit's Codescan (at least as far as I can tell.)
@jsotuyod Please advise if this description needs some work.
A happy PMD user,
Justin Stroud
Beta Was this translation helpful? Give feedback.
All reactions