-
Notifications
You must be signed in to change notification settings - Fork 108
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
Add support for nested modules #578
Comments
What about the use case when having a top level package just for grouping modules? Let's say:
In reality, group contains more packages in a very complex application. domain1+2 are core domains and top level modules. foo and bar are kind of auxiliary domains that are used by both domain1 and 2. Would it be possible to put a If this feature doesn't, would you consider this as a valid use case? If yes, I would create an issue for that. |
If it's solely grouping, it's not nesting. You could tackle your scenario by providing a custom implementation of
For convenience, we expose |
@odrotbohm Yes, I think so! Thanks a lot. If that works, would it make sense to contribute this? EDIT: Would this go under |
As such an implementation would be entirely specific to your scenario, it would have to live in your implementation by definition, wouldn't it? Or do you mean us providing an implementation of that out of the box? |
@odrotbohm I mean contributing another |
I am not sure how you'd generally do that without explicit markers. How would you know you'd have to consider I wouldn't mind seeing some means to make the “explicitly annotated packages only” mode a bit easier to use. A dedicated class for that might make sense. I guess we could swap out the current enums against dedicated classes then. I wonder if we could also inspect |
It actually just works out of the box: public class GroupingApplicationModuleDetectionStrategy implements ApplicationModuleDetectionStrategy {
@Override
public Stream<JavaPackage> getModuleBasePackages( JavaPackage basePackage ) {
return ApplicationModuleDetectionStrategy.explictlyAnnotated().getModuleBasePackages( basePackage );
}
} No custom logic necessary. So would be great to switch this strategy. Why not adding an optional strategy to the Modulithic annotation? |
|
@odrotbohm Don't you think that, putting aside that it currently has technical limitations, it would have been a lot better from a DX point of view to add it to the I see two and a half ways this could still be done.
@Modulithic(
moduleDetectionStrategy = Modulithic.ModuleDetectionStrategy.EXPLICITLY_ANNOTATED,
)
@Modulithic(
moduleDetectionStrategy = "com.acme.MyCustomApplicationModuleDetectionStrategy",
)
@Modulithic(
moduleDetectionStrategy = Modulithic.ModuleDetectionStrategy.CUSTOM,
customModuleDetectionStrategy = "com.acme.MyCustomApplicationModuleDetectionStrategy",
) They all have some downsides, but at least there are a lot more accessible. |
The reason I am hesitant about the annotation is twofold:
I have a spike available that introduces an application property |
The current module system is flat. In other words, only one level of modules is supported. In some cases, it would be nice to be able to structure a module into submodules, that would stay hidden from the outside, but allow hiding internals from the parent module. They would also only be visible to their parents and direct sibling modules.
Related discussions / issues
The text was updated successfully, but these errors were encountered: