[jbosstools-dev] parent pom variable jbosstools-site-stream has been renamed to jbosstools_stream in master branch

[Max Rydahl Andersen]

On 13 Mar 2015, at 12:19, Nick Boldt wrote:

> To restate the problem a 3rd time:
>
> * Jenkins bash scripts (such as the newer, simpler, easier rsync.sh 
> replacement for the crazy complicated publish.sh) can't expand a 
> variable that's named with dashes.

that is not a problem. It is not sharing any logic/parameter passing 
with the parent pom.

> * Parent pom uses variables with dashes.

Yes, it actually by now has *alot* of naming conventions. It is a shame 
we don't just stick with one.

> * Therefore to use the SAME variable in Jenkins and in Maven, we need 
> to rename the variable.

No, you don't need to give it a new *name*, just have it use _ in bash 
and - in parent pom and
things would not be perfect but they would be easily understood/mapped 
and not need any kind of broad change.

> To explain the need for both jbosstools_stream and 
> jbosstools-site-stream:
>
> "I thought we had an agreement that parent Pom "api" changes was to at 
> least be reviewed before applied."
>
> And I agree with that. Therefore, to be able to move forward with the 
> work I needed to do, I created this wrapper.
> The old one still works for Maven builds (but not for shell scripts). 
> The new one works for both. Therefore the old (broken) API is 
> respected and the new (better) API can be the way forward.
>
> So, you were able to review, and I was able to verify my changes 
> worked in Jenkins. It's a win-win, without delays!

I'm sorry but you did *not* need to create a wrapper, you could just us 
easily have used jbosstools_site_stream in the bash scripts.
I'm simply not following where this ever would be a problem.

Also a review implies that things don't go into master and result in 
mails asking for everyone to do a non-reviewed change - that is exactly
what will cause a delay if there is some easy to fix before going live 
fix.

> "Why not just use the underscore form in the bash script?"
>
> That's what I did. Renamed the variable in parent pom so I could reuse 
> the same var across all jobs; had I not done that, we'd be passing 
> jbosstools-site-stream to maven, and jbosstools_stream to bash, via 
> two job parameters. Surely THAT would have been an ugly solution you 
> would have reviewed and rejected?

I simply do not follow why you need *two* job parameters for that. The 
jenkins job just need to have *one* (call it "jbosstools-site-stream" 
and when the mvn script is called you do mvn 
-Djbosstools-site-stream=${jbosstools-site-stream} and when using bash 
you do syncstuff.sh jbosstools_site_stream=${jbosstools-site-stream}

That is completely clean.
No renames, just a - replaced with _ and no broad changes needed in 
parent pom nor in all affected projects and avoided subtle different 
between or branches/builds.

Also you only wrote this as jbosstools-site-stream changes, but it also 
(for consistency) would affect all the repository references for each 
component build.

So yeah, most definitely I would have accepted the simplest and less 
intrusive fix where it is *only* the bash script that has a different 
change.

Can we get it back to the minimal change in master instead of this big 
broad one, please ?

/max
http://about.me/maxandersen