Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH
Sergio Schvezov
sergio.schvezov at canonical.com
Tue Oct 11 11:06:11 UTC 2016
El martes, 11 de octubre de 2016 07h'37:33 ART, Jian LUO
<jian.luo.cn at gmail.com> escribió:
> On Oct 11, 2016 12:23, "Sergio Schvezov" <sergio.schvezov at canonical.com>
> wrote:
>>
>> El martes, 11 de octubre de 2016 06h'38:49 ART, Jian LUO <
> jian.luo.cn at gmail.com> 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?
Indeed it will
--
Enviado con Dekko desde mi dispositivo Ubuntu
More information about the Snapcraft
mailing list