When inheriting from a parent POM, is there a list of which element types will be merged (i.e. the actual value in the child is the union of the parent values and the child values) vs which will be clobbered (i.e. if the child specifies a value, it overrides the parent value)?
You can find the list of values inherited from parent pom here .
About that clobbering AFAIK for the leaf nodes if the item has no id then child's definition will override the parent value as in the dependency declaration and parameter values.
If there is an id you should use that id to override the value.
For the outer nodes like "dependency","plugins","repositories" the default behaviour is merge.
If for example there is different plugin definitions in both parent and child those will be merge. If there is a definition for the same plugin then the value in the child will override the parent's one.
Related
I have a parent state composed of a child state :
#State({
name: 'parent',
default: { parentProp : 'foo' },
children: [
ChildState,
]
}) class ParentState {}
And a child state :
#State({
name: 'child',
default: { },
}) class ChildState {}
I would like to access parentProp inside ChildState, I tried with the shared state method but it creates a circular dependency as ParentState imports ChildState and vis-versa.
Did I miss a simple solution ?
The simple solution would be to put them in the same file to avoid the circular reference.
That being said, I would ask why the child is so interested in the parent property. Maybe that property could shift down to the child or the child could respond to the same action that the parent uses to set that property to capture its own copy of the value.
If you are looking for a way to create a selector across the two states then you could create a joining selector (see the relevant section here: https://ngxs.gitbook.io/ngxs/concepts/select).
I have exactly the same need as author. The reason why child would be interested in parent property is quite simple.
You focus here mainly on selecting part, but in my case I need it to keep clean files with state, where I'd like to avoid mess.
It's not my case, but corespond with it :). Let say we have main state with some properties and some child states keeping more complex data structure.
And now some action happens which set some valu in main state, then other happen which set something in child state, but I want to set it f.e. in map with key as value of property from main state.
It's nothing spectacular... And such possibility probably would help a lot.
If my pom is a child a hierarchy of other poms, is there a way to show exactly which parent pom contains the definition of a plugin?
Short answer is most probably: No.
According to the way Maven builds its model before executing a certain build, the Maven Builder Model:
In phase 1 the hierarchy of poms is resolved
In phase 2 model normalization and plugins configurations are further resolved
But only at the end of phase 2 the effective model validation is performed, which is done on the final effective pom.xml file, as a result of merges, overriding, profiling, injections (of properties) and so on.
To have a look at the full pom, the effective-pom goal of the maven-help-plugin is definitely the right tool. It will show (or write to a given file) the final effective pom a build is gonna use.
The full definition of a plugin (its executions, its global configuration and so on) can only be created once we have the effective pom, because:
the pluginManagement section in any point in the hierarchy can influence a certain plugin
The plugin section in any point in the hierarchy can also influnce it
profiles declared in any point in the hierarchy can also influence it
properties, if used as placeholders, can also play an important role
Having a look at the official Maven POM reference, we can see many entry point to influence a certain plugin definition, which will only be effective to our build once merged through the whole pom hierarchy. A definition per se would not help much since it can then be overriden/influenced further on on the hierarchy chain.
Think about the inherited element of a plugin:
true or false, whether or not this plugin configuration should apply to POMs which inherit from this one. Default value is true.
Or merging of plugin configuration sections:
The default behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. if the child POM does not have an element, but the parent does, the parent value becomes the effective value.
You can control how child POMs inherit configuration from parent POMs by adding attributes to the children of the configuration element. The attributes are combine.children and combine.self. Use these attributes in a child POM to control how Maven combines plugin configuration from the parent with the explicit configuration in the child.
Or further down per execution of a plugin:
inherited: Like the inherited element above, setting this false will supress Maven from passing this execution onto its children. This element is only meaningful to parent POMs.
The overall management can then be influenced by pluginManagement:
Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.
As such, the plugin definition at a certain point of the pom hierarchy may not be meaningful to the final effective build.
Is it possible to write something similar to this code so that in the child objects I get a reference to parent object during the mapping process? Let's assume I have a child object with a property of type ParentClass called parent:
RKPropertyMapping* parentPropertyMapping =
[RKRelationshipMapping relationshipMappingFromKeyPath:#"#parent."
toKeyPath:#"parent"
withMapping:[mapping copy]];
[mapping addPropertyMapping:parentPropertyMapping];
I can later traverse from within the child objects to their parents.
UPDATE 1:
The code above is used by any entity in the hierarchy of JSON objects (except strings, numbers, etc). That is, it tries to set the linkage between the nested json objects and their owners (parents).
JSON response body:
response.body={"returnCode":{"messages":[],"name":"OK","returnCode":1}}
There is a ReturnCodeClass and a MessageClass both with a parent property. I'd like to have a reference (parent) pointing back to the owning (parent) object from these nested objects. E.g. from every message to the returnCode. In case of NSManagedObjects it is done automatically by the inverse relationship. But in case of NSObjects I try to emulate this behavior with using the #parent accessor.
I am trying to find an authoritative list of which elements get inherited from a parent POM. Based on this page
When you inherit a POM, you can choose to live with the inherited POM information or to selectively override it. The following is a list of items a Maven POM inherits from its parent POM:
identifiers (at least one of groupId or artifactId must be overridden.)
dependencies
developers and contributors
plugin lists
reports lists
plugin executions (executions with matching ids are merged)
plugin configuration
But when I see the effective POM in one of my projects I see it also inherits inceptionYear, description (which is a problem, this should be a description of the POM that contains it, not of its children. What's the point of all children having a description like "The root of all POMs")
So is there an actual list or does it just inherit everything from the parent pom? i use some of these properties in the artifact's manifest so I want to add meaningful values
The child pom inherits everything from the parent pom. If you need to set meaningful values in the child pom then you will need to override the values in the parent pom.
From the Docs:
When a project specifies a parent project, Maven uses that parent POM
as a starting point before it reads the current project’s POM. It
inherits everything, including the groupId and version number.
Most elements from the parent POM are inherited by its children. Two elements that aren't inherited are artifactId & name. (Also, any plugins which explicitly set <inherited>false)
Assume that I have an Ecore-model containing a package and some classes that make reference to each other. If i create a "Dynamic Instance", Eclipse produces an XMI-file and I can instantiate some classes. Containment-relations are directly serialized to an XML-tree in the XMI (the children elements in the example). But if I instantiate references to elements that are already contained somewhere in the tree, the Editor writes Path-Expressions like in the following, for the currentChild attribute:
<parent currentChild="//#parent/#children.1">
<children/>
<children/>
</parent>
As far as I know this is not XPath, because:
The "childrens" are elements not attributes and have not to be referenced via "#"
XPath uses the e.g., elem[1] and not elem.1 to get e.g., the second elem of a list
What is it and where can I find a information on it? I already tried to browse the EMF pages/specs but could not find it.
It's an EMF Fragment Path. The Javadoc describes it like this:
String org.eclipse.emf.ecore.InternalEObject.eURIFragmentSegment(EStructuralFeature eFeature, EObject eObject)
Returns the fragment segment that, when passed to eObjectForURIFragmentSegment, will resolve to the given object in this object's given feature.
The feature argument may be null in which case it will be deduced, if possible. The default result will be of the form:
"#feature-name[.index]"
The index is used only for many-valued features; it represents the position within the list.
Parameters:
eFeature the feature relating the given object to this object, or null.
eObject the object to be identified.
Returns:
the fragment segment that resolves to the given object in this object's given feature.