naming conflicts

[derrickburns]

The default property names that the plugin creates cannot be placed into a JSON structure. For example, these two values cannot be put into a JSON object commit.id

commit.id:2eed44f166489b2f03169a2e2d7f910430ecf7a9
commit.id.abbrev:2eed44f

Instead, the first value should be named as a field in the "commit.id" object. Foe example:

commit.id.full:2eed44f166489b2f03169a2e2d7f910430ecf7a9
commit.id.abbrev:2eed44f

[ktoso]

Hi there,
I agree this needs some way of addressing, I'll do something about it for 2.1.12 (to be released this week). Even if the solution is guidance on how to solve this (I think we don't have to change the plugin IMHO... but it's late and I may be wrong there).

[ktoso]

I don't think this is worth breaking all existing users.

You can:

• simply write a git.json file in /src/main/resources, where you'd prepare the structure like you want it to, and use maven properties replacemenet in there, like so: { "git" : { "commit" : { "id" : { "full" : "${git.commit.id}" } } }} etc,
• if you're generating the json in code, simply do replace the property 2 lines, one get and one remove solve this.

I will keep this issue open and will want to address this, but not as part of a minor release - this is not a good point to break existing users. When we have a next bigger release I'll provide a fix.

[derrickburns]

Why make a movie release? Use semantic versioning. Make a major release.

Sent from my iPhone

On Dec 13, 2014, at 10:32 AM, Konrad Malawski notifications@github.com wrote:

I don't think this is worth breaking all existing users.

You can:

simply write a git.json file in /src/main/resources, where you'd prepare the structure like you want it to, and use maven properties replacemenet in there, like so: { "git" : { "commit" : { "id" : { "full" : "${git.commit.id}" } } }} etc,
if you're generating the json in code, simply do replace the property 2 lines, one get and one remove solve this.
I will keep this issue open and will want to address this, but not as part of a minor release - this is not a good point to break existing users. When we have a next bigger release I'll provide a fix.

—
Reply to this email directly or view it on GitHub.

[ktoso]

Sure, I'm aware of versioning schemes.
I still do not want this change in the current 2.1.12 release (which is now), and I also explained how this is solved with basically an oneliner.

Once there's a major, I'll address this.

[derrickburns]

The issue is in the properties file, not in the json file.

When properties get converted to JSON you have a problem. Your workarounds
do not address this.

On Sat, Dec 13, 2014 at 10:40 AM, Konrad Malawski notifications@github.com
wrote:

Sure, I'm aware of versioning schemes.
I still do not want this change in the current 2.1.12 release, and I also
explained how this is solved with basically an oneliner.

Once there's a major, I'll address this.

—
Reply to this email directly or view it on GitHub
#122 (comment)
.

[ktoso]

When properties get converted to JSON you have a problem.

By who?
Where do you expose this properties object?
Why cannot you expose your properties object and must expose this one directly?

[derrickburns]

I use code that reads all configuration info into a single settings object. It is a fork of code used in Elasticsearch.

Sent from my iPhone

On Dec 13, 2014, at 11:35 AM, Konrad Malawski notifications@github.com wrote:

When properties get converted to JSON you have a problem.
By whom.

—
Reply to this email directly or view it on GitHub.

[derrickburns]

It reads HOCON, YAML, JSON, and Java properties files.

Sent from my iPhone

On Dec 13, 2014, at 11:35 AM, Konrad Malawski notifications@github.com wrote:

When properties get converted to JSON you have a problem.
By whom.

—
Reply to this email directly or view it on GitHub.

[ktoso]

That helps a bit, but still I don't get why it would be unfixable by the workarounds. A link to the sources if open source or a proper description (more than 1 iphone sentence 😉) would really help here.

As I said, I want to address this, but did not want to address it in today's 2.1.12 release - since it's a minor release and MUST NOT break existing users.

[derrickburns]

I've explained the problem repeatedly and clearly. It sounds like you don't want to make the exceedingly simple change, and I don't want to spend any more time on the issue.

I forked the code a long time ago for my needs. Thanks for creating a useful package.

Derrick

Sent from my iPhone

On Dec 13, 2014, at 5:02 PM, Konrad Malawski notifications@github.com wrote:

That helps a bit, but still I don't get why it would be unfixable by the workarounds. A link to the sources if open source or a proper description (more than 1 iphone sentence ) would really help here.

—
Reply to this email directly or view it on GitHub.

[derrickburns]

The open source config library from typesafe will break without this bug fix.

[TheSnoozer]

finally fixed with #206