make releases more easily available for users of maven/gradle/sbt/leinigen etc.

[Dierk]

Since the sonatype and equivalent approaches are too much work, I tried to get https://jitpack.io/docs/ working, i.e. with every github release, one can immediately fetch the release from the jitpack.io maven repo.

To this end, we need a gradle build that jitpack can call like gradlew installor alternatively provide a project.pom in the root dir. Both is a bit more work than expected a) because the make dist depends on frege-interpreter and frege-repl, which in turn depend on frege b) we don't have the frege-xxx.jar as a static artifact in the project itself such that we can easily refer to it from the project.pom.

[Ingo60]

1. I'm not sure if it is possible to clone the frege-interpreter and frege-repl projects in subdirectories of the frege project instead in sibling directories. Or if that would help. It might, as they do have build.gradle files in them?

2. we have

   make fetch-fregec.jar

BTW, @matil019 has agreed to try something similar (in the chat).

[Dierk]

We have to break the dependency cycle. This is most easily done by having a separate project where we do the packaging of the last release without interfering with the frege build process itself. @talios used this approach for the sonatype upload in the https://github.com/talios/frege-bundle project. In fact, his approach works well - with the possible downsides that

• it depends on Mark's availability and his maven credentials to do the publishing step
• the artifact is published under his name rather than the "frege organization". It comes with the benefit that users don't have to specify the extra "jitpack" maven repo url.

Projects like FregeFX, FregeTutorial, or any other project that just happen to use Frege directly or transitively should need nothing else but setting the dependency. The story is a bit different for frege-interpreter and frege-repl since they are part of the frege build process and in that process depend on the to-be-created frege version (not the last released one).

[matil019]

I'm considering another approach for packaging Frege. The Frege release can be split into frege-core that doesn't depend on frege-interpreter, frege-repl, etc.

Their dependencies should look like:

frege-standalone (the "batteries included" release)
|- frege-core
|- frege-interpreter
|  `- frege-core (elided)
|- frege-repl
|  `- frege-core (elided)
|- frege.Starter
`- other dependencies...

The current Frege release corresponds to frege-standalone in the above diagram.

frege-core will have no dependencies declared, and frege-interpreter and frege-repl will have frege-core as its dependency. Duplicate dependencies should be elided upon packaging frege-standalone. As long as the interpreter and the repl depends on the core not on the standalone, the circular dependency can be avoided. This should be already possible because make fregec.jar builds dependency-free Frege if the interpreter and the repl are missing.

I propose this because the current Frege release contains an old version of jline. Build tools like maven can be configured to exclude transitive dependencies when needs arise, but it's not possible if an artifact is packaged as one jar file.

[Ingo60]

@matil019 , FYI, frege-repl has frege-interpreter as its dependency.

One could further divide frege-core into frege-lib and frege-tools but I have no strong opinion on that.

What is absolutely crucial is that the REPL packed into frege-standalone is itself compiled with the compiler it uses. This is because it uses functions form the compiler and when we do changes, it may be that laziness changes for an argument (or result) of a function, which, in turn, will change the Java signature of the corresponding method. Hence, when the repl gets compiled with an older compiler version, we may get MethodNoFoundException. (This is a general weakness of the approach to Laziness we need to address sooner or later).

[matil019]

@Ingo60 All right, then the whole order of compilation would be like this:

1. frege-core (compiled with a stock fregec.jar) a. frege-lib b. frege-tools
2. frege-interpreter (compiled using 1.)
3. frege-repl (compiled using 1.)
4. frege-standalone specific classes (if any, compiled using 1.)

As a side note, Scala splits its jar into the library, the compiler, and the reflection classes. Since most Frege programs won't use Frege compiler as a part of them, splitting it may be helpful.

[Ingo60]

@Dierk, even if the users would need one more line in their POM or whatever, what's the deal? I've seen that build files have been published in various projects, hence they get copy-pasted anyway.

The independence from someone who has certain special credentials, even if it is such a nice guy as @talios, weights a thousand times more, in my view.

[Dierk]

true.

OTOH, I just released JavaFX 0.8 to jcenter (which in turn get synced to maven central) and that was done in three clicks. Anyway, it is good to have multiple options.

I'll step back for the moment from this issue and let @matil019 move forward.

[matil019]

@Ingo60 Speaking of which, there is a Frege artifact on Maven Central (https://mvnrepository.com/artifact/org.frege-lang/frege/3.24.100.1). Its HomePage implies it's maintained by @talios, too. Since it's on Maven Central, there is no need to configure custom repositories for maven users. It comes first by googling "maven frege", and has groupId org.frege-lang, so I'm pretty sure most users consider it as the official release.

If you have no credentials/controls over it then I think it's a problem. It should be where new releases get published to.

[Ingo60]

@matil019

Indeed, I don't have the control here. Is it possible to withdraw this artifact from Maven?

[matil019]

@Ingo60 I don't know, I'm afraid.

[Dierk]

Well, even if possible, one should never withdraw anything from a central repo (the problem is meanwhile known as the "leftpad" issue 🤓). It should be possible to transfer the credentials. If not, start with a new name for the module: "frege-core" (?)

[Ingo60]

Well, I remember, that was one reason I'm not that happy with a public central repository, where the users see the contents as official, bullet-proof and proven artifacts. IMHO, the Frege releases are still too ephemeral for being in an "eternal" repository.

[talios]

On 14 Apr 2018, at 22:16, Dierk König wrote:

the artifact is published under his name rather than the "frege organization".

I thought we changed to deploy under the frege organisation ages ago? One can deploy to oss.sonatype.org with just a curl command tho.... so that could also easily be done by anyone.

Mark

---

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

[talios]

On 15 Apr 2018, at 4:33, Ingo Wechsung wrote:

Indeed, I don't have the control here. Is it possible to withdraw this artifact from Maven?

It's not - but I don't control it either. ANYONE can as long as they get permissions given to their oss.sonatype.org account - which one can do easily with a JIRA request to sonatype.

Mark

---

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

[Ingo60]

Thank you for clarification, @talios

[Dierk]

Hi Mark,

Thanks for looking at this. I might be wrong but last I checked, the Frege POM still had theoryinpractise in the url.

Cheers Dierk

Am 16.04.2018 um 06:23 schrieb Ingo Wechsung notifications@github.com:

Thank you for clarification, @talios

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[talios]

On my local machine at least:

    <groupId>org.frege-lang</groupId>
    <artifactId>frege</artifactId>
    <version>3.24.100.2-SNAPSHOT</version>

for scm:git:git@github.com:Frege/frege-bundle.git

[matil019]

@Dierk Have you compiled frege-interpreter with gradle with OpenJDK9? It seems javaCompile doesn't work with it...

[matil019]

@Ingo60 @Dierk It's almost done. Since frege.Starter is the only class in Frege that depends on frege-repl, I'm considering that it can be merged into the REPL. How do you think?

[Dierk]

no objection from my side. Sorry, I lost track of this issue due to other distractions :-) IIRC I compiled with the oracle distribution of Java 9, not OpenJDK.

[Ingo60]

@matil019 Yes that'd be okay as the repl has the compiler as a dependency anyway.

[gilinykh]

Eventually what is the recommended way to get the latest Frege version for a Maven user? Public repos only contain v. 3.24.100 which even can not be resolved when used. If there are any issues with using a 3rd party maven repo then may be it's worth considering using Github packages to publish maven artifacts? https://docs.github.com/en/packages/using-github-packages-with-your-projects-ecosystem/configuring-apache-maven-for-use-with-github-packages https://docs.github.com/en/actions/language-and-framework-guides/publishing-java-packages-with-maven

[Dierk]

looks good to me. Would you like to care for the issue?

[Dierk]

it appears that jitpack (https://github.com/jitpack/jitpack.io) can be set as a maven/gradle repository url such that the github release can be used as a normal dependency.

[Dierk]

and for reference, here is my setup for using Frege in a gradle build. https://github.com/Dierk/HelloFrege/blob/43499eedb54a037e37da1a2dd7533da3b73ae83b/build.gradle where fregeInit downloads the respective frege release, stores it locally, and uses the local jar as a dependency.