Versions: debian 10.5 "buster", amd64
openjdk 11
maven 3.6.0 (debian) and 3.6.3 (apache binary) (same issue on both
versions of maven)
When I introduced a nexus-staging-maven-plugin config into my project's
top pom, "mvn deploy" of snapshots stopped w
Karl Heinz Marbaise writes:
>> I'm interested to test my current work on the latest official Maven
>> version, but also the latest snapshot (now that would be 3.6.1-SNAPSHOT).
>> Is it published and publicly available somewhere ?
>
> this could be fetched here (current master):
>
> https://builds
Hi,
On 24.01.19 13:23, François Guillot wrote:
Hi,
I'm interested to test my current work on the latest official Maven
version, but also the latest snapshot (now that would be 3.6.1-SNAPSHOT).
Is it published and publicly available somewhere ?
this could be fetched here (current master):
htt
Howdy.
there are published here
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/3.6.1-SNAPSHOT/
Thanks
T
On Thu, Jan 24, 2019 at 1:24 PM François Guillot <
francoisguillo...@gmail.com> wrote:
> Hi,
>
> I'm interested to test my
Hi,
I'm interested to test my current work on the latest official Maven
version, but also the latest snapshot (now that would be 3.6.1-SNAPSHOT).
Is it published and publicly available somewhere ?
Thanks,
François
to checkout the release
branch, but
> whatever it checks out probably still has 0.9.2.7-SNAPSHOT as the
version
> instead of 0.9.2.8
>
> Once the build things it's building a SNAPSHOT version, it has no
choice
> but to deploy to the Snapshots re
been informed at https://issues.sonatype.org/browse/OSSRH-34445
> that:
> > "The logs show that the build is trying to checkout the release branch,
> but
> > whatever it checks out probably still has 0.9.2.7-SNAPSHOT as the version
> > instead of 0.9.2.8
> >
>
e build is trying to checkout the release branch, but
whatever it checks out probably still has 0.9.2.7-SNAPSHOT as the version
instead of 0.9.2.8
Once the build things it's building a SNAPSHOT version, it has no choice
but to deploy to the Snapshots repo"
I've changed my release shel
I see that after you build the release version, you are then building the
snapshot version. It is the latter that is being uploaded:
>
> Uploaded:
> https://oss.sonatype.org/content/repositories/snapshots/io/github/pr0methean/betterrandom/BetterRandom/0.9.2.11
ding a SNAPSHOT version, it has no choice
but to deploy to the Snapshots repo"
I've changed my release shell script a little bit since then to properly
integrate the Proguard step, but I'm still having the same issue. A more
up-to-date output log is here: https://pastebin.ca/3866418 The
Also:
The command
mvn dependency:tree
may be your rescue, look for entries marked as conflicting.
- Erik
2017-04-22 9:31 GMT+02:00 Anders Hammar :
>> Nope it pick the *nearest* version.
>>
>
>> Direct dependency trumps transitive
>>
>
> And to give the full picture, if different versions are
> Nope it pick the *nearest* version.
>
> Direct dependency trumps transitive
>
And to give the full picture, if different versions are declared at the
same level in the dependency tree (typically via transitive dependencies
when you don't have a direct dep), the first declaration wins. So, the
o
On Sat 22 Apr 2017 at 00:21, Curtis Rueden wrote:
> Hi Jörg,
>
> As far as I know, Maven has no notion of "major" vs. "minor" vs. "patch"
> versions in the style of e.g. SemVer.
>
> It simply judges which version is the newest via its algorithm, and uses
> the newest, since it is assumed that a d
Hi Jörg,
As far as I know, Maven has no notion of "major" vs. "minor" vs. "patch"
versions in the style of e.g. SemVer.
It simply judges which version is the newest via its algorithm, and uses
the newest, since it is assumed that a dependency on e.g. 3.2.0 means
"version must be at least as new a
In a project 2 "different" versions of the same library A are used. One, as
a direct dependency with a snapshot version *3.2.1-SNAPSHOT* and the same
library - but with version *3.2.0* - is being used as a transient
dependency in yet another library B. So, the 2 dependencies of A only
differ in th
You're welcome Curtis, thanks for the discussion! If you want to see a live
example of this build structure check Spring-boot on GitHub.
Cheers,
S.
On Wednesday, 24 August 2016, Curtis Rueden wrote:
> Hi Christian & Stephane,
>
> Christian Schulte wrote:
> > It has never been possible to overri
Hi Christian & Stephane,
Christian Schulte wrote:
> It has never been possible to override a property in the BOM from the
> imorting POM.
Thanks Christian, I stand corrected!
So it is a consequence of the fact that my projects' managed dependency
versions previously came in through inheritance,
Am 24.08.2016 um 19:05 schrieb Curtis Rueden:
> One nuance I do not discuss is how importing a BOM under the new scheme now
> resolves all version properties, such that overriding them in the consuming
> POM has no effect anymore. I still feel this is a bug (or at least
> undesired quality) of the
Hi everyone,
For those who just can't get enough Maven BOM goodness, here are a couple
of threads in my community (SciJava/ImageJ/Fiji) where we are discussing
the impact these changes will have for us:
* http://forum.imagej.net/t/maven-3-4-0-may-break-imagej-
and-fiji-project-builds/2471/2
* htt
Hi Robert,
> Keep in mind that Maven is not the only tool/application using the
> pom.xml. Some of them probably never check the xsd or the
> modelVersion, so we need to be very carefull with this.
Are there specific tools in mind which you believe would be broken by the
4.1.0 model bump? If no o
Am 08/21/16 um 16:35 schrieb Christian Schulte:
> There is no other proposal I can make.
Call the new behaviour 'include' scope and both scopes could co-exist. I
forgot the name of that person who said it's not possible to introduce a
new scope in 3.4.0 :-)
Regards,
--
Christian
--
Am 08/21/16 um 14:36 schrieb Robert Scholte:
> Hi,
>
> Keep in mind that Maven is not the only tool/application using the pom.xml.
Do they implement the import scope feature themselves?
> Some of them probably never check the xsd or the modelVersion, so we need
> to be very carefull with this.
Hi,
Keep in mind that Maven is not the only tool/application using the pom.xml.
Some of them probably never check the xsd or the modelVersion, so we need
to be very carefull with this.
If we introduce a new major modelVersion, that should probably result in a
new file including a backported t
Am 08/21/16 um 00:30 schrieb Mark Derricutt:
> Christian, is there anywhere describing what changes there are/or planned
> in Model version 4.1.0 at all?
Nothing is documented yet. There have never been any plans. It's more
about having to revert a bunch of useful things to stay backwards
compatib
Christian, is there anywhere describing what changes there are/or planned
in Model version 4.1.0 at all?
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
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-plugi
w 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 c
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
"requireReproducible
Am Tue, 21 Jul 2015 23:00:12 +0300
schrieb Alex Ditu :
> I am not sure if it
> is a specific artifactory issue, I found this:
> https://www.jfrog.com/jira/browse/RTFACT-5404 if it helps
Yes, if the repo does not provide the timestamps, then the policy wont
work. You can purge your
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'
>> 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>
kaged' 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:
imple 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 wrote:
> Hi,
>
> Nexus has some tasks to she
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 wrote:
> Yeah, that&#x
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
fline 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 d
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 t
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
;>> 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 h
n 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 t
ion 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
s 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 hav
t 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=artifa
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 SNAPSHO
Hello,
not sure if you are asking about the general handling or a specific
problem with Artifactory. But with mvn you can use the -U switch to
force a snapshot update.
Otherwise it will use the updatePolicy from
your settings.xml (I think "daily" would be the default for snapshots
rep
Hello,
I am new to maven and do not know how to solve this issue: I decided
not to keep timestampped artifacts in Aritfactory but now maven is not
downloading newer artifacts from Artifactory, although in metadata the
versions differ.
I do not want to manually delete my local copy of an artifact
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
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 Hein
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, J
gt; > 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
> >
>
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
>
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
ah, that works with a project, in my case, i prefer not to have a project
On Tue, Aug 19, 2014 at 8:07 PM, Mark Derricutt wrote:
> Nope, it's takes the dependencies from your project pom.xml:
>
>mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId
>
> Mark
>
> On 20 Aug 20
Nope, it's takes the dependencies from your project pom.xml:
mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId
Mark
On 20 Aug 2014, at 14:11, Dan Tran wrote:
> the problem here is I have to enter artifactId, am I missing any thing?
> specially for a developer who is very
the problem here is I have to enter artifactId, am I missing any thing?
specially for a developer who is very clueless about Maven
-D
On Tue, Aug 19, 2014 at 7:09 PM, Mark Derricutt wrote:
> So not using the dependency plugin like I suggested?
>
> On 20 Aug 2014, at 10:14, Dan Tran wrote:
>
>
So not using the dependency plugin like I suggested?
On 20 Aug 2014, at 10:14, Dan Tran wrote:
> After all consideration. I use Ron's advice and create a internal plugin
> to clean it up.
-
To unsubscribe, e-mail: users-unsubsc
After all consideration. I use Ron's advice and create a internal plugin
to clean it up.
-D
On Tue, Aug 19, 2014 at 6:06 AM, Ron Wheeler wrote:
> On 19/08/2014 1:49 AM, Barrie Treloar wrote:
>
>> What's wrong with just blowing away ~/.m2/repository ?
>>
>> If you have a local Maven Repository
On 19/08/2014 1:49 AM, Barrie Treloar wrote:
What's wrong with just blowing away ~/.m2/repository ?
If you have a local Maven Repository Manager it doesn't take very long to
reseed it.
(At least less time in aggregate than thinking of ways to prune snapshot
files in the repository correctly...)
What's wrong with just blowing away ~/.m2/repository ?
If you have a local Maven Repository Manager it doesn't take very long to
reseed it.
(At least less time in aggregate than thinking of ways to prune snapshot
files in the repository correctly...)
h it's could contain releases (and snapshots).
Such a artifactId naming is not very good and kind of deserves to cause
issues though...
/Anders
On Tue, Aug 19, 2014 at 7:28 AM, Dan Tran wrote:
> This would not work, since it still leave all snapshot of timestamp around
>
> -D
>
>
&
d option.
> >
> > Thanks
> >
> > -D
> >
> >
> > On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler <
> > rwhee...@artifact-software.com> wrote:
> >
> > > On 17/08/2014 1:50 AM, Dan Tran wrote:
> > >
> > >> Hi I need to
I tend to use:
mvn dependency:purge-local-repository
when sitting in a project directory, it'll go thru and delete all the
SNAPSHOTs and re-resolve.
The only problem with it in the default mode, is that is _only_ deletes
the `.jar`. files and doesn't rebuild any metadata, so
> On 17/08/2014 1:50 AM, Dan Tran wrote:
> >
> >> Hi I need to find a way to walk into local repository and remove all old
> >> snapshots.
> >>
> >> This is very helpful for developer to clean up his/her local rep.
> >>
> >> how
sounds like a good option.
Thanks
-D
On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:
> On 17/08/2014 1:50 AM, Dan Tran wrote:
>
>> Hi I need to find a way to walk into local repository and remove all old
>> snapshots.
>&g
On 17/08/2014 1:50 AM, Dan Tran wrote:
Hi I need to find a way to walk into local repository and remove all old
snapshots.
This is very helpful for developer to clean up his/her local rep.
how safe it is by blindly remove any file with timestamp format ( ie
xxx-1.0.0-20140816.071953-49.jar
Hi I need to find a way to walk into local repository and remove all old
snapshots.
This is very helpful for developer to clean up his/her local rep.
how safe it is by blindly remove any file with timestamp format ( ie
xxx-1.0.0-20140816.071953-49.jar)?
Thanks
-D
ubject: Spring snapshots
> From: alexander.g.kai...@gmail.com
> To: users@maven.apache.org
>
> Hi,
>
> I am trying to understand mavens downloading of snapshots (maven 3.0.4,
> vanilla install)
>
> I use only spring RELEASE (3.1.4.RELEASE) builds in my pom and I have no
&g
Hi Karl,
thanks for your reply.
No, there are no repository definitions in settings.xml.
Alex
2014-05-01 14:31 GMT+02:00 Karl Heinz Marbaise :
> Hi,
>
> > Hi,
>
>
>> I use only spring RELEASE (3.1.4.RELEASE) builds in my pom and I have no
>> repository definitions in the pom.
>>
>
> Do you ha
Most likely somewhere in that spring dependency tree is a version range...
you could use dependency management to pin that to a non-range version
On 1 May 2014 12:58, Alexander Kaiser wrote:
> Hi,
>
> I am trying to understand mavens downloading of snapshots (maven 3.0.4,
> van
Hi,
> Hi,
I use only spring RELEASE (3.1.4.RELEASE) builds in my pom and I have no
repository definitions in the pom.
Do you have repository definitions in your settings.xml file ?
--
Kind regards
Karl-Heinz Marbaise
-
To
Hi,
I am trying to understand mavens downloading of snapshots (maven 3.0.4,
vanilla install)
I use only spring RELEASE (3.1.4.RELEASE) builds in my pom and I have no
repository definitions in the pom.
When I display the dependency tree with mvn dependency:tree I also see that
my project has no
s got better described.
Ron
On 29/03/2014 12:50 AM, ghostwolf59 wrote:
So if I understand correctly you want to use SNAPSHOTs because:
- you don't want the artifact to end up in the "releases"-repository yes,
correct
because QA needs to be done first
Not quite - occasionall
> So if I understand correctly you want to use SNAPSHOTs because:
> - you don't want the artifact to end up in the "releases"-repository yes,
correct
> because QA needs to be done first
Not quite - occasionally projects (still in development state but nearing
its end
> Let me join this thread, because that "someone" is me. As said by Stephen:
> the version handling prior to 2.4 contained several issues, so you were
> relying on a bug.
Reminds me of this classic XKCD... :)
https://xkcd.com/1172/
Wayne
--
ritical (mind you these test phases is done before
even taken the app to UAT - technically still in a development phase).
Allowing these "formal" snapshots releases to be released into the
snapshot
repo can hardly affect the normal behavior of releasing local builds
(without any const
or the new branch (and both should be used for
> ongoing development so should be snapshots...)
>
> /James
>
> > -Original Message-
> > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > Sent: 28 March 2014 13:32
> > To: Maven Users List
>
So if I understand correctly you want to use SNAPSHOTs because:
- you don't want the artifact to end up in the "releases"-repository yes,
because QA needs to be done first
- SNAPSHOTs are cleaned up automatically, so if QA doesn't accept a
release, it's cleaned u
Fully agree but with a snapshot not should be treated an release.
The concept of "official snapshots" along with full site info and branch
tagging don't seem wrong where I come from.
If a project going through some stringent QA where formal test teams want to
keep track of wh
shouldn't release:branch still support this still though?
If not that's bad as you will end up with a release version on the head of
either the source branch or the new branch (and both should be used for ongoing
development so should be snapshots...)
/James
> -Ori
implementing formal test signoffs where exact version
tested against become critical (mind you these test phases is done before
even taken the app to UAT - technically still in a development phase).
Allowing these "formal" snapshots releases to be released into the snapshot
repo can hardly
ven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.1.jpg
> >
>
> <
> http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.jpg
> >
>
>
>
>
>
> -
> good @ being sucked @
> --
> View this message in
rompt-v.2.4.2.jpg>
<http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.1.jpg>
<http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.jpg>
-
good @ being sucked @
--
View this message in context:
http://maven.40175.n5.na
g this.
>
> Using v.2.2.2 allow me to overwrite this with anything that then takes me
> to
> the scm prompt and so on - which ultimately allow me to do what I really
> want.
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-release-plugi
t:
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789868.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.or
On 28 March 2014 11:12, ghostwolf59 wrote:
> 2.2.2
Then you are not using version 2.5
ge in context:
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789843.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-uns
-
> does
> anyone know how this can be done using the most recent
> maven-release-plugin?
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> --
> Baptiste MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
ge in context:
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837.html
Sent from the Maven - Users mailing list archive at Nabble.com.
It seems there is no way in the copy-dependencies goal to exclude snapshot
dependencies. Can anyone think of a way to accomplish this using some kind
of workaround? I want to copy all the released dependencies only. I'm
using OSGi+pde and I want to create my target platform with released
depend
> I got them to "force" to update to the latest remote snapshot using
> "mvn -U …", which I assume is the maven way?
Well, the first thing I would check knowing that -U does the update is
the configuration of your repo in your settings.xml. I bet you want an
update policy more like "always" and it
Hi Wayne,
I got them to "force" to update to the latest remote snapshot using "mvn -U …",
which I assume is the maven way?
My next questions is: inside the plugin code, how can it know for a given
artifact that it has been updated from remote since the last time the plugin
ran? It seems like
> Sure! It is Sonatype Nexus.
Can you (easily) construct a test case where you push a snapshot of
something in using just the GAV (no C) and then pull it back it with
your plugin code, then rinse and repeat a few times to confirm it
either works or fails *without* any classifiers?
Then you should
Sure! It is Sonatype Nexus.
Patrick
On Mar 18, 2013, at 3:59 PM, Wayne Fay wrote:
>> Interesting. I haven't watched the network traffic yet, but I have checked
>> the
>> metadata that is cached on the local repository for the artifact[s] in
>> question
>> and they are not up to date based on
> Interesting. I haven't watched the network traffic yet, but I have checked the
> metadata that is cached on the local repository for the artifact[s] in
> question
> and they are not up to date based on the latest timestamp I know to exist on
> the remote snapshot repository.
I meant to ask, wha
Interesting. I haven't watched the network traffic yet, but I have checked the
metadata that is cached on the local repository for the artifact[s] in question
and they are not up to date based on the latest timestamp I know to exist on
the remote snapshot repository.
I haven't tried your sugges
> The problem is, when one of these is a snapshot, the plugin doesn't
> bother to check with the remote repository for an update snapshot. If it
> sees it in the local repository, it simply goes about its business. Is this
> an acceptable method for pulling in platform-specific native packages? If
d as I'd expect them to be (unlike the former method, which
would check for a snapshot if it isn't in the local, but will never check for
updated snapshots with same version), but I can't figure out how to tell the
plugin that a new snapshot has been downloaded so it knows to do the
Am 23.02.2013 21:21, schrieb Baptiste MATHUS:
Hi Joachim,
Could you please tell us the URL of the page(s) you read where you think
this information would have been valuable?
We can improve it.
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#updateReleaseInfo
-
on-unique snapshots.
>>
>
> This should be documented in the plugin's docs.
> I wasted half an afternoon trying to get this to work, and that was just
> for me.
>
> There's an option on the repository in Artifactory that can restore that
> behaviour.
> I gue
mvn package/install will always build unique artifacts locally.
The unique artifacts option is only used when deploying (i.e. mvn deploy).
Using a repository manager, this is actually not really an issue: just
configure it to remove old snapshots (with nexus, it's called Scheduled
Tasks, I
1 - 100 of 743 matches
Mail list logo
