[Feature Request] Can't handle classes with more than one constructor about jam HOT 9 CLOSED

@coreywoodfield I don't think that this is a good idea to store jam specific metadata in the class itself... I'm suggesting to consider following solutions:

val a: A = jam.brew(new A(_: String))

or

def fromString(c: String): A = new A(c)
val a: A = jam.brew(fromString _)

Feel free to reopen the issue if you will have some related ideas.

from jam.

I think we've found a use case for this feature. The Play Framework automatically generates routing code, and for its compile-time dependency injection, you can construct the router using components that you manually pass to the generated constructor.

We're trying to migrate some things over to Jam, but the issue that we're running into is that the Play Framework generates two constructors, and annotates one with that standard javax.inject.Inject annotation, basically like this:

class Routes(
  override val errorHandler: play.api.http.HttpErrorHandler,
  Application_0: controllers.Application,
  bar_Routes_0: bar.Routes,
  Assets_1: controllers.Assets,
  val prefix: String
) extends GeneratedRouter {

  @javax.inject.Inject()
  def this(
    errorHandler: play.api.http.HttpErrorHandler,
    Application_0: controllers.Application,
    bar_Routes_0: bar.Routes,
    Assets_1: controllers.Assets
  ) = this(Application_0, bar_Routes_0, Assets_1, "/")
  ...
}

Unfortunately, this means we get the More than one primary constructor was found for (router.Routes) error when we try to construct the routes with Jam. We also can't control the generation of the routing code, and I think the alternative is to have to pass in every individual controller, which can be difficult within larger projects like ours. This issue is sort of blocking our migration from Macwire to Jam, so we were hoping to have Jam be able to handle annotations, even if it's just for annotating a "primary" constructor with javax.inject.Inject like Macwire does; does that seem compatible with your long-term views for the project, @yakivy?

from jam.

@denvercoder10 extra java dependency doesn't fit in my long-term view, but I also cannot leave you without a solution... What about extra jsr330 module with brew method that will read javax.inject.Inject annotation? It will look like:

jam.jsr330.brew[Routes]

from jam.

That solution seems great to me, @yakivy!

from jam.

@coreywoodfield yes, sure, but I'm talking not only about ivy dependencies, code behaviour depends on javax.inject annotation and needs to be maintained as a part of core lib. But maybe I'm being too stubborn, I need some time to rethink this idea...

from jam.

We saw that, and we really appreciate your effort! Thanks so much, this has been really helpful for a hackathon this week :)

from jam.

I've got a proof of concept PR up to support the javax.inject.Inject annotation. If anyone has feedback on it or how it would fit into the project, feel free to let me know!

from jam.

I will point out that the opened PR only added the new dependency to tests. No dependencies were added to the core jam code

from jam.

So I let perfectionism go 😄
I merged PR but with minor refactoring (I don't trust toString methods). 0.0.12 is already published.

from jam.