I agree Stephan, and its specially sad that that Google does not want to help stuff like onami grow. In the end that will be what keeps guice from growing.
Soon I will put another vote for sending onami to attic. -Nino On Fri, Jul 31, 2015, 13:54 Stephan Classen <st.clas...@gmx.ch> wrote: > 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 > >>>>>> > >>>> > >> > >
