OXP distribution

[montana05]

Hiran is correct, but we are not talking about multi-national software houses. What we have here is an open-source game and a distribution from a private person, a bit different I would think. I strongly doubt that multi-million dollar trials would haunt us for the next years.

[hiran]

So what about if we tweak the wiki site to allow uploading oxp's as well, and put the original untweaked GN & Sothis there? Then we could allow downloading from the wiki pages without sending people off to extraneous sites which might sunder at any time? That way people are downloading the untweaked, unmodified original packages, as devised by the departed.

Or is this also dodgy?

Your suggestion is to centralize all OXPs in one location, to enhance comfort and availability. The same availability that I was told it's better to distribute homepage, forum and wiki over three domains?
From my POV it is something that should be done. Availability-wise there are technical concepts to decouple from single IPs, single hosts and whatnot, and organisational concepts to decouple from individuals.

But how does this change the legal problem?

[Cholmondely]

So what about if we tweak the wiki site to allow uploading oxp's as well, and put the original untweaked GN & Sothis there? Then we could allow downloading from the wiki pages without sending people off to extraneous sites which might sunder at any time? That way people are downloading the untweaked, unmodified original packages, as devised by the departed.

Or is this also dodgy?

Your suggestion is to centralize all OXPs in one location, to enhance comfort and availability. The same availability that I was told it's better to distribute homepage, forum and wiki over three domains?
From my POV it is something that should be done. Availability-wise there are technical concepts to decouple from single IPs, single hosts and whatnot, and organisational concepts to decouple from individuals.

But how does this change the legal problem?

Ah... the legal problem was why I was asking. No, I'd be happier with all the oxp's (not the oxz's) collected somewhere too. I presume that of the 3 Oolite websites, that only the wiki is suitable...

... but I suppose we could see about trying out capnhack.com/hosting who still keeps Oosat1 going!

[hiran]

Ah... the legal problem was why I was asking. No, I'd be happier with all the oxp's (not the oxz's) collected somewhere too. I presume that of the 3 Oolite websites, that only the wiki is suitable...

... but I suppose we could see about trying out capnhack.com/hosting who still keeps Oosat1 going!

Ok, so we can agree the legal problem does neither get created nor resolved, so it should not be considered for now.
On top two OXP authors already told me that reducing the two step process with lots of whats and ifs that can go wrong into a one step process that ensures quality by automation will make publishing just so much easier.

I could create a demo OXP repository to show off what I mean. But I have nowhere to host this application, so I kindly ask whether it could join one of the existing systems, preferrably oolite.org. And I would put the code in Github - under my own project for now and later willing to move it to Oolite. License to be discussed - I'd be fine with GPL, Apache Commons or Creative Commons. Even the Borland No Nonsene License Agreement is ok

[hiran]

I created a proof-of-concept OXP Repository (POC).
Although not yet fully usable it shall show how OXP distribution could happen.

The (revolutionary) change is as follows:
Until today, a developer creates an OXP. At some point he decides to publish it. So he create the OXZ, which requires a manifest.plist file inside to be filled with some information.
1) This OXZ is then uploaded to some publicly available internet location.
2) On top of this, the OXZ file needs to be announced for the expansion manager. For this to happen, the developer needs to fill a form with exactly the same information - probably done via cut&paste from the already created manifest.plist.

This whole process allows for shortcuts and errors, which can already be seen today in the various OXPs. Most of them are uncritical, but there may be situations where a user chooses something from the Expansion Manager's offering and gets something else.

This POC shall demonstrate that
- steps 1 and 2 can be combined, making it easier for the developer as he does not have to find suitable web space and does not have to enter the same information multiple times
- the quality of OXPs can be ramped up as the developer gets an immediate validation and feedback

You can find the compiled POC here: https://app.box.com/s/ta6d8vtjoqd4tmah9oe8gb4t7z9m2nlg
In that you find a readme pdf and an executable jar application.
The source code is meanwhile at https://github.com/HiranChaudhuri/OoliteOxpRepository

Comments are welcome.

[hiran]

Hmmm, no comments at all. Noone had a look at this?

Meanwhile I stumbled over the source of the main website - and hey, it is dynamic!
It could be possible to directly add the functions I tried to demo in there!

Is there someone somewhat familar with https://github.com/OoliteProject/oolite-web ?

[UK_Eliter]

This sounds like a good idea - and thank you for your work.

I am having trouble getting the tool to run on Windows. The tool complained about my Java version, so I obtained and installed jdk-16.0.1_windows-x64_bin. But still I see this:

Code: Select all

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/vaadin/tutorial/crm/Application has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

I'll try on Linux if I get a moment.

[hiran]

This sounds like a good idea - and thank you for your work.

I am having trouble getting the tool to run on Windows. The tool complained about my Java version, so I obtained and installed jdk-16.0.1_windows-x64_bin. But still I see this:

Code: Select all

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/vaadin/tutorial/crm/Application has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

I'll try on Linux if I get a moment.

Hmmm, I compiled and ran it in

Code: Select all

$ java -version
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment (build 16.0.1+9-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 16.0.1+9-Ubuntu-120.04, mixed mode, sharing)
$

But it seems you are the first to try at all. Let's figure out what is missing.
So I can run the code on JDK 16.0.1
In the pom I can see java.version=11

Would you mind to try on JDK 11?

[hiran]

Even more interestingly, I found this resource:
https://docs.oracle.com/javase/specs/jv ... .1-200-B.2

a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

From this I understand I compiled with Java 11 (which would resemble the information from the pom), but you were running a Java 8 installation?

[UK_Eliter]

As I said, 'I obtained and installed jdk-16.0.1_windows-x64_bin'. If that's wrong, please point me towards a place that I can get the version that I need!

[Commander_X]

<shakes head in disbelief>

[...] I understand I compiled with Java 11 (which would resemble the information from the pom) [...]

Fair disclosure: I didn't follow this thread very closely.

But the above doesn't sound very ... "sound" to me.
It's like the Oolite source code will start doing the "dependency lap dance" after you've "git " "--done everything". When you run your make command, stuff will start to be pulled of all over the internet (again and again).

I'm a Slackware Linux user. Whenever a gradle or maven Java project comes my way, my first concern is to "ant"-ize it, such that any (compile-time and/or runtime) dependency is clearly outlined. Honestly, it's not very hard, and it usually makes the difference between 500M - 1G compile-time dependencies, to only max 10M of them (usually less; and I can download them all manually). And the runtime deal might even come close to nothing.

I understand that developing in Java is a very convenient way to have things done, but artificially (or worse, unknowingly) raising some requirements, really, shouldn't happen.

[Cody]

<scratches head> Anyone got a Babel fish handy?

[hiran]

As I said, 'I obtained and installed jdk-16.0.1_windows-x64_bin'. If that's wrong, please point me towards a place that I can get the version that I need!

Ok, let me put it that way:

I trust in you that you downloaded and installed JDK 16 properly.
But from the error message I see that you likely ran a JDK 8.

They can be installed in parallel, and I am not surprised that you may have a JDK 8 installation on your system already.
Please post the exact command you ran, or how otherwise you launched the jar I provided.

[hiran]

<shakes head in disbelief>

[...] I understand I compiled with Java 11 (which would resemble the information from the pom) [...]

Fair disclosure: I didn't follow this thread very closely.

But the above doesn't sound very ... "sound" to me.
It's like the Oolite source code will start doing the "dependency lap dance" after you've "git " "--done everything". When you run your make command, stuff will start to be pulled of all over the internet (again and again).

I'm a Slackware Linux user. Whenever a gradle or maven Java project comes my way, my first concern is to "ant"-ize it, such that any (compile-time and/or runtime) dependency is clearly outlined. Honestly, it's not very hard, and it usually makes the difference between 500M - 1G compile-time dependencies, to only max 10M of them (usually less; and I can download them all manually). And the runtime deal might even come close to nothing.

I understand that developing in Java is a very convenient way to have things done, but artificially (or worse, unknowingly) raising some requirements, really, shouldn't happen.

Yep, it is an unusual situation for me as well. I like that ecosystem as long it allows me to focus on the purpose of the code.
The code for this project is on github, feel free to ant-ize it.

[Commander_X]

<scratches head> Anyone got a Babel fish handy?

Dunno about Babel, but I have friends that can provide fish

[...]
Yep, it is an unusual situation for me as well. I like that ecosystem as long it allows me to focus on the purpose of the code.
The code for this project is on github, feel free to ant-ize it.

Will try to step back from a "down-er" tone, I've downloaded the github repo, and your box binary. Looking through the source code I started to realize you've relied on vaadin and spring frameworks (and I'm not very familiar with any of them). I postponed the "ant-izing" task.

I tried the runtime route UK_Eliter took. After sorting-out the same JDK 8 (my default JVM) issue (i.e. "class file version"), and switching to a JDK 11 I happen to have around (

Code: Select all

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

), there were two exceptions that came out.
First:

Code: Select all

 ERROR 7328 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Exception sending context initialized event to listener instance of class [com.vaadin.flow.spring.VaadinServletContextInitializer$DevModeServletContextListener]

java.lang.IllegalStateException: Running project in development mode with no access to folder '/home/hiran/NetBeansProjects/oxp-repository'.
Build project in production mode instead, see https://vaadin.com/docs/v14/flow/production/tutorial-production-mode-basic.html

This seemed simple enough to fix, I created the folder, and after another try, the second one came up:

Code: Select all

ERROR 7472 --- [           main] dev-updater                              : Command `/home/<MY_LOCAL_USERNAME>/.vaadin/node/node --no-update-notifier --no-audit --scripts-prepend-node-path=true install` failed:

2021-07-08 21:37:01.065 ERROR 7472 --- [           main] dev-updater                              : >>> Dependency ERROR. Check that all required dependencies are deployed in npm repositories.
2021-07-08 21:37:01.073 ERROR 7472 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Exception sending context initialized event to listener instance of class [com.vaadin.flow.spring.VaadinServletContextInitializer$DevModeServletContextListener]

java.lang.RuntimeException: Unable to initialize Vaadin DevModeHandler

This is where I stopped, as I'm trying as hard as possible to stay away of anything having to do with node/npm.