You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Kervin Sam 9d2b1b2574 Packet registry now singleton instance rather than statics 6 years ago
src Packet registry now singleton instance rather than statics 6 years ago
README.md Removed JMS and Spring 6 years ago
pom.xml Removed JMS and Spring 6 years ago

README.md

What is DrawPic-Core?

DrawPic-Core is a set of interfaces, classes, and resources that can be shared between any java-based implementation of the DrawPic server or client.

Why is it in a separate repository?

Having this separate repository allows for a common ground, or standard protocol, that can reduce errors caused by needing to maintain two sets of the same code.

How will it be used?

It is meant to be “shaded into” the packages of the previously mentioned projects. This means that the packages/classes of this project will be included in their archives (jar files).

In order to do this, one must install the project into their local Maven repository. This is done by running Maven’s “install” goal in the project directory. Afterwards a dependent project can shade it by having the following in their pom.xml

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <artifactSet>
                <includes>
                  <include>cse110team4.drawpic:drawpic-core</include>
                </includes>
              </artifactSet>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

How is DrawPic-Core being developed?

Currently Kervin Sam is in charge of the structure and direction of the core files. It is recommended that other team members give him prior notice before attempting any changes as it could lead to breakage of dependents.

Notes

  • We previously used the Spring dependency inversion framework and ActiveMQ, so some of the code may look irregular. This is because we wanted to avoid recoding whole sections of code that previously depended on these systems.
  • For most cases, it is recommended if there is an interface in here that a dependent can use, it should use it