Okay, we have a support agreement so that isn't a problem. However what concerns me is the change. We need a consistent approach for accessing GXT releases going forward. I can't ask the guys that manage our Nexus server to make this change and then change it back or change it to something else for the next release.
So can you guarantee me that if i switch to this new approach I will ALWAYS have access to the latest GXT releases/builds?
If I don't change anything, when will 3.0.2 be available using the other/older approach? I.e. is this a required change or only a needed change if I want to get new releases right away.
Thanks for the feedback - I'm cautiously optimistic I'll be able to set your concerns at ease.
The public releases will continue to be available in the /commercial-release/ and /gpl-release/ repositories going forward - this will continue to include 3.0.0 and 3.0.1, and will eventually also include 3.1 and 3.2, etc. These are the public artifacts, accessible without a support contract.
Support releases, starting with 3.0.2 (the first support release of the 3.x series) will also be made available in our maven repository, but will require active support credentials to access. My understanding is that 3.0.2 will be a support-only release, and will only be available through the support repository - not through the regular /commercial-release/ or through maven central.
Please note also that now that the support repository is active, it will contain all public releases as well, so this change to requiring support credentials will only have to be made once. Also note that using these same credentials, the /support-commercial-snapshot/ repo is now available, with nightly snapshots (which can also be found in the support portal itself).
Again, thanks for expressing your concerns with our process, and please feel free to continue this discussion here or to contact Edmund or myself directly with any other concerns.
Wow, could you make this more complicated? When I point my browser to https://maven.sencha.com/repo/gxt-su...encha/gxt/gxt/ (after logging into your artifactory) I don't see anything but 3.0.2...but you say they are all there, hum?
I suppose I can ask my Nexus guys to proxy both gxt-commercial-release and gxt-support-commercial-release but not clear yet if that's needed.
As for /support-commercial-snapshot repo, I don't find that at all in Artifactory? Did you mean gxt-commercial-snapshot? Not sure if that requires a login or not.
The url you started with is the repo that we push to, the support-only repo - this has to do with how artifactory manages permissions:
Instead, please use this one: this aggregates all commercial releases, support or otherwise. This is the url that is referred to in both Edmund's post and mine above:
On the technical side, we're using the concept of a 'virtual' repo that groups all other repos accessible by support users. This way, if we want to add another repo later on, all we do is create it, upload artifacts, and group it into support-commercial-release, and you'll automatically have access to it.
Using the artifactory site is useful to see what objects are in what real repos, but little else. When feeding information to your pom, please use the ones we've posted. Here's the full list of important repo urls, with and without support, gpl and commercial, snapshot and release (and please again note that if you aren't authenticated, the support- repos will be missing artifacts through the web interfaces):
Standard GPL release artifacts:
Standard commercial release artifacts:
Support GPL release artifacts:
Support Commercial release artifacts:
Support GPL snapshot artifacts:
Support Commercial snapshot artifacts:
If your organization uses the Commercial release, and has a support contract, then you only want support-commercial-release, or support-commercial-snapshot, depending on if you want the latest release, or last night's build. If you only want all release artifacts, you only need support-commercial-release, it will contain all artifacts your credentials have access to.
Okay thanks, that's the first good consolidated statement of how this works going forward with Maven. (All the rest are more or less confusing). I will get our Nexus guys to make the changes on our end.
Thanks for the feedback - I'll see about putting together an article on commercial/support maven usage for releases and snapshots that we can reference instead of a network of comments and posts.