Maven snapshot repository available ?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Maven snapshot repository available ?

Cristiano Gavião

Hello all,

recently I discovered that equinox and platform released bundles are finally being deployed at maven central repository. 

I got very happy to see that happen and would like to thank the responsible for this !

Certainly this will bring a great improvement to my building process which do not use tycho nor p2.

But I also need to build and test against the latest bundles. So, is a snapshot repository being generated anywhere ?


thanks,

Cristiano


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Jonah Graham
Hi Cristiano,

AFAIK the bundles are being pushed as part of the Platform release
cycle, after aggregation rather than from the equinox builds
themselves.

Stephan Herrmann has been doing that work and has written it up on the
mailing list[1], wiki[2] and did a blog post[3] about it.

However that does not answer your snapshot question, perhaps it will
give you the information on where to obtain the information?

[1] https://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg10352.html
[2] https://wiki.eclipse.org/Platform-releng/Publish_To_Maven_Central
[3] https://objectteams.wordpress.com/2017/01/09/eclipse-neon-2-is-on-maven-central/

HTH
Jonah



~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 10 April 2017 at 12:52, Cristiano Gavião <[hidden email]> wrote:

> Hello all,
>
> recently I discovered that equinox and platform released bundles are finally
> being deployed at maven central repository.
>
> I got very happy to see that happen and would like to thank the responsible
> for this !
>
> Certainly this will bring a great improvement to my building process which
> do not use tycho nor p2.
>
> But I also need to build and test against the latest bundles. So, is a
> snapshot repository being generated anywhere ?
>
>
> thanks,
>
> Cristiano
>
>
> _______________________________________________
> equinox-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Stephan Herrmann-2
Let me directly add some words of caution:

When pushing Eclipse artifacts to Maven Central we convert
OSGi 4 part versions to 3 part versions as suitable for a Maven Release.

When anybody starts to publish snapshots they should be very
careful in testing that snapshots don't interfere with builds
requesting a release version. Example: [4.6.0,4.7.0) should
select any of 4.6.1, 4.6.2 ... but *not* 4.7.0.
As soon as a snapshot exists, e.g., as 4.7.0.v2017040112000
then this version would be considered (by some maven versions)
as < 4.7.0 and thus be picked via the above version range.
Client builds using Maven may not customarily use such version
ranges, but dependencies among Eclipse artifacts do make use
of semantic versioning and thus could be wired in incompatible
ways.

One way around this, *might* be to publish / consume snapshots
only via repo.eclipse.org, not Maven Central. This would leave
the due diligence to consumers, who only have to ensure that
artifacts from repo.eclipse.org don't accidentally creep into
release builds via their local maven repository.

Another way, might be to enhance the aggregator to create literally
4.7.0-SNAPSHOT versions (no qualifier expansion). So far, however,
I don't see huge demand for this.

Yep, there's plenty of ways how Maven can get confused (to say
the least) about mavenized OSGi artifacts.

cheers,
Stephan


On 11.04.2017 10:50, Jonah Graham wrote:

> Hi Cristiano,
>
> AFAIK the bundles are being pushed as part of the Platform release
> cycle, after aggregation rather than from the equinox builds
> themselves.
>
> Stephan Herrmann has been doing that work and has written it up on the
> mailing list[1], wiki[2] and did a blog post[3] about it.
>
> However that does not answer your snapshot question, perhaps it will
> give you the information on where to obtain the information?
>
> [1] https://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg10352.html
> [2] https://wiki.eclipse.org/Platform-releng/Publish_To_Maven_Central
> [3] https://objectteams.wordpress.com/2017/01/09/eclipse-neon-2-is-on-maven-central/
>
> HTH
> Jonah
>
>
>
> ~~~
> Jonah Graham
> Kichwa Coders Ltd.
> www.kichwacoders.com
>
>
> On 10 April 2017 at 12:52, Cristiano Gavião <[hidden email]> wrote:
>> Hello all,
>>
>> recently I discovered that equinox and platform released bundles are finally
>> being deployed at maven central repository.
>>
>> I got very happy to see that happen and would like to thank the responsible
>> for this !
>>
>> Certainly this will bring a great improvement to my building process which
>> do not use tycho nor p2.
>>
>> But I also need to build and test against the latest bundles. So, is a
>> snapshot repository being generated anywhere ?
>>
>>
>> thanks,
>>
>> Cristiano
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> [hidden email]
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>

_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Andreas Sewe
Hi Stephan.,

> Let me directly add some words of caution:

all good advice...

> When pushing Eclipse artifacts to Maven Central we convert
> OSGi 4 part versions to 3 part versions as suitable for a Maven Release.
>
> When anybody starts to publish snapshots they should be very
> careful in testing that snapshots don't interfere with builds
> requesting a release version. Example: [4.6.0,4.7.0) should
> select any of 4.6.1, 4.6.2 ... but *not* 4.7.0.
> As soon as a snapshot exists, e.g., as 4.7.0.v2017040112000
> then this version would be considered (by some maven versions)
> as < 4.7.0 and thus be picked via the above version range.
> Client builds using Maven may not customarily use such version
> ranges, but dependencies among Eclipse artifacts do make use
> of semantic versioning and thus could be wired in incompatible
> ways.
...but why does publishing to central use version ranges in Maven
dependencies on the first place?

I get that these are a more truthful translation of the original OSGi
manifests *but* AFAIK they not only suffer from the above problem but
also make you build irreproducible; as Maven's "target platform" is
"whatever is in Maven Central" at the moment, what a version range
resolves to may change over time. IIRC, using version ranges are
considered to be a bad practice by the Maven developers themselves for
the latter reason.

Best wishes,

Andreas

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Cristiano Gavião
In reply to this post by Stephan Herrmann-2



On 11/04/2017 09:42, Stephan Herrmann wrote:
One way around this, *might* be to publish / consume snapshots
only via repo.eclipse.org, not Maven Central.

In my vision, the better approach is to publish into maven central repository only the released versions of bundles.

Bundles that are part of any M# or RC# should be deployed using a full timestamp (ex: 4.7.0.v2017040112000 ), but into a different repository, a snapshot only one.
Sonatype provides one: https://oss.sonatype.org/content/repositories/snapshots/ and its process is described here (http://central.sonatype.org/pages/ossrh-guide.html)

About the range issues. I think that the use of version range in maven builds is not trustworthy, so I don't use them.
But I have in my build process a plugin that generates a R5 index repository from the maven based bundles dependencies and I use those repositories to setup one or more test osgi containers that allows me safely use version range when necessary.

regards,

Cristiano


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Stephan Herrmann-2
In reply to this post by Andreas Sewe
Hi Andreas,

On 11.04.2017 15:03, Andreas Sewe wrote:

> ...but why does publishing to central use version ranges in Maven
> dependencies on the first place?
>
> I get that these are a more truthful translation of the original OSGi
> manifests *but* AFAIK they not only suffer from the above problem but
> also make you build irreproducible; as Maven's "target platform" is
> "whatever is in Maven Central" at the moment, what a version range
> resolves to may change over time. IIRC, using version ranges are
> considered to be a bad practice by the Maven developers themselves for
> the latter reason.

Good reasoning, but I did not feel entitled to effectively *change*
the meta data of all of the Eclipse project in the official upload.
(And no-one spoke up when I announce my strategy on eclipse-dev :p)
Semantic versioning is a key factor in the reusability of Eclipse
components, where the consumer building an application decides the
exact combination of versions, not the library provider.

In fact, my company use of mavenized artifacts heavily relies on the
ability to combine artifacts in our specific selection of versions,
in particular to avoid a dependency on Java 8 (so some artifacts are
nailed to Luna), while consuming latest from other components.

I recently learned, that Maven indeed has an equivalent of what we
call the "target platform": create a pom with only a huge section
of dependencyManagement and then let your main pom depend on that
'target platform' with scope "import".

Keeping original version ranges and using this huge dependencyManagement
is the best translation into Maven-land that I could come up.

If for the future artifacts published to Maven should be significantly
different from what we publish to our p2 consumers, then this would
have to be driven by someone else, I'm afraid. Likely the Eclipse PMC
should first define the strategy in that case.

Stephan

_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Stephan Herrmann-2
In reply to this post by Cristiano Gavião
On 11.04.2017 16:01, Cristiano Gavião wrote:

>
>
> On 11/04/2017 09:42, Stephan Herrmann wrote:
>> One way around this, *might* be to publish / consume snapshots
>> only via repo.eclipse.org, not Maven Central.
>
> In my vision, the better approach is to publish into maven central repository only the released versions of bundles.
>
> Bundles that are part of any M# or RC# should be deployed using a full timestamp (ex: 4.7.0.v2017040112000 ), but into a different
> repository, a snapshot only one.
> Sonatype provides one: https://oss.sonatype.org/content/repositories/snapshots/ and its process is described here
> (http://central.sonatype.org/pages/ossrh-guide.html)

I've not seen much guidance on *how* to use the OSSRH snapshots repo.

In particular: if someone references a repo with
        <snapshots><enabled>false</enabled></snapshots>
how exactly must a snapshot be marked in order to remain invisible?

Consider a company repository manager standing between you and
the outside, i.e., you can't directly turn on/off your connection
to OSSRH snapshots, but need to excluded snapshots in a given build.

In that repo I see artifacts like this:
 
https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/org.eclipse.jdt.core-3.10.0.v20140528-1959-20140625.081446-8.jar

which exhibits two variants of the version: directory mentions SNAPSHOT,
artifact expands that to a time stamp. Is this artifact enabled/disabled
by the <snapshots> element? If so, then this could help avoid the problem
I mentioned in my first mail.

best,
Stephan




_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Cristiano Gavião

Hello Stephan, hope I have understood your question...


On 11/04/2017 11:26, Stephan Herrmann wrote:

In particular: if someone references a repo with
    <snapshots><enabled>false</enabled></snapshots>
how exactly must a snapshot be marked in order to remain invisible?
if you set the repository as false it won't be considered by maven in order to looking for remote artfacts/bundles. but maven can still use already downloaded ones.


Consider a company repository manager standing between you and
the outside, i.e., you can't directly turn on/off your connection
to OSSRH snapshots, but need to excluded snapshots in a given build.
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 world or internal network.

and if we use thirty-part snapshot repo or p2 bundles, what I normally used to do at dev time (briefly) are:
  • Download the bundles from the http links provided by Eclipse and create a local maven repository and point nexus to it (the most boring part);
  • create a new branch in our releng project in git where I will change the FPOM ( a fragment POM with only dependencyManagement and version that I want to work). Normally I declare every dependency, including transitive ones.  Then I install those fpom in 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):
   <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.c8tech.releng.maven</groupId>
                <artifactId>com.c8tech-maven-fpom-node-equinox</artifactId>
                <version>${com.c8tech.releng.version}</version>
                <scope>import</scope>
                <type>pom</type>
            </dependency>
        </dependencies>
    </dependencyManagement>

  • Also in the releng project I do change the settings.xml that is being used by Jenkins and local machines. There, I include and enable the snapshot repositories and disable the release ones. Note that I also set the updatePolicy to never, just to avoid download newer version and to pollute my local repo, but that can be bypassed by using -U option:

<profiles>
    <profile>
      ...
      <repositories>
        <repository>
          <id>C8TechSnapshots</id>
          <name>C8Tech Snapshots</name>
          <releases>
            <enabled>false</enabled>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
            <checksumPolicy>fail</checksumPolicy>
          </snapshots>
          <url>http://192.168.19.2/maven2/snapshots</url>
          <layout>default</layout>
        </repository>
      </repositories>

  • At Jenkins, I can create different jobs for each development branch combination;
  • After release I can clean or delete the snapshot repositories that I have created.


Using jenkins is easier because you can set a clean local repository for each job while at local machine, sometimes, you need to delete some downloaded resources in order to avoid the issues related to semantic versions that you have referred.

best regards,

Cristiano


In that repo I see artifacts like this:

https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/org.eclipse.jdt.core-3.10.0.v20140528-1959-20140625.081446-8.jar

which exhibits two variants of the version: directory mentions SNAPSHOT,
artifact expands that to a time stamp. Is this artifact enabled/disabled
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 versions. what defines which one is the latest is the https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/maven-metadata.xml file.


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Stephan Herrmann-2
On 11.04.2017 18:11, Cristiano Gavião wrote:
> Hello Stephan, hope I have understood your question...

Sorry, if I was unclear.

> On 11/04/2017 11:26, Stephan Herrmann wrote:
>
>> In particular: if someone references a repo with
>>     <snapshots><enabled>false</enabled></snapshots>
>> how exactly must a snapshot be marked in order to remain invisible?
> if you set the repository as false it won't be considered by maven in order to looking for remote artfacts/bundles. but maven can
> still use already downloaded ones.

Here I wasn't asking about disabling a repo, but about restricting downloads
from it so that you only get release artifacts, not snapshots.
More precisely, what rules Maven applies when it finds the above element
in a repository declaration, or: how exactly does Maven recognize an
artifact as a snapshot.

>
>> Consider a company repository manager standing between you and
>> the outside, i.e., you can't directly turn on/off your connection
>> to OSSRH snapshots, but need to excluded snapshots in a given build.
> 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
> world or internal network.

I don't operate the nexus. In that role I just need to ensure that the
intended versions are fetched from it. Consider this scenario as an
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) are:
>
>   * Download the bundles from the http links provided by Eclipse and create a local maven repository and point nexus to it (the most
>     boring part);
>   * create a new branch in our releng project in git where I will change the FPOM ( a fragment POM with only dependencyManagement
>     and version that I want to work). Normally I declare every dependency, including transitive ones.  Then I install those fpom in
>     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):
>
>        <dependencyManagement>
>             <dependencies>
>                 <dependency>
>                     <groupId>com.c8tech.releng.maven</groupId>
>                     <artifactId>com.c8tech-maven-fpom-node-equinox</artifactId>
>                     <version>${com.c8tech.releng.version}</version>
>                     <scope>import</scope>
>                     <type>pom</type>
>                 </dependency>
>             </dependencies>
>         </dependencyManagement>

Up-to this point this roughly corresponds to what I wrote about a huge dependencyManagement
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
     org.eclipse.platform:eclipse-sdk-dependencies:4.7.0:pom
containing dependencyManagement with all exact versions as of Oxygen GA.
I filed https://bugs.eclipse.org/515137


[...]

>> In that repo I see artifacts like this:
>>
>> https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/org.eclipse.jdt.core-3.10.0.v20140528-1959-20140625.081446-8.jar
>>
>>
>> which exhibits two variants of the version: directory mentions SNAPSHOT,
>> artifact expands that to a time stamp. Is this artifact enabled/disabled
>> 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 versions.
> what defines which one is the latest is the
> https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/maven-metadata.xml
> file.

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
        <snapshots><enabled>false</enabled></snapshots>

I'm insisting in this point, because only if this is fully understood,
someone may publish snapshots to a global repository without affecting
consumers who rely on receiving release artifacts only.


best,
Stephan

_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven snapshot repository available ?

Cristiano Gavião

Hi Stephan,

Have you seen this article: http://blog.osgi.org/2017/02/osgi-api-snapshots-are-live.html ?


best regards,

Cristiano


On 11/04/2017 16:47, Stephan Herrmann wrote:
On 11.04.2017 18:11, Cristiano Gavião wrote:
Hello Stephan, hope I have understood your question...

Sorry, if I was unclear.

On 11/04/2017 11:26, Stephan Herrmann wrote:

In particular: if someone references a repo with
    <snapshots><enabled>false</enabled></snapshots>
how exactly must a snapshot be marked in order to remain invisible?
if you set the repository as false it won't be considered by maven in order to looking for remote artfacts/bundles. but maven can
still use already downloaded ones.

Here I wasn't asking about disabling a repo, but about restricting downloads
from it so that you only get release artifacts, not snapshots.
More precisely, what rules Maven applies when it finds the above element
in a repository declaration, or: how exactly does Maven recognize an
artifact as a snapshot.


Consider a company repository manager standing between you and
the outside, i.e., you can't directly turn on/off your connection
to OSSRH snapshots, but need to excluded snapshots in a given build.
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
world or internal network.

I don't operate the nexus. In that role I just need to ensure that the
intended versions are fetched from it. Consider this scenario as an
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) are:

  * Download the bundles from the http links provided by Eclipse and create a local maven repository and point nexus to it (the most
    boring part);
  * create a new branch in our releng project in git where I will change the FPOM ( a fragment POM with only dependencyManagement
    and version that I want to work). Normally I declare every dependency, including transitive ones.  Then I install those fpom in
    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):

       <dependencyManagement>
            <dependencies>
                <dependency>
                    <groupId>com.c8tech.releng.maven</groupId>
                    <artifactId>com.c8tech-maven-fpom-node-equinox</artifactId>
                    <version>${com.c8tech.releng.version}</version>
                    <scope>import</scope>
                    <type>pom</type>
                </dependency>
            </dependencies>
        </dependencyManagement>

Up-to this point this roughly corresponds to what I wrote about a huge dependencyManagement
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
    org.eclipse.platform:eclipse-sdk-dependencies:4.7.0:pom
containing dependencyManagement with all exact versions as of Oxygen GA.
I filed https://bugs.eclipse.org/515137


[...]

In that repo I see artifacts like this:

https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/org.eclipse.jdt.core-3.10.0.v20140528-1959-20140625.081446-8.jar


which exhibits two variants of the version: directory mentions SNAPSHOT,
artifact expands that to a time stamp. Is this artifact enabled/disabled
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 versions.
what defines which one is the latest is the
https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/tycho/org.eclipse.jdt.core/3.10.0.v20140528-1959-SNAPSHOT/maven-metadata.xml
file.

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
    <snapshots><enabled>false</enabled></snapshots>

I'm insisting in this point, because only if this is fully understood,
someone may publish snapshots to a global repository without affecting
consumers who rely on receiving release artifacts only.


best,
Stephan

_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Loading...