Have you seen this article: http://blog.osgi.org/2017/02/osgi-api-snapshots-are-live.html
On 11/04/2017 16:47, Stephan Herrmann
On 11.04.2017 18:11, Cristiano Gavião wrote:
Hello Stephan, hope I have understood your
Sorry, if I was unclear.
On 11/04/2017 11:26, Stephan Herrmann
In particular: if someone references a
if you set the repository as false it won't be considered by
maven in order to looking for remote artfacts/bundles. but maven
how exactly must a snapshot be marked in order to remain
still use already downloaded ones.
Here I wasn't asking about disabling a repo, but about restricting
from it so that you only get release artifacts, not snapshots.
More precisely, what rules Maven applies when it finds the above
in a repository declaration, or: how exactly does Maven recognize
artifact as a snapshot.
Consider a company repository manager
standing between you and
if you have Nexus OSS free(https://www.sonatype.com/download-oss-sonatype),
you can start and stop a snapshot that is exposed to the
the outside, i.e., you can't directly turn on/off your
to OSSRH snapshots, but need to excluded snapshots in a given
world or internal network.
I don't operate the nexus. In that role I just need to ensure that
intended versions are fetched from it. Consider this scenario as
illustration for the above question.
and if we use thirty-part snapshot repo or
p2 bundles, what I normally used to do at dev time (briefly)
* Download the bundles from the http links provided by Eclipse
and create a local maven repository and point nexus to it (the
* create a new branch in our releng project in git where I
will change the FPOM ( a fragment POM with only
and version that I want to work). Normally I declare every
dependency, including transitive ones. Then I install those
maven snapshot repo;
* create a branch for consumer projects and change every
multi-project root pom that imports fpom to use the snapshot and
consequently all hierarchy below it will have the right
versions ( I use versions plugin for that):
Up-to this point this roughly corresponds to what I wrote about a
as a stand-in for a target platform definition. We seem to be on
the same page, good.
Thinking more about it, we might consider publishing this kind of
target platform definition
in the future, s.t. like
containing dependencyManagement with all exact versions as of
I filed https://bugs.eclipse.org/515137
In that repo I see artifacts like this:
which exhibits two variants of the version: directory mentions
artifact expands that to a time stamp. Is this artifact
by the <snapshots> element? If so, then this could help
avoid the problem
I mentioned in my first mail.
The first variation that you see is the directory. inside that
directory you can have one or more different timestamped
what defines which one is the latest is the
I know what is a directory ;p
But I still don't know how exactly versions in directory names
and/or artifact names
must be constructed to be (negatively) affected by
I'm insisting in this point, because only if this is fully
someone may publish snapshots to a global repository without
consumers who rely on receiving release artifacts only.
equinox-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit