Open rajmahendra opened 8 years ago
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? If not I would close the issue.
nobody is working on that at the moment. We can reopen later if need be.
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. Would be better yet if people actually did something to get their preferred build/install tool supported.
@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
I am willing to help in order to get this published on sdkman.
Beg your pardon, but my interpretation was that you would actually do something about it. If only to outline what must be done.
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:
These should be lightweight shell scripts that do the smarts of inferring JAVA_HOME
etc, much like the gradle
, groovy
, kotlin
and scala
scripts provided in the bin
folders of their respective SDKs.
These should probably in turn reach out to a lib
folder that contains the frege jar.
The bin
and lib
folders would typically live in a folder that is usually the name and version of the sdk, something like frege3.24-7.100
.
So the structure final structure would be something like:
frege3.24-7.100.zip
+- frege-3.24-7.100/
+-bin/
|-frege
|-fregec
|-fregedoc
+-fregerepl
+-lib/
+-frege3.24-7.100.jar
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