Re: Re: Re: Version Management in 'mvn dependency:tree'
Howdy, "I delete 3.12.0" -- you deleted the "3.12.0" directory? "still downloads 3.12.0" -- means you got again the "3.12.0" directory? As it _will_ download the POM during collection, but not the JAR (or at least should not) T On Wed, Nov 1, 2023 at 6:37 AM yukai zhao wrote: > Thank you for your response! > Additionally, I've noticed that in this situation, if I delete 3.12.0 from > my local repository and then recompile the project, Maven still downloads > 3.12.0. Is this behavior normal? > > On 2023/11/01 03:45:49 Greg Chabala wrote: > > On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > > > > > has the project actually introduced the > org.apache.commons:commons-lang3 > > > with version 3.12.0 during the actual compilation process? > > > > > > > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why > > it was not even mentioned without turning on verbose output. > > > > This is basically the core purpose of Maven, choosing what version of an > > artifact to include in the classpath. > > >
Re: Version Management in 'mvn dependency:tree'
On Wednesday, 1. November 2023, 06:37:31 CET yukai zhao wrote: > Thank you for your response! > Additionally, I've noticed that in this situation, if I delete 3.12.0 from > my local repository and then recompile the project, Maven still downloads > 3.12.0. Is this behavior normal? In this case, yes, because the core of Maven 3.9.4 is actually *using* this version when you run it. This has nothing to do with the classpath of a project where you're using maven-core as dependency. Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Re: Re: Version Management in 'mvn dependency:tree'
Thank you for your response! Additionally, I've noticed that in this situation, if I delete 3.12.0 from my local repository and then recompile the project, Maven still downloads 3.12.0. Is this behavior normal? On 2023/11/01 03:45:49 Greg Chabala wrote: > On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > > > has the project actually introduced the org.apache.commons:commons-lang3 > > with version 3.12.0 during the actual compilation process? > > > > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why > it was not even mentioned without turning on verbose output. > > This is basically the core purpose of Maven, choosing what version of an > artifact to include in the classpath. >
Re: Re: Version Management in 'mvn dependency:tree'
On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > has the project actually introduced the org.apache.commons:commons-lang3 > with version 3.12.0 during the actual compilation process? > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why it was not even mentioned without turning on verbose output. This is basically the core purpose of Maven, choosing what version of an artifact to include in the classpath.
RE: Re: Version Management in 'mvn dependency:tree'
I apologize for my unclear description! Allow me to explain my problem
specifically. You are right; it is indeed a confusion.
Firstly, I compiled a project using Maven. This step was completed with the
command mvn clean install. Below is part of the output (I have omitted some
information for brevity).
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=316672,
ConflictMarker.markTime=152305, ConflictMarker.nodeCount=135,
ConflictIdSorter.graphTime=146303, ConflictIdSorter.topsortTime=42955,
ConflictIdSorter.conflictIdCount=59, ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=4445286, ConflictResolver.conflictItemCount=131,
DefaultDependencyCollector.collectTime=204337663,
DefaultDependencyCollector.transformTime=5194486}
[DEBUG]
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:maven-plugin:2.4.2-SNAPSHOT
...
[DEBUG] org.apache.maven:maven-core:jar:3.9.4:provided
...
[DEBUG] org.codehaus.plexus:plexus-interpolation:jar:1.26:provided
[DEBUG]
org.codehaus.plexus:plexus-component-annotations:jar:2.1.0:provided
[DEBUG] org.slf4j:slf4j-api:jar:1.7.36:provided
[DEBUG]
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.9.0:provided
[DEBUG] org.apache.commons:commons-lang3:jar:3.13.0:compile
[DEBUG] junit:junit:jar:4.13.2:test
...
>From this portion of the information, we can see that the version of the
>dependency package org.apache.commons:commons-lang3 is 3.13.0. However,
>because the compilation output hides duplicate dependency information, I tried
>mvn dependency:tree -Dverbose=true to get more detailed information. Here is
>the output:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
launch4j-maven-plugin ---
[INFO]
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:maven-plugin:2.4.2-SNAPSHOT
...
[INFO] +- org.apache.maven:maven-core:jar:3.9.4:provided
...
[INFO] | +- org.codehaus.plexus:plexus-interpolation:jar:1.26:provided
[INFO] | +- org.codehaus.plexus:plexus-component-annotations:jar:2.1.0:provided
[INFO] | +- (org.apache.commons:commons-lang3:jar:3.12.0:provided - omitted for
duplicate)
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.36:provided
[INFO] +-
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.9.0:provided
[INFO] +- org.apache.commons:commons-lang3:jar:3.13.0:compile
[INFO] +- junit:junit:jar:4.13.2:test
...
>From this, we can still find the dependency package
>org.apache.commons:commons-lang3 at its original location, and the version
>matches the one mentioned in the compilation output, which is 3.13.0. However,
>within the dependency of org.apache.maven:maven-core, there is another
>occurrence of org.apache.commons:commons-lang3. It's worth noting that this
>dependency package does not have the version 3.13.0.
My confusion is: based on the above situation, has the project actually
introduced the org.apache.commons:commons-lang3 with version 3.12.0 during the
actual compilation process?
I hope this clarifies my confusion.
On 2023/10/31 19:14:08 Greg Chabala wrote:
> On Tue, Oct 31, 2023 at 11:27 AM
> wrote:
>
> > Can't quite make sense of all this; given that you got no replies, maybe
> > no one else understood either.
>
>
> I second this sentiment. All I could tell is it seems like there's some
> confusion about interpreting the dependency:tree output, and perhaps
> confusion on how dependency convergence works, or how a project should
> specify dependency versions.
>
> See
> https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
> for an overview.
>
Re: Version Management in 'mvn dependency:tree'
On Tue, Oct 31, 2023 at 11:27 AM wrote: > Can't quite make sense of all this; given that you got no replies, maybe > no one else understood either. I second this sentiment. All I could tell is it seems like there's some confusion about interpreting the dependency:tree output, and perhaps confusion on how dependency convergence works, or how a project should specify dependency versions. See https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html for an overview.
RE: Version Management in 'mvn dependency:tree'
Can't quite make sense of all this; given that you got no replies, maybe no one else understood either. Could you explain a bit better? -Original Message- From: yukai zhao Sent: Monday, October 30, 2023 9:10 PM To: users@maven.apache.org Subject: Version Management in 'mvn dependency:tree' CAUTION: This email originated from outside our organisation - yukz...@163.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Hello, Recently, I attempted to use 'mvn dependency:tree' to retrieve the project's dependency tree. However, in the output, I noticed that for the same dependency with different scopes, its version doesn't appear to be consistent. The specific scenario is as follows: (org.checkerframework:checker-qual:jar:3.5.0:compile - scope updated from runtime; omitted for duplicate) org.checkerframework:checker-qual:jar:3.12.0:compile I made sure that these two pieces of information are present in the dependency tree of the same JAR. However, in the compilation information, I found that the first entry was hidden, and only the second entry was displayed. I'm curious about what happened here. In the actual compilation process, were both versions utilized, or was only the first version used? Additionally, I attempted to remove the existing dependency package of version 3.5.0 and recompile the project. Surprisingly, even after removing the 3.5.0 version dependency package, Maven still downloads and utilizes it. Does this indicate that the project is still using the 3.5.0 version of the dependency package? Of course, I need to add a clarification: the 3.5.0 version of the dependency package is an indirect dependency of the project, while version 3.12.0 is a direct dependency. Best regards, Yukai zhao This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version management in a Maven CI environment
On Fri, August 12, 2011 10:34 am, leonfranzen wrote: My organization has been using Maven and CI for a few years now. Although we have a process in place that works for us, it has always been difficult to come up with a successful approach to dependency version management in Maven at release-time. We use the release plugin extensively, are familiar with the version plugin and use them both in an attempt to automate the process as much as possible but I feel that our approach may not be a best-practice. The Sonatype CI best practices blog post was very helpful but I think it was light on details regarding dependency version handling. The two areas I feel we have the clunkiest processes are: 1. When a component is released, we don't have a good way to automatically update dependent projects that need a corresponding snapshot version reference update. What is the recommended Maven best practice for synchronizing snapshot dependencies in a complex dependency tree? For us this requires an awareness of the dependencies and manual notification and maintenance. What about using dependency management in a parent pom? 2. Just prior to release time, we have snapshot dependencies. What is the recommended Maven best practice for transitioning those references to released versions while still maintaining proper continuous integration of trunk source changes to the dependencies? In other words where does CI go when we fix our dependency references around release time? We want to avoid any concept of code-freeze around these times. Depending on your scm strategy e.g. trunk moves straight to the next snapshot, release branch gets separate CI setup.. Of course depending on your CI server and SCM things around this idea might vary.. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version management in a Maven CI environment
Manfred Moser wrote: What about using dependency management in a parent pom? I'm not sure I understand what you're suggesting. Do you mean all dependency versions are provided by a common parent POM? Doesn't that present the problem of needing to constantly release the parent POM which would in turn force all projects to update their referenced parent version? This would be compounded if you have deep POM inheritance. Manfred Moser wrote: Depending on your scm strategy e.g. trunk moves straight to the next snapshot, release branch gets separate CI setup.. Of course depending on your CI server and SCM things around this idea might vary.. We have tried a few approaches here, including branch and then release from branch, while trunk maintains Snapshot. While this works, it still requires updating of the snapshot dependency versions. I was hoping to find the Maven-way documented somewhere. One of the main strengths of Maven is its predictable process but it's lighter on details than I would like when it comes to fitting it into a typical CI release cycle. In other words, it's not as simple as mvn release:prepare, mvn release:perform. Since it's not that simple, documentation of a real SCM-integrated, CI process seems to be necessary. -- View this message in context: http://maven.40175.n5.nabble.com/Version-management-in-a-Maven-CI-environment-tp4694136p4702766.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Version Management
What do you mean by version management? We do use maven to add specific tags at the end of project.xml with every Build something like following. versions version id1.0.2/id name1.0.2/name tagLGB_reFUEL_ServiceOrchestration_DEVGRP_dev_JAVA14_051018_2/tag /version version id1.1/id name1.1/name tagLGB_reFUEL_ServiceOrchestration_QAGRP_test_JAVA14_051102_1/tag /version version id1.2/id name1.2/name tagLGB_reFUEL_ServiceOrchestration_QAGRP_test_JAVA14_051115_2/tag /version version id1.3/id name1.3/name tagLGB_reFUEL_ServiceOrchestration_QAGRP_test_JAVA14_051117_3/tag /version /versions -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 6:59 AM To: [EMAIL PROTECTED] Subject: Version Management Hi Can Maven be used as a Version mangement tool? Is it possible to automate the Version management using Maven? Thanks and Regards Hemant Ved * This message has originated from RLPTechnologies, 34405 W 12 Mile Road, Suite 343, Farmington Hills, MI 48331. If you do not wish to receive further e-mails regarding RLPTechnologies, please forward this e-mail to [EMAIL PROTECTED] with the word remove in the subject line. This e-mail message and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please delete this message and notify the RLPTechnologies System Administrator at [EMAIL PROTECTED] * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version Management
Yes, Maven can be used as a Version management tool. The first time written POM file should have the version number and all other file can include a relative path for the versions later on. Thanks and Regards Vaishali G.P. | Cognizant Technology Solutions, Pune-India | PSTN: +9120 40051735 | VNet: 203735 | | Your duty is to Be And not to be this or that | -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 4:29 PM To: [EMAIL PROTECTED] Subject: Version Management Hi Can Maven be used as a Version mangement tool? Is it possible to automate the Version management using Maven? Thanks and Regards Hemant Ved This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version Management
Hi Hermant, No, Maven cannot be used as a Version management tool. Maven is a build tool, an advanced build tool. You can, however, interact with a version management tool (like Subversion) from within Maven, so that Maven performs checking in and checking out (commit and update) to and from Subversion for you as part of the automated build process. Regards Arne -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: 16. august 2007 12:59 To: [EMAIL PROTECTED] Subject: Version Management Hi Can Maven be used as a Version mangement tool? Is it possible to automate the Version management using Maven? Thanks and Regards Hemant Ved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version management question
This does not work.
If you think about it you can see why.
You would define 'sensage-version' in the parent pom and use it in all the
children. The problem is that as it is parsing the child pom, maven has to
find the parent. To do that, it looks in the parent section and has to use
the value of sensage-version'.
Its a classic catch-22 situation. You can't find the parent without the
value of 'sensage-version' and you you can't find the value of
'sensage-versin' without the parent.
-- Lee
On 11/14/06, Christian Goetze [EMAIL PROTECTED] wrote:
I recently asked the question below, but no answer.
I was wondering whether I really need to edit all pom.xml files in all
my project whenever I bump version numbers.
I'm still new at this, so if this is a trivial question, please bear
with me...
--
cg
Christian Goetze wrote:
Why can't I do this:
project
modelVersion4.0.0/modelVersion
!-- This project belongs to ... --
parent
groupIdcom.sensage/groupId
artifactIdsensage/artifactId
version${sensage-version}/version
/parent
I do run mvn -Dsensage-version=3.6...
It works fine when I run from the top of the project down.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
Re: Version management question
Lee Meador wrote: This does not work. If you think about it you can see why. You would define 'sensage-version' in the parent pom and use it in all the children. The problem is that as it is parsing the child pom, maven has to find the parent. To do that, it looks in the parent section and has to use the value of sensage-version'. Not really, since I pass in the value of sensage-version via a -D flag. Maven just refuses to resolve it within a parent.../parent section. Its a classic catch-22 situation. You can't find the parent without the value of 'sensage-version' and you you can't find the value of 'sensage-versin' without the parent. Yeah, I guess so... I'm wondering, though, why maven can't just go look in the parent directory for a pom.xml file and not require me to specify where the parent is - after all, maven has no qualms about imposing all sorts of directory structure conventions, so why not just go that extra step, or at least have a tag use whatever is in the parent directory Meanwhile, I guess I just need to live with having to manage all versions in all the pom.xml files by hand - sigh -. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
