Hi, I’m trying to wrap my head around a complex Coldfusion project I want to automate.
The project is made of a huge number of sub-modules, which have to be checked out from CVS and “restructured” in the final structure for deployment.
.
├── build
│ └── target
│ └── customer_1
│ ├── customer_1_web
│ │ ├── client
│ │ └── core
│ └── customer_1_cflib
│ ├── module_1_1
│ ├── module_1_2
│ ├── module_1_3
│ ├── module_2_1
│ └── module_2_2
└── src
├── customer_1
│ ├── group_1
│ │ ├── module_1_1
│ │ ├── module_1_2
│ │ └── module_1_3
│ └── group_2
│ ├── module_2_1
│ └── module_2_2
└── customer_2
├── group_1
│ ├── module_1_1
│ ├── module_1_2
│ └── module_1_3
└── group_3
└── module_3_1
Here an example of the structure I’m trying to manage. Consider that “customers” can potentially be 200, and each “customer” can have a different version of the about 50 modules available.
What I need is to have the “customers” in the src folder to be “managed” and be assembled as in the tree visible in the build/target folder.
But, it does not seems ideal to me, for example because keeping everything in the same bucket would result in a very huge project.
So, I’m thinking about how I can change my gradle project structure and split things up.
What I’m thinking about is to invert the concept, so I don’t have a single project with all my customers, but a different project for each one, and transfer all the “knowledge” about my modules in a configurable plugin,
so that I can create a build and say:
“For this customer you need this modules, with this versions.”
Also, I’d make every module a gradle subproject, so that each one will know how to assemble itself.
In the end I’ll have a gazilion projects, but probably everything should be more sane and manageable.
Does it make sense, or you have some better idea?