How to use JpsFacetConfigurationSerializer with a properties class outside of jps-module Follow
We want to integrate with IntelliJ's build system so that, when a Webapp artifact is built, we generate source context files at build time and add them to the final artifact.
The generation process is configured by settings in a facet that our plugin adds. From every usage of JpsFacetConfigurationSerializer that I've seen, XmlSerializer.deserialize(facetConfigurationElement, [OUR_PROPERTIES_CLASS].class) is always used.
Problem: OUR_PROPERTIES_CLASS is in the main module, not in the jps-module. Because jps-module doesn't depend on the main module, it doesn't know about that class. Moreover, we don't want to move the properties class to jps-module, since it doesn't sense for it to live there. The facet is mainly used in the main plugin, but it should be possible to read it using this or another mechanism from jps-module.
Any suggestions for how to parse the facet from jps-module/JpsFacetConfigurationSerializer that don't involve OUR_PROPERTIES_CLASS to live in jps-module?
Please sign in to leave a comment.
So I understand it like you want to read facet data into a data bean class, but don't want to put this class into the process' classpath.
In see only two possibilities here:
1. Put the class into the classpath. If you don't want the put all classes from the main module, I would extract shared classes needed to read the project model into a separate module.
2. Create a different class duplicating the original data bean class and use it exclusively in the JPS process.
I would prefer solution (1) as it avoids logic duplication and enforces better structure for the plugin code
Eugene, thanks a lot for your prompt support, as always.
I was also toying around with a third idea, to add a separate facet that could have its properties object in jps-module.
But we ended up going for the different class duplicating fields of the original, since we don't want module proliferation.
Looking at XmlSerializer.deserialize, it sounds like it could use another utility method that just gets a member name and retrieves its value from the DOM tree.
We could also just manually parse the XML ourselves, but it would be great if the platform could offer us a more practical way of doing this (not sure if many people would use it, though...).