Feature/acp10 mapp merge

[JcJakeway]

What: This combines the ACP10 feature branch with the main Mapp Motion branch.

Why: A feature branch was acting as a main branch for the ACP10 motion library. Both motion library can now be managed through the main branch.

[DavidWLoupe]

Have we given proper discussion to the question of whether these two (ACP10 and Mapp) AxisLib's should be merged, rather than split into two separate repos?

It seems to me like merging them creates a one-off of complexity that requires another iteration of LPM development (folder structure, Jenkinsfile convention, etc) to accommodate. What are the downsides to splitting them up into Acp10AxisLib and MappAxisLib repos?

[Joshpolansky]

@DavidWLoupe Fair question. I think there are benefits to keeping them in one repo, but possible don't outweigh the cost for this specific use case.

However, I don't see why this wouldn't be supported, and I think it is something that LPM should support. I would have expected this to work out of the box today, what is complicated here? One note, is that I would expect a single jenkins file, so maybe i'm missing something here. Why can't we have a the two jenkins files as a single file?

[DavidWLoupe]

@Joshpolansky I suppose complexity is added by moving from 1 -> N in multiple areas In an LPM-compatible repo...

• Instead of a single Jenkings file or buildPublishPipline, there are now 2+ that need to be accommodated
• Instead of one Automation studio example project, there are 2+
• Instead of one src/Ar folder, there are multiple arbitrarily named folders in src (also this doc would need to be updated to match)
• Instead of handling one conceptual domain, the README must address 2+

I see value in keeping things simple if we can help it. But maybe we want LPM to be able to handle this situation because this isn't a one-off situation.

I'm not actually "dug-in" on my position, just trying to write down reasons for my gut feel.

[Joshpolansky]

@DavidWLoupe I would argue with the exception of possibly the first point, I thought we already decided we wanted to support those things. One point that might simplify this is that we have talked about, by default, not using the buildPublishPipeline function, and instead having a more verbose standard jenkins file that would more easily support all these things.

[Joshpolansky]

I would also note, that this isn't actually an LPM development, it's a jenkins build server development. I'm not sure what here would affect LPM.