Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using JavaExec when calling DataNucleus #314

Open
thc202 opened this issue Feb 20, 2022 · 3 comments
Open

Consider using JavaExec when calling DataNucleus #314

thc202 opened this issue Feb 20, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@thc202
Copy link
Contributor

thc202 commented Feb 20, 2022

The DataNucleusEnhancer and SchemaTool use System#exit in case of errors which ends up terminating the Gradle daemon, with JavaExec it is created a different process and the exit calls wouldn't affect the Gradle daemon.

Is there are specific reason why they are being called programmatically instead of as command line?

Happy to provide a pull request if this is acceptable.

@thc202
Copy link
Contributor Author

thc202 commented Feb 20, 2022

While not directly related to this issue, have you considered using lazy configuration and also task configuration avoidance?

@rm3l
Copy link
Owner

rm3l commented Mar 27, 2022

Hi @thc202 ,

Thanks for your feedback.

The DataNucleusEnhancer and SchemaTool use System#exit in case of errors which ends up terminating the Gradle daemon, with JavaExec it is created a different process and the exit calls wouldn't affect the Gradle daemon.

Is there are specific reason why they are being called programmatically instead of as command line?

Happy to provide a pull request if this is acceptable.

No specific reason for this, except that I tried to use the methods already available in datanucleus-core.
I think only the schema tool tasks explicitly call the datanucleus-core SchemaTool main method, which indeed might end up calling System#exit:

On the other hand, I don't think the enhancer tasks have a similar issue. They instantiate a new DataNucleusEnhancer object, which contains methods to perform the operations needed, without calling the main method.

final DataNucleusEnhancer enhancer = new DataNucleusEnhancer(api.name(), null)
.setVerbose(verbose != null && verbose)
.setClassLoader(new URLClassLoader(classloaderUrls, Thread.currentThread().getContextClassLoader()))
.addPersistenceUnit(persistenceUnitName)
.setDetachListener(detachListener != null && detachListener)
.setGenerateConstructor(generateConstructor != null && generateConstructor)
.setGeneratePK(generatePK != null && generatePK)
.setSystemOut(quiet == null || !quiet);
if (targetDirectory != null) {
enhancer.setOutputDirectory(targetDirectory.getAbsolutePath());
}
final int result;
if (this.checkOnly) {
result = enhancer.validate();
getProject().getLogger().info("Enhancement validation succeeded for {} class(es)", result);
} else {
result = enhancer.enhance();
projectLogger.info("Enhanced {} class using DataNucleus Enhancer", result);
}

Anyways, thanks for pointing this out. This definitely makes sense. So if you get a chance to contribute a PR, that would be greatly appreciated.
Thanks.

@rm3l
Copy link
Owner

rm3l commented Mar 27, 2022

While not directly related to this issue, have you considered using lazy configuration and also task configuration avoidance?

Not yet, but any contribution is more than welcome :-)
I've created #331 and #332 to help keep track of these.
Thanks.

@rm3l rm3l added the bug Something isn't working label Mar 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants