On Oct 11, 2016 12:23, "Sergio Schvezov" <sergio.schve...@canonical.com>
wrote:
>
> El martes, 11 de octubre de 2016 06h'38:49 ART, Jian LUO <
jian.luo...@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?

Jian
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Reply via email to