hdouss / jeometry Goto Github PK

Generic introduction on aljebra entities made Degrees entity to be generic. This is not necessary, only the resolve method should be parametrized. It does not make sens that Degrees is parametrized for itself.

After resolving #64 many entities has became generic. We should parametrize our usage of this classes in jeometry-double.

Stroke style width and dashing is well rendered by AWT renderers but stroke style colors are not taken into account by AWT renderers.

The testing classes has many unchecked warnings suppression. This is essentially due to generic classes could not be mocked safely. Let's get our mocking objects and get rid of these suppressions

Aljebra package entities should be parametrized. This could lead to better type safety and to seamless Scalar.Default.value implementation.

Add preconditions check to vector sum : vectors should be of the same dimension

A new DefaultStyle class was introduced in #13, but it is still not defining any class. We should define a by-default style and implement it as a default stroke and a default fill styles.

Documentation should precise release and versions management describing: milestones, release steps and release timing

Increase test coverage to 94%

Today, shapes are only renderables with a name. We should enhance shapes to have more attributes that could be useful to enhance rendering capabilities/options. First thing that will be added is a style property that will be defined these rendering attributes (could be enriched in the future):

• Stroke properties (width, style, color)
• Fill properties (color)

The class and its properties should be renderer-agnostic and cannot rely on (for example) AWT classes unless it is obvious that an AWT class describes perfectly the property. We could for example use the Color AWT class because it is describing a color without being AWT dependent.

Keep in mind that:

• Renderable classes instances are bare objects describing a geometric spatial properties
• Shape classes instances encapsulate a Renderable along with rendering related properties like name, color, style..

The first version to be released (v0.1) should be released and deployed automatically with one and a single action.
Like merging process, the release and deployment process could be done with github workflow actions.
Issues are organized in milestones.
Closing a milestone should be the event that triggers the release.

Travis CI build should not rely on Oracle jdk anymore. We should switch to openjdk in travis config file.

After resolving #74, the same thing should be done for OrderedRandom.
Either we use a "simple" implementation, or implement our own mocking objects. The objective being to remove warning suppression of Mockito mocking calls.

Add preconditions check to matrix sum : operands should be of the same size

There are some null usages that could be avoidable. Let's get rid of all null usages, and keep only those where no other option is available

Update release management workflow to upload artifacts. Uploaded arifacts should be jar package and javadoc for the 3 modules: aljebra, jeometry-api and jeometry-double.

After introducing rendering styles in #13 and #20, we should document this feature.

.gitattributes file should add the ident attribute to (at least) java files in order to have the version tag in javadoc with a proper id.

After parametrizing many classes, documentation should be updated to reflect generic classes usage

AWT renderers should use the introduced (in #13) rendering styles.

After resolving #74, there is still a need for mocking scalars for verifying purpose. Let's have our own spying mock for Scalar.

After resolving #64 many entities has became generic. We should parametrize our usage of this classes in jeometry-api.

We should get rid of aspectj dependency and AOP style be removing SameDimensionCheck. We can start by removing without replacing by anything as this check is not critical for now

Hi Douss, I am trying to use your library to draw road networks. Mostly, it is convenient. But I encountered some issues about it.

How to define the color of each individual shape? Currently, they are all black. I notice that the axises are in red. Could customise the shapes to different colours?

Looking forward your reply~

The project should meet all the requirements explained in Requirements, in order to be deployed to Sonatype which will synchronize artifacts to Maven Central.
Especially the group id should be com.github.hdouss as this is the group id applied for.
All secrets should be added to github secrets project settings and not commited to git.

Copyright dates in licence are still referencing 2016. They should be updated to 2020.

Implementing a class in OOP way to convert jeometry stroke style classes to an implementation of java.awt.Stroke in order to be used in renderers.

Axis in AWT Panel are drawn with the last stroke style that was set. They should be drawn with a default stroke style and with red color.

FixedVector class have constructor with varargs generic parameters. This forces the user of this classes to add warning suppression every time. We should get rid of this by either replacing this constructor with Lists or adding SafeVarargs annotation to these constructors.

Like the merging workflow, the release workflow should set X11 display so it can run in a headless environment.

The illustration in the documentation is not anymore corresponding to the code shown above it, after introducing styles. A new illustration with styles should be attached.

These classes miss tests :

• FixedColorFill
• FixedStroke
• FixedStyle

These classes have misleading names:

• DefaultStyle
• DefaultStroke
• DefaultFill

They are not really default classes as they have constructors to be more generic. We should rename them and probably create new real default classes.

The project documentation lacks contribution guidelines. These guidelines should detail pull requests merging process, code quality standards and test coverage thresholds that makes a pull request accepted.

After resolving #64 many entities has became generic. We should parametrize our usage of this classes in aljebra.

Update qulice to 0.18.19 version.
We should create separate issues if some new validations rules makes the build to fail.

Add line break before illustration in documentation. The layout is bad having a text just before the illustration.

After resolving #74, the same thing should be done for Vect.
Either we use a "simple" implementation like FixedVect, or implement our own mocking objects. The objective being to remove warning suppression of Mockito mocking calls.

The different Add and Sum classes (over scalars, vectors, matrices...) have constructors with varargs generic parameters. This forces the user of this classes to add warning suppression every time. We should get rid of this by either replacing this constructor with Lists or adding SafeVarargs annotation to these constructors.

The different Multiplication classes (over scalars, vectors, matrices...) have constructors with varargs generic parameters. This forces the user of this classes to add warning suppression every time. We should get rid of this by either replacing this constructor with Lists or adding SafeVarargs annotation to these constructors.

The project should have a gitattributes file to force checkout text in UNIX format with LF as end of file.

FixedMatrix class have constructor with varargs generic parameters. This forces the user of this classes to add warning suppression every time. We should get rid of this by either replacing this constructor with Lists or adding SafeVarargs annotation to these constructors.

jeometry should have an svg output figure renderer.

The project should have an automated way to build, check and merge pull requests.
We could use github actions to do that when the PR is labeled with "tomerge".

Generic introduction on aljebra entities made Predicate entity to be generic. This is not necessary, only the resolve method should be parametrized. It does not make sens that Predicate is parametrized for itself.

Settings in coveralls were modified to accept PR if the coverage does not drop more than 1%. In documentation, it is mentioned 5%, so it should be updated.

Documentation should have a section to document pom dependency declaration in projects using jeometry.

Increase test coverage to 93.5%

jeometry should have a test coverage of 93%. Special attention should be made to jeometry-api module.