Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate files in submodules, not only in root package #466

Open
Tumist76 opened this issue Sep 2, 2022 · 1 comment
Open

Generate files in submodules, not only in root package #466

Tumist76 opened this issue Sep 2, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@Tumist76
Copy link

Tumist76 commented Sep 2, 2022

In our team we have a multi-package application using Objectbox. For a while we had Objectbox and all classes using it in a root package. Now we want to decouple all of that for root package and move to one of our dependencies.

As you know, Objectbox uses generated files to work. In our case we run build_runner in root_package with the following build.yaml file content:

targets:
  $default:
    sources:
      - modules/**
      - lib/**
      - test/**
      # Note that it is important to include these in the default target.
      - pubspec.*
      - $package$

This allows us to run build_runner only once and have files generated in all our modules (sub-packages). objectbox_generator:resolver handles this nicely as *.objectbox.info files are being generated for our files. objectbox_generator:generator doesn't generate outputs though.

As I see in the generator's source code, It handles files only present in lib of current package, though files of submodules are accessible from buildStep.

Is this behaviour intentional or this can be changed in the future to use files from packages too?

@Tumist76 Tumist76 added the enhancement New feature or request label Sep 2, 2022
@greenrobot-team
Copy link
Member

Thanks for your question! This is currently by design. The recommended architecture approach is to have a separate database for each package and wrap that in a repository class to not expose any internal details to other packages.

But if there are no technical reasons that prevent seeing classes of other packages, then it might be possible to add this as an optional behavior in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants