Not currently possible with annotation processing. Not sure if there are techniques or ways around this, but my understanding of annotation processing is that they run in isolation from each other. Meaning, the annotation processor in one module has no knowledge of other annotations from another project.

Could you simply add a prefix for GeneratedDatabaseHolder in order to avoid duplicates or would this cause other issues?

@eboissonneault I was thinking something along the same line. I'm probably going to try and give it a go this week.

@agrosner the problem is not that I need the annotation processing to know of the existence of all the modules in order for them to interact, the problem is that when the code gets compiled into the dex files it throws an error because it finds two classes that share the same fully qualified name (DataBaseGenerator in the same package). This is not really a problem until I want to develop a library and the project that includes it is also trying to use DBFlow. Of course I could be mistaken, I'm just now starting to use both gradle and this library. If you could give me instructions on how to build it (in order to include it as a maven repo and test changes) I would really appreciate it.

i have the same problem，use DBFlow in more than one module

alright. Ill add the ability to do so in 3.0.0, which lets you change the generated class file name. But youll have to do something like this: FlowManager.init(context, "_MyModule"); which will append it to the end of the file name and in your Database:

@Database(...holderClassSuffix="_MyModule")

Great! Thank you very much.

Hi @agrosner! Finally did you manage to get this into 3.0.0? I was having a look at the code and it doesn't look like. I have tried to implement it in a fork. I have been able to generate the classes using the suffix but I am stuck in something probably quite stupid. When I executed FlowManager.init(context, "_MyModule"); the second time (I have to execute it twice: the first one for the module, the second one for the main app), mDatabaseHolder is not null. Therefore getDatabaseHolder() returns the first holder and never instantiate the second GeneratedDatabaseHolder (I am talking about this method). Can you shed some light on this? What am I missing?

hey @adrianq not quite yet, I will need to add it at some point. But if you get it working, make the PR against the 3.0 branch, that would be great. So what's missing is the ability for you to define the GeneratedPlaceHolder class that DBFlow looks for. The generated class is always in same package and may get overwritten (as you mention here). What's missing is the ability to define where this placeholder class lives, so we could essentially operate with two different ones for each module. What we would need is to add a simple FlowManager.init(context, "_MyModule"); method to that class and have it look for a class with that postfix in the FlowManager instead of always checking for :"

 protected static DatabaseHolder getDatabaseHolder() {
        if (mDatabaseHolder == null) {
            try {
                mDatabaseHolder = (DatabaseHolder) Class.forName(
                        "com.raizlabs.android.dbflow.config.GeneratedDatabaseHolder").newInstance();
            } catch (Throwable e) {
                throw new RuntimeException(e);
            }
        }

        return mDatabaseHolder;
    }

It would append or change that class that was created. The only downside is that you'd need to specify which holder to put the @Database into.

@agrosner and we kind of merge GeneratedDatabaseHolder and GeneratedDatabaseHolder_suffix into the same mDatabaseHolder? or are we using two different mDatabaseHolder? I am not sure if I understood you right. I already generate the two GeneratedDatabaseHolder but the two apps (module and main app) are sharing the same FlowManager. So mDatabaseHolder != null by the time the second FlowManager.init(context, "_MyModule"); is called.

@agrosner I've made it work merging the two GeneratedDatabaseHolder into a single mDatabaseHolder. It is looking good so far although I will have to test it a little bit more. If you are happy with this approach, I can clean up the code and create a PR.