I didn't say x.x.x is the only version in the parent. I said it is a SNAPSHOT. The version varies (of course) but in my prior example I said it was 1.0-SNAPSHOT.
-Dave On Tue, Jul 21, 2015 at 9:36 PM, Ron Wheeler <[email protected] > wrote: > Where are the possible SNAPSHOT versions creeping into the build if x.x.x > is the only versions in your parent and the dependencies do not have any > versions (as I suggested). > > Ron > > > On 21/07/2015 10:54 PM, David Hoffer wrote: > >> Yes we use one version for all modules...comes from top level. What I >> mean >> is this is a non-release build so by maven definition is a snapshot. E.g. >> x.x.x is built only once at release, x.x.x-SNAPSHOT is built on every CI >> build. >> >> -Dave >> >> On Tue, Jul 21, 2015 at 8:38 PM, Ron Wheeler < >> [email protected] >> >>> wrote: >>> On 21/07/2015 5:53 PM, David Hoffer wrote: >>> >>> I'm not sure I understand your reply. We use dependency management to >>>> specify versions (for both external & project dependencies), however >>>> that's >>>> not the issue, we have no problem specifying the version to use for both >>>> of >>>> those. What is only in view here are the multi-module project >>>> dependencies >>>> and by definition they are all SNAPSHOTS as we have not released yet. >>>> >>>> What do you mean "by definition"? >>> If the modules use the parent version as their version, they will be >>> SNAPSHOTS or releases depending on the parent pom having a version of >>> x.x.x-SNAPSHOT or x.x.x. >>> i.e. the module version is missing so that the parent's version is the >>> version of the module. >>> Any dependency in another module that is part of the project is set to >>> <version>${project.version}</version> >>> <dependency> >>> <groupId>com.example</groupId> >>> <artifactId>anything-core</artifactId> >>> <version>${project.version}</version> >>> <scope>provided</scope> >>> </dependency> >>> >>> Ron >>> >>> >>> >>> >>> Let me give an example that might help. The multi-module project is >>>> large >>>> and is growing...you start out with these modules (all the versions are >>>> 1.0-SNAPSHOT). >>>> >>>> groupId=com.mycompany.myproject >>>> artifactId=artifactA, artifactB, artifactC, artifact1, artifact2, >>>> artifact3 >>>> >>>> This has been building with your CI system for 1 month when you realize >>>> you >>>> really want these modules. >>>> >>>> groupId=com.mycompany.myproject >>>> artifactId=app-parent >>>> >>>> groupId=com.mycompany.myproject.service >>>> artifactId=artifactA, artifactB, artifactC >>>> >>>> groupId=com.mycompany.myproject.transform >>>> artifactId=artifact1, artifact2, artifact3 >>>> >>>> This too builds fine, however in reality somewhere in this new build is >>>> a >>>> reference to com.mycompany.myproject:artifactA:1.0-SNAPSHOT...perhaps >>>> for >>>> an unpack goal. The build is fine as Nexus will always have this >>>> artifact >>>> although it was removed from the build during the refactor. >>>> >>>> We want to purge all com.mycompany.myproject.* snapshots from Nexus so >>>> the >>>> CI build will fail until the build is correct. >>>> >>>> -Dave >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Jul 21, 2015 at 3:20 PM, Ron Wheeler < >>>> [email protected] >>>> >>>> wrote: >>>>> Using the parent pom to specify the versions of dependencies solves >>>>> this >>>>> problem for most people. >>>>> >>>>> If there are no SNAPSHOTS in the parent's properties and the parent >>>>> poms >>>>> version is not a SNAPSHOT, then your project is not being built with >>>>> SNAPSHOTS. >>>>> >>>>> We never worry about the SNAPSHOTs in the repo. >>>>> >>>>> Ron >>>>> >>>>> >>>>> On 21/07/2015 2:42 PM, David Hoffer wrote: >>>>> >>>>> Yeah it appears our IT group is right...Nexus doesn't have a >>>>> UI/feature >>>>> >>>>>> to >>>>>> do what we want. What other options are there? >>>>>> >>>>>> This would seem a common need, major project does a refactor of Maven >>>>>> GA >>>>>> and want to delete all SNAPSHOTS used by the project to verify the >>>>>> refactor >>>>>> is 100% complete. We have had too many cases where the build is still >>>>>> pointing to an old artifact that isn't part of the build anymore yet >>>>>> the >>>>>> build is happy because old artifacts are still in Nexus. >>>>>> >>>>>> -Dave >>>>>> >>>>>> On Tue, Jul 21, 2015 at 12:36 PM, Karl Heinz Marbaise < >>>>>> [email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> On 7/21/15 6:03 PM, David Hoffer wrote: >>>>>>> >>>>>>> We use Nexus as our corporate Maven repository and would like to >>>>>>> >>>>>>> periodically delete certain SNAPSHOT artifacts. We need to be able >>>>>>>> to >>>>>>>> filter/select by groupId and by version...so delete all where >>>>>>>> groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT. >>>>>>>> >>>>>>>> You can only delete all kind of SNAPSHOT's in Nexus based on a >>>>>>>> time >>>>>>>> >>>>>>>> frame >>>>>>> for example delete all SNAPSHOT's which are older than 30 days etc.. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Our use case is that when we refactor part of the build to use new >>>>>>> >>>>>>> groupIds >>>>>>>> the old ones are not valid anymore however sometimes there is a >>>>>>>> lingering >>>>>>>> reference to the old groupId, if we can delete all the old SNAPSHOTS >>>>>>>> we >>>>>>>> could find those errors now instead of when we release. >>>>>>>> >>>>>>>> Any ideas on how to do this are much appreciated. >>>>>>>> >>>>>>>> -Dave >>>>>>>> >>>>>>>> >>>>>>>> Kind regards >>>>>>>> >>>>>>>> Karl Heinz Marbaise >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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] >>>>>>> >>>>>>> >>>>>>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
