Topics

Publishing Artifacts to maven.java.net


Will Hopkins
 

I've updated soteria so that it can be published to maven.java.net, and published version 1.0-b08. It's currently only in the "Promoted" repo -- the Glassfish build will see it there -- but I can push it to "Releases" if there's a need. I also published a SNAPSHOT version of 1.0-b08.

Previously I updated security-api and published to maven.java.net. Version 1.0-b06 is currently in "Releases", and there is a SNAPSHOT as well in "Snapshots". Soteria now depends on the published version of the API artifacts. The dependencies may need some tweaking, as I'm not sure they'll pick up SNAPSHOT versions of the API at this point, and a pom change would be needed to pick up a newer version.

Note that both API and RI needed some tweaks to naming and versioning to conform to the requirements in https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html; in particular, the jars now have different names (javax.security.enterprise-api-<version>.jar and javax.security.enterprise-<version>.jar).

I'll look into automating snapshot publication with Hudson.

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Thanks Will!

It would be probably be a good idea to publish the milestone builds (1.0-b08 etc) of Soteria to maven central as well, since Soteria is also usable from within a war archive on Tomcat etc, and this would make testing by the community and demonstrations on conferences etc much easier.

Thanks again!

Kind regards,
Arjan Tijms


Will Hopkins
 

I can push them to "Releases" on maven.java.net; my understanding is that "released" artifacts from maven.java.net are pushed to maven central periodically (every 6 hours or so).

I just released soteria 1.0-b07, so it should appear on maven central soon. Not sure it makes sense to release every build we push to maven.java.net -- some of them will be primarily intended for the GF team, which can consume "promoted" artifacts -- but certainly we can release any build we think represents a significant milestone or a change that should be public.

Now that we're publishing to maven.java.net, can someone go through and delete all of the bintray/jfrog artifacts that are out there? I don't have an account, and EE/JSR-related artifacts aren't supposed to be published anywhere other than maven.java.net. I'm also concerned about confusion over which artifacts are the "real" ones, and issues related to the fact that they're published with the wrong API package/group/artifact names (javax.security vs. javax.security.enterprise, etc.).

Will

On 06/16/2017 03:06 AM, Arjan Tijms wrote:
Thanks Will!

It would be probably be a good idea to publish the milestone builds (1.0-b08 etc) of Soteria to maven central as well, since Soteria is also usable from within a war archive on Tomcat etc, and this would make testing by the community and demonstrations on conferences etc much easier.

Thanks again!

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Ideally the "snapshot" releases get deployed automatically by Travis-CI.

The actual milestones if b09 follows b08 should also be in the release repo wherever possible.

Kind Regards,
Werner


Will Hopkins
 


On 06/16/2017 03:06 PM, Werner Keil wrote:
Ideally the "snapshot" releases get deployed automatically by Travis-CI.
We can probably set something up via hudson, but Travis won't work because it needs my credentials (or the GF build credentials) to be published in maven.java.net.

The actual milestones if b09 follows b08 should also be in the release repo wherever possible.
Not sure I understand what you mean about "if b09 follows b08" ... ?

Bill and Romain have commented later in the thread about when things should be published to release repo or not, I'll respond there to that aspect of your comment.


Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Hudson, is there an official Hudson instance for Java EE/Glassfish?


Will Hopkins
 

Not sure how "official" it is, but I'm pretty sure there's a hudson running for Java EE/Glassffish.

Regarding publishing releases, there's been some internal discussion to the effect that we should try not to "release" many milestone builds, so as to avoid "polluting" Maven Central with a lot of interim, pre-release artifacts. That makes a lot of sense to me -- such artifacts aren't final, but they will live forever at maven.java.net (and Maven Central), as they can't (easily) be removed.

EG:  Are you OK with publishing milestones only to the "Promoted" repo on maven.java.net? They're easily accessible from there; just need to set up the right repo:

        <repository>
          <id>jvnet-nexus-promoted</id>
          <name>Java.net Promoted Repositories</name>
          <url>https://maven.java.net/content/repositories/promoted/</url>
        </repository>

Will


On 06/16/2017 04:34 PM, Werner Keil wrote:
Hudson, is there an official Hudson instance for Java EE/Glassfish?

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

>Now that we're publishing to maven.java.net, can someone go through and delete all of the bintray/jfrog artifacts that are out there? I don't have an account, and EE/JSR-related artifacts aren't supposed to be published anywhere other than maven.java.net.

I removed the publishing to bintray/jfrog/jcentre. Not sure if existing releases can be removed, the may be immutable just as on Maven central, but I'll take a look. bintray/jfrog/jcentre is often also a mirror of Maven Central, so probably shouldn't cause that much confusion.

>Regarding publishing releases, there's been some internal discussion to the effect that we should try not to "release" many milestone builds, so as to avoid "polluting" Maven Central with a lot of interim, pre-release artifacts.

Indeed, but when you changed m to b, you also released them more often. That's a difference with the m releases, which are supposed to be released every few months at most. So 1 release at Maven central would be okay, but indeed, of course not "many" within a short time span.

>Are you OK with publishing milestones only to the "Promoted" repo on maven.java.net? They're easily accessible from there; just need to set up the right repo:

Should be fine, thanks!


Rudy De Busscher
 

All,

Bintray packages can be deleted. Don't know what happen if they are mirrored on JCenter.

Since I see the API and Soteria artifacts on Maven Central, I'll delete the packages from BinTray.

Best regards
Rudy

On 17 June 2017 at 08:52, Arjan Tijms <arjan.tijms@...> wrote:
>Now that we're publishing to maven.java.net, can someone go through and delete all of the bintray/jfrog artifacts that are out there? I don't have an account, and EE/JSR-related artifacts aren't supposed to be published anywhere other than maven.java.net.

I removed the publishing to bintray/jfrog/jcentre. Not sure if existing releases can be removed, the may be immutable just as on Maven central, but I'll take a look. bintray/jfrog/jcentre is often also a mirror of Maven Central, so probably shouldn't cause that much confusion.

>Regarding publishing releases, there's been some internal discussion to the effect that we should try not to "release" many milestone builds, so as to avoid "polluting" Maven Central with a lot of interim, pre-release artifacts.

Indeed, but when you changed m to b, you also released them more often. That's a difference with the m releases, which are supposed to be released every few months at most. So 1 release at Maven central would be okay, but indeed, of course not "many" within a short time span.

>Are you OK with publishing milestones only to the "Promoted" repo on maven.java.net? They're easily accessible from there; just need to set up the right repo:

Should be fine, thanks!



Rudy De Busscher
 

All,

The delete button says that I can't delete the package, nor released versions if they are older than 6 months.

So I deleted as many versions as possible. Only m01 could not be removed. But that shouldn't be a major issue.

Rudy

On 17 June 2017 at 11:16, Rudy De Busscher <rdebusscher@...> wrote:
All,

Bintray packages can be deleted. Don't know what happen if they are mirrored on JCenter.

Since I see the API and Soteria artifacts on Maven Central, I'll delete the packages from BinTray.

Best regards
Rudy

On 17 June 2017 at 08:52, Arjan Tijms <arjan.tijms@...> wrote:
>Now that we're publishing to maven.java.net, can someone go through and delete all of the bintray/jfrog artifacts that are out there? I don't have an account, and EE/JSR-related artifacts aren't supposed to be published anywhere other than maven.java.net.

I removed the publishing to bintray/jfrog/jcentre. Not sure if existing releases can be removed, the may be immutable just as on Maven central, but I'll take a look. bintray/jfrog/jcentre is often also a mirror of Maven Central, so probably shouldn't cause that much confusion.

>Regarding publishing releases, there's been some internal discussion to the effect that we should try not to "release" many milestone builds, so as to avoid "polluting" Maven Central with a lot of interim, pre-release artifacts.

Indeed, but when you changed m to b, you also released them more often. That's a difference with the m releases, which are supposed to be released every few months at most. So 1 release at Maven central would be okay, but indeed, of course not "many" within a short time span.

>Are you OK with publishing milestones only to the "Promoted" repo on maven.java.net? They're easily accessible from there; just need to set up the right repo:

Should be fine, thanks!




Werner Keil
 

Rudy,

Did you also delete the PRD version  v1.0-m04-prd ??
That was almost a bit too much. For the sake of transparency a matching Maven content for the Public Review should also have been preserved.
With that damage done I'm afraid all we have is a GitHub release tag: https://github.com/javaee-security-spec/security-api/releases/tag/v1.0-m04-prd

There is an inconsistency on MavenCentral, too, because the RI is available in 1.0-b07
https://search.maven.org/#artifactdetails%7Corg.glassfish.soteria%7Cjavax.security.enterprise%7C1.0-b07%7Cbundle
while the API bundle is only available in the earlier build:
https://search.maven.org/#artifactdetails%7Cjavax.security.enterprise%7Cjavax.security.enterprise-api%7C1.0-b06%7Cbundle

Is there an effort to get API 1.0-b07 out?

Regards,
Werner


Werner Keil
 

It seems even for this "dedicated PRD tag" there was no equivalent in Soteria, so the https://github.com/javaee-security-spec/soteria/releases/tag/1.0-m01 ones were the last to be in sync.

They reflected a "Renewal Ballot 2" kind of state, so for transparency reasons it is also not bad to have, but it would be far more important to keep API and RI in sync now whenever something gets published.

Werner


Rudy De Busscher
 

The version can be pushed again to Bintray again if needed based on the tag.

Let me know if this needed.

On 17 June 2017 at 17:09, Werner Keil <werner.keil@...> wrote:
Rudy,

Did you also delete the PRD version  v1.0-m04-prd ??
That was almost a bit too much. For the sake of transparency a matching Maven content for the Public Review should also have been preserved.
With that damage done I'm afraid all we have is a GitHub release tag: https://github.com/javaee-security-spec/security-api/releases/tag/v1.0-m04-prd

There is an inconsistency on MavenCentral, too, because the RI is available in 1.0-b07
https://search.maven.org/#artifactdetails%7Corg.glassfish.soteria%7Cjavax.security.enterprise%7C1.0-b07%7Cbundle
while the API bundle is only available in the earlier build:
https://search.maven.org/#artifactdetails%7Cjavax.security.enterprise%7Cjavax.security.enterprise-api%7C1.0-b06%7Cbundle

Is there an effort to get API 1.0-b07 out?

Regards,
Werner



Will Hopkins
 

Thanks, Rudy, for taking care of this.

A couple of points:
  • I don't personally have strong feelings, but my understanding of Oracle policy is that no artrifacts are supposed to be published except at maven.java.net. If there are versions out there that we can't delete, then we're stuck with them, but we shouldn't publish anything else, even the PRD milestone build, IMO. If really necessary, we could try to branch at the PRD label -- which I only tagged on spec and API, because I wasn't sure there was an equivalent, buildable, RI version -- then merge the commits that enable the release machinery, and publish the PRD version to maven.java.net. I don't have the time to do those updates, but I'd be happy to push the release if it's checked in on a branch.
  • The change from "m" to "b" was not driven by a desire to change the semantics, but because the release plugin only supports the "b" notation. I think we can pick and choose "b" releases that we decide are "milestones", and add additional tags to indicate that those builds are also milestones.
  • I'm not sure we should expect to keep the build numbers in sync between API and RI. If we change the RI, but not the API, do we really need to increment the API build number and release it again? The manifest for the RI jar indicates which API version it depended on at build time, and we can always add tags in source to indicate which version of the API matches which version of the RI for a given milestone.

Will


On 06/17/2017 02:36 PM, Rudy De Busscher wrote:
The version can be pushed again to Bintray again if needed based on the tag.

Let me know if this needed.

On 17 June 2017 at 17:09, Werner Keil <werner.keil@...> wrote:
Rudy,

Did you also delete the PRD version  v1.0-m04-prd ??
That was almost a bit too much. For the sake of transparency a matching Maven content for the Public Review should also have been preserved.
With that damage done I'm afraid all we have is a GitHub release tag: https://github.com/javaee-security-spec/security-api/releases/tag/v1.0-m04-prd

There is an inconsistency on MavenCentral, too, because the RI is available in 1.0-b07
https://search.maven.org/#artifactdetails%7Corg.glassfish.soteria%7Cjavax.security.enterprise%7C1.0-b07%7Cbundle
while the API bundle is only available in the earlier build:
https://search.maven.org/#artifactdetails%7Cjavax.security.enterprise%7Cjavax.security.enterprise-api%7C1.0-b06%7Cbundle

Is there an effort to get API 1.0-b07 out?

Regards,
Werner


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi,

On Mon, Jun 19, 2017 at 10:12 PM, Will Hopkins <will.hopkins@...> wrote:

  • The change from "m" to "b" was not driven by a desire to change the semantics, but because the release plugin only supports the "b" notation. I think we can pick and choose "b" releases that we decide are "milestones", and add additional tags to indicate that those builds are also milestones.

I'm not really sure how they did it, but the JSF, MVC and JAX-RS projects did somehow manage to get an "m" in their milestone version numbers. Could be worth it talking to any representatives of those groups inside Oracle to find out how exactly they accomplished that.

I've cc'ed Manfred who I think was responsible for this at both the JSF and MVC groups.

 
  • I'm not sure we should expect to keep the build numbers in sync between API and RI. If we change the RI, but not the API, do we really need to increment the API build number and release it again? The manifest for the RI jar indicates which API version it depended on at build time, and we can always add tags in source to indicate which version of the API matches which version of the RI for a given milestone.

They can indeed run out of sync, but both matching numbers should be available of course. That is, if impl b07 uses api b23u-14 then both should be available in "some" repo.

Kind regards,
Arjan Tijms

 

Will


On 06/17/2017 02:36 PM, Rudy De Busscher wrote:
The version can be pushed again to Bintray again if needed based on the tag.

Let me know if this needed.

On 17 June 2017 at 17:09, Werner Keil <werner.keil@...> wrote:
Rudy,

Did you also delete the PRD version  v1.0-m04-prd ??
That was almost a bit too much. For the sake of transparency a matching Maven content for the Public Review should also have been preserved.
With that damage done I'm afraid all we have is a GitHub release tag: https://github.com/javaee-security-spec/security-api/releases/tag/v1.0-m04-prd

There is an inconsistency on MavenCentral, too, because the RI is available in 1.0-b07
https://search.maven.org/#artifactdetails%7Corg.glassfish.soteria%7Cjavax.security.enterprise%7C1.0-b07%7Cbundle
while the API bundle is only available in the earlier build:
https://search.maven.org/#artifactdetails%7Cjavax.security.enterprise%7Cjavax.security.enterprise-api%7C1.0-b06%7Cbundle

Is there an effort to get API 1.0-b07 out?

Regards,
Werner


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Werner Keil
 

For transparency reasons, having the v1.0-m04-prd of the API in "some repo" is also important. The EC votes on it, but others may also give the API a try and the JCP downloads only contain the Spec and JavaDoc. Having a binary deliverably to use instead of the need to build it from https://github.com/javaee-security-spec/security-api/releases/tag/v1.0-m04-prd is certainly a good thing.

JCenter will pick up from MavenCentral, how often a sync-back happens I can't say, but for example this old release of a security-api http://jcenter.bintray.com/javax/security/security-api/1.1-rev-1/ certainly must have come from MavenCentral. I doubt the java.net repo is also mirrored, but maybe it goes through MavenCentral first?

I am not aware of proper statistics at MavenCentral, at least they all require you to log in before you can see data. After java.net went away, at most Will or those who have an account to deploy there could see any stats if they ever existed (they do for the Apache Nexus) 
https://bintray.com/javaee-security-spec/maven/javax.security%3Ajavax.security-api#statistics only for the 2 versions that remained shows especially the M01 was downloaded/used around 300 times. If other milestone releases or the Final one come back to JCenter that (under the new groupId) will also show its usage. I am confident numbers are cumulated across MavenCentral and JCenter, otherwise the soon 200k downloads of JSR 275 would be hard to explain: https://bintray.com/keilw/maven/javax.measure%3Ajsr-275#statistics

A slow decrease over the past few months is a sign, projects are slowly but steadily adopting JSR 363 although its numbers are not so gigantic at this point.
That's the beauty of Bintray, whether you push artifact there or they get synced back. All you have to do is enable stats, otherwise they still show something, e.g. which days "anything" was downloaded, but no hard numbers, see https://bintray.com/bintray/jcenter/org.glassfish%3Ajavax.security.jacc#statistics

Regards,
Werner


Will Hopkins
 



On 06/19/2017 04:43 PM, Arjan Tijms wrote:
Hi,

On Mon, Jun 19, 2017 at 10:12 PM, Will Hopkins <will.hopkins@...> wrote:

  • The change from "m" to "b" was not driven by a desire to change the semantics, but because the release plugin only supports the "b" notation. I think we can pick and choose "b" releases that we decide are "milestones", and add additional tags to indicate that those builds are also milestones.

I'm not really sure how they did it, but the JSF, MVC and JAX-RS projects did somehow manage to get an "m" in their milestone version numbers. Could be worth it talking to any representatives of those groups inside Oracle to find out how exactly they accomplished that.

I've cc'ed Manfred who I think was responsible for this at both the JSF and MVC groups.

To be more precise, I believe it was the spec-version-maven-plugin that didn't handle "m" very well -- if I provided a "raw" build number, it prefixed it with "b", and if I provided build number as "mNN", it still prefixed with "b", yielding (for example), "bm05" as the build number. Whether the maven-release-plugin would handle "m" or not I can't say.

There may be some way to make the version plugin work, but the existing machinery doesn't make it easy in the context of all the requirements specified here: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html. Unfortunately, documentation for the glassfish plugins seems to be another casualty of the java.net decommissioning.


 
  • I'm not sure we should expect to keep the build numbers in sync between API and RI. If we change the RI, but not the API, do we really need to increment the API build number and release it again? The manifest for the RI jar indicates which API version it depended on at build time, and we can always add tags in source to indicate which version of the API matches which version of the RI for a given milestone.

They can indeed run out of sync, but both matching numbers should be available of course. That is, if impl b07 uses api b23u-14 then both should be available in "some" repo.

Absolutely -- we need to publish matched sets, even if the build numbers vary.


Kind regards,
Arjan Tijms

 

Will


On 06/17/2017 02:36 PM, Rudy De Busscher wrote:
The version can be pushed again to Bintray again if needed based on the tag.

Let me know if this needed.

On 17 June 2017 at 17:09, Werner Keil <werner.keil@...> wrote:
Rudy,

Did you also delete the PRD version  v1.0-m04-prd ??
That was almost a bit too much. For the sake of transparency a matching Maven content for the Public Review should also have been preserved.
With that damage done I'm afraid all we have is a GitHub release tag: https://github.com/javaee-security-spec/security-api/releases/tag/v1.0-m04-prd

There is an inconsistency on MavenCentral, too, because the RI is available in 1.0-b07
https://search.maven.org/#artifactdetails%7Corg.glassfish.soteria%7Cjavax.security.enterprise%7C1.0-b07%7Cbundle
while the API bundle is only available in the earlier build:
https://search.maven.org/#artifactdetails%7Cjavax.security.enterprise%7Cjavax.security.enterprise-api%7C1.0-b06%7Cbundle

Is there an effort to get API 1.0-b07 out?

Regards,
Werner


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803