IdP version in the code

[Brent Putman]

On 7/18/14, 5:06 PM, Cantor, Scott wrote:
> On 7/18/14, 4:59 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>> I've never quite understood how that stuff worked in v3, using the Java
>> package implementation manifest stuff.
> That was also done in V2, but when it was copied up to V3 it never worked.

Yeah, I actually meant v2.

>
> What it was doing before is calling a Java API that pulls out some
> built-in value the POM build is inserting:

Ok, I guess it's not that mysterious. :-)


>
> That particular maven plugin is only running for a module that no longer
> generates a jar, so it never runs.

I see.  So if it's maybe just a matter of re-jiggering where the Version
class lives so that there is an appropriate jar and manifest, then I don. 

I guess that argument for the current method would be that it's a
natively Java approach using the manifest (which could be populated by
any build process), as where the POM properties is specifically tied to
a Maven build process.  But unless we're going to move away from Maven
anytime soon, then maybe the latter is ok.  Using the POM resources
would also mean I think hardcoding in the Version classes the path to
them, which includes the groupId and artifactId, which I suppose could
change at some point.