Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable profile if release (of if dirty) #62

Closed
3 tasks done
vromero opened this issue Oct 26, 2017 · 6 comments
Closed
3 tasks done

Enable profile if release (of if dirty) #62

vromero opened this issue Oct 26, 2017 · 6 comments

Comments

@vromero
Copy link

vromero commented Oct 26, 2017

  • searched for similar already existing issue
  • read the documentation and wiki

Issue

version: 1.0.0

usage context:

  • maven command line: 3.5.0

Problem description:

I keep finding myself needing to do special things when on a release that doesn't happen on a dirty build or the other way around. The good-old release plugin that this extension deprecates had the releaseProfiles that could be activated only on releases. I believe jgitver should support either of the following:

  • support a releaseProfiles=commaSeparatedProfiles and/or dirtyProfiles=commaSeparatedProfiles
  • set the jgitver.dirty a systemProperty, so profiles could be activated by jgitver.dirty or !jgitver.dirty (I assume this should work already but for some reason it doesn't).
@McFoggy
Copy link
Contributor

McFoggy commented Oct 30, 2017

The profile activation does not work because the ProfileActivationContext object (holding properties and used during the property evaluation) is built before the jgitver extension is called, so none of the properties maps (user & system) contain jgitver properties.

jgitver is fired too late in the build process to be picked up by the any of the ProfileActivator.

Regarding your demand of a releaseProfiles=commaSeparatedProfiles property. This is not possible to me, jgitver has no knowledge of a release.
On the opposite, I think dirtyProfiles=commaSeparatedProfiles could be a more valid demand. Would you think it would still be needed if the jgitver calculated properties were made available to the profile activation?

@vromero
Copy link
Author

vromero commented Oct 30, 2017

Thanks for taking the time to reploy this

The profile activation does not work because the ProfileActivationContext object (holding properties and used during the property evaluation) is built before the jgitver extension is called, so none of the properties maps (user & system) contain jgitver properties.

jgitver is fired too late in the build process to be picked up by the any of the ProfileActivator.

I see

Regarding your demand of a releaseProfiles=commaSeparatedProfiles property. This is not possible to me, jgitver has no knowledge of a release.
On the opposite, I think dirtyProfiles=commaSeparatedProfiles could be a more valid demand.

I understand that with jgitver there is no release per-se. What I actually meant is a concept opposed to dirtyProfiles. Something like nonDirtyProfiles. Just to give an example, lets say that someone needs to send a docker image to a repo x on dirty builds and to repy y on non dirty builds. That someone could have dirtyProfiles=dockerSnapshot and nonDirtyProfiles=dockerRelease.

It can be argued thow that given that when -P is passed, only the passed profiles are active, nonDirtyProfiles would not be necessary (or the other way around).

Would you think it would still be needed if the jgitver calculated properties were made available to the profile activation?

IMHO this would be the ideal solution, brings the freedom to the user to do whatever they want in the best place possible because here maven even support the negation with !.

McFoggy added a commit that referenced this issue Oct 31, 2017
McFoggy added a commit that referenced this issue Oct 31, 2017
@McFoggy
Copy link
Contributor

McFoggy commented Oct 31, 2017

@vromero please look at following it tests issue-62.1 & issue-62.2.

I think latest version will answer your needs. If not let's continue discussions.

@vromero
Copy link
Author

vromero commented Oct 31, 2017

That is great! thank you!
I'll give it a try and feedback ASAP.

@vromero
Copy link
Author

vromero commented Nov 4, 2017

Works like a charm, thanks!

@McFoggy
Copy link
Contributor

McFoggy commented Nov 4, 2017

Glad to hear that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants