Re: ToolInstaller, PATH and environment

2013-09-03 Thread Oleg Nenashev
Hello, Probably, you could add custom-tools as a dependency in order to prevent duplication of DecoratedLauncher. Usage of @buildEnvVars(EnvVars env) is a real hack, but I don't see alternate solution as well :( BTW, it would be great to have an additional extension point in the custom-tool

Re: ToolInstaller, PATH and environment

2013-09-03 Thread nicolas de loof
2013/9/3 Oleg Nenashev o.v.nenas...@gmail.com Hello, Probably, you could add custom-tools as a dependency in order to prevent duplication of DecoratedLauncher. I think it would be even better to move it to core. nodejs also use a copy-paste for this class Usage of @buildEnvVars(EnvVars

Re: ToolInstaller, PATH and environment

2013-09-03 Thread Oleg Nenashev
I agree with such approach: https://issues.jenkins-ci.org/browse/JENKINS-19454 BTW, all plugins will need to retain classes till the next LTS release. Best regards, Oleg Nenashev вторник, 3 сентября 2013 г., 11:24:37 UTC+4 пользователь nicolas de loof написал: 2013/9/3 Oleg Nenashev

Re: ToolInstaller, PATH and environment

2013-09-02 Thread nicolas de loof
inspired by other plugins (custom-tools, nodejs) I've added a DecoratedLauncher to convert proc.env into EnvVar, then let the ToolInstallation post-process, then re-convert into env. Looks os hacky I wonder there isn't a better way ...