- initial docker-compose support

[jgangemi]

now from the correct repository... :)

Signed-off-by: Jae Gangemi jgangemi@gmail.com

[jgangemi]

ugh - i feel like this poor thing is languishing...

[rhuss]

No, not really ;-) I'm already integrating it, however was stuck with some other work. Little by little, the bird builds its nest ...

[jgangemi]

that's wonderful news! sorry i've been more or less missing in action, i just haven't been able to find any free time to devote here which makes me sad b/c i love this project. hopefully soon though b/c we are starting to use the plugin more and more at the day job.

[slamp]

We would like to generate docker-compose.yml. Any idea when you can close this ?

[fusesource-ci]

Can one of the admins verify this patch?

[fusesource-ci]

Can one of the admins verify this patch?

[jgangemi]

what ever happened w/ this?

[rhuss]

the bird was tired :). not forgotten, just late. the Duke-Nukem-forever PR, sorry. I won't get into it before the end of the month because of having to give some talks and going to conferences next week.

but the pr bubbles up in my prio list. please keep poking me ....

sorry.

[rhuss]

@jgangemi next baby step. No, its a bigger one: I just rebased it to the current branch (was a bit of a work because package names has changed). And did some adaptions. Test are not yet running because I remove one (of two) mocking frameworks, and this was Mockito ;-) (using jmockit right now).

One thought about the 'extended' configuration for stuff which is not available in the compose file. I'd like to avoid reusing the existing image configuration for this as a background objects, because thats becomes too complex and you dont know which part of the ImageConfiguration is in effect and which not (most of it).

My ideal solution would be to 'extend' docker-compose.yml about the things we have in addition. Hopefully this is possible (so that compose ignores our stuff). If this is not possible, then we add the extra stuff as key-value pairs in the configuration. I want to keep the external configuration configuration :-) as plain as possible, without nested structures so that it is kept 'slim'.

I pushed my changes to branch 384-docker-compose, would be cool if we work on this for the future, so that I'm closing this PR for now.

[jgangemi]

meh, i find jmockit to be overly confusing compared to mockito but i guess i'll have to get over that. :)

being able to extend docker-compose.yml sounds interesting. i thought compose supported inheritance last i checked. if so, that could be one way to add plugin configuration to the yaml.

if we assume it's not possible to augment the compose file, how do you propose handling lists? i guess there is the option of the .1, .2... identifiers like the properties file uses but i'm not a huge fan of that. what about a separate configuration block that just has the fields applicable to compose? i realize you want to keep things slim but that does seem limiting at the same time.

i'll try and take a look in the coming days - i have some sprint work slated at the day job based around the plugin.

[slamp]

Thanks a lot for that. I hope I will be able to test it soon. We are using 0.16.2 for now