|
If you were logged in you would be able to see more operations.
|
|
|
Possible problems
- using properties in the parent tag
- using proeprties in the repositories tag with the parent being unknown except to that repo
Attach is a sample project whose child project does not get built.
|
|
Description
|
Possible problems
- using properties in the parent tag
- using proeprties in the repositories tag with the parent being unknown except to that repo
Attach is a sample project whose child project does not get built. |
Show » |
|
Bug
Closed
Major
parent resolution is done first before property interpolation
not have been examined at the time of <parent>-block evaluation...
Either way, I'm also VERY interested in having properties expanded while evaluating the <parent>-block contents. Even if only properties defined in settings.xml or supplied by -D to the mvn-command will affect the evaluation.
I'm currently working in a project with many active developers. The project is therefore brached into several development tracks - each track being developed 'independently' of the other over a limited period of time. Regularily, the branches are merged back together in order to keep the project aligned over time. This stragegy is necessary in order keep the environment within each branch stable enough for CI to work and developers productive writing code and not struggling with problems that other branches might introduce...
Anyway, keeping the pom-hierarchy (and individual poms) configurable with respect to (in my case) groupIds configurable using parameters would make the recurring merging activities a lot easier...
The current workaround is to let each branch have its own repository and have all developers remember to delete their local repository when they change development track...
Either way, I'm also VERY interested in having properties expanded while evaluating the <parent>-block contents. Even if only properties defined in settings.xml or supplied by -D to the mvn-command will affect the evaluation.
I'm currently working in a project with many active developers. The project is therefore brached into several development tracks - each track being developed 'independently' of the other over a limited period of time. Regularily, the branches are merged back together in order to keep the project aligned over time. This stragegy is necessary in order keep the environment within each branch stable enough for CI to work and developers productive writing code and not struggling with problems that other branches might introduce...
Anyway, keeping the pom-hierarchy (and individual poms) configurable with respect to (in my case) groupIds configurable using parameters would make the recurring merging activities a lot easier...
The current workaround is to let each branch have its own repository and have all developers remember to delete their local repository when they change development track...