On Oct 11, 2016 12:23, "Sergio Schvezov" <<a href="mailto:sergio.schvezov@canonical.com">sergio.schvezov@canonical.com</a>> wrote: > > El martes, 11 de octubre de 2016 06h'38:49 ART, Jian LUO <<a href="mailto:jian.luo.cn@gmail.com">jian.luo.cn@gmail.com</a>> escribió: >> >> Hi, >> >> Thanks for the explanation. That's exactly what comes first in my mind. >> I've tried to customize the ant / jdk plugin by overriding the env method. >> The doc string of BasePlugin.env reads "return a list with the execution >> environment for building". However the result env applies both to build >> time and to the generated wrapper nonetheless. How can i override runtime >> only env in the plugin? > > > Look at how we do it in the go plugin. That will give you anice idea. Thanks. I'll give it a try. > > With regards to a way to do it more generically we want to eventually introduce a build-environment keyword for parts and have that carry some weight in the chaining of parts with the `after` keyword. As an illustration you would be able to do something like this: > > parts: > my-app: > plugin:maven > source: <path to source> > after: [ibm-java] > environment: > - CLASSPATH:.... > build-environment: > - $ibm-java > ibm-java: > plugin: dump > source: <path to IBM java sources> > build-environment: > - JAVA_HOME: .... > - PATH:.... > environment: > - PATH:.... > > And for apps: > > apps: > my-app: > command: <command> > environment: > - $ibm-java > -.... > > Something like that. This in the design phase though. But this way you can provide a Java to build as a part and a subsequent one to use as the runtime. Great! Will it be back ported to 16.04 when finished? Jian