assignment operator in mule 4

• Manage Email Subscriptions
• How to Post to DZone
• Article Submission Guidelines
• Manage My Drafts

2024 DZone Community Survey: Tell us what's in your tech stack. Help us build a better DZone. Enter for a chance to win swag!

Automate (almost) Anything: Join us for a discussion to learn how to build and maintain automations, integrating databases, APIs, and more!

Database Systems: In 2024, the focus around databases is on their ability to scale and perform in modern data architectures. See why.

Data Pipeline Essentials: Dive into the fundamentals of data pipelines and the problems they solve for modern enterprises.

• Trigger Salesforce Assignment Rules and Send Notifications From MuleSoft
• How To Plan a (Successful) MuleSoft VPN Migration (Part I)
• On-Demand-Schedulers With MuleSoft CloudHub APIs
• Create Proxy Application for Mule APIs
• Vulnerability Management in DevOps Environments
• Quick Scrum Gains
• Streaming Data Joins: A Deep Dive Into Real-Time Data Enrichment
• Why I Use RTK Query for API Calls in React
• Software Design and Architecture
• Integration

Understanding Mule Events in Mule 4

In this article, let's find out more about the structure and basic functionality of each segment or part of mule events in mule 4..

Join the DZone community and get the full member experience.

In MuleSoft integration , events play a crucial role in ensuring communication between two or more flows. Within MuleSoft's Anypoint Studio , each flow that is triggered operates with its event and can make it possible to transfer data and control from one flow to another. Before delving deep into today's topic, let us discover why Mule events are essential to understand for MuleSoft developers. It is because it enables efficient data flow management, and helps in debugging and troubleshooting errors, which ultimately boosts developer productivity. 

Let's find out more about the structure and basic functionality of each segment or part of Mule Events in Mule 4.

What Is a Mule Event?

A Mule Event contains all the core information processed by the Mule runtime. A Mule event is triggered by a message source, such as a Listener or an HTTP request. These Mule Events are critical for the smooth execution of flows in an API creation. As we discussed earlier, each flow has its event, and thus events are immutable, which means a small change to an instance of a Mule event will create a whole new instance. When an event is triggered, all the core information like attributes, payload, and variables are passed to the next processor.

It is important to note that for a flow to execute, the event processor plays a more crucial role than the event source. 

A Mule event consists of two main components: the Mule Message and Variables .

Mule 4 contains a simplified Mule message model in which each Mule event has a message and associated variables.

Mule Message

The Mule Message contains two different parts, namely the attributes and the payload . It serves as a container for message content and metadata, from external sources, as it is processed within flows of a Mule 4 application. 

Attributes contain metadata such as headers and properties, including the method type used, host, and port. When an HTTP request is sent, attributes such as method type, host, and port are included. These attributes are stored in the attributes section under the Mule Message. These attributes will be passed to the rest of the flow until the attributes are updated.

The payload contains the core data being processed throughout the flow. It stores the data that is processed by the application. 'Set payload' is usually used to set the payload, and is carried till the end of the flow in the payload section of the Mule message. Whatever JSON or XML code you write will be stored in the payload section. It is also considered as the main body of a Mule message. The payload is replaced when a new 'set payload' is triggered every time in the Mule runtime flow.

Have you thought about why variables are separated from the Mule message? Because they are the temporary values in an event flow that will be replaced each time a new variable is set.

Variables are used to store per-event values for use within a flow of a Mule app. Variables in a Mule event are created using the Set Variable component. They are used to store temporary values specific to an event within a flow. Variables can hold any supported data type, such as objects, numbers, or strings. They are accessible only within the scope of the flow where they were created.

Hope you understand how a Mule Event works in Mule 4. Please do like and comment on your views on today's topic. Happy learning!!  

Do check my previous blogs on system integration using Mulesoft:

• Build RAML-Based API Specification Using MuleSoft Platform
• Publishing API to Anypoint Exchange Using MuleSoft Platform
• Error Handling in Mule 
• HTTP Response Codes in Mule 4

Opinions expressed by DZone contributors are their own.

Partner Resources

• About DZone
• Send feedback
• Community research
• Advertise with DZone

CONTRIBUTE ON DZONE

• Become a Contributor
• Core Program
• Visit the Writers' Zone
• Terms of Service
• Privacy Policy
• 3343 Perimeter Hill Drive
• Nashville, TN 37211
• [email protected]

Let's be friends:

Weaving the interactive tutorial... 🐑

Gartner names MuleSoft a Leader

Create connected experiences with AI

Future of connected AI agents

The world of AI is a world of APIs

Deutschsprachig.

Diese Inhalte gibt es auch auf Deutsch. Um die Sprache zu ändern, klicken Sie auf das Symbol.

Deutsche Version

© Copyright 2024 Salesforce, Inc. All rights reserved .

MuleSoft is closed for new business in your country.

We are not accepting downloads and new sign-ups at this time. If you are already a customer, you can still login to your account.

LOG INTO YOUR ACCOUNT

You have been redirected

You have been redirected to this page because Servicetrace has been acquired by MuleSoft. Click here to learn more.

After 17 years of reporting on the API economy, ProgrammableWeb has made the decision to shut down operations. Click here to learn more.

Cette page est disponible en Français

Voir en Français

Verfügbar in Deutsch

Diese Seite gibt es auch auf Deutsch

Deutsche Seite

Stay on English page

Esta página está disponible en español

Ver en español

Essa página está disponível em Português

Veja-a em Português

このページは日本語でもご利用いただけます

• What are microservices?
• API Strategy Resources
• API Management Platform

Gartner names MuleSoft a Leader

Unleash the power of Salesforce Customer 360 through integration

Anypoint Platform Fundamentals

The world of AI is a world of APIs

© Copyright 2024 Salesforce, Inc. All rights reserved .

Thread management and auto-tuning in Mule 4

My first two posts in this Mule 4 blog series were on scaling your APIs and reactive programming in our newest version of Mule runtime engine. This blog dives into thread management and auto-tuning.

Mule 4 eradicates the need for manual thread pool configuration as this is done automatically by the Mule runtime.

Centralized thread pools

Thread pools are no longer configurable at the level of a Mule application. We now have three centralized pools:

• CPU_INTENSIVE
• BLOCKING_IO

All three are managed by the Mule runtime and shared across all applications deployed to that runtime. A running Mule application will pull threads from each of those pools as events pass through its processors. The consequence of this is that a single flow may run in multiple threads. Mule 4 optimizes the execution of a flow to avoid unnecessary thread switches.

HTTP thread pools

The Mule 4 HTTP module uses Grizzly under the covers. Grizzly needs selector thread pools configured. Java NIO has the concept of selector threads. These check the state of NIO channels and create and dispatch events when they arrive. The HTTP Listener selectors poll for request events only. The HTTP Requester selectors poll for response events only.

There is a special thread pool for the HTTP Listener. This is configured at the Mule runtime level and shared by all applications deployed to that runtime. There is also a special thread pool for the HTTP Requester. This is dedicated to the application that uses an HTTP Requester. So 2 applications on the one runtime both using an HTTP Requester will have one selector pool each for that HTTP Requester. If they both use an HTTP Listener they will share the one pool for the HTTP Listener.

Thread pool responsibilities

The source of the flow and each event processor must execute in a thread that is taken from one of the three centralized thread pools (with the exception of the selector threads needed by HTTP Listener and Requester). The task accomplished by an event processor is either 100% nonblocking, partially blocking, or mostly blocking.

The CPU_LITE pool is for tasks that are 100% non-blocking and typically take less than 10ms to complete. The CPU_INTENSIVE pool is for tasks that typically take more than 10ms and are potentially blocking less than 20% of the clock time. The BLOCKING_IO pool is for tasks that are blocked most of the time.

Thread pool sizing

The minimum size of the three thread pools is determined when the Mule runtime starts up.

The minimum size of the shared Grizzly pool for the HTTP Listener is determined upon the deployment of the first app to the Mule runtime that uses an HTTP Listener. The size of the dedicated Grizzly for the HTTP Requester pool is determined upon deployment of each app that uses an HTTP Requester.

In all cases, the minimum number of threads equals the number of CPU cores available to the Mule runtime. Growth towards the maximum is realized in increments of one thread as needed.

The maximum size of the BLOCKING_IO thread pool is calculated based on the amount of usable memory made available to the Mule runtime. This is determined by a call the Mule runtime makes when it boots to Runtime.maxMemory().

For a Mule runtime sitting on a 2 core / 1 Gig machine or container, the following table shows what the minimum and maximum values are for each thread pool.

Thread pool scheduler assignment criteria

In Java, the responsibility of managing thread pools falls on the Scheduler. It pulls threads from the pool and returns them and adds new threads to the pool. Each of the five pools we described above has its own Scheduler. When a Mule 4 app is deployed each of its event processors is assigned a Scheduler following the criteria outlined in the following table.

An important consideration is the handoff between each event processor. That is always executed on a CPU_LITE thread.

Over time our engineers will enhance modules to make their operations non-blocking.

Mule runtime example consumption of thread pools

The following diagrams show how threads are assigned in various types of Mule flow. Watch out for the red traffic light, which denotes a blocking operation (BLOCKING_IO). The amber traffic light denotes potential partial blocking (CPU_INTENSIVE). The space or handoff between each event processor is non-blocking and catered to by a CPU_LITE thread. Nevertheless, the optimization in the thread schedulers will avoid unnecessary thread switching so a thread from a given pool can continue to execute across processors as we shall see.

Typical thread switching scenario

In this first scenario:

• SHARED_GRIZZLY Thread #10 receives the HTTP Listener request.
• CPU_LITE Thread #8 caters to the handoff between the HTTP Listener and the Database select operation.
• BLOCKING_IO Thread #5 must make the call to the database server and then wait for the result set to be sent back.
• A thread from CPU_LITE is needed for the Logger operation but Scheduler optimization allows for CPU_LITE Thread #2 to also be used for the handoff before and after it.
• CPU_INTENSIVE Thread #16 executes the DataWeave transformation. DataWeave always takes a thread from this pool regardless of whether blocking actually occurs.
• A similar optimization occurs on the second Logger and handoffs with CPU_LITE Thread #1 also making the outbound HTTP Requester call.
• DEDICATED GRIZZLY Thread #2 receives the HTTP Requester response.
• There is an optimization on the response after flow completion: CPU_LITE Thread #7 does the handoff back to the flow source (HTTP Listener) and also executes the response to the client.

Try scope with Transaction

Here the Transactional Try scope mandates the use of a single thread. This will always be from the BLOCKING_IO pool regardless of what type of operations are contained within the scope.

JMS Transactional

In this scenario the whole flow is transactional and requires a single thread from BLOCKING_IO up to the HTTP request.

JMS transactional with Async scope

In this scenario, the Async scope ends the transaction and normal thread selection applies.

My next blog will dive into input streams in Mule 4 . You can try Mule 4 today to see how you can address vertical scalability in an effective way or read our whitepaper, Reactive programming: New foundations for high scalability in Mule 4.

Related articles

Tutorial: Salesforce Imports and Exports With Dataloader.io

• Jackie Wulfsohn
• 6 mins read

How to Initiate Fast App Rollback With CloudHub 2.0

• Michael McDonnell
• 4 mins read

Setting up real-time Secure File Transfer Protocol (SFTP) data integration with webhooks

• Saggi Neumann
• 11 mins read

Get the latest news delivered to your inbox

You have been redirected

You have been redirected to this page because Servicetrace has been acquired by MuleSoft. Click here to learn more.

• Trending Now
• Foundational Courses
• Data Science
• Practice Problem
• Machine Learning
• System Design
• DevOps Tutorial

Assignment Operators in Programming

Assignment operators in programming are symbols used to assign values to variables. They offer shorthand notations for performing arithmetic operations and updating variable values in a single step. These operators are fundamental in most programming languages and help streamline code while improving readability.

Table of Content

What are Assignment Operators?

• Types of Assignment Operators
• Assignment Operators in C
• Assignment Operators in C++
• Assignment Operators in Java
• Assignment Operators in Python
• Assignment Operators in C#
• Assignment Operators in JavaScript
• Application of Assignment Operators

Assignment operators are used in programming to  assign values  to variables. We use an assignment operator to store and update data within a program. They enable programmers to store data in variables and manipulate that data. The most common assignment operator is the equals sign ( = ), which assigns the value on the right side of the operator to the variable on the left side.

Types of Assignment Operators:

• Simple Assignment Operator ( = )
• Addition Assignment Operator ( += )
• Subtraction Assignment Operator ( -= )
• Multiplication Assignment Operator ( *= )
• Division Assignment Operator ( /= )
• Modulus Assignment Operator ( %= )

Below is a table summarizing common assignment operators along with their symbols, description, and examples:

Assignment Operators in C:

Here are the implementation of Assignment Operator in C language:

Assignment Operators in C++:

Here are the implementation of Assignment Operator in C++ language:

Assignment Operators in Java:

Here are the implementation of Assignment Operator in java language:

Assignment Operators in Python:

Here are the implementation of Assignment Operator in python language:

Assignment Operators in C#:

Here are the implementation of Assignment Operator in C# language:

Assignment Operators in Javascript:

Here are the implementation of Assignment Operator in javascript language:

Application of Assignment Operators:

• Variable Initialization : Setting initial values to variables during declaration.
• Mathematical Operations : Combining arithmetic operations with assignment to update variable values.
• Loop Control : Updating loop variables to control loop iterations.
• Conditional Statements : Assigning different values based on conditions in conditional statements.
• Function Return Values : Storing the return values of functions in variables.
• Data Manipulation : Assigning values received from user input or retrieved from databases to variables.

Conclusion:

In conclusion, assignment operators in programming are essential tools for assigning values to variables and performing operations in a concise and efficient manner. They allow programmers to manipulate data and control the flow of their programs effectively. Understanding and using assignment operators correctly is fundamental to writing clear, efficient, and maintainable code in various programming languages.

Please Login to comment...

Similar reads.

• Programming

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Rule of 4.5: No move assignment operator?

Based on the popular question What is the copy-and-swap idiom? :

Why does the rule of 4.5 not include the move assignment operator (to effectively become the rule of 5.5)? Instead I've read (eg. here What is the Rule of Four (and a half)? ) that we either have rule of 4.5 or 5?

Since the swap member function is noexcept , shouldnt the copy assignment operator also be marked the same (the move constructor can't since it calls the default constructor that can throw)?

• move-semantics

Because it would not be useful.

Click your second link then forth link there The Rule of The Big Four (and a half) – Move Semantics and Resource Management

Read carefully section 5 – Move assignment .

You will see

Eliminating the move assignment operator In reality is the move assignment operator is unnecessary!

with all the explanation!

Essentially the operator dumb_array& operator=(dumb_array other) will be used when normally you would have used move assignment operator.

I haven't verified but you might be able to delete it too as it will not be generated anyway.

• Thanks. Could you also clarify the second question about making the copy assignment noexcept? –  tangy Commented Jan 6, 2019 at 3:50
• 1 noexcept should not be there. dumb_array other constructs a copy or moves an object depending on lvalue or rvalue passed. Both are not noexcept. –  3CxEZiVlQ Commented Jan 6, 2019 at 7:30

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged c++ c++11 move-semantics or ask your own question .

• The Overflow Blog
• Scaling systems to manage all the metadata ABOUT the data
• Navigating cities of code with Norris Numbers
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• Tag hover experiment wrap-up and next steps

Hot Network Questions

• Aligning equations inside 'cases' with individual text tags in each row and equation labels
• Claims of "badness" without a moral framework?
• How to Vertically Join Images?
• How to interpret coefficients of logistic regression using natural cubic splines?
• Why do individuals with revoked master’s/PhD degrees due to plagiarism or misconduct not return to retake them?
• How can we objectively measure the similarity between two scatter plots whose coordinates are known?
• Counter in Loop
• Why does editing '/etc/shells' file using 'sudo open' show an error saying I don't own the file?
• Unstable output C++: running the same thing twice gives different output
• Someone wants to pay me to be his texting buddy. How am I being scammed?
• Is an invalid date considered the same as a NULL value?
• Writing a Puzzle Book: Enigmatic Puzzles
• Is Psalm 107:4-7 ascribing the forty years of wandering in the wilderness to Moses refusing to ask for directions?
• When would it be legal to ask back (parts of) the salary?
• Why does Air Force Two lack a tail number?
• What's the polarity of this electrolytic capacitor symbol?
• How are USB-C cables so thin?
• What is a word/phrase that best describes a "blatant disregard or neglect" for something, but with the connotation of that they should have known?
• Argument of Complex Numbers with unknown values
• "Undefined" when attempting analytical expression for a RegionIntersection and its Area in V14.0
• Why would luck magic become obsolete in the modern era?
• How do you determine maximum frequency of AD574A 12-bit ADC?
• Has the application of a law ever being appealed anywhere due to the lawmakers not knowing what they were voting/ruling?
• I need to better understand this clause in an independent contract agreement for Waiverability:

Gartner names MuleSoft a Leader

Unleash the power of Salesforce Customer 360 through integration

Anypoint Platform Fundamentals

The world of AI is a world of APIs

© Copyright 2024 Salesforce, Inc. All rights reserved .

• Release Notes

Mule Runtime Engine 4.5.0 Release Notes

This version of the product has reached End of Life .

Mule runtime engine (Mule) is a lightweight integration engine that runs Mule applications and supports domains and policies.

This version of Mule provides important enhancements and fixes. Deploy all your new and existing applications to the latest version to benefit from the improvements.

Patch release version: 4.5.4

This patch update addresses the following Mule issues:

There is no DataWeave update for this version.

For guidance with the patching process, see Apply Patch Updates .

January 2024

Patch release version: 4.5.3

DataWeave 2.5.2 is bundled with the Mule 4.5.3 release. This patch release addresses the following DataWeave issues:

November 2023

Patch 4.5.2.

The November patch update 4.5.2 addresses a regression in the previous November patch update, 4.5.1, and includes the fixes in the patch.

Patch release version: 4.5.2

Patch 4.5.1

Patch release version: 4.5.1

DataWeave 2.5.1 is bundled with the Mule 4.5.1 release. This patch release addresses the following DataWeave issues:

October 3, 2023

What’s new.

The 4.5.0 version of Mule runtime introduces the following enhancements:

New release channels:

Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Consider the following factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.

See Edge and LTS Releases for Mule .

Memory management:

The Mule runtime has a centralized memory service that controls the memory allocation for different components such as HTTP and DataWeave.

API Gateway improvements:

Enhancements on policy ordering and editing to optimize the synchronization between API Manager and the API Gateway.

General improvements:

toString is now implemented in properties objects to help with troubleshooting. (W-12081340)

MVEL resource releaser logs are now improved. (W-12513080)

Trace/debug logging is now added to registry-bootstrap for troubleshooting. (W-12117737)

The name of the resource is now added when there is a failure in PropertiesUtils#discoverProperties . (W-11336085)

To waive expression required parameters on design time is now allowed when the value is a property. (W-12226023)

The log "HTTP response stream was closed before being read but response streams must always be consumed" now throws LOGGER.error . (W-12173136)

Declaration enrichers are now optimized to improve extension load time. (W-12102817)

FileUtils#unzip performance is now improved. (MULE-19894)

Extension models are loaded in parallel when deploying applications. (W-12073186)

The extension model loading performance is now improved. (MULE-19706)

The message on Duplicate Key error for Value Provider on Build is now improved. (W-11803219)

Design time validations are now introduced to check the existence of the file referenced by parse-template. (MULE-19813)

A build validation is now added to check that FirstSuccessful has at least 2 routes. (MULE-19244)

A build validation is now added to check that referenced DataWeave files exist. (EE-8091)

Kryo Serializer is now added for commonly used Java classes. (W-13059082)

Kryo Serializer is now added for ReentrantReadWriteLock. (W-13066966)

Kryo Serializer is now added for Map.Entry. (W-13059266)

Kryo Serializer is now added for unmodifiable and synchronized collections. (W-13055604)

Kryo Serializer is now added for ArrayList classes. (W-13021182)

Kryo Serializer is now added for GregorianCalendar. (W-13013723)

Kryo Serializer is now added for Atomic classes. (W-13007667)

The resolution of properties is now refactored. (W-12138147)

Where possible, we changed noninclusive terms in our codebase to align with our company value of Equity. (W-11894128)

DeploymentService must attempt to use the serializedAst if present. (MULE-20062)

Reflective equals/hashcode in MetadataType is no longer used. (W-12622215)

Internal sun classes are no longer used. (W-12621856)

Trigger, private, and active flow metrics are now introduced to enable the usage-based pricing initiative. (W-11493854)

The messagesDispatched metric is now added to statistics. (W-11954914)

Supported Java version concept in SDK is now added. (W-13497626)

BODY as a parameter placement in @OAuthParameter is now supported. (W-13544791)

SDK no longer processes fields from enums. (W-13759844)

Polling Source notifications are now improved. (W-11492717)

A library folder for Java 8-specific libraries is now added. (W-12761115)

New cluster-specific exceptions are now created to wrap Hazelcast exceptions. (W-14077819)

Internal Telemetry enhancements are now added.

Feature Flagging Mechanism:

Mule 4.5 incorporates new feature flags, which enables you to disable certain features that change core functionality in Mule to avoid backward compatibility issues. See Feature Flagging for a detailed description of each feature flag and configuration instructions.

DataWeave Features

The 2.5.0 version of DataWeave introduces the following new features and enhancements:

Support for backward compatibility with previous 2.x versions of DataWeave:

Compatibility flags retain previous DataWeave behavior at the Mule application level. For details, see DataWeave System Properties .

Syntax of an earlier version of DataWeave is supported through the %dw directive (such as %dw 2.4 ).

Setting the directive to an earlier version of DataWeave avoids any syntax-breaking changes when the DataWeave runtime engine runs the script. This script-level setting enables you to retain earlier behavior in some scripts while using the latest behavior in others. DataWeave syntax did not change between DataWeave versions 2.1 through 2.4. See discussion of %dw in DataWeave Header .

Extended format support:

ProtoBuf format support is available. See Protobuf Format .

cXML support in the XML format is available for reading and creating doctype directives (DTDs). See XML Format .

Extended type support:

Loading type definitions from Java classes, JSON schemas, and XML schemas, and using the definitions in DataWeave scripts is supported. See Selecting Types .

Creating new DataWeave types from existing types is supported. See Reuse Types .

Specifying type parameters (similar to generics in other programming languages) of a function at the call site is supported. For details and examples, see Type Parameters and Work with Functions and Lambdas in DataWeave .

Introducing a Metadata Assignment Operator ( <~ ) which enables you to set the metadata of any value without using the as operator. See Metadata Assignment Operator .

DataWeave now uses a centralized memory service provided by the Mule runtime when executing in that context.

DataWeave module features:

The Dtd module ( dw::xml::Dtd ) is new.

The toString function adds the locale parameter.

The Core annotation @UntrustedCode() changes to @UntrustedCode(privileges: Array<String>) .

The concatWith function is new.

The version function is new.

Fixed Issues

The release addresses the following Mule issues and incorporates all patch updates from the 4.4.0 Mule release through September 2023:

DataWeave 2.5.0 is bundled with the Mule 4.5.0 release. This release addresses the following DataWeave issues:

Bundled Components

Dataweave version 2.5.0

Runtime Manager Agent plugin version 2.5.0

If you are upgrading to this version of Mule from an earlier Mule 4.x version, see Mule Upgrades and Patch Updates .

To ensure optimal performance with this version of Mule and avoid unexpected issues, update the following modules and extensions to their latest version at the time of this release:

Considerations for Mule Extensions Developers

If you update the version of your parent pom.xml file to 1.4.0 or later when you build a Mule extension, ensure that the dependencies in your pom.xml file do not override dependencies defined in the parent pom.xml file, and declare only the dependencies you need. If you need to declare a dependency that is already declared in the parent pom.xml file, do not specify a version so it uses the version from the parent pom.xml file.

MuleSoft Help Center

MuleSoft Services