All Child Projects In Multi Module Use Wrong Control File Path

[fredcooke]

I have a project that I'm actively working on for my own use that has a parent reactor pom with a standard organisation-parent of its own, and N children, each of which uses a deb-meta parent with a standard jdeb configuration, and has only a pom and control file in a standard directory path.

At first I had the parent reactor pom also using my jdeb meta parent and having a control file of its own that had a flat depends-on-all-children structure, but then I noticed that jdeb was ignoring it due to type packaging, fair enough. So I removed the control file and changed the reactor pom's parent to be plain.

That's when things got weird.

Turns out that the first project in the reactor is using the control file path from the parent reactor even when the parent has no jdeb build plugin section whatsoever. So, of course, my first child failed with control dir not found, file not found, bad content as I mkdired and touched and so forth.

If I go into any of the children and "mvn package" it works fine. If I put the control file back in the parent dir under my standard path, it works fine, but produces a first child .deb with the content of the parent control file and not its own! :-(

Actually, I just checked now, all of the children have used the same control file and have the same dependencies! This is not at all what I want, as I'm sure you can understand.

Beyond the contents of this report, how can I help get this resolved ASAP? I'm super excited to get this project finished and out the door so I can start using it to make other great open source software.

Help! / Help me to help you help me! :-D

[fredcooke]

I'm kinda surprised that no one struck this before, as I want my packages to depend on each other with >= [[version]] so as to be able to install development debs and also guarantee upgrades that reach down through the tree by just installing the necessary roots.

[fredcooke]

I was reading the DebMojo class last night on my phone in bed before my eye lids fell down and the only thing that struck me was that packaging type, which is proven to function correctly per project) was a normal parameter and that the problematic types were not just parameters, but also stuck into a variable resolver object. On my phone I couldn't check usage of this to find out if it was somehow static, but the thought crossed my mind. If no one else has had a look, I might do so tonight, and try some other experiments, too.

[fredcooke]

On a bus:

    final File controlDirFile = new File(Utils.replaceVariables(resolver, controlDir, openReplaceToken, closeReplaceToken));

the resolver does this:

    @SuppressWarnings("unchecked")
    final Map<String, String> projectProperties = Map.class.cast(getProject().getProperties());

Which I assume is the overall project under which it's executing, not the module subproject where we want it to be building. I can't see anything else in the code that could possibly cause this. However without knowing what "getProject()" really means, it could mean "get the current module that we're in", however the behaviour with maven 3.3.9 does not match this, and does match my earlier assumption.

[fredcooke]

OK, I totally misunderstood what the resolver did, but now see where the issue lies...

The variable in the code is [[baseDir]]/whatever/path and now that I setup my parent to contain this substitution as well, it works as expected, however I'd argue that the behaviour is wrong. The relative path should be relative to the current project directory, not the VM's working directory (ie, the parent project). So the lines that do "File X = new File(string)" are wrong in my eyes in a nested module of a MM project as they use the top level by default.

They should really be smarter and find out if the String is relative or absolute, and if relative, give it the correct base path from the correct current project directory.

Worth noting that anyone using the default value would get correct behaviour OOTB. Overriding it without the [[baseDir]]/ leading part is the thing that caused the issue in combination with that little bit of code around line 490 to 500.

In any case, I have a work around, so I'll proceed with that. Hope this helps, sorry for the erroneous comments in between.

[tcurdt]

Thanks for digging through this! Care to send through a patch?

[fredcooke]

Sometimes I think I'd make a better tester than a developer ;-) I don't have a patch, but I'd love to contribute actual code to jdeb, so if I get a chance, I'll have a crack. I don't think it's a huge deal, but it definitely confused me for a bit.