Testing custom SBT commandline application
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I've been working on a custom SBT CLI application, based on the documentation here. It works, but my problem is that testing it is quite cumbersome.
The issue is that in your sometool.build.properties file, you need to set the version of the app in the [app] section. Mine is set like this:
[app]
org: com.something
name: sometool
version: 0.2-SNAPSHOT
class: com.something.SomeTool
components: xsbti
cross-versioned: binary
I then run sbt publishLocal and sbt @src/main/resources/sometool.build.properties. This fetches the packaged version of the sometool app and runs it. The issue is that when I make code changes, and run another publishLocal, it keeps picking up the old version. I've tried sbt clean, removing the jar from my local ivy cache, and deleting it from the project's target directory, but still it gets the old version.
I can get around this by bumping the version in both build.sbt and sometool.build.properties, but that's quite annoying to do each time you want to test your changes. There has to be a better way to test this, but I don't know what it is.
Any thoughts or recommendations are appreciated.
Edit
Looking at this a couple of days later, figuring out which file it uses is pretty simple. I checked the open file descriptors for the SBT process, and found that it downloads the jar to <project_root>/project/boot/scala-<version>/<app.org>/<app.name>/<app.version>.
Deleting this forces SBT to fetch the dependency again, which will pick up the new version assuming you ran sbt publishLocal prior.
However, neither sbt clean nor sbt cleanFiles cleans this up, meaning that I still have to manually delete this file every time I want to run a new version.
EDIT 2
I added cleanFiles <+= baseDirectory{base => base / "project" / "boot"}, to my build, which means that I can now at least manage everything from within SBT. Downside is that running sbt clean each time cleans up more than is necessary, so I'm still looking for a better way to do this.
scala sbt
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
add a comment |
I've been working on a custom SBT CLI application, based on the documentation here. It works, but my problem is that testing it is quite cumbersome.
The issue is that in your sometool.build.properties file, you need to set the version of the app in the [app] section. Mine is set like this:
[app]
org: com.something
name: sometool
version: 0.2-SNAPSHOT
class: com.something.SomeTool
components: xsbti
cross-versioned: binary
I then run sbt publishLocal and sbt @src/main/resources/sometool.build.properties. This fetches the packaged version of the sometool app and runs it. The issue is that when I make code changes, and run another publishLocal, it keeps picking up the old version. I've tried sbt clean, removing the jar from my local ivy cache, and deleting it from the project's target directory, but still it gets the old version.
I can get around this by bumping the version in both build.sbt and sometool.build.properties, but that's quite annoying to do each time you want to test your changes. There has to be a better way to test this, but I don't know what it is.
Any thoughts or recommendations are appreciated.
Edit
Looking at this a couple of days later, figuring out which file it uses is pretty simple. I checked the open file descriptors for the SBT process, and found that it downloads the jar to <project_root>/project/boot/scala-<version>/<app.org>/<app.name>/<app.version>.
Deleting this forces SBT to fetch the dependency again, which will pick up the new version assuming you ran sbt publishLocal prior.
However, neither sbt clean nor sbt cleanFiles cleans this up, meaning that I still have to manually delete this file every time I want to run a new version.
EDIT 2
I added cleanFiles <+= baseDirectory{base => base / "project" / "boot"}, to my build, which means that I can now at least manage everything from within SBT. Downside is that running sbt clean each time cleans up more than is necessary, so I'm still looking for a better way to do this.
scala sbt
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
add a comment |
I've been working on a custom SBT CLI application, based on the documentation here. It works, but my problem is that testing it is quite cumbersome.
The issue is that in your sometool.build.properties file, you need to set the version of the app in the [app] section. Mine is set like this:
[app]
org: com.something
name: sometool
version: 0.2-SNAPSHOT
class: com.something.SomeTool
components: xsbti
cross-versioned: binary
I then run sbt publishLocal and sbt @src/main/resources/sometool.build.properties. This fetches the packaged version of the sometool app and runs it. The issue is that when I make code changes, and run another publishLocal, it keeps picking up the old version. I've tried sbt clean, removing the jar from my local ivy cache, and deleting it from the project's target directory, but still it gets the old version.
I can get around this by bumping the version in both build.sbt and sometool.build.properties, but that's quite annoying to do each time you want to test your changes. There has to be a better way to test this, but I don't know what it is.
Any thoughts or recommendations are appreciated.
Edit
Looking at this a couple of days later, figuring out which file it uses is pretty simple. I checked the open file descriptors for the SBT process, and found that it downloads the jar to <project_root>/project/boot/scala-<version>/<app.org>/<app.name>/<app.version>.
Deleting this forces SBT to fetch the dependency again, which will pick up the new version assuming you ran sbt publishLocal prior.
However, neither sbt clean nor sbt cleanFiles cleans this up, meaning that I still have to manually delete this file every time I want to run a new version.
EDIT 2
I added cleanFiles <+= baseDirectory{base => base / "project" / "boot"}, to my build, which means that I can now at least manage everything from within SBT. Downside is that running sbt clean each time cleans up more than is necessary, so I'm still looking for a better way to do this.
scala sbt
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
I've been working on a custom SBT CLI application, based on the documentation here. It works, but my problem is that testing it is quite cumbersome.
The issue is that in your sometool.build.properties file, you need to set the version of the app in the [app] section. Mine is set like this:
[app]
org: com.something
name: sometool
version: 0.2-SNAPSHOT
class: com.something.SomeTool
components: xsbti
cross-versioned: binary
I then run sbt publishLocal and sbt @src/main/resources/sometool.build.properties. This fetches the packaged version of the sometool app and runs it. The issue is that when I make code changes, and run another publishLocal, it keeps picking up the old version. I've tried sbt clean, removing the jar from my local ivy cache, and deleting it from the project's target directory, but still it gets the old version.
I can get around this by bumping the version in both build.sbt and sometool.build.properties, but that's quite annoying to do each time you want to test your changes. There has to be a better way to test this, but I don't know what it is.
Any thoughts or recommendations are appreciated.
Edit
Looking at this a couple of days later, figuring out which file it uses is pretty simple. I checked the open file descriptors for the SBT process, and found that it downloads the jar to <project_root>/project/boot/scala-<version>/<app.org>/<app.name>/<app.version>.
Deleting this forces SBT to fetch the dependency again, which will pick up the new version assuming you ran sbt publishLocal prior.
However, neither sbt clean nor sbt cleanFiles cleans this up, meaning that I still have to manually delete this file every time I want to run a new version.
EDIT 2
I added cleanFiles <+= baseDirectory{base => base / "project" / "boot"}, to my build, which means that I can now at least manage everything from within SBT. Downside is that running sbt clean each time cleans up more than is necessary, so I'm still looking for a better way to do this.
scala sbt
scala sbt
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
edited Nov 27 '18 at 10:56
Mopper
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
asked Nov 23 '18 at 17:17
MopperMopper
1,2081432
1,2081432
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450730%2ftesting-custom-sbt-commandline-application%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450730%2ftesting-custom-sbt-commandline-application%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
