|
||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hey Cletus,
Sorry for bothering you with this one again, its just to have a final statement from you about maybe supplying or totally refusing 'si createsandbox' support.
Background is, in my company we have various tools that need a registered sandbox of the integrity project for e.g version information, that are used for releasenotes and the graphical integrity client is installed anyway.
I totally understand you with relying on the Integrity Java API since we have an own Integrity plugin implementation using the CLI tools provided by the IntegrityClient installation. I'm currently trying to make this implementation stable but it is suffering from instablilities by the client itself (we are bound to version 10.1x) and for some cases it looks nearly impossible to work arround bugs in the client (Out of memory/Stackoverflow errors) leaving the client irresponsible) imposed by the distributed design si/integrityg/IntegrityClient...
Because of these issues i'm having a hard time thinking about working arround these problems or switching to the Java API too. Easiest way would be to have a checkbox 'Create Sandbox' replacing the 'projectco' commands in your implementation by 'createsandbox'. Do you think of the changes as being complex? I do not have any experience with the Java API and first observation of your current sources didn't get me far.
i' willing to contribute for having a stable solution, some recommandations?
br
Daniel