Open techpavan opened 6 years ago
Out of curiosity, why do you keep generated code in source control?
This development scenario involves the same RAML being developed into multiple services - related, but disconnected. Client can consume multiple such services. If RAML file is being checked in to each such repository and generated code is built as a part of build process, it might lead to a case when one or few of the repos are out of sync. Thus, we maintain RAML and its documentation generated with raml2html in one repository, generated code is in a different repository and built artifacts pushed into the artifactory which is consumed as a maven dependency.
Can you consider a PR?
Will give it a try.
I'm running into the same issue. Can't we simply skip writing the generated source file if only the serialversionuid
was changed?
It will be hard to detect if there are some other changes but serialVersionUID
.
What about solution that @techpavan suggested?
Another option might be to generate default serialVersionUID
(config option) so POJOs remain the same.
wdyt?
If the class changes, so should the serialVersionUid. Vice versa, if the class does not have any changes, it should not be regenerated.
I would suggest a bit of a "hacky" solution here:
That's a real "hacky" solution.
Do you have some other idea?
What about objectStreamClass.getSerialVersionUID()
as @techpavan suggested?
I added the required code (see PR).
Notes:
objectStreamClass.getSerialVersionUID()
doesn't do the job as it returns serialVersionUID
- it doesn't generate it.
Actually it does, if you take a look at this stack overflow question: https://stackoverflow.com/questions/18294326/how-to-generate-serialversionuid-programmatically-in-java and this answer specifically https://stackoverflow.com/a/18294506/812272
However I have a feeling that the serialVersionUID
is not required at all and we are barking up the wrong tree.
serialVersionUID
is not needed when (de)serializing java objects to JSON (as per https://stackoverflow.com/questions/27738757/can-serialversionuid-be-ignored-when-serializing-to-json).
The plugins purpose is to generate controllers, clients and POJOs for data transfer. Inherently this means the objects transferred are
serialVersionUID
in other languagesObjectStreamClass
and friends) - if you do, then the application's architecture is terribly brokenFor that reason I'd vote for removing the serialVersionUID
and the Serializable
marker interface completely.
Still, some people prefer to have serialVersionUID
so I will propose:
serialVersionUID
optional (config param)serialVersionUID
. If the answer to that stackoverflow question is correct, we should use it. Otherwise, we can come up with our custom logic based on POJO's full name, methods' signatures etc to generate some kind of hash and get consistent uid. Please consider a PR(s) if this makes sense for you.
I have a project with multiple types and each time a minor change is made in the RAML and generate the code, all the POJOs get regenerated. Though the content of POJOs are same, it just comes up on the change list due to change in serialVersionUID forcing me to take an action - either commit or revert. It would be great if this can be handled by handing over the responsibility of serialVersionUID generation to standard Java packages rather than using a random long.
This can be done using the serialver command or objectStreamClass.getSerialVersionUID()