rework pom

[glelouet]

Just a few changes on the poms.

• the root pom is org.choco-solver.Choco . It manages the version of the sub projects to ${project.version}.
• the solver subproject is renamed org.choco-solver.choco.Solver
• basically each sub project is renamed with a upper case first letter, and placed in the lower case package of the parent pom (so parent is org.choco-solver.Choco => package is org.choco-solver.choco.X )
• each child project version is set to the root project version. No more specific version to upload, when deploying/releasing all are released altogether.
• push new version with version=x.y.z ; mvn versions:set -DnewVersion=$version . This also allows to tag and push the tag after deploy : git tag "$version" ; git push --tags

Still bugged as the geost ? project requires choco-solver 10.0.5 and … well it can't compile.

Anyhow not supposed to be accepted, just an example.

[cprudhom]

It is not clear to me why you put a capital letter on each artifact's name?
Same with parent/package name: that requires users to change their pom.xml...
In addition, I don't want all artifacts to have the same version; there is no need when an artifact has not been modified since last release.
You are right about Geost, it should be removed from parsers.

[glelouet]

Most of those are answered by : you are making a multi module project.
In that case, all the modules are supposed to work together. That avoids typically the issue of having a dependency on a module with a different version, which has a dependency on an older version, which is what is happening here. On the opposite if you have the same version for all children projects, whenever you make a change that may break a child you will be noticed as soon as you do the change if your IDE has both open, or when you want to maven package.

Yes, that means that whenever you push a new version, ALL children are also pushed to that new version, even if they did not have a change. But it also ensures they work together at any time, which is the goal of a multi module project.

If you consider that some modules are not supposed to be packaged at the same time, then there is no point in putting them in the multi module. But then they may lag very far behind and you will have to make complex updates when you want to update them to the last version.

This way, when you update Choco, people just need to change the choco-version variable in their pom to last version, and everything works.

[glelouet]

WRT Geost : if a module is no more maintained but may be maintained later, just remove it from its parent children. It remains in the git, can be added later on.

[glelouet]

WRT Upper and lower case first letter : it's to be sure the code you are using is in a packaged module and not a pom .
It also mimics the package/class in java : you can have a chocosolver.Choco class that defines what a Choco is, and a chocosolver.choco package that contains the definition of what is used in the Choco class.
eg you have a Model in chocosolver.choco package, so it's better if model-specific classes are placed in the chocosolver.choco.model package.

But you are right that it's not necessary and should be kept for a major version change(so after some thoughts). It however makes the modules tree a lot less messy.

[cprudhom]

So, in my opinion, there are some modifications you suggest that I should take into account and other I could.
I should :

• remove children that are not supposed to change that often (ie, cutoffseq, pf4cs, and sat). The other ones should be kept in the same project as parsers and examples rely on solver,
• have one unique version, declared in the parent pom.xml,
• remove Geost dependency, since the projet is not maintained anymore.

I could do:

• rename the package (but I'm afraid it has a huge impact on users' project) since all imports have to be updated,

What is still not clear to me is

it's to be sure the code you are using is in a packaged module and not a pom .

Do you have a pointer to this ?

[glelouet]

remove children that are not supposed to change that often

Frequency of updates is irrelevant. What is relevant is, if your modules adds "services" (not web services, more like abstract notion) in the scope of your global project.

For example, a child module that adds constraints code is obviously in the present scope of Choco. A module that allows to use Choco in parallel on several servers is also in this scope.

a module that makes comparison between choco and other solvers should not : it brings nothing to "solving problem in java using constraint programing".
Unless you decide that comparison is also the scope, and then you should create a jar submodule org.chocosolver.Eval to define the common evaluation classes, and the pom submodule org.chocosolver.eval to hold the various modules dedicated eg to a specific other solver.

Modules that are basically example of how to use choco should be maintained. When they are no more maintained(member of team leave, usage deprecated, etc.), they should simply be removed from their parent list to not be updated, pushed, etc anymore. Such a remove shall trigger a major version update, so adding "external" submodules to the main project should not be done lightly. Unless you don't mind adding 10 major version every month ^^ .

If you consider a project made by someone else is interesting, then you won't maintain it : so it should not be in the submodules of choco. Instead it should have its own project, so its own git, page, even though it can be placed in the groupid eg org.chocosolver.external . Let's say that I want to make several graph modeling tools in choco, but they use very specific heuristics and you have nobody to maintain it in the team because their use case is so specific. Then you don't add it in the multi module, I need to make my own project, and you advice me to add it in the org.chocosolver.external.glelouet package. Then later on I simplify and generalize it enough, then you can maintain it and will just copy the files from the git , just updating its groupid to eg org.chocosolver.solver.contraints, ensuring that it will always be updated along all Choco files.

[glelouet]

have one unique version, declared in the parent pom.xml

Yes for unicity, no for parent pom.xml . ALL children must have their own version specified, which MUST be the same as their parent. The maven versions:set -DnewVersion=1.0.0 will automatically update them all as long as they are recursively referenced from their parent.

You can also resolve it to a property and pass the actual value by command eg
${version_prop}
I tried it and was not convinced.

See this guys for more and interesting details :
https://jeanchristophegay.com/en/posts/maven-unique-version-multi-modules-build/

I did not check more than that, so my guess is things should be better by now - I just don't know it.

In the end I just use the mvn versions:set and it's the simpler for me (mvn release works fine too but if creates tags on the distant git even when it fails, leading to potential issues when the mvn process does several compilation for eg dynamic classes which result in being pushed in the git and treated as new files by the classloader and fail at reusing them. It make a big mess sometimes, when you are using dynamic class generation)

[cprudhom]

Frequency of updates is irrelevant. What is relevant is, if your modules adds "services" (not web services, more like abstract notion) in the scope of your global project.

Consider a child that is stable (no bug, no features), what is the point to keep it in an active big project ?

[glelouet]

remove Geost dependency, since the projet is not maintained anymore.

The correct term is : yes remove it from dependencies, and also remove it from its parent as a child. Don't remove the code, or if you do move it to eg a deprecated submodule

example of modules hierarchy :

org.chocosolver:chocosolver(pom) the root, with all the deployment params, has all the dependencies management, etc. It's never used by people, only called as parent.
  - org.chocosolver:deprecated(pom) with NO children declared
    - org.chocosolver.deprecated:Geost . The version of a deprecated project MUST be set to the last version if was used as, so as to know exactly in which branch it was working.
  - org.chocosolver:Solver(jar) that contains the main code of choco
  - org.chocosolver:solver(pom)
    - org.chocosolver.solver:contraints
      - org.chocosolver.solver.contraints:Graph(jar) that contains several constraints dedicated to graph management.
    - org.chocosolver.solver:parser(pom) contains the modules dedicated to parsing text to choco instructions.
    - org.chocosolver:FullSolver(jar) empty, just dependencies of Solver and all the constraints modules.
  - org.chocosolver:remote(pom) contains all the project that allow to execute/deploy/control chocosolvers in a grid of computers
    - org.chocosolver.remote:API(jar) gives all the interface provided  to control a remote choco or a grid of remote choco. (typically, submit a problem to be parsed , and return a Stream of entries : Search-> Solution )
    - org.chocosolver.remote:HTTP(jar) proposes an implementation of the API using a HTTP server as the registration point of the remote chocos, and proposing an HTTP interface for submiting problems to the grid of chocos.  
  - org.chocosolver:examples(pom) root of all examples. The examples can be linked in the root markdown (readme.md) with eg [Here](examples/TravelingSalesman/src/main/java/org/chocosolver/examples/traveling/Salesman.java)
    - org.chocosolver.examples:Basic(jar) give a simple code for basic example
    - org.chocosolver.examples:TravelingSalesman(jar) example of solver instantiation dedicated to TS.

[glelouet]

Consider a child that is stable (no bug, no features), what is the point to keep it in an active big project ?

How do you prove there is no bug ? How do you ensure there won't ever be a need for feature that should go into that project ?

The point of keeping it in an active project is to ensure it will be updated as soon as anything it relies on is updated,so you will have errors eg if updating a version of your logger.

Yes, if a user of such a project tries to always be up-to-date, he may be told that a major version was pushed while actually no diff was present in the project he uses. But he can always try to update and revert if needed.

But of course, maybe it will never be moved again. But then maybe the project should be moved outside of the multimodule project.
IMO the main idea is : be Lazy. Don't add modules you don't intend to maintain as a part of the core project. If you don't intend to maintain the remote choco manager(which is just in my head), then just don't add it. Make another project "ChocoRemote", maintain it when you want - or tell me to do it. But trying ot merge too many scopes in the same multi modules project will make it a mess to understand, maintain, use.

[mergify]

Welcome to our great project!
We're delight to have you onboard !