VK-Uploader is a true object-oriented and immutable VK (Вконтакте) group management utility. It is based on EO principles:
- No
null
usage (why NULL is bad?) - No static methods (why they are bad?)
- No mutable classes (why they are bad?)
- No
instanceof
keyword usage, type casting, or reflection (why?) - No code in constructors (why?)
- No getters and setters (why?)
- No public methods without contract (interface) (why?)
- No statements in test methods except assertThat (why?)
- 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).
- Qulice (static analysis check)
$ mvn clean test -DskipTests=true qulice:check
- Unit tests
$ mvn clean test
- Integration Tests
$ clean verify -Dvk.userId= -Dvk.groupId= -Dvk.token=
- Full Pre-push validation (static analysis + unit tests + integration tests)
$ mvn clean verify qulice:check -Dvk.userId= -Dvk.groupId= -Dvk.token=
- 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.