I quickly made a simple project to test and simplified my setup. I get the error below as soon as I create the DataComponent, and have AppComponent use it as a dependency. If i only use AppComponent and ActivityComponent ( the latter depends on the former ), i have no issues.

So I'm either doing something wrong entirely and Snapshot 12 didn't mind ( most probable ), or there's a new issue in Snapshot 13.

Error:(36, 14) error:.di.ActivityComponent depends on scoped components in a non-hierarchical scope ordering:
@singleton di.DataComponent
@singleton di.AppComponent
@qast.di.PerActivity di.ActivityComponent

Similar issue, If you want more than 2 Components deep dagger is unusable.

This is by design.

@JakeWharton I appreciate that, looking through #96, its to make components stricter. It just makes things like this impossible:

@dagger.Component(dependencies = {ActivityComponent.class, AppComponent.class}, modules = ScreenModule.class)
@PerScreenScope
interface ScreenComponent {}
//--
@dagger.Component(dependencies = AppComponent.class, modules = ActivityModule.class)
@PerActivityScope
interface ActivityComponent {}
//--
@dagger.Component(modules = AppModule.class)
@Singleton
interface AppComponent {}

This was done to stop chances of depending on different lifecycled scopes (e.g. @PerActivity scope getting cleaned up before @PerScreen.) Which I understand.
But then I wish hierarchy component injection worked. (injecting something in the @PerScreen throws "May not reference binding with difference scopes")

Unless I am missing something? Docs are pretty light right now, but I guess thats due to the API changes.

@JakeWharton, care to explain or point me to some resources on how to either set up multiple components? ( Imagine I'd like to have modules and components per seperate layer (data/business/...))

I've read @chrisjenx's explanation and understand the choice, but it seems to me that both components in the @singleton scope (or any same scope) should be able to depend on one-another?

@Trikke I agree with what happened with Cyclic dependencies that will stop potential cases where you get multiple singletons. If you want to seperate your Data/Business logic, I use different Modules.

@JakeWharton if thats the case surely this should be acceptable:

Component1 c1 = Dagger_Component1.create();
Component2 c2 = Dagger_Component2.builder().component1(c1).build();
Component3 c3 = Dagger_Component3.builder().component2(c2).build();

c3.inject(ClassWithDependencencyInComponent1 classWithDep);

As you can build multiple c3's off one c2's which in turn will have a route to the c1 singletons?

@chrisjenx Yep. I wasn't disagreeing with your use case. Not at a place where I can test it right now.

@JakeWharton Ahh OK, My use case throws up in my face at the moment then. Hopefully a bug or me doing it wrong...

Error:(48, 5) error: ui.mortar.ActivateAddCard.Component scoped with @qualifiers.PerScreen may not reference bindings with different scopes:
@Singleton class io.database.DatabaseManager
//---

(That component depends on an Activity component, which depends on the App component)

@chrisjenx , I already had different modules for separation of data/logic, and had components laid out in the same way. I'm still new to this stuff, so I'll have to read up on how to structure components properly. Although i think i had practically the same use case as you described above as something that should be possible.

I ended up using different scopes for each of my subcomponents while my main component is annotated with @Singleton. Is this how you should do it or is there a way to not having to create scopes for each component?

@Singleton
@Component(modules = DatabaseModule.class)
public interface MainComponent {
    DatabaseProvider databaseProvider();
}

@OrderScope
@Component(dependencies = MainComponent.class, modules = OrderModule.class) 
public interface OrderListComponent {
    void inject(OrderListActivity activity);
}

@ScanningScope
@Component(dependencies = MainComponent.class, modules = ScanningModule.class)
public interface ScanningComponent {
    void inject(ScanActivity activity);
}

A few things -

Firstly, greg is working out a more flexible sub-component approach for this. It'll be cleaner, I think.

If you're going to do subcomponents in three levels, and you want to shuttle your singletons to the bottom layer, in the current code, just have your middle-tier component extend the application-level component. THis will expose those bindings to the lower-tier component without requring that you have your lower-tier depend on two scoped components.

@dagger.Component(dependencies = ActivityComponent.class, modules = ScreenModule.class)
@PerScreenScope
interface ScreenComponent {}
//--
@dagger.Component(dependencies = AppComponent.class, modules = ActivityModule.class)
@PerActivityScope
interface ActivityComponent extends AppComponent {} // <---- note here, the pass-through contract.
//--
@dagger.Component(modules = AppModule.class)
@Singleton
interface AppComponent {}

if you do this, then all the contract of AppComponent is visible to ScreenComponent via ActivityComponent. then you don't have to do the multiple dependencies (which are disallowed)

That said, I think the forthcoming @SubComponent approach will make this a little cleaner, and with fewer methods, etc. But for now, the above should be a reasonable way to go.

Also, during migration, you can disable the "singleton can't depend on singleton" bit with an annotation processor flag -Adagger.disableInterComponentScopeValidation=warning (or none). It is intended as a migration aid from dagger 1 so please don't rely on it, as it may not be there forever. It doesn't disable all validations, but should at least permit you to do the singleton->singleton stuff while you migrate to separate meaningful scoping annotations.

@cgruber Thanks for that, thats pretty much what I have done, I have Dependent interfaces for each activity scope which expose the singleton and app scopes up the tree.

@SubComponent sounds better, as there feels like way too much boilerplate right now.

I'll stay posted.

Any update on this? Is it sane to want the access controls of component dependencies and the transitive-ness of @subcomponents?

i.e., some flag to toggle for Subcomponents to honor the provision methods of the parent component interface (and thus restrict access to non-exposed provisions in parent modules)?

is there a final solution to handle this requirement?i mean the 3-level Component dependencies.

@cxzhang2 you can use the default java accessibility system to block provisions to be "passed" to a child subcomponent. I.e. if package com.example.foo has the @Component and uses a package-private annotation @Private, then a subcomponent in com.example.bar won't be able to access provisions from the parent since Java won't allow it to reference com.example.foo.Private. That's what we've been recommending.

@ronshapiro I see, thank you!