I used to have projects with 90-120 different pom files on the same repository. With heaps of OSGI plugins, plugins in different repositories, our own customised lifecycle, different versions of maven. Of course all sorts of profiles you can find. Of all the things I can say, it wasn't a simple and small project.
CI with peaks of 1000 slaves/agents running, majority of the builds were in maven. Still, we never needed this specific functionality. But clearly, we handled it in other ways. On 22 July 2015 at 16:15, Adrien Rivard <[email protected]> wrote: > Hi, > > Nexus has some tasks to shedule snapshots suppressions, see > https://books.sonatype.com/nexus-book/reference/scheduled-tasks.html > Days rentention and specific repository are some of the options. > > Maybe that will help. > > > On Wed, Jul 22, 2015 at 8:02 AM, David Hoffer <[email protected]> wrote: > > > Yeah, that's the Nexus API I found too and will probably use. > > > > I agree that for simple/small projects this isn't much of an issue as the > > developer can generally get it right and the 'old/obsolete' snapshots > don't > > cause any problems. Going offline to catch these issues is problematic > as > > we have other released versions we don't want to delete so users can't > just > > delete a single folder and go offline and test...it would be hundreds of > > folders to manually delete. I'm trying to make it easy and catch it at > the > > CI server. To be fair to our devs this is not your normal small/simple > > app, rather it's huge with tons of modules/profiles and > complexity...often > > the issue that breaks our releases is just an unpack goal on a resources > > zip or an OSGi features.xml that didn't get updated correctly. In any > case > > if I could simply get Nexus to delete our (prior) project's snapshots and > > then fail the CI build it would help a lot. (It would help Nexus too as > the > > old/obsolete snapshots are just wasting its resources and some of them > are > > very large.) > > > > -Dave > > > > On Tue, Jul 21, 2015 at 11:27 PM, Cintia Del Rio < > [email protected]> > > wrote: > > > > > Nexus has a REST api: > > > > > > > > > > > > http://blog.sonatype.com/2012/07/learning-the-nexus-rest-api-read-the-docs-or-fire-up-a-browser/#.Va8oFhOqpBc > > > > > > It allows deleting files and folders, it will even reconstruct the > > > metadata. I've done a few CURL to delete file on the past. > > > > > > Anyway, maven provides an offline mode, if the problem is only testing > if > > > it's not getting dependencies from outside the reactor. Or you can use > > > versions:set and set something completely arbitrary > > > > > > Other option is not deploy snapshots at all. > > > > > > > > > http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html > > > Or deploy to a repo that your CI won't fetch. > > > > > > But no, it's not really a common need. Deleting non-unique and released > > > snapshots is the mainstream feature, and that's all I've seen being > used. > > > > > > > > > > > > On 22 July 2015 at 15:11, David Hoffer <[email protected]> wrote: > > > > > > > Apparently our communication has broken down, it seems your not > > > > understanding the issue/question. > > > > > > > > I did find that Nexus does have an API we can use for this...I sure > > wish > > > > there was a more 'packaged' solution but I've discussed it with our > IT > > > > department and between us I think we can solve this issue using that > > > > approach. If anyone knows of a better solution please let me know. > > > > > > > > -Dave > > > > > > > > On Tue, Jul 21, 2015 at 10:32 PM, Ron Wheeler < > > > > [email protected]> wrote: > > > > > > > > > If you have SNAPSHOTs specified, you will get SNAPSHOTs in the > build. > > > > > When you remove the SNAPSHOT from the parent, there should not be > any > > > way > > > > > for a SNAPSHOT to be included. > > > > > > > > > > > > > > > I am not sure where the SNAPSHOTS are being brought in to a x.x.x > > > release > > > > > unless you are allowing modules to specify the versions of their > > > > > dependencies. > > > > > Stop that. > > > > > Modules should have no versions on an dependency unless it is a > > > reference > > > > > to a property in the parent. > > > > > Modules should have no references to a version on a dependency that > > is > > > > one > > > > > of the modules that your wrote - > > <version>${project.version}</version> > > > > > > > > > > Ron > > > > > > > > > > > > > > > On 21/07/2015 11:40 PM, David Hoffer wrote: > > > > > > > > > >> 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 > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > > -- > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ------- > > > Sent from TARDIS. Typos might be a timey whyney thingy. > > > Enviado da TARDIS, podem existir erros devido à diferenças de > > espaço-tempo. > > > > > > Cintia Del Rio > > > > > > > > > -- > Adrien Rivard > -- ------- Sent from TARDIS. Typos might be a timey whyney thingy. Enviado da TARDIS, podem existir erros devido à diferenças de espaço-tempo. Cintia Del Rio
