Point at a local installation for dev purpose about sdkman-cli HOT 31 CLOSED

Do you want this tied to a particular version or a generic dev label? The path you give in the example could change its version depending on what branch you're on.

I have to say, I normally work with a dev installation that changes its version based on what branch I'm on (and I may explicitly change the version myself).

from sdkman-cli.

That's a good question.
Perhaps the mechanism I'm after is the ability to define any custom local label I'd want?
Rather than just one single mandatory label.
Anyhow, even with just that one label that'd already fulfill my need.

from sdkman-cli.

I'm thinking along the lines of allowing multiple labels. You would then be able to point any of these labels to any directory on your machine. In other words, you wouldn't need to go digging for it in your .gvm folder.

This would then allow support for a single dev version, or multiple versions like 2.1.0-SNAPSHOT, 2.2.0-SNAPSHOT etc.

from sdkman-cli.

The local development candidate feature is now available for testing on our test environment.

export GVM_SERVICE="http://test.gvmtool.net"
gvm selfupdate

Don't forget to source the gvm-init.sh after the selfupdate, otherwise it simply won't work ;-)

You can now perform all the commands except listing of candidates. If you attempt to list, the local version simply won't show up in the list (yet). I'll be looking at implementing this shortly.

For now, please read the cucumber feature for local development versions which should make the usage very clear.

/cc @graemerocher

from sdkman-cli.

Thanks Marco... will give a go!

from sdkman-cli.

On my Mac, when sourcing gvm-init.sh I got:

glaforge-mbp:groovy-git glaforge$ source "/Users/glaforge/.gvm/bin/gvm-init.sh"
uname: illegal option -- o
usage: uname [-amnprsv]

from sdkman-cli.

But apart from that uname problem... the local installation worked fine for me, and I could use my local version!

from sdkman-cli.

Thanks for picking that up. The error that you are seeing is due to something else I was working on. Looks like the Mac version of uname is a little different from other platforms.

from sdkman-cli.

Yeah I also noticed the uname problem, also if you do "gvm list grails" it doesn't display local builds, not serious but for consistency maybe it should? Otherwise works great!

from sdkman-cli.

@graemerocher You might want to read his comment with the bold statement 'You can now perform all the commands except listing of candidates' 😉

from sdkman-cli.

But since when do we have to read comments, manuals, tutorials, documentation and what not? :-D

from sdkman-cli.

@graemerocher yes, I'll be releasing the listing within the next day or so.

from sdkman-cli.

@pledbrook Wow, I think because it was in bold I just skimmed over that 8D

from sdkman-cli.

Switching from a local installation to a standard one doesn't seem to work. Will investigate.

from sdkman-cli.

OK, so gvm-use.sh is still assuming a numeric version number when it updates PATH. A quick fix to the regex should work fine. We should probably forbid '/' in labels though, otherwise that's going to really screw gvm up.

from sdkman-cli.

I'm struggling to get a Cucumber test that reproduces the problem :( This is passing, even with the broken code:

Scenario: Switch from a local version to a standard one
    Given the candidate "groovy" version "2.0.5" is already installed and default
    And the candidate "groovy" version "2.1-SNAPSHOT" is already linked to "/tmp/groovy-core"
    When I enter "gvm use groovy 2.1-SNAPSHOT"
    Then I see "Using groovy version 2.1-SNAPSHOT in this shell"
    When I enter "gvm use groovy 2.0.5"
    Then I see "Using groovy version 2.0.5 in this shell"
    When I enter "gvm current groovy"
    Then I see "Using groovy version 2.0.5"

@marcoVermeulen Any ideas?

from sdkman-cli.

@pledbrook Strange, but I can't replicate what you are seeing. I've run through your scenario manually and it works perfectly on my side.

Can you tell me what the exact steps are that you take?
Do you have the latest code from http://test.gvmtool.net?

from sdkman-cli.

Is that because you use a label that starts with a number? Ah ha! That's why the test succeeds. I should be trying with a label of 'dev'. Doh!

from sdkman-cli.

Ah, okay. I can replicate it as well now. Well spotted! Are you going to be looking into this one or should I fix it?

from sdkman-cli.

I have a simple fix and cucumber test, but now I'm getting a whole bunch of cuke test failures unrelated to my change. The failures almost look as if aeroplane mode is misfunctioning in the tests.

from sdkman-cli.

Do you perhaps have a local server running on port 8080?

from sdkman-cli.

Yes. Perhaps the tests could fail with a big error message about 8080 already being in use? 😄 Anyway, changing the feature to use dev hasn't impacted the Cucumber test, so it's still not reproducing the problem. I don't really want to commit a fix until there is test coverage for it.

from sdkman-cli.

Is this because the local_developement_versions feature is not running in isolated mode? Are the tests not all running once in isolated mode and then once not in isolated mode?

from sdkman-cli.

No, they're not run in both modes. They should be run with isolated mode enabled. In fact, I'm thinking of stripping out the isolated mode configuration. Isolated mode is proven to work well and is default behaviour by now. I'm all for just keeping it simple.

from sdkman-cli.

OK. Well I've pushed fix + two scenarios (one with isolated mode active, one without). I'm OK with only having the one mode of operation now, but before going 1.0 we should sort out the variables as you've mentioned before. Although they aren't visible via the env command, you can still do things like echo $CURRENT. I'll raise an issue.

from sdkman-cli.

Agree. About isolated_mode, I can look at it this weekend after finishing this feature.

from sdkman-cli.

@graemerocher I've pushed the changes for listing local dev versions. Cukes can be found here.

I've deployed it to the test environment as before so give it a go.

from sdkman-cli.

@marcoVermeulen Nice! will give it a go

from sdkman-cli.

Okay guys, not hearing anything back from you so presume it's working...

Closing this issue.

from sdkman-cli.

It's indeed working fine.
Sorry for not replying earlier.

On Tue, Jan 22, 2013 at 10:12 PM, Marco Vermeulen
[email protected]:

Okay guys, not hearing anything back from you so presume it's working...

Closing this issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-12566745.

Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/
Social: @glaforge http://twitter.com/glaforge /
Google+https://plus.google.com/u/0/114130972232398734985/posts

from sdkman-cli.

No probs :-)

from sdkman-cli.