-
Notifications
You must be signed in to change notification settings - Fork 310
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
Move to org.bdgenomics.utils 0.2.0 release #664
Conversation
Test FAILed. Build result: FAILUREGitHub pull request #664 of commit ed7a98f automatically merged.Notifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'[EnvInject] - Loading node environment variables.Building remotely on amp-jenkins-worker-05 (centos) in workspace /home/jenkins/workspace/ADAM-prb > git rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/bigdatagenomics/adam.git # timeout=10Fetching upstream changes from https://github.com/bigdatagenomics/adam.git > git --version # timeout=10 > git fetch --tags --progress https://github.com/bigdatagenomics/adam.git +refs/pull/:refs/remotes/origin/pr/ > git rev-parse origin/pr/664/merge^{commit} # timeout=10 > git branch -a --contains 3066f146a1794ec8541556a1f976abd800469192 # timeout=10 > git rev-parse remotes/origin/pr/664/merge^{commit} # timeout=10Checking out Revision 3066f146a1794ec8541556a1f976abd800469192 (origin/pr/664/merge) > git config core.sparsecheckout # timeout=10 > git checkout -f 3066f146a1794ec8541556a1f976abd800469192First time build. Skipping changelog.Triggering ADAM-prb ? 1.0.4,centosTriggering ADAM-prb ? 2.2.0,centosTriggering ADAM-prb ? 2.3.0,centosADAM-prb ? 1.0.4,centos completed with result FAILUREADAM-prb ? 2.2.0,centos completed with result FAILUREADAM-prb ? 2.3.0,centos completed with result FAILURENotifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'Test FAILed. |
Test PASSed. |
Test PASSed. |
<description>A fast, scalable genome analysis system</description> | ||
<url>http://bdgenomics.org/</url> | ||
|
||
<properties> | ||
<java.version>1.7</java.version> | ||
<scala.version>2.10.4</scala.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why take these out, OOC? just feel like it's cleaner to not interpolate these variables below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's part of the dual-build process. Specifically, we "flatten" the POM by hardcoding defaults to Scala 2.10 (scala.version = 2.10.4, scala.artifact.suffix = 2.10). Then, when we want to build for Scala 2.11, we run the scripts/move_to_scala_2.11.sh
script which just uses sed
to swap 2.10.4 with 2.11.4 and 2.10 with 2.11. Not beautiful, but gets the job done.
If Maven allowed you to put variables in the artifact names, you wouldn't need to do this. However, as I found via experimentation, there's "good" reasons that Maven doesn't allow you to have variables in artifact names. If you required all published POM's to be "flattened", then variables in an unpublished POM would be OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok, I think I get it, and that the piece I was missing was "Maven doesn't allow variables in the <artifactId>
field", which necessitates this change. Thanks for the info!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, Maven doesn't strictly disallow variables in the <artifactId>
field (it just gives you a warning that "this might break things"), but then I did bigdatagenomics/utils@47e325a, and tried to cut a release of that.
Let's just say it broke in spectacular and vengeful ways. After I made that commit, I spent a long time wondering asking reflecting on the mistakes in my life that led me to write 47e325a
. The commit seemed so innocent at the time, but alas, my youthful ignorance (of mvn) led me astray.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very interesting. I am out of my Maven depth, but now somewhat curious about the failure modes if it's at all interesting; no need to go into further detail if not. Seems innocuous enough, as you said.
And, confirming one piece of subtext: this is all happening because you are trying to release different artifacts for 2.10
vs. 2.11
for the first time, right?
it's never used… fixes bigdatagenomics#662 Moves to utils:0.2.1.
Test PASSed. |
+1, lgtm, I'm good to merge @fnothaft |
er, after rebasing, of course |
bump! this would be nice to have in |
@fnothaft let me know if you want me to rebase this for you... |
@laserson I actually just sent fnothaft/adam#6 to do so, albeit with a merge of |
Well, feel free to just apply the changes, git commit --amend, and either ...................................... On Tue, May 26, 2015 at 3:11 PM, Ryan Williams [email protected]
|
Sorry, I was OOO at UCSF for meetings today. I will rebase this now. |
no worries, @fnothaft, thanks |
Merged through @ryan-williams's PR (#678). Thanks guys! |
Thanks @laserson and @ryan-williams! |
Resolves #536, #581, #603, #657. In anticipation of the 0.17.0 release, this moves to the org.bdgenomics.utils 0.2.0 release. This leads to:
org.bdgenomics.utils.parquet.io
package to theorg.bdgenomics.utils.io
package