Update easyrdf library to 1.0.0

I'd go for rewriting the trait and dropping the dependency, since it's barely maintained.

We could also probably get away with dropping the dependency during beta (though maybe not RC) in order to avoid it being in our lockfile until D10.

The pull request has been merged: https://github.com/easyrdf/easyrdf/pull/311
Also, they are trying to establish a broader maintenance model and are heading for a 1.0 release: https://github.com/easyrdf/easyrdf/issues/320

+++ b/composer.json
@@ -32,7 +32,7 @@
-        "easyrdf/easyrdf": "^0.9"
+        "easyrdf/easyrdf": "dev-master"

Re #5. Instead of dev-master, I would suggest using 1395e5d6ed9ee8efbb4c76ef7227ec69b271616b as 1.0.0, doing so we get a fixed commit locked.

Added the alias, also added the codesniffer suggestions.

As far as I can tell, the main difference between 0.9.8 and 0.10.0-alpha.1 (and upcoming 1.0.0) compatibility wise is namespaces and changed class names. That should be rather easy to update.

So, for Drupal 9 we would be free to either update the dependency in --dev or remove it?

For Drupal 8 we'd need contrib to explicitly require an updated version and update their code?
We have two modules that already require a newer version that should be (mostly) compatible with the upcoming 1.0.0 release.
We have 5 that rely on core shipping the library, after a quick look, updating them should be really, really easy.
For RDFUI I've already done this, now waiting for git access, see https://github.com/sanduhrs/drupal-rdfui and https://www.drupal.org/project/rdfui/issues/3155327
And we have one that explicitly requires the 0.9.x version, updating this should also be relatively easy.

I'd suggest to inform the maintainers of the needed changes.
They should declare the dependency and update the code to work with the upcoming 1.0.0.
Where they do not respond, I'd be willing to provide initial patches - so existing users still have the possibility to update their setups.

Fine with that.
Attached is an updated patch for D9 updating the --dev dependency
and a patch for D8 allowing for an updated library through contrib.

1.0.0-rc.1 was out, FYI. https://github.com/easyrdf/easyrdf/releases/tag/1.0.0-rc.1

easyrdf has an 1.0.0 release, now.
Patch attached.

^1.0 it is!

Actually a few more class aliases might work ;)
Or should we go for conditional class usage in the trait's methods?

Reattached the patch for D9 from #22.

- It requires easyrdf/easyrdf: ^1.0 as a dev dependency
- It removes the workaround from #3110972: Update easyrdf library to 1.0.0
- It updates \EasyRdf usage to use namespaces

Tests passed already in #22.
What's left to be done?

Here is a draft change record https://www.drupal.org/node/3159977

Tested the latest patch on local instance of drupal 9.1.x
Checked if easyrdf is updated to 1.0.0 version
Looks good
This can be moved to RTBC if code review is fine

@samiullah, thanks for the review.

But in general, you do not have to attach any screenshots, unless it's asked. For example: tagged Needs manual testing.

Attaching screenshot of patch applying, which might be taken as a behavior of credit gaming by committer.

CR added. removing the Needs change record tag.

- It requires easyrdf/easyrdf: ^1.0 as a dev dependency
- It removes the workaround from #3110972: Update easyrdf library to 1.0.0
- It updates \EasyRdf usage to use namespaces

@sanduhrs's "self-review" is good. besides, the link to the workaround issue points THIS, it should be #3090017: Isolate test dependency on easyrdf/easyrdf to a single trait

Thanks!

Needs a re-roll.

composer require easyrdf/easyrdf:"^1.0" --dev --no-update

composer update easyrdf/easyrdf       
> Drupal\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Updating easyrdf/easyrdf (0.9.1 => 1.0.0): Loading from cache
    Cleaning: easyrdf/easyrdf
Writing lock file
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
Hardening vendor directory with .htaccess and web.config files.
44 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Cleaning vendor directory.
> Drupal\Composer\Composer::generateMetapackages
Updated metapackage file composer/Metapackage/CoreRecommended/composer.json.
Updated metapackage file composer/Metapackage/DevDependencies/composer.json.
Updated metapackage file composer/Metapackage/PinnedDevDependencies/composer.json.
If you make a patch, ensure that the files above are included.
composer update easyrdf/easyrdf  17.02s user 1.43s system 38% cpu 48.299 total

Ho can I prevent composer from updating the metapackages?
Did not have this issue before :/

Attached is a patch that includes the metapackage updates.

Patch #41 no longer applies. Re-rolling.

Unrelated test failure.

1) Drupal\Tests\quickedit\FunctionalJavascript\QuickEditIntegrationTest::testCustomBlock
Field block_content/1/body/en/full did not match its expectation selector (.cke_editable_inline), actual HTML: The name "llama" was adopted by European settlers from native Peruvians.
Failed asserting that 'The name "llama" was adopted by European settlers from native Peruvians.' is true.

Triggering test again

FYI, following warnings got while running composer install against Drupal core 9.0.7

Generating optimized autoload files
Deprecation Notice: Class EasyRdf_Parser_JsonLd located in ./vendor/easyrdf/easyrdf/lib/EasyRdf/Parser/JsonLdImplementation.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Stack trace:
 phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:116
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:355
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:341
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:264
 phar:///usr/local/bin/composer/src/Composer/Installer.php:307
 phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:122
 phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 phar:///usr/local/bin/composer/src/Composer/Console/Application.php:281
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 phar:///usr/local/bin/composer/src/Composer/Console/Application.php:113
 phar:///usr/local/bin/composer/bin/composer:61
 /usr/local/bin/composer:24
Deprecation Notice: Class EasyRdf_Serialiser_JsonLd located in ./vendor/easyrdf/easyrdf/lib/EasyRdf/Serialiser/JsonLd_real.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Stack trace:
 phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:116
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:355
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:341
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:264
 phar:///usr/local/bin/composer/src/Composer/Installer.php:307
 phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:122
 phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 phar:///usr/local/bin/composer/src/Composer/Console/Application.php:281
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 phar:///usr/local/bin/composer/src/Composer/Console/Application.php:113
 phar:///usr/local/bin/composer/bin/composer:61
 /usr/local/bin/composer:24

Attaching a raw interdiff for #45.

Updated composer.lock with composer update --lock -vvv and Composer version 2.0.0-RC1 2020-09-10 15:39:45

All changes in interdiff-45-49.txt are support key added to each packages. See https://getcomposer.org/doc/04-schema.md#support. So if #49 passes, I would set it to RTBC.

+++ b/composer.lock
@@ -7181,5 +7605,5 @@
-    "plugin-api-version": "1.1.0"
+    "plugin-api-version": "2.0.0"

this change looks unrelated

Thanks, @andypost!

Started from #45 again with Composer version 1.10.13 2020-09-09 11:46:34

And got composer.lock updated with composer update --lock -vvv, reverted

-    "plugin-api-version": "1.1.0"
+    "plugin-api-version": "2.0.0"

This release has been tagged with Composer 2.0.0-RC1. Please report any issues in the Drupal core issue queue.

Meanwhile, as https://www.drupal.org/project/drupal/releases/9.0.7 tagged with Composer 2.0.0-RC1 already, maybe it's time and it's ok switching to "plugin-api-version": "2.0.0".

I think it's ready

@jungle I think the related issue is #3103918: [policy + docs] Decide on backwards compatibility policy for Composer plugins in Drupal 8

@alexpott asked me to look at the issues raised in #10.

Only one of these modules is both stable and Drupal 9 compatible: https://www.drupal.org/project/wisski, and this patch will break it by the looks of things. I think we should file an issue asking them to loosen to ^0.9|^1.0 or similar before this goes in. (And the other modules too, but they already have other work to do to become Drupal 9 compatible and/or stable).

For Drupal 8... I think we just can't commit this to Drupal 8 and it won't fully support Composer 2 (but de facto, it mostly does), agree with #3110972-12: Update easyrdf library to 1.0.0:

So the question is do we need to touch Drupal 8? I'm not sure we do. At least atm update using composer 2 works on Drupal 8 and there are no warnings or anything during a regular install. You only get a warning when doing composer dump-autoload --optimize so it's not that bad imo.

I do think we should continue trying to remove the dependency altogether, either by refactoring, or #2152459: [Policy] Deprecate RDF module and move it to contrib.

Addresing #57

Then it needs todo and d10 issue

Addressed #59, added a D10 issue #3176468: Remove support for EasyRDF 0.9 and @todo

Thanks!

Looks ready, thanks!

Missed to change status

+++ b/composer.json
@@ -33,7 +33,7 @@
+        "easyrdf/easyrdf": "^0.9 || ^1.0"

A double pipe (||) will be treated as a logical OR

Sorry, forgot to mention. I have not found docs for the usage of single pipe (|) in composer versions and constraints. Not sure if a single pipe (|) is treated as OR per the official docs here for Version Range, @alexpott suggested to use the single pipe (|) in #59, in the patch #61, I used double pipe (||).

• FYI, following warnings got while running composer install against Drupal core 9.0.7

  For the warnings mentioned in #48, I would suggest backporting this to 9.0.x. In addition, the release note of 9.0.7 says "This release has been tagged with Composer 2.0.0-RC1. Please report any issues in the Drupal core issue queue.", this is another reason to me to backport this. Please set to NW if you agree.

• And BTW, the CR associated has not been published.

Self-reply to #68

We can not ever remove this or it'd break existing versions, we can only tell you || is preferred now :)

-- @Seldaek commented on 7 Apr, @see https://github.com/composer/composer/issues/6755#issuecomment-610363856

That means double pipe (||) is preferred.

Thanks @voleger guided me here to find it.

@alexpott, Can we, at least, in 8.9.x, move easyrdf/easyrdf from require (./core/composer.json) to require-dev (./composer.json)? As is now it prevents me updating to 1.0.0 and this is a pain as we plan to stay on 8.9.x more months for now

I've opened a follow-up for 8.9.x #3176975: Allow updating easyrdf/easyrdf on 8.9.x.