This is useful to implement automatic triggers of re-stock, e.g. by creating a supplier order or the like.

As the constraints to select events for verification are usually focused on the event's payload it would be nice if there was API to easily map to the content and register a Predicate on that to filter the owning event.

class SomeEvent {
  Payload payload;
}

// Before
events.ofType(SomeEvent.class).matching(it -> it.getPayload().equals(reference));

// After
events.ofType(SomeEvent.class).matchingMapped(SomeEvent::getPayload, reference::equals);

When accessed concurrently from multiple threads, Lazy.getNullable() could return null unexpectedly.

• [x] You have read the Spring Data contribution guidelines.
• [x] There is a ticket in the bug tracker for the project in our JIRA.
• [x] You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• [ ] You submit test cases (unit or integration tests) that back your changes.
• [x] You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

No test case provided in code as due to the nature of concurrency issues it is problematic to quickly test the issue. There's a test setup provided in the jira ticket.

Lovely, looking forward!

As the constraints to select events for verification are usually focused on the event's payload it would be nice if there was API to easily map to the content and register a Predicate on that to filter the owning event.

class SomeEvent {
  Payload payload;
}

// Before
events.ofType(SomeEvent.class).matching(it -> it.getPayload().equals(reference));

// After
events.ofType(SomeEvent.class).matchingMapped(SomeEvent::getPayload, reference::equals);

We replaced the component scan in RespositoryRestMvcConfiguration with dedicated bean methods. This allows us to be more explicit in resolving required components, which is required for better support of GraalVM native image.

Relates to: spring-projects-experimental/spring-graalvm-native#192

Great one, @Rawi01. Thanks! 🙇

Avoids the impression that the concept is an actor on the system. Also hints at the interface being the primary abstraction to initially look at.

Duplicates #328.

Spring Data provides means to register events for publication. It would be nice to be able to easily create a PublishedEvents instance from an aggregate instance for use in unit tests.

Spring Data provides means to register events for publication. It would be nice to be able to easily create a PublishedEvents instance from an aggregate instance for use in unit tests.

We now build and deploy artifacts on every commit and deploy the documentation every night.

The Lernraum revealed some weird behavior. Observably, Quantity instances loaded from the database always have decimal places. Turns out that QuantityAttributeConverter isn't applied actually. Assumingly die to Quantity being an @Embeddable.

If I actually apply the converter (by removing @Embeddable) queries start to fail, as they reference components of Quantity (like the amount) and the converter causing Hibernate to treat the value like an opaque string.

https://bugs.openjdk.java.net/browse/JDK-8240169

https://bugs.openjdk.java.net/browse/JDK-8240169

You can hover above the autocompleted names of salespointpackages but clicking leads to 404 :(

Describe the bug

Executing a Maven build with JDK 15 and the Maven Delombok plugin in version 1.18.12.0 leads to the following:

[ERROR] Failed to execute goal org.projectlombok:lombok-maven-plugin:1.18.12.0:delombok (default) on project salespoint-framework: Unable to delombok: InvocationTargetException: 'void com.sun.tools.javac.main.Arguments.init(java.lang.String, java.lang.String[])' -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.projectlombok:lombok-maven-plugin:1.18.12.0:delombok (default) on project salespoint-framework: Unable to delombok
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to delombok
    at lombok.maven.AbstractDelombokMojo.execute (AbstractDelombokMojo.java:196)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: java.lang.reflect.InvocationTargetException
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    at lombok.launch.Delombok.delombok (Delombok.java:50)
    at lombok.maven.AbstractDelombokMojo.execute (AbstractDelombokMojo.java:175)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: java.lang.NoSuchMethodError: 'void com.sun.tools.javac.main.Arguments.init(java.lang.String, java.lang.String[])'
    at lombok.delombok.Delombok.delombok (Delombok.java:705)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    at lombok.launch.Delombok.delombok (Delombok.java:50)
    at lombok.maven.AbstractDelombokMojo.execute (AbstractDelombokMojo.java:175)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)

In order to get some real-world experience, we should migrate a Spring Boot app with more than a couple hundred lines of code to a Modulith. For this to work, the library must have matured a bit and at least a snapshot should be released to Maven Central or JCenter.

I think we can cross this off as we're 10 GA now and there are a couple of projects already using the library, most notably Quarano on the open-source side.

That seems to be working properly, even in 1.0.

I wonder if that technical separation on the persistence context level has to be put in place as it clearly complicates the picture. The JPA @Table annotation allows to declare the schema an entity is supposed to live in. Using that and strictly governing that aggregates in one module must only refer to other aggregates by identifier, you should be able to get pretty far.

That's an interesting suggestion. I wonder if you could elaborate on what this could look like. Currently we only "report" violations that are usually verified for in a test and which would break the latter. I don't think we'd want to break a build because of that because it might actually be generally acceptable if convenience trumps decoupling.

In general, we'd need to find components that invoke other components from other modules within a method marked as transactional. Tricky bit could be that that invocation of the other module component might be hidden behind an indirection: @-tx-method -> private method -> method invocation on other module component. Also, the invocation might be hidden behind an event publication that exists a listener for in the other module.

Currently Spring application event listeners are not properly handled by the modules abstractions. Take the following structure for example:

com.acme.orders
+ ….Order (publishes OrderCreated events)
com.acme.accounting
o ….OrderEventListener

Further assume that OrderEventListener looks like this:

@Component
class OrderEventListener {

  @EventListener
  void on(OrderCreated event) { … }
}

As we currently only inspect type dependencies and interpret them as indicator for a downstream module dependency this scenario results in accounting to have a module dependency to orders. This is clearly wrong. I suggest to alter the model setup to change to the following:

• When collecting the module dependencies, explicitly check for modules annotated with @EventListener and make the nature of the dependency explicit (listens-to).
• Do not consider this type dependency a module dependency or at least don't include the module referred to into the ones that need to be included when bootstrapping upstream dependencies.
• The additional meta-information can be included in the diagrams created in #16 to distinguish between the different module relationships.

That's been fixed a while ago. Event listeners are handled correctly and appear correctly in generated documentation etc.

I might stretch the scope of the ticket a bit but would it be terribly hard to extend the functionality to not only react on annotations present but the type implementing another one? A use case I have is the following: in the jDDD library we expose interfaces that express DDD building blocks. There's also an annotation based model but interfaces allow us to express relationship constraints using generics. One of the interfaces is Identifier. Implementations usually look like this:

@EqualsAndHashCode
@RequiredArgsConstructor(staticName = "of")
@NoArgsConstructor(access = AccessLevel.PRIVATE, force = true)
class SomeIdentifier implements Identifier { … }

Having expressed the type to be an identifier via the interface already it would be cool if I could avoid the annotations by registering:

lombok.metaAnnotations = Identifier lombok.EqualsAndHashCode lombok.RequiredArgsConstructor(staticName = "of") lombok.NoArgsConstructor(access = lombok.AccessLevel.PRIVATE, force = true)

i.e. let the trigger of the annotations to be added be an interface instead of an annotation.

I just spoke to @abuijze of Axon Framework and we wondered whether it'd make sense to introduce annotations and types to declare CQRS / Event Sourcing building blocks:

• @Command – type annotation
• @CommandHandler – method annotation
• @(Domain)EventHandler – method annotation
• @ViewModel / @Projection – type annotation

Axon also provides annotations for querying:

• @Query
• @QueryHandler

but they seem to be a little more specific to Axon rather than a CQRS / ES concept that is to be mapped to types and packages in general.

Open questions

1. Should this be a dedicated artifact (jddd-cqrs) or a part of the already existing jddd-architecture artifact. As using CQRS / ES as implementation is a pretty significant decision, I personally tend to vote for the former as I wouldn't want to impose the types on the classpath of someone who just pulled in the jddd-architecture artifact on the classpath to e.g. demarcate layers.
2. Axon currently provides @EventHandler but we have chosen @DomainEvent in the jddd-events module. Thus, I'd vote to name the corresponding handler annotation @DomainEventHandler for consistency.
3. @ViewModel or @Projection? I tend to vote for the former.

⚠️ Dependabot is rebasing this PR ⚠️

If you make any changes to it yourself then they will take precedence over the rebase.

Bumps nokogiri from 1.10.4 to 1.10.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/sparklemotion/nokogiri/releases">nokogiri's releases</a>.</em></p> <blockquote> <h2>1.10.9 / 2020-03-01</h2> <h3>Fixed</h3> <ul> <li>[MRI] Raise an exception when Nokogiri detects a specific libxml2 edge case involving blank Schema nodes wrapped by Ruby objects that would cause a segfault. Currently no fix is available upstream, so we're preventing a dangerous operation and informing users to code around it if possible. [<a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1985">#1985</a>, <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/2001">#2001</a>]</li> <li>[JRuby] Change <code>NodeSet#to_a</code> to return a RubyArray instead of Object, for compilation under JRuby 9.2.9 and later. [<a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1968">#1968</a>, <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1969">#1969</a>] (Thanks, <a href="https://github.com/headius">@headius</a>!)</li> </ul> <h2>1.10.8 / 2020-02-10</h2> <h3>Security</h3> <p>[MRI] Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1992">#1992</a>. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.</p> <h2>1.10.7 / 2019-12-03</h2> <h3>Bug</h3> <ul> <li>[MRI] Ensure the patch applied in v1.10.6 works with GNU <code>patch</code>. <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1954">#1954</a></li> </ul> <h2>1.10.6 / 2019-12-03</h2> <h3>Bug</h3> <ul> <li>[MRI] Fix FreeBSD installation of vendored libxml2. [#1941, <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1953">#1953</a>] (Thanks, <a href="https://github.com/nurse">@nurse</a>!)</li> </ul> <h2>1.10.5 / 2019-10-31</h2> <h3>Dependencies</h3> <ul> <li>[MRI] vendored libxml2 is updated from 2.9.9 to 2.9.10</li> <li>[MRI] vendored libxslt is updated from 1.1.33 to 1.1.34</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/sparklemotion/nokogiri/blob/v1.10.9/CHANGELOG.md">nokogiri's changelog</a>.</em></p> <blockquote> <h2>1.10.9 / 2020-03-01</h2> <h3>Fixed</h3> <ul> <li>[MRI] Raise an exception when Nokogiri detects a specific libxml2 edge case involving blank Schema nodes wrapped by Ruby objects that would cause a segfault. Currently no fix is available upstream, so we're preventing a dangerous operation and informing users to code around it if possible. [<a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1985">#1985</a>, <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/2001">#2001</a>]</li> <li>[JRuby] Change <code>NodeSet#to_a</code> to return a RubyArray instead of Object, for compilation under JRuby 9.2.9 and later. [<a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1968">#1968</a>, <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1969">#1969</a>] (Thanks, <a href="https://github.com/headius">@headius</a>!)</li> </ul> <h2>1.10.8 / 2020-02-10</h2> <h3>Security</h3> <p>[MRI] Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1992">#1992</a>. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.</p> <h2>1.10.7 / 2019-12-03</h2> <h3>Bug</h3> <ul> <li>[MRI] Ensure the patch applied in v1.10.6 works with GNU <code>patch</code>. <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1954">#1954</a></li> </ul> <h2>1.10.6 / 2019-12-03</h2> <h3>Bug</h3> <ul> <li>[MRI] Fix FreeBSD installation of vendored libxml2. [#1941, <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1953">#1953</a>] (Thanks, <a href="https://github.com/nurse">@nurse</a>!)</li> </ul> <h2>1.10.5 / 2019-10-31</h2> <h3>Security</h3> <p>[MRI] Vendored libxslt upgraded to v1.1.34 which addresses three CVEs for libxslt:</p> <ul> <li>CVE-2019-13117</li> <li>CVE-2019-13118</li> <li>CVE-2019-18197</li> <li>CVE-2019-19956</li> </ul> <p>More details are available at <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1943">#1943</a>.</p> <h3>Dependencies</h3> <ul> <li>[MRI] vendored libxml2 is updated from 2.9.9 to 2.9.10</li> <li>[MRI] vendored libxslt is updated from 1.1.33 to 1.1.34</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/sparklemotion/nokogiri/commit/e2e191de387f854619bc8a3f9b39ca687fe0bf31"><code>e2e191d</code></a> version bump to v1.10.9</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/50f8fdeae4afb8582ff6347d7aa17822a1e11242"><code>50f8fde</code></a> update CHANGELOG</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/9b5deef76aeb5e3868cafb0b0956cca3708136f3"><code>9b5deef</code></a> Change return type to RubyArray</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/ae054f750283dccb1454d71dc00d0343dc2b1c60"><code>ae054f7</code></a> update CHANGELOG for <a href="https://github-redirect.dependabot.com/sparklemotion/nokogiri/issues/1985">#1985</a></li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/71bcaf0bb1351c09e48f41f10314cb35bb4a4db4"><code>71bcaf0</code></a> Work around a bug in libxml2</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/6ce10d15d7af6ad65813a495eaf168f73eba211c"><code>6ce10d1</code></a> version bump to v1.10.8</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/2320f5bd6319dca9c68d85bbf41629bbf8052a49"><code>2320f5b</code></a> update CHANGELOG for v1.10.8</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/4a77fdb789aefed7ca65c7c7f57ad4dca0d3b209"><code>4a77fdb</code></a> remove patches from the hoe Manifest</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/570b6cbc5fbc5ee7ef969332c587b951ae35bcd0"><code>570b6cb</code></a> update to use rake-compiler ~1.1.0</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/2cdb68e95aa075ac36a08d4d82d9b410a950a051"><code>2cdb68e</code></a> backport libxml2 patch for CVE-2020-7595</li> <li>Additional commits viewable in <a href="https://github.com/sparklemotion/nokogiri/compare/v1.10.4...v1.10.9">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>