VK-Uploader is a true object-oriented and immutable VK (Вконтакте) group management utility. It is based on EO principles:

1. No null usage (why NULL is bad?)
2. No static methods (why they are bad?)
   • No public static methods
   • No private static methods
3. No mutable classes (why they are bad?)
4. No instanceof keyword usage, type casting, or reflection (why?)
5. No code in constructors (why?)
6. No getters and setters (why?)
7. No public methods without contract (interface) (why?)
8. No statements in test methods except assertThat (why?)
9. No implementation inheritance (why? and why?)

This interface is implemented by the classes which construct (decorate) VK WallPosts. For example the WallPostBase class is a fundamental implementation of that interface, as it encapsulates a VK API client instance and a UserActor instance.

Other implementations of this interface, such as WallPostWithMessage or WallPostWithAttachments add content to a wall post (text and attachments, accordingly).

Also, there are some convenient implementations of that interface, such as WallPostMusicAlbum or WallPostPhotoAlbum, which create a WallPost with audio (music album and a album artwork) or image (photo album) content.

A full list of classes implementing this interface can be found in the package wallpost.

In addition, the examples, which showcase how to utilize this interface and its implementations can be found in corresponding test package.

This interface is implemented by the classes which generate a series of WallPosts and combine them into a list of ExecuteBatchQueries. After the queries are executed, the updateProperties method shall be called in order to cache the queries` results. (usually with properties files).

This interface is implemented by classes which create WallPosts. For example, the PostableRootDir class creates WallPosts from the provided directory.

This interface serves as an entry point to the WallPosts. The classes which implement this interface create WallPosts using a Posts instance and then post (execute the generated queries) them.

Application starting point. The EntranceDirectory class, for instance, tracks the provided folder for changes and acts upon them (creates WallPosts and executes them).

1. Qulice (static analysis check)

   $ mvn clean test -DskipTests=true qulice:check
   

2. Unit tests

   $ mvn clean test
   

3. Integration Tests

   $ clean verify -Dvk.userId= -Dvk.groupId= -Dvk.token=
   

4. Full Pre-push validation (static analysis + unit tests + integration tests)

   $ mvn clean verify qulice:check -Dvk.userId= -Dvk.groupId= -Dvk.token=
   

5. Test coverage report (located in VK-Uploader/target/site)

   $ mvn clean test jacoco:report
   

For more info see Authorization Code Flow for User Access Token

Fork repository, make changes, send us a pull request. We will review your changes and apply them to the master branch shortly, provided they don't violate our quality standards. To avoid frustration, before sending us your pull request please run full Maven build:

$ mvn clean test -DskipTests=true qulice:check

To avoid build errors use maven 3.2+.

Pay attention that our pom.xml inherits a lot of configuration from jcabi-parent. This article explains why it's done this way.

If you have questions or general suggestions, don't hesitate to submit a new Github issue.