Power TAC server plugin structure

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Power TAC server plugin structure

grampajohn
Administrator
As plugins proliferate, it gets harder and harder to manage the process and make tests on isolated plugins work properly. I count 6 out of 17 plugins that someone might want to replace for research purposes. One (powertac-common) is a plugin because it represents definitions that need to be shared among broker, server, and visualizer environments. One (powertac-server-interface) might need to stay a plugin because of dependency relationships, but I'm not sure about that. The rest could be moved into the server, I think. Is this worth doing?

In the meantime, here's a simple shell script that updates all your local clones. It might be worthwhile to write another that would tell you which local repos have un-pushed changes. That won't be quite as simple.
---
#!/bin/bash

for dir in `ls -d powertac-*`
do
    pushd $dir
    git pull
    popd
done
---

Thoughts?

John
Reply | Threaded
Open this post in threaded view
|

Re: Power TAC server plugin structure

ddauer
I think we should leave things the way they are right now. Just to name few, we need powertac-web-app as a plugin because we want to be able to integrate the web-app into the server as well as have it running separately. The same goes for any customer-model: If you want to add/remove it, you should not have to modify server code/folder structures but simply be able to do "grails install-plugin name".

But should there be code in a plugin that is absolutely not likely to be exchanged/extended with/by other plugins, I guess merging the code into powertac-server would be ok.

- David

On Fri, Mar 18, 2011 at 7:10 PM, grampajohn [via Power TAC Developers] <[hidden email]> wrote:
As plugins proliferate, it gets harder and harder to manage the process and make tests on isolated plugins work properly. I count 6 out of 17 plugins that someone might want to replace for research purposes. One (powertac-common) is a plugin because it represents definitions that need to be shared among broker, server, and visualizer environments. One (powertac-server-interface) might need to stay a plugin because of dependency relationships, but I'm not sure about that. The rest could be moved into the server, I think. Is this worth doing?

In the meantime, here's a simple shell script that updates all your local clones. It might be worthwhile to write another that would tell you which local repos have un-pushed changes. That won't be quite as simple.
---
#!/bin/bash

for dir in `ls -d powertac-*`
do
    pushd $dir
    git pull
    popd
done
---

Thoughts?

John



If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Power-TAC-server-plugin-structure-tp2699006p2699006.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Power TAC server plugin structure

grampajohn
Administrator
I am not suggesting we change anything right now, and the ones you mention are indeed ones that should remain as plugins. The ones I was thinking of are accounting-service, broker-proxy, physical-environment, random, and tariff-market. It might make sense to do some consolidation in the short term. For example, the dependency graph gets simpler if we bundle tariff-market with accounting-service.

Does this make more sense?

John
Reply | Threaded
Open this post in threaded view
|

Re: Power TAC server plugin structure

ddauer
Sure, ok, but is accounting-service than still an adequate name?

David

On Fri, Mar 18, 2011 at 9:45 PM, grampajohn [via Power TAC Developers] <[hidden email]> wrote:
I am not suggesting we change anything right now, and the ones you mention are indeed ones that should remain as plugins. The ones I was thinking of are accounting-service, broker-proxy, physical-environment, random, and tariff-market. It might make sense to do some consolidation in the short term. For example, the dependency graph gets simpler if we bundle tariff-market with accounting-service.

Does this make more sense?

John



If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Power-TAC-server-plugin-structure-tp2699006p2699574.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Power TAC server plugin structure

grampajohn
Administrator
ddauer wrote
Sure, ok, but is accounting-service than still an adequate name?
I'm open to suggestions, but remember, the original idea behind the accounting-service included the functionality of the tariff market. In the meantime, I have already consolidated tariff-market into accounting-service. The tariff-market plugin is no longer needed.

John