Hi Simo! Please see my comments inline.
2014-02-26 14:56 GMT+06:00 Simone Tripodi <simonetrip...@apache.org>: > Hi Mikhail!!! :) > see my replies inline > > On Sat, Feb 22, 2014 at 3:11 PM, Mikhail Mazursky < > mikhail.mazur...@gmail.com> wrote: > > > Hello guys, > > > > I decided to try a -SNAPSHOT of Lifecycle few days ago but it just don't > > work. My maven cannot find it. We definitelly need a release. > > > > > Thanks a lot for stepping out, refreshed energies are definitively needed > here :) > > > > After some investigation I found out that the build was broken [1], [2]. > > The first issue is fixed, the second one is not yet. I've just did some > > minor fixes and closed all the resolved issues (sorry for the spam). > Next I > > want to update the sites for all the components and finally do a release > of > > at least the Lifecycle component. > > > > > +1, but before cutting a release I would kindly ask you to react to a > couple of TODOs: > > * currently the Lifecycle component is the only one that to configure > Modules follows the Builder pattern than the usual Guice style, exposing a > custom `configure()` method - can you modify that? > > Looks like you are talking about ONAMI-102. I'm not sure what to do about it. I think I forgot what the current API looks like :) So I need to try to use it in real application and see what improvements I can propose. BTW the first mention about changing this is in ONAMI-45, where the functionality was introduced. * there is an intense usage of Guice internal APIs, that would not work > in an OSGi environment since internals are not exposed - can we replace > internals with OSGi-friendly code? > > I'm conserned about OSGi too - in a part of our app we use Equinox. Assuming you are talking about com.google.inject.internal package usage, I fixed couple of places but there is still one place (org.apache.onami.scopes.ConcurrentLazySingletonScopeImpl) where it is used. The mentioned usage can be reimplemented by using class object inspection instead of directly doing instanceOf check. Any better ideas? Please note that these requests are non-blockers, take the freedom to > choice to have them included or not in first release - code can be adjusted > during development anyway - it is just a matter of starting with a better > approach. > > > > I have some questions: > > > > 1. I found the release How To [3] but I'm not sure if I will be able to > > perform all the steps or if I have the necessary authority. Can someone > > help me? > > > > 2. It is not clear if the site should be deployed using step 3.2 or 3.3 > > from the How To, Finalize The Release section. For step 3.3 I haven't > found > > where the mentioned deploySite.sh is located. > > > > 3. Is there any interest in this project or the need for our Guice > > extensions is gone? There were no commits for a long time. > > > > > Absolutely yes - the decreasing number of commits doesn't necessarily > reflect the lack of interest but rather, at least in my case, the lack of > spare time :( I am working on a product which relies on an OSGi container > and no chances to have Guice involved ATM, so I don't have the reason to > justify my work on different stuff. > > There are of course topics that still need to be discussed, such as: > > * sandboxes still need to be discussed and promoted then released (I will > try to send a discussion to dev@ tonight to expose the console idea); > > * Guice 4.0-beta has been released time ago - we need definitively be > prepared to integrate it :) > > I don't think that will be an issue. Probably some people wait for 4.0 release but we can bump to -beta - I do not have any objections here. > > > What do you think? > > > > let's try to find some more spare time and keep the rock rolling :) > > Sounds great! :) Kind regards, Mikhail.
