Re: How to delete certain snapshots from Nexus
Hi Curtis,
First I want to say this plugin works great, I added it to the build and it
caught a number of issues before we went to release.
I do have a few questions. First I'm not sure I have it fully configured
correctly, my usage is below. With this usage it found all the cases where
the build was consuming a snapshot not being generated in the reactor which
is exactly what I was looking for.
There are a few other options I need as well and was hoping you could
provide some guidance on how to support them.
1. I didn't set requireReproducibleBuilds as I wasn't sure how or if that
is done internally by the verify-no-snapshots goal. (Worked really well
w/o setting it.)
2. How to skip per pom? I didn't see any skip configuration option so as a
workaround I set the groupId in configuration to be 'skip' and that works.
3. How to disable globally via command line argument? I tried
-Denforcer.skip=true but it doesn't seem to work...still testing that again.
4. How to exclude a few groupIds from enforcement? We have a couple cases
where we do consume an approved snapshot so I need a way to configure
allowed snapshot groupIds.
5. How to ignore certain points of failure such as a artifact pom (not a
snapshot one) that has two organizational sections currently causes a build
failure, I'd like to just warn on those types of issues.
Again, works super well but I just need to tweak its configuration a bit.
plugin
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
dependencies
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdextra-enforcer-rules/artifactId
version1.0-beta-3/version
/dependency
dependency
groupIdorg.scijava/groupId
artifactIdscijava-maven-plugin/artifactId
version${scijava-maven-plugin.version}/version
/dependency
/dependencies
/plugin
plugin
groupIdorg.scijava/groupId
artifactIdscijava-maven-plugin/artifactId
executions
execution
idverify-no-nonreactor-snapshots/id
phasevalidate/phase
goals
goalverify-no-snapshots/goal
/goals
configuration
/configuration
/execution
/executions
/plugin
On Wed, Jul 22, 2015 at 10:12 PM, Curtis Rueden ctrue...@wisc.edu wrote:
Hi Dave,
if you have a plugin that solves the same problem that is fine.
If you could elaborate on your solution that would be great.
The plugin I mentioned, scijava-maven-plugin [1], has a
verify-no-snapshots goal—and corresponding enforcer rule
requireReproducibleBuilds—which is more thorough than the enforcer's
built-in no snapshots rule: it recursively scans dependencies for
snapshot dependencies and parents, and fails the build if any are found.
This is important because some releases on Maven Central are actually
tainted, containing snapshot dependencies somewhere upstream.
My group's projects use one Git repo = one single-module Maven project =
one JAR file. Projects use release couplings between components so that
builds are reproducible [2]. We avoid multi-module builds because they are
more complex and make it harder to release components individually
[3]—although it is still possible [4]. The requireReproducibleBuilds rule
understands multi-module builds and will not fail the build unless there is
a snapshot dependency outside the reactor.
The requireReproducibleBuilds rule would go a long way toward solving your
use case, but might not catch every scenario such as old GAVs referenced
from an unpack goal config. However, the proper way to solve that is to
declare version properties in the parent for all your GAs, then use those
properties everywhere that version is needed. E.g.:
-
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L133-L134
-
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L815-L819
-
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L1094-L1099
Then your chances of out-of-sync versions will be drastically reduced.
Regards,
Curtis
[1] https://github.com/scijava/scijava-maven-plugin
[2] http://imagej.net/Reproducible_builds
[3] http://imagej.net/Philosophy#Release_early.2C_release_often
[4] We do have one exception (https://github.com/trakem2/TrakEM2) which is
a multi-module build, but with separately versioned components. Cutting a
release of (some subset of) those modules is unintuitive:
- We comment out the irrelevant modules in the aggregator POM (which
doubles as the parent POM), leaving only the modules to be released; then
- bump the versions of those modules forward to their new release versions;
and
- bump the version properties of the not-being-released modules _backward_
to their last release versions.
Then the (reduced in size) reactor has no snapshot dependencies in the
released modules. But we cannot release in this
Re: How to delete certain snapshots from Nexus
Hi Dave,
1. I didn't set requireReproducibleBuilds as I wasn't sure how or if
that is done internally by the verify-no-snapshots goal. (Worked
really well w/o setting it.)
Use either the verify-no-snapshots goal (as you are doing now), _or_ the
scijava-maven-plugin as a set of extra enforcer rules. You don't need both.
The latter is nice if you are already using enforcer and want to keep all
those sorts of checks together. Here is how my projects configure the
enforcer:
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L1112-L1221
You of course wouldn't need all those rules. The important block is:
requireReproducibleBuilds
implementation=org.scijava.maven.plugin.RequireReproducibleBuilds
groupIdsorg.scijava/groupIds
/requireReproducibleBuilds
Replacing groupIds with the groupIds you want to check.
2. How to skip per pom? I didn't see any skip configuration option
so as a workaround I set the groupId in configuration to be 'skip'
and that works.
That seems like a reasonable workaround.
If you want to add a more proper skip flag, PRs are warmly welcomed. :-)
3. How to disable globally via command line argument? I tried
-Denforcer.skip=true but it doesn't seem to work...still testing that
again.
If you use the requireReproducibleBuilds rule of the enforcer, instead of
binding the verify-no-snapshots goal, then -Denforcer.skip=true will do
the job for you. That's how we skip it during local development. Of course,
this skips _all_ enforcer checks, so would be highly discouraged for
production.
4. How to exclude a few groupIds from enforcement? We have a couple
cases where we do consume an approved snapshot so I need a way to
configure allowed snapshot groupIds.
Yeah, there's an open issue for that:
https://github.com/scijava/scijava-maven-plugin/issues/8
5. How to ignore certain points of failure such as a artifact pom (not
a snapshot one) that has two organizational sections currently causes
a build failure, I'd like to just warn on those types of issues.
Hmm, this may be another use case for issue #8 linked above. If you had
full GA(V) include/exclude filtering, you could filter out that particular
POM from consideration.
Again, works super well but I just need to tweak its configuration a
bit.
Really glad to hear it is helpful!
Regards,
Curtis
On Fri, Jul 24, 2015 at 11:55 AM, David Hoffer dhoff...@gmail.com wrote:
Hi Curtis,
First I want to say this plugin works great, I added it to the build and it
caught a number of issues before we went to release.
I do have a few questions. First I'm not sure I have it fully configured
correctly, my usage is below. With this usage it found all the cases where
the build was consuming a snapshot not being generated in the reactor which
is exactly what I was looking for.
There are a few other options I need as well and was hoping you could
provide some guidance on how to support them.
1. I didn't set requireReproducibleBuilds as I wasn't sure how or if that
is done internally by the verify-no-snapshots goal. (Worked really well
w/o setting it.)
2. How to skip per pom? I didn't see any skip configuration option so as a
workaround I set the groupId in configuration to be 'skip' and that works.
3. How to disable globally via command line argument? I tried
-Denforcer.skip=true but it doesn't seem to work...still testing that
again.
4. How to exclude a few groupIds from enforcement? We have a couple cases
where we do consume an approved snapshot so I need a way to configure
allowed snapshot groupIds.
5. How to ignore certain points of failure such as a artifact pom (not a
snapshot one) that has two organizational sections currently causes a build
failure, I'd like to just warn on those types of issues.
Again, works super well but I just need to tweak its configuration a bit.
plugin
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
dependencies
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdextra-enforcer-rules/artifactId
version1.0-beta-3/version
/dependency
dependency
groupIdorg.scijava/groupId
artifactIdscijava-maven-plugin/artifactId
version${scijava-maven-plugin.version}/version
/dependency
/dependencies
/plugin
plugin
groupIdorg.scijava/groupId
artifactIdscijava-maven-plugin/artifactId
executions
execution
idverify-no-nonreactor-snapshots/id
phasevalidate/phase
goals
goalverify-no-snapshots/goal
/goals
configuration
/configuration
/execution
/executions
/plugin
On Wed, Jul 22, 2015 at 10:12 PM, Curtis Rueden ctrue...@wisc.edu wrote:
Hi Dave,
if you have a plugin that solves the same problem that is fine.
If you could elaborate on your solution that would
Re: How to delete certain snapshots from Nexus
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 adrien.riv...@gmail.com 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 dhoff...@gmail.com 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
miladyarte...@gmail.com
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 dhoff...@gmail.com 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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.
Re: How to delete certain snapshots from Nexus
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 miladyarte...@gmail.com
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 dhoff...@gmail.com 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
Re: How to delete certain snapshots from Nexus
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 dhoff...@gmail.com 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 miladyarte...@gmail.com
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 dhoff...@gmail.com 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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.
Re: How to delete certain snapshots from Nexus
Glad you have found a solution even if I can not understand the source
of the problem.
It does not seem to a general problem which is why you have to develop a
custom solution.
This is a pretty big mailing list and attracts a lot of experienced
developers and if there was a general solution, someone would have
chimed in by now.
Good luck.
Ron
On 22/07/2015 1:11 AM, David Hoffer 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
rwhee...@artifact-software.com
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
Re: How to delete certain snapshots from Nexus
Hi Dave, if you have a plugin that solves the same problem that is fine. If you could elaborate on your solution that would be great. The plugin I mentioned, scijava-maven-plugin [1], has a verify-no-snapshots goal—and corresponding enforcer rule requireReproducibleBuilds—which is more thorough than the enforcer's built-in no snapshots rule: it recursively scans dependencies for snapshot dependencies and parents, and fails the build if any are found. This is important because some releases on Maven Central are actually tainted, containing snapshot dependencies somewhere upstream. My group's projects use one Git repo = one single-module Maven project = one JAR file. Projects use release couplings between components so that builds are reproducible [2]. We avoid multi-module builds because they are more complex and make it harder to release components individually [3]—although it is still possible [4]. The requireReproducibleBuilds rule understands multi-module builds and will not fail the build unless there is a snapshot dependency outside the reactor. The requireReproducibleBuilds rule would go a long way toward solving your use case, but might not catch every scenario such as old GAVs referenced from an unpack goal config. However, the proper way to solve that is to declare version properties in the parent for all your GAs, then use those properties everywhere that version is needed. E.g.: - https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L133-L134 - https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L815-L819 - https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L1094-L1099 Then your chances of out-of-sync versions will be drastically reduced. Regards, Curtis [1] https://github.com/scijava/scijava-maven-plugin [2] http://imagej.net/Reproducible_builds [3] http://imagej.net/Philosophy#Release_early.2C_release_often [4] We do have one exception (https://github.com/trakem2/TrakEM2) which is a multi-module build, but with separately versioned components. Cutting a release of (some subset of) those modules is unintuitive: - We comment out the irrelevant modules in the aggregator POM (which doubles as the parent POM), leaving only the modules to be released; then - bump the versions of those modules forward to their new release versions; and - bump the version properties of the not-being-released modules _backward_ to their last release versions. Then the (reduced in size) reactor has no snapshot dependencies in the released modules. But we cannot release in this fashion using the maven-release-plugin, unfortunately. So there are lots of downsides. The upside is that you maintain a reproducible build on master always, with tightly coupled modules normally, and proper release couplings for each set of released modules. On Wed, Jul 22, 2015 at 9:49 AM, David Hoffer dhoff...@gmail.com wrote: Hi Curtis, Yes that is the issue I'm trying to solve, except that we are less formal than your description implies. We don't have 'approved' and 'non-approved' snapshots, rather we have valid ones and ones made obsolete by the refactor. Leaning on Nexus doesn't seem like a bad solution as after the refactor, as it does no one any good (including Nexus) to continue to retain the old artifacts, it would just clean things up if they could be deleted. That being said...if you have a plugin that solves the same problem that is fine. If you could elaborate on your solution that would be great. I'd actually prefer to 'fix' this in the pom rather than Nexus as our Nexus is managed by IT and it's difficult for devs to get more than read privileges. -Dave On Wed, Jul 22, 2015 at 8:24 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Dave, This problem strikes me as just a particular incarnation of make sure only approved deps are used where old snapshot versions of 1st party modules are no longer approved after a refactoring. As such, I would suggest looking for tools intended to support such dependency analysis more generally, rather than leaning on Nexus in the way you are trying to do. I personally also prefer no snapshot deps ever outside the reactor, as it will result in irreproducible builds. My group actually wrote an enforcer rule to detect exactly that situation; it is part of the scijava-maven-plugin. Happy to elaborate if you are interested. -Curtis On Jul 22, 2015 8:47 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Glad you have found a solution even if I can not understand the source of the problem. It does not seem to a general problem which is why you have to develop a custom solution. This is a pretty big mailing list and attracts a lot of experienced developers and if there was a general solution, someone would have chimed in by now. Good luck. Ron On 22/07/2015 1:11 AM, David Hoffer wrote: Apparently our communication has broken
Re: How to delete certain snapshots from Nexus
Hi Curtis,
Yes that is the issue I'm trying to solve, except that we are less formal
than your description implies. We don't have 'approved' and 'non-approved'
snapshots, rather we have valid ones and ones made obsolete by the
refactor.
Leaning on Nexus doesn't seem like a bad solution as after the refactor, as
it does no one any good (including Nexus) to continue to retain the old
artifacts, it would just clean things up if they could be deleted. That
being said...if you have a plugin that solves the same problem that is
fine. If you could elaborate on your solution that would be great. I'd
actually prefer to 'fix' this in the pom rather than Nexus as our Nexus is
managed by IT and it's difficult for devs to get more than read privileges.
-Dave
On Wed, Jul 22, 2015 at 8:24 AM, Curtis Rueden ctrue...@wisc.edu wrote:
Hi Dave,
This problem strikes me as just a particular incarnation of make sure only
approved deps are used where old snapshot versions of 1st party modules
are no longer approved after a refactoring.
As such, I would suggest looking for tools intended to support such
dependency analysis more generally, rather than leaning on Nexus in the way
you are trying to do.
I personally also prefer no snapshot deps ever outside the reactor, as it
will result in irreproducible builds. My group actually wrote an enforcer
rule to detect exactly that situation; it is part of the
scijava-maven-plugin. Happy to elaborate if you are interested.
-Curtis
On Jul 22, 2015 8:47 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:
Glad you have found a solution even if I can not understand the source of
the problem.
It does not seem to a general problem which is why you have to develop a
custom solution.
This is a pretty big mailing list and attracts a lot of experienced
developers and if there was a general solution, someone would have chimed
in by now.
Good luck.
Ron
On 22/07/2015 1:11 AM, David Hoffer 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
Re: How to delete certain snapshots from Nexus
Hi Dave,
This problem strikes me as just a particular incarnation of make sure only
approved deps are used where old snapshot versions of 1st party modules
are no longer approved after a refactoring.
As such, I would suggest looking for tools intended to support such
dependency analysis more generally, rather than leaning on Nexus in the way
you are trying to do.
I personally also prefer no snapshot deps ever outside the reactor, as it
will result in irreproducible builds. My group actually wrote an enforcer
rule to detect exactly that situation; it is part of the
scijava-maven-plugin. Happy to elaborate if you are interested.
-Curtis
On Jul 22, 2015 8:47 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:
Glad you have found a solution even if I can not understand the source of
the problem.
It does not seem to a general problem which is why you have to develop a
custom solution.
This is a pretty big mailing list and attracts a lot of experienced
developers and if there was a general solution, someone would have chimed
in by now.
Good luck.
Ron
On 22/07/2015 1:11 AM, David Hoffer 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
Re: How to delete certain snapshots from Nexus
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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 rwhee...@artifact-software.com
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 khmarba...@gmx.de
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to delete certain snapshots from Nexus
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 rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
rwhee...@artifact-software.com
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
khmarba...@gmx.de
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail:
Re: How to delete certain snapshots from Nexus
Nexus tasks ? Jeff Le 21 juil. 2015 18:03, David Hoffer dhoff...@gmail.com a écrit : 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. 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
Re: How to delete certain snapshots from Nexus
Our IT group handles managing Nexus and they say there is no Nexus interface/feature to do this. The last time we requested this they ended up deleting these directly on the file system. Ideally I'd like to find a way developers could do this, either using a Maven plugin or something similar, or by a Nexus API if that exists. -Dave On Tue, Jul 21, 2015 at 12:07 PM, Jeff MAURY jeffma...@jeffmaury.com wrote: Nexus tasks ? Jeff Le 21 juil. 2015 18:03, David Hoffer dhoff...@gmail.com a écrit : 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. 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
Re: How to delete certain snapshots from Nexus
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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
rwhee...@artifact-software.com
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
Re: How to delete certain snapshots from Nexus
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 rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
rwhee...@artifact-software.com
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
khmarba...@gmx.de
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..
Re: How to delete certain snapshots from Nexus
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 dhoff...@gmail.com 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
rwhee...@artifact-software.com 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
rwhee...@artifact-software.com
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
rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
Re: How to delete certain snapshots from Nexus
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 rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
rwhee...@artifact-software.com
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
khmarba...@gmx.de
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: How to delete certain snapshots from Nexus
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 rwhee...@artifact-software.com
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
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/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
rwhee...@artifact-software.com
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
khmarba...@gmx.de
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: How to delete certain snapshots from Nexus
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 khmarba...@gmx.de 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to delete certain snapshots from Nexus
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to delete certain snapshots from Nexus
Hi Dave, Our IT group handles managing Nexus and they say there is no Nexus interface/feature to do this. You can use the Remove Snapshots from Repository scheduled task. See: https://books.sonatype.com/nexus-book/reference/scheduled-tasks.html Regards, Curtis On Tue, Jul 21, 2015 at 1:20 PM, David Hoffer dhoff...@gmail.com wrote: Our IT group handles managing Nexus and they say there is no Nexus interface/feature to do this. The last time we requested this they ended up deleting these directly on the file system. Ideally I'd like to find a way developers could do this, either using a Maven plugin or something similar, or by a Nexus API if that exists. -Dave On Tue, Jul 21, 2015 at 12:07 PM, Jeff MAURY jeffma...@jeffmaury.com wrote: Nexus tasks ? Jeff Le 21 juil. 2015 18:03, David Hoffer dhoff...@gmail.com a écrit : 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. 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
Re: How to delete certain snapshots from Nexus
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. 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 rwhee...@artifact-software.com 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 khmarba...@gmx.de 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to delete certain snapshots from Nexus
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 khmarba...@gmx.de 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
