Gin 3.0.0 released and available in Maven Central

[Grzegorz Nowak]

More information here: https://github.com/gwtplus/google-gin/releases/tag/v3.0.0

Enjoy :)

[Stefano Ciccarelli]

Great!

Thank you!

Il giorno dom 8 apr 2018 alle ore 17:52 Grzegorz Nowak <grz3gor...@gmail.com> ha scritto:

More information here: https://github.com/gwtplus/google-gin/releases/tag/v3.0.0

Enjoy :)

--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-gin+...@googlegroups.com.
To post to this group, send email to googl...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-gin.
For more options, visit https://groups.google.com/d/optout.

--

Stefano Ciccarelli 
GAE Application Division 
/ Director 
stefano.c...@mmbsoftware.it 

M.M.B. s.r.l. 
via Granarolo, 177/7 - 48018 Faenza (RA) - Italy 
tel. +39.0546.637711 - fax +39.0546.46077 
www.mmbsoftware.it - in...@mmbsoftware.it

Le informazioni contenute in questa comunicazione sono riservate e destinate esclusivamente alla/e persona/e o all'ente sopra indicati. E' vietato ai soggetti diversi dai destinatari qualsiasi uso, copia, diffusione di quanto in esso contenuto sia ai sensi dell'art. 616 c.p., sia ai sensi del DL n. 196/03. Se questa comunicazione Vi e' pervenuta per errore, Vi preghiamo di rispondere a questa e-mail e successivamente cancellarla dal Vostro sistema.

[Harsh Yadav]

Thanks a lot for the update, much awaited and needed.

I tested it out on some of the applications, and no issues so far. Also, the roadmap on github issues list looks promising.

Is there a way, this project can be ported to the main GWT github project. I think a lot of people would be benefited from it. Maybe work with the steering committee?

Also, an announcement in the GWT Users group regarding the same would be great as well, since google-gin group seems almost dead now.

Again, thank you for your effort on this!

[Thomas Broyer]

On Tuesday, April 17, 2018 at 8:43:53 PM UTC+2, Harsh Yadav wrote:

Thanks a lot for the update, much awaited and needed.

I tested it out on some of the applications, and no issues so far. Also, the roadmap on github issues list looks promising.

Is there a way, this project can be ported to the main GWT github project. I think a lot of people would be benefited from it. Maybe work with the steering committee?

It's highly unlikely that this would happen. If only because GIN is not forward-compatible with J2Cl/GWT3 (see also https://github.com/gwtplus/google-gin/issues/4)

Dagger2 is based on annotation processing so is forward-compatible, and while not a complete replacement for GIN (no static injection, @ProvidedBy/@ImplementedBy, @Inject(optional=true), or assisted-inject; though auto-factory can replace most uses of assisted-inject, and AFAICT it is planned that Dagger will get htis feature built-in eventually), migrating from GIN to Dagger is a rather mechanical process.

Fwiw, I'm in the process of migrating an application from GIN to Dagger:

1. replace assisted-inject with auto-factory,
2. replace static injection with either a static singleton Ginjector/Component to "pull from" or manual injection from the EntryPoint,
3. replace @ImplementedBy with @Binds methods, or having a direct dependency on the implementation class instead (when used with MVP, have your Presenter depend on the ViewImpl rather than the View in its @Inject constructor, possibly delegating to a non-@Inject constructor with View argument if you use it from tests with a mock view); replace @ProvideBy with @Provides methods that directly call the provider's get() method.
4. add @Inject on constructors (Dagger behaves similarly to Guice 4's requireAtInjectOnConstructors)
5. migrate all bind().to() et al. to @Provides and @Binds methods
6. "open" injection points: they cannot be 'private'; must be "package private" at a minimum.

(maybe I'll write a blog post once I finish the migration)

Note that @Binds in Dagger is syntactic sugar, so you could use @Provides methods instead (that are supported by both Dagger and GIN, though not using the same annotation) in the interim, and simply swap the imports once the module is ready to really migrate to Dagger.

BTW, that "new GIN" might benefit from having requireAtInjectOnConstructors and DaggerAdapter to ease migration.

Also, an announcement in the GWT Users group regarding the same would be great as well, since google-gin group seems almost dead now.

+1

 

[Harsh Yadav]

Thanks for the detailed insight on this Thomas as always. A blog post would be really awesome!

There are a lot of frameworks which depends on GIN (GWTP for one), and having an easier migration path would be really useful

[Stanislav Spiridonov]

I tried to migrate a project to Dagger and may confirm that migration is more or less mechanical job, but be prepared to follow things:

1. Dagger has a completely different ideology behind it. In GiN, you can have Gin Module (extends AbstractGinModule) for each your application part and include necessary parts set into application  Gin module (install(new UtilsGinModule())). Then you need to initialize the application context (extends Ginjector) with all necessary modules. In Dagger, you will need to include all modules into a component but it is more complicated because you need to maintain the same scope for all objects. Really I read many articles but my understanding of Dagger is far from ideal. IMHO, if you are going from Android maybe Dagger will be more easy for you, but if you work with core Java and Spring GIN will be more clear for you.
2. As I remember Dagger doesn't allow to define beans with different scope in the single modules. So if you have such things in the GIN you will need to change it.
3. Implementation of GWT code split loading with Dagger is puzzling (at least). You can check this project https://github.com/ibaca/gwt-dagger2-coffee but I was not able to create the same in my case - the APT generators can't create compilable code.
4. EagerSingleton is not possible (at least several months ago), so you will need to use something to emulate this (I have used the @IntoSet)
5. At the last, the support for APT generator is very different from IDE to IDE, for example in the Eclipse they work very unstable.  

Stas