I see it more as a loosely coupled group of modules.
Not as much from the developers side. But from the end user side.
The point is that I don't like these big platform solutions.
I like to pick what I need and chose the best tool for the job.
That's also why I went with guice instead of spring.
Currently the most pain I have is the heaviness of onami.
- It is hard to update the homepage -> maven build and svn commit and stuff
- It is hard to participate (if you are not a committer) -> send patches
by mail
- It is hard to get user feedback -> need to create a login at the
apache JIRA
And I think the biggest problem onami has is its lack of visibility.
Basically Google doesn't do a thing to support the existence of a
community around guice.
I.e. their list of third parties module [1] is helplessly outdated.
Onami and some other guice modules I use are not listed there.
So I feel if you want to get some drive into onami you have to achieve
the following
- make it visible
- make it light weight
Both of them are hard to do. And I somehow have the feeling that being
part of Apache can be both an advantage and a disadvantage. So in the
end, I might just not be too sad if onami gets send to attic.
[1] https://github.com/google/guice/wiki/3rdPartyModules
On 07/31/2015 10:44 AM, Eric Charles wrote:
I think it is more how we see onami. Are they independent modules that
live more or less independently and maintained by different people, or
a service for the application developer.
If you have changes in only one module, the workload will be the same,
but if you have changes in multiple modules, you would have to release
multiple times instead of one. Of course, releasing one supposes the
timing is good to do it.
On 2015-07-31 10:36, Stephan Classen wrote:
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
