[
http://jira.codehaus.org/browse/MVERSIONS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=212374#action_212374
]
Stephen Connolly commented on MVERSIONS-96:
-------------------------------------------
I am unclear how you envision such filtering from working...
are you saying that we would only consider the artifacts in the filters when
updating properties (which could result in an update which breaks your build)
are you looking for adding additional artifacts to the property update
availability checking (a feature which is already present and where filtering
does not make sense)
are you saying that we would only update properties which control artifacts
matching the specified filters (but that the available versions would be
tracked across all the artifacts linked to the property)...
The way this is designed to work is that you have a property for which all the
dependencies must align, e.g.
<properties>
<jetty-version>6.1.20</jetty-version>
<jsf-version>1.2_12</jsf-version>
<seam-version>2.2.0.GA</seam-version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf-version}</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf-version}</version>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>root</artifactId>
<version>${seam-version}</version>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>parent</artifactId>
<version>${seam-version}</version>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
<version>${seam-version}</version>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
<version>${seam-version}</version>
<type>ejb</type>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-debug</artifactId>
<version>${seam-version}</version>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-ui</artifactId>
<version>${seam-version}</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty</artifactId>
<version>${jetty-version}</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-annotations</artifactId>
<version>${jetty-version}</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-management</artifactId>
<version>${jetty-version}</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-naming</artifactId>
<version>${jetty-version}</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-plus</artifactId>
<version>${jetty-version}</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-util</artifactId>
<version>${jetty-version}</version>
</dependency>
</dependencies>
</dependencyManagement>
When update-properties runs, it looks at all the dependencies which have
versions controlled by properties, e.g. jetty-version. It then looks for all
newer versions of each dependency producing a list which is the intersection of
all the dependent dependencies... then it updates the property to the highest
available version. e.g.
org.mortbay.jetty:jetty has 6.0.0, 6.0.2, 6.0.7, 6.0.9
org.mortbay.jetty:jetty-annotations has 6.0.0, 6.0.1, 6.0.7
org.mortbay.jetty:jetty-management has 6.0.3, 6.0.7, 6.0.9, 6.0.12
org.mortbay.jetty:jetty-naming has 6.0.0, 6.0.2, 6.0.7, 6.0.9
org.mortbay.jetty:jetty-plus 6.0.0, 6.0.2, 6.0.7, 6.0.9
org.mortbay.jetty:jetty-util 6.0.0, 6.0.2, 6.0.7, 6.0.9
Then the only version we can update to without breaking the build is 6.0.7
Update-properties does not make sense if you only have one dependency based off
the property. Update-properties is for the cases above where _multiple_
dependencies are all tied to the same property, and I do not see how filtering
will make life easier in such a situation.
I'll give you 2 weeks to show me how it is useful, otherwise I'm closing as
"won't fix"
> Add groupid/artifactid filtering to update-properties
> -----------------------------------------------------
>
> Key: MVERSIONS-96
> URL: http://jira.codehaus.org/browse/MVERSIONS-96
> Project: Maven 2.x Versions Plugin
> Issue Type: Improvement
> Affects Versions: 1.1
> Reporter: Nicolas Adrian Barrera
>
> I guess that if the goal that updates the dependency versions' setted up in
> properties can realize, for example, which is the next version then it surely
> can realize which groupid or artifactid that dependency has...
> so imho it makes sense to ask the goal an option with parameters just like
> other goals that doesn't replace properties:
> excludes: A list of artifact patterns to exclude. Follows the pattern
> "groupId:artifactId:type:classifier:version"
> includes: A list of artifact patterns to include. Follows the pattern
> "groupId:artifactId:type:classifier:version"
> which can also handle wildcards in the pattern (eg: com.groupI*:*)
> i hope you consider adding this new behaviour to the update-properties goal,
> as i see it's really worthy considering i 've all my dependency versions
> setted as properties as many other people do.
> cheers
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
