decoupling will reduce the workload for releasing. because you only
release one module and don't have to worry about all the rest.
what increases a little is the work for the developer of a module since
they have to maintain their dependencies and cannot rely to the parent
because it would only contain the most basic/common dependencies
On 07/31/2015 10:30 AM, Eric Charles wrote:
I see onami more like a platform, meaning that if a dev decides to use
onami-persist, it will potentially decides to use onami-configuration...
On my side I can invest to release if the workload is not high. Taking
the decoupling way is going to explode the needed work which I won't
be able to offer.
On 2015-07-31 10:20, Stephan Classen wrote:
OK, I see you point.
Still i vote -1
There are currently so few commits that at most 2 modules will have
changes in a release.
This means that all other modules have a version released which is equal
to the previous one.
In the end this makes it very confusing for the end user which version
they should choose.
On the other hand it is hard for the developers to figure out which
versions are affected by a bug.
I would rather suggest going the other direction and decouple the models
more.
Make them more like full projects and not part of a bigger one.
This would mean
- reduce the number common dependencies in the parent
- have a repository per project and not a big repo for all projects
- decouple the builds -> don't build all modules but have a build for
every module
- separate project/module for the homepage -> maybe move away from
building the main page with maven to something more flexible and include
only sub pages from maven (like statistics, testcoverage, javadoc,
dependencies, ...)
My hopes with this approach would be
- more up to date homepage
- like onami-persist is still in 'sandbox' even though it is
productive since over a year
- maybe become a 'community' site for guice
- easier to on-board new modules and developers
- it is just a pain if it takes more than an hour to get started
- move to git
- this is way simpler if we follow the default maven directory
hierarchy, which is again simpler for single projects than for
multi-projects
I think this would address you first two points. What it cannot address
is you third point about incompatible module versions.
But the question here is how interdependent are the modules? I don't
know most of the modules but the ones I took a look at did not interact
with anything except guice.
So what do you think?
Stephan
On 07/31/2015 09:55 AM, Eric Charles wrote:
This would result in:
- less manual version maintenance in the pom for the developer
- less work to have module(s) released
- less risk to have users use non compatible modules
On 2015-07-31 09:32, Stephan Classen wrote:
What is the main goal of this?
Releasing is currently not a pain.
Do you want to clear the way for a migration to git?
Stephan
On 07/31/2015 09:04 AM, Eric Charles wrote:
Hi,
To make it easier and lighter, I would like proposing having a single
release for all onami modules/extensions.
The downside is that we may have to release some modules even if
there
is no change for some of them.
WDYT?
Eric
