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>
               <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 <
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




--
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

Reply via email to