Loading ...
Sorry, an error occurred while loading the content.

Plugin Organization - Proposal for 6.1

Expand Messages
  • thpr
    This is a proposal around Plugin Organization that came out of the last code meeting, and would be a proposal for an initial action right after 6.0 is taken
    Message 1 of 5 , Jul 19, 2010
    • 0 Attachment
      This is a proposal around Plugin Organization that came out of the last code meeting, and would be a proposal for an initial action right after 6.0 is taken into RC stage (not at initial branch, but at the point where we are less concerned with backporting patches)

      Currently, we have a lot of items under plugin.lsttokens
      This includes both Rules Tokens (LST tokens) as well as Game Mode Tokens.
      We are now in the process of developing some tokens that control UI behavior, which would be a third set.

      I believe we should split these out into separate packages.

      Principles:
      - Items which are related to file types defined in PCC files (or the PCC file itself) stay in lsttokens.
      - Option to put the PCC tokens into pcctokens, if that is clearer.
      - Items which are loaded from files in the system folder go into plugin.modetokens.
      - Items which are controlling the UI (even if related to the game mode) go into plugin.uitokens

      "controlling the UI" gets to be a bit tricky, so here are some key items there:
      - Items which simply clarify language (such as the plural for an Ability Category) are not uitokens
      - Items which control very specifically what is displayed (such as an HTML file) are uitokens
      - Conceptually, think about whether it is closely tied to OUR UI or to generic information related to the object.
      Generic information goes into modetokens, specific to OUR UI goes into uitokens.

      The plugin location (inside the plugins directory) can also be changed, although I'm far less concerned about that than I am trying to sort out the package names in the code.
    • Martijn Verburg
      Hi all, ... +1 from me, easier for new developers to understand the code base (every little helps). ... Very happy with all that. ... Sounds fair. ... If there
      Message 2 of 5 , Jul 20, 2010
      • 0 Attachment
        Hi all,

        On Tue, Jul 20, 2010 at 3:32 AM, thpr <thpr@...> wrote:
         

        This is a proposal around Plugin Organization that came out of the last code meeting, and would be a proposal for an initial action right after 6.0 is taken into RC stage (not at initial branch, but at the point where we are less concerned with backporting patches)

        Currently, we have a lot of items under plugin.lsttokens
        This includes both Rules Tokens (LST tokens) as well as Game Mode Tokens.
        We are now in the process of developing some tokens that control UI behavior, which would be a third set.

        I believe we should split these out into separate packages.

        Principles:
        - Items which are related to file types defined in PCC files (or the PCC file itself) stay in lsttokens.
        - Option to put the PCC tokens into pcctokens, if that is clearer.

        +1 from me, easier for new developers to understand the code base (every little helps).

        - Items which are loaded from files in the system folder go into plugin.modetokens.
        - Items which are controlling the UI (even if related to the game mode) go into plugin.uitokens

        Very happy with all that. 

        "controlling the UI" gets to be a bit tricky, so here are some key items there:
        - Items which simply clarify language (such as the plural for an Ability Category) are not uitokens
        - Items which control very specifically what is displayed (such as an HTML file) are uitokens
        - Conceptually, think about whether it is closely tied to OUR UI or to generic information related to the object.
        Generic information goes into modetokens, specific to OUR UI goes into uitokens.

        Sounds fair. 

        The plugin location (inside the plugins directory) can also be changed, although I'm far less concerned about that than I am trying to sort out the package names in the code.

        If there are no objections, then moving it to a more friendly maven structure might be one option.

        K
      • Andrew Wilson
        This all sounds good to me. andrew
        Message 3 of 5 , Jul 20, 2010
        • 0 Attachment
          This all sounds good to me.

          andrew

          On 20 July 2010 03:32, thpr <thpr@...> wrote:
          >
          > This is a proposal around Plugin Organization that came out of the last code meeting, and would be a proposal for an initial action right after 6.0 is taken into RC stage (not at initial branch, but at the point where we are less concerned with backporting patches)
          >
          > Currently, we have a lot of items under plugin.lsttokens
          > This includes both Rules Tokens (LST tokens) as well as Game Mode Tokens.
          > We are now in the process of developing some tokens that control UI behavior, which would be a third set.
          >
          > I believe we should split these out into separate packages.
          >
          > Principles:
          > - Items which are related to file types defined in PCC files (or the PCC file itself) stay in lsttokens.
          >        - Option to put the PCC tokens into pcctokens, if that is clearer.
          > - Items which are loaded from files in the system folder go into plugin.modetokens.
          > - Items which are controlling the UI (even if related to the game mode) go into plugin.uitokens
          >
          > "controlling the UI" gets to be a bit tricky, so here are some key items there:
          > - Items which simply clarify language (such as the plural for an Ability Category) are not uitokens
          > - Items which control very specifically what is displayed (such as an HTML file) are uitokens
          > - Conceptually, think about whether it is closely tied to OUR UI or to generic information related to the object.
          >        Generic information goes into modetokens, specific to OUR UI goes into uitokens.
          >
          > The plugin location (inside the plugins directory) can also be changed, although I'm far less concerned about that than I am trying to sort out the package names in the code.
          >
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
        • James Dempsey
          Hi, On 20/07/2010 7:50 PM Martijn Verburg wrote ... Agreed. ... Yes happy with that split. ... Any thoughts in that regard Kar? Cheers, James.
          Message 4 of 5 , Jul 20, 2010
          • 0 Attachment
            Hi,

            On 20/07/2010 7:50 PM Martijn Verburg wrote
            >
            >
            > Hi all,
            >
            > On Tue, Jul 20, 2010 at 3:32 AM, thpr <thpr@...
            > <mailto:thpr@...>> wrote:
            >
            >
            >
            > This is a proposal around Plugin Organization that came out of the
            > last code meeting, and would be a proposal for an initial action
            > right after 6.0 is taken into RC stage (not at initial branch, but
            > at the point where we are less concerned with backporting patches)
            >
            > Currently, we have a lot of items under plugin.lsttokens
            > This includes both Rules Tokens (LST tokens) as well as Game Mode
            > Tokens.
            > We are now in the process of developing some tokens that control
            > UI behavior, which would be a third set.
            >
            > I believe we should split these out into separate packages.
            >
            > Principles:
            > - Items which are related to file types defined in PCC files (or
            > the PCC file itself) stay in lsttokens.
            > - Option to put the PCC tokens into pcctokens, if that is clearer.
            >
            > +1 from me, easier for new developers to understand the code base
            > (every little helps).
            Agreed.

            > - Items which are loaded from files in the system folder go into
            > plugin.modetokens.
            > - Items which are controlling the UI (even if related to the game
            > mode) go into plugin.uitokens
            >
            > Very happy with all that.
            >
            > "controlling the UI" gets to be a bit tricky, so here are some key
            > items there:
            > - Items which simply clarify language (such as the plural for an
            > Ability Category) are not uitokens
            > - Items which control very specifically what is displayed (such as
            > an HTML file) are uitokens
            > - Conceptually, think about whether it is closely tied to OUR UI
            > or to generic information related to the object.
            > Generic information goes into modetokens, specific to OUR UI goes
            > into uitokens.
            >
            > Sounds fair.
            Yes happy with that split.

            > The plugin location (inside the plugins directory) can also be
            > changed, although I'm far less concerned about that than I am
            > trying to sort out the package names in the code.
            >
            > If there are no objections, then moving it to a more friendly maven
            > structure might be one option.
            Any thoughts in that regard Kar?

            Cheers,
            James.
          • Martijn Verburg
            Hi James/All, ... Any thoughts in that regard Kar? ... Maven likes to have the code structured like so: src/main/java src/main/resources src/main/sql
            Message 5 of 5 , Jul 20, 2010
            • 0 Attachment
              Hi James/All,

              > The plugin location (inside the plugins directory) can also be
              > changed, although I'm far less concerned about that than I am
              > trying to sort out the package names in the code.
              >
              > If there are no objections, then moving it to a more friendly maven
              > structure might be one option. 
              Any thoughts in that regard Kar?

              Maven likes to have the code structured like so:

              src/main/java
              src/main/resources
              src/main/sql
              src/main/assembly
              ..
              ..
              src/test/java
              src/test/resources
              ..
              ..

              It recommends using filters in its test plugin so that unit tests only run through its unit test phase but integration tests run through its integrationTest phase, so you could have all of our tests under src/test/java but split them after that.

              So where the plugin folder is currently is actually OK, it's the overall source code structure which would need some serious moving around to be friendly to Maven.  Is that desirable?  I think we'd need a majority decision there as it's not an insignificant shift.

              K
            Your message has been successfully submitted and would be delivered to recipients shortly.