-
Notifications
You must be signed in to change notification settings - Fork 145
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
Support for installing Frege using sdkman #261
Comments
I like the idea as SDKMan is really convenient for managing tools like this. We have integrated sdkman into the gradle release process too. |
So, what activities have to be carried out by whom? |
Is anybody doing something about this, or is planning to do so? |
nobody is working on that at the moment. |
I would like to see this issues re-opened. I am willing to help in order to get this published on sdkman. I'm fairly certain @breskeby would also be willing to help. |
Let's have another attempt. |
Nobody seems to care. It is ok to want something, and ask for plans underway. |
@Ingo60 Yep, it's sad that you don't seem to care that your project isn't available on a free open source distribution channel which I provide you with. The responsibility to do something is not mine, but yours. |
@marc0der it is available as github releases and thus per jitpack to be consumed via maven/gradle and else |
@marc0der Wasn't it you who said
Beg your pardon, but my interpretation was that you would actually do something about it. |
Okay this isn't getting us anywhere so let's start over and be nice :-) Frege first needs to be bundled as an SDK archive (zip/tgz), just like all other JVM SDKs are. Such archives typically have a bin folder containing all executables which we subsequently add to the user's path. This was what I was proposing perhaps @breskeby to get involved with. Once this is in place I can help you get set up with credentials for our Vendor API that will allow you to publish your own SDKs as part of your release pipeline/manual process. Hope this is all clearer now. |
note to self: the bin could contain
|
I'm thinking the following about the packaging of the SDK:
So the structure final structure would be something like:
Most of the modern build tools like gradle and sbt have an application plugin that does this by convention already. Are you using one of these tools for your build? Hope these pointers help a little. |
This looks easy enough. What is SDKMAN doing on install? Just unpacking the TGZ and setting PATH variables? What about man pages - can we provide some, and if so, which format? (I do hope it's not nroff! Did this stuff 30 years ago .... ) |
Correct yes, and we get the archive directly from the original binary repository on each install; we don't hold any binaries of our own. We don't manage man pages currently, although some SDKs are being shipped with a docs folder for containing html docs like javadoc. |
Please shout if I can assist with anything. |
SDKMan becoming easy way to install many Java based app/api/tools etc
If we give option to install compiler,runner,repl etc it will be easy for users to run and compile code
See:
http://sdkman.io/
http://sdkman.io/vendors.html
The text was updated successfully, but these errors were encountered: