Plugin structure and server development

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

Plugin structure and server development

grampajohn
Administrator
I've spent the last five hours trying to figure out how to get the server to depend on locally-installed plugins. I found dependencies listed in three different places (of which I've found only one in the grails documentation), and with different version numbers. Apparently the file application.properties is updated by install-plugin. In server/grails-app/conf/BuildConfig.groovy, we can specify plugin dependencies, but only with explicit version numbers. The 0.9 > * syntax and all variations I've tried are rejected. On the other hand, it seems that if you simply add a line like <br/>
grails.plugin.location.PowertacCommon = "../powertac-common"<br/>
to BuildConfig.groovy, then list-plugins says it's installed.

This, and the problems I'm seeing with configuration, building, and testing, all makes me wonder why we are building core server components as plugins. I cannot imagine a working server without powertac-common, so why is that a plugin? It's not going to be used elsewhere, and I cannot imagine an alternative implementation. The same thing goes for the random and accounting-service modules.

Therefore, I propose that we fold powertac-common and accounting-service into powertac-server. I would like to do that sooner rather than later, because the longer we keep them separate, the longer we have to maintain separate configurations for testing and distribution.
Reply | Threaded
Open this post in threaded view
|

RE: Plugin structure and server development

Wolf
Administrator

I agree with John, that all components which are only used in the server shouldn’t be plugins, they should be all folded into powertac-server.

 

Best,

 

Wolf

 

From: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Sent: Monday, February 07, 2011 07:40 PM
To: Wolf Ketter
Subject: Plugin structure and server development

 

I've spent the last five hours trying to figure out how to get the server to depend on locally-installed plugins. I found dependencies listed in three different places (of which I've found only one in the grails documentation), and with different version numbers. Apparently the file application.properties is updated by install-plugin. In server/grails-app/conf/BuildConfig.groovy, we can specify plugin dependencies, but only with explicit version numbers. The 0.9 > * syntax and all variations I've tried are rejected. On the other hand, it seems that if you simply add a line like <br/>
grails.plugin.location.PowertacCommon = "../powertac-common"<br/>
to BuildConfig.groovy, then list-plugins says it's installed.

This, and the problems I'm seeing with configuration, building, and testing, all makes me wonder why we are building core server components as plugins. I cannot imagine a working server without powertac-common, so why is that a plugin? It's not going to be used elsewhere, and I cannot imagine an alternative implementation. The same thing goes for the random and accounting-service modules.

Therefore, I propose that we fold powertac-common and accounting-service into powertac-server. I would like to do that sooner rather than later, because the longer we keep them separate, the longer we have to maintain separate configurations for testing and distribution.


If you reply to this email, your message will be added to the discussion below:

http://power-tac-developers.975333.n3.nabble.com/Plugin-structure-and-server-development-tp2445743p2445743.html

To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.



Disclaimer
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.

The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.

Reply | Threaded
Open this post in threaded view
|

Re: Plugin structure and server development

ddauer
In reply to this post by grampajohn
Just some quick notes:

 I cannot imagine a working server without powertac-common, so why is that a plugin? It's not going to be used elsewhere, and I cannot imagine an alternative implementation.

What about brokers? Why should they not have access to powertac-common? The initial idea was that (grails) brokers can setup their broker in a fast and easy way with immediate access to the domain classes.

Therefore, I propose that we fold powertac-common and accounting-service into powertac-server. I would like to do that sooner rather than later, because the longer we keep them separate, the longer we have to maintain separate configurations for testing and distribution. 

This however means that powertac-common and accounting-service are going to have the same owner and that you are more likely to run into conflicts when multiple people are working on these two plugins.

I agree with John, that all components which are only used in the server shouldn’t be plugins, they should be all folded into powertac-server.

I wouldn't say "all components" because this would include customer/auctioneer/etc plugins as well. They really should remain plugins so we can have potentially multiple implementations of each plugin.

- David



Reply | Threaded
Open this post in threaded view
|

Re: Plugin structure and server development

grampajohn
Administrator
On 02/07/2011 03:33 PM, ddauer [via Power TAC Developers] wrote:

> Just some quick notes:
>
>       I cannot imagine a working server without powertac-common, so why
>     is that a plugin? It's not going to be used elsewhere, and I cannot
>     imagine an alternative implementation.
>
>
> What about brokers? Why should they not have access to powertac-common?
> The initial idea was that (grails) brokers can setup their broker in a
> fast and easy way with immediate access to the domain classes.

Thanks, David. That's the reason I could not remember. And the broker
does not need the accounting-service, hence the need to break that out
separately from powertac-common. However, brokers don't need ALL the
types in powertac-common -- for example, they would have no use for
TariffSubscription, and some are entity types (like Tariff and
TariffSubscription) that will never be communicated between server and
broker. How about Competition? Is everything in Competition public
information for brokers?

Our architecture documentation is very incomplete. I'll continue to work
at it.

>
>     Therefore, I propose that we fold powertac-common and
>     accounting-service into powertac-server. I would like to do that
>     sooner rather than later, because the longer we keep them separate,
>     the longer we have to maintain separate configurations for testing
>     and distribution.
>
>
> This however means that powertac-common and accounting-service are going
> to have the same owner and that you are more likely to run into
> conflicts when multiple people are working on these two plugins.

My experience with handling a few pull requests, including the most
recent one which would have been totally impossible with cvs or svn,
tells me not to worry too much about this problem. It's been much easier
than I anticipated.

I guess I'll go back to figuring out how to do development with this
setup. We are at a stage where we need to be updating the server,
common, and accounting together, so loading from the repository is not
an option.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

Re: Plugin structure and server development

grampajohn
Administrator
I have pulled apart powertac-common into powertac-common and powertac-server-interface, and tested the setup with powertac-accounting-service (Issue #99). You now need both powertac-common and powertac-server-interface to do server plugin development. Dependencies should be local for now (no dependencies on packaged powertac plugins), so you need to have them in sibling directories, and you have to run grails compile down the chain before your IDE will be happy.