search

mulesoft-labs / mule-gradle-plugin

Plugin for building mule apps with the gradle build system.
Apache License 2.0
24 stars 14 forks source link

Support non-bundled domain projects #75

Open carstenlenz opened 8 years ago

carstenlenz commented 8 years ago

Currently the domain plugin makes non-changeable assumptions that are problematic for us:

We want to have support projects in our multi-project setup with shared code. We are deploying all of our mule apps separately and individually.

I work around this by making the domain project it's own subproject and just configure all subprojects individually (although by applying common configuration to all mule apps to reduce duplication)

Maybe this assumptions can be loosened somehow to make the setup more flexible .

juancavallotti commented 8 years ago

@carstenlenz thanks for the feedback! I will consider it for further improvements.

The domainZip task is a rather simple task and can be customised or as well emulated. In this case I would suggest introducing a new zip task that simply copies the files from src/main/domain to the root of the zip archive as well as the files located in src/main/resources

carstenlenz commented 8 years ago

Thanks for the suggestions. With that I think the bigger problem is the fixed assumption that all subprojects are mule apps by default. I want to share some common code (custom transformers etc.) via a project dependency.

But thanks anyway for considering it. I think currently for us the best approach is to put the domain into a subproject on itself. The only thing we are loosing are some utility tasks like fixDomain, checkDomain and install and having a slightly more complex build.

juancavallotti commented 8 years ago

@carstenlenz I believe that having modules in a domain that are not mule projects would make it somehow less cohesive. In this case I would try and make a regular multi-module with the shared libraries and the domain, and mule apps inside of the domain. Now you would have two nesting levels, however you would have a more cohesive project structure i.e:

globalProject: 
  | - > shared
  | - > domain
           | - > domain App 1
           | - > domain App 2  
           | - > domain App 3

So then domain has a library dependency to shared and your apps remain lightweight while at the same time being able to take advantage of the features.

carstenlenz commented 8 years ago

Hey. Nice. That's a good idea. Thank you.