Logback Maven repo for deploying releases?
Hi all, Is there an existing public Maven repo to which Logback releases are deployed (like Nexus)? If so, I'd like to be able to deploy to it when cutting a release of Logback Extension if possible. Thoughts? Also, how are these artifacts promoted to Maven Central? Thanks, Les
Hi Les, Logback releases are deployed to a non-public repo located on pixie.qos.ch. The Maven central repo synchronizes with this non-public repo via rsync. We could either copy logback-extension artifacts from a site that you own and control. Alternatively, you could upload logback-extension artifacts to one of the qos.ch servers and pixie.qos.ch would copy and then publish them. The same techniques apply to pages published under http://logback.qos.ch/logback-extensions. Comments? -- Ceki http://twitter.com/#!/ceki On 10.03.2012 22:55, Les Hazlewood wrote:
Hi all,
Is there an existing public Maven repo to which Logback releases are deployed (like Nexus)?
If so, I'd like to be able to deploy to it when cutting a release of Logback Extension if possible. Thoughts? Also, how are these artifacts promoted to Maven Central?
Thanks,
Les
On Sat, Mar 10, 2012 at 5:24 PM, ceki <ceki@qos.ch> wrote:
Hi Les,
Logback releases are deployed to a non-public repo located on pixie.qos.ch. The Maven central repo synchronizes with this non-public repo via rsync.
We could either copy logback-extension artifacts from a site that you own and control. Alternatively, you could upload logback-extension artifacts to one of the qos.ch servers and pixie.qos.ch would copy and then publish them. The same techniques apply to pages published under http://logback.qos.ch/logback-**extensions<http://logback.qos.ch/logback-extensions> .
Comments?
Which commands would we use to upload artifacts to the servers you mention? --
On 11.03.2012 00:20, Tony Trinh wrote:
On Sat, Mar 10, 2012 at 5:24 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
We could either copy logback-extension artifacts from a site that you own and control. Alternatively, you could upload logback-extension artifacts to one of the qos.ch <http://qos.ch> servers and pixie.qos.ch <http://pixie.qos.ch> would copy and then publish them. The same techniques apply to pages published under http://logback.qos.ch/logback-__extensions <http://logback.qos.ch/logback-extensions>.
Comments?
Which commands would we use to upload artifacts to the servers you mention?
You'd upload artifacts using scp. -- Ceki http://twitter.com/#!/ceki
On Sun, Mar 11, 2012 at 4:20 AM, ceki <ceki@qos.ch> wrote:
On 11.03.2012 00:20, Tony Trinh wrote:
Which commands would we use to upload artifacts to the servers you mention?
You'd upload artifacts using scp.
Ok, I see. I imagine it would be something like: scp foo.jar tony19@qos.ch:/path/to/staging/area/. What would be the remote path for the staging area? Can you create my account? Or is there somewhere I can do it myself? Thanks, Tony
On 11.03.2012 10:08, Tony Trinh wrote:
Ok, I see. I imagine it would be something like:
scp foo.jar tony19@qos.ch:/path/to/staging/area/.
Yes. For the web-site would upload a folder. As for artifacts, it is not clear to me how logback-android integrates with Maven if at all. We'd have to discuss that.
What would be the remote path for the staging area?
The actual path is something we can discuss privately.
Can you create my account? Or is there somewhere I can do it myself?
Yes, I can create an account for you. What user id would you like?
Thanks, Tony
-- Ceki http://twitter.com/#!/ceki
Hi Ceki, Would you be open to using a Nexus repository manager built for this kind of stuff (granting/removing access, promoting artifacts to Maven Central when you specify), etc? Sonatype, the company behind Nexus and Maven Central offer repository hosting for open source projects: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U... This way, you don't have to open up SSH/shell accounts, use SCP or expose your systems to people you may not know. Thoughts? Les
P.S. Things like logback-extensions and logback-android could use Sonatype's hosted Nexus while existing qos.ch projects retain their current approach. You could then move those at your leisure to Sonatype's hosted Nexus if you wanted. Thoughts? On Sun, Mar 11, 2012 at 11:38 AM, Les Hazlewood <les@hazlewood.com> wrote:
Hi Ceki,
Would you be open to using a Nexus repository manager built for this kind of stuff (granting/removing access, promoting artifacts to Maven Central when you specify), etc?
Sonatype, the company behind Nexus and Maven Central offer repository hosting for open source projects:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
This way, you don't have to open up SSH/shell accounts, use SCP or expose your systems to people you may not know.
Thoughts?
Les
On 11.03.2012 19:38, Les Hazlewood wrote:
Hi Ceki,
Would you be open to using a Nexus repository manager built for this kind of stuff (granting/removing access, promoting artifacts to Maven Central when you specify), etc?
Hi Les, The current approach where artifacts are pushed during 'mvn deploy' to a private repo and then having Maven Central automatically pickup changes is an *automated*, simple and very convenient process. I would not want to change in favor of a process with no identified upside (assuming shell accounts are needed for integrating with the web-site anyhow).
Sonatype, the company behind Nexus and Maven Central offer repository hosting for open source projects:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
This way, you don't have to open up SSH/shell accounts, use SCP or expose your systems to people you may not know.
SSH accounts would be needed for the web-site in any case.
Thoughts?
Les
-- Ceki http://twitter.com/#!/ceki
On Mar 11, 2012, at 2:13 PM, ceki wrote:
On 11.03.2012 19:38, Les Hazlewood wrote:
Hi Ceki,
Would you be open to using a Nexus repository manager built for this kind of stuff (granting/removing access, promoting artifacts to Maven Central when you specify), etc?
Hi Les,
The current approach where artifacts are pushed during 'mvn deploy' to a private repo and then having Maven Central automatically pickup changes is an *automated*, simple and very convenient process. I would not want to change in favor of a process with no identified upside (assuming shell accounts are needed for integrating with the web-site anyhow).
You might want to look at how the ASF's Nexus repo works if you haven't already. Projects do a mvn deploy to a staging repository and then after it is reviewed Nexus "publishes it" to its live repository where Maven Central then retrieves it. Specific user's can have permissions for only specific repositories within Nexus. Ralph
On 12.03.2012, at 00:41, Ralph Goers wrote:
On Mar 11, 2012, at 2:13 PM, ceki wrote:
On 11.03.2012 19:38, Les Hazlewood wrote:
Hi Ceki,
Would you be open to using a Nexus repository manager built for this kind of stuff (granting/removing access, promoting artifacts to Maven Central when you specify), etc?
Hi Les,
The current approach where artifacts are pushed during 'mvn deploy' to a private repo and then having Maven Central automatically pickup changes is an *automated*, simple and very convenient process. I would not want to change in favor of a process with no identified upside (assuming shell accounts are needed for integrating with the web-site anyhow).
You might want to look at how the ASF's Nexus repo works if you haven't already. Projects do a mvn deploy to a staging repository and then after it is reviewed Nexus "publishes it" to its live repository where Maven Central then retrieves it. Specific user's can have permissions for only specific repositories within Nexus.
Ralph
I personally use https://oss.sonatype.org/ for sulky and lilith. See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U... They are very, very fast. I just released a new Lilith version and all the artifacts have already synced into the central maven repository. Cheers, Joern.
On 12.03.2012 02:22, Joern Huxhorn wrote:
On 12.03.2012, at 00:41, Ralph Goers wrote:
Ralph, thanks for the info.
You might want to look at how the ASF's Nexus repo works if you haven't already. Projects do a mvn deploy to a staging repository and then after it is reviewed Nexus "publishes it" to its live repository where Maven Central then retrieves it. Specific user's can have permissions for only specific repositories within Nexus.
Ralph
I personally use https://oss.sonatype.org/ for sulky and lilith. See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They are very, very fast. I just released a new Lilith version and all the artifacts have already synced into the central maven repository.
Succumbing to reason, I've asked for the creation of a repo for logback https://oss.sonatype.org. See https://issues.sonatype.org/browse/OSSRH-3121
Cheers, Joern.
-- Ceki http://twitter.com/#!/ceki
On 12.03.2012 18:08, ceki wrote: As stated by Joel Orlina in OSSRH-3121 [1], configuration has been prepared for hosting a repository for logback on oss.sonatype. He writes: Configuration has been prepared, now you can: repo_1) Deploy snapshot artifacts into repository https://oss.sonatype.org/content/repositories/snapshots repo_2) Deploy release artifacts into the staging repository https://oss.sonatype.org/service/local/staging/deploy/maven2 Promote staged artifacts into repository 'Releases' repo_3) Download snapshot and release artifacts from group https://oss.sonatype.org/content/groups/public repo_4) Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/content/groups/staging I can see use for repo_1 for deploying snapshots and repo_2 for releasing artifacts (to be subsequently synced with Maven Central). However, what use is there for repo_3 and repo_4? I guess one could ignore repo_3 and repo_4 if one has no use for it. What am I missing? I'll keep this list posted on the progress made on the logback repo. Cheers, [1] https://issues.sonatype.org/browse/OSSRH-3121 -- Ceki http://twitter.com/#!/ceki
Configuration has been prepared, now you can:
repo_1) Deploy snapshot artifacts into repository https://oss.sonatype.org/content/repositories/snapshots
repo_2) Deploy release artifacts into the staging repository https://oss.sonatype.org/service/local/staging/deploy/maven2
Promote staged artifacts into repository 'Releases'
repo_3) Download snapshot and release artifacts from group https://oss.sonatype.org/content/groups/public
repo_4) Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/content/groups/staging
I can see use for repo_1 for deploying snapshots and repo_2 for releasing artifacts (to be subsequently synced with Maven Central). However, what use is there for repo_3 and repo_4?
I guess one could ignore repo_3 and repo_4 if one has no use for it. What am I missing?
repo_2 is a REST end-point used to deploy artifacts too, you would not configure maven to fetch artifacts from this url. Users will fetch artifacts using the repo_3 url. When artifacts are staged, the repository of the staged artifacts will be in the staging group under repo_4. This is useful to help verify your staged artifacts are as desired before promoting them. Some example config here: http://search.maven.org/remotecontent?filepath=org/sonatype/oss/oss-parent/7... Many projects using this repository actually make this their parent, but you don't need to do that if you don't want. Oh, also keep in mind that you *must* GPG sign everything deployed, or NX will reject the artifacts. --jason
On 12.03.2012 23:04, Jason Dillon wrote:
Configuration has been prepared, now you can:
repo_1) Deploy snapshot artifacts into repository https://oss.sonatype.org/content/repositories/snapshots
repo_2) Deploy release artifacts into the staging repository https://oss.sonatype.org/service/local/staging/deploy/maven2
Promote staged artifacts into repository 'Releases'
repo_3) Download snapshot and release artifacts from group https://oss.sonatype.org/content/groups/public
repo_4) Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/content/groups/staging
I can see use for repo_1 for deploying snapshots and repo_2 for releasing artifacts (to be subsequently synced with Maven Central). However, what use is there for repo_3 and repo_4?
I guess one could ignore repo_3 and repo_4 if one has no use for it. What am I missing?
repo_2 is a REST end-point used to deploy artifacts too, you would not configure maven to fetch artifacts from this url. Users will fetch artifacts using the repo_3 url.
When artifacts are staged, the repository of the staged artifacts will be in the staging group under repo_4. This is useful to help verify your staged artifacts are as desired before promoting them.
Some example config here:
http://search.maven.org/remotecontent?filepath=org/sonatype/oss/oss-parent/7...
Many projects using this repository actually make this their parent, but you don't need to do that if you don't want.
Oh, also keep in mind that you *must* GPG sign everything deployed, or NX will reject the artifacts.
--jason
Thanks for the information Jason. I suppose it is possible to grant privileges to sub-trees of "ch.qos" to specified users? The docs mention a "privileges" button in the UI but I can't see one. I guess I would need to file a jira issue and request privilege changes. Cheers, -- Ceki http://twitter.com/#!/ceki
Yup, you'd need to file a request /me thinks. On Monday, March 12, 2012 at 3:30 PM, ceki wrote:
On 12.03.2012 23:04, Jason Dillon wrote:
Configuration has been prepared, now you can:
repo_1) Deploy snapshot artifacts into repository https://oss.sonatype.org/content/repositories/snapshots
repo_2) Deploy release artifacts into the staging repository https://oss.sonatype.org/service/local/staging/deploy/maven2
Promote staged artifacts into repository 'Releases'
repo_3) Download snapshot and release artifacts from group https://oss.sonatype.org/content/groups/public
repo_4) Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/content/groups/staging
I can see use for repo_1 for deploying snapshots and repo_2 for releasing artifacts (to be subsequently synced with Maven Central). However, what use is there for repo_3 and repo_4?
I guess one could ignore repo_3 and repo_4 if one has no use for it. What am I missing?
repo_2 is a REST end-point used to deploy artifacts too, you would not configure maven to fetch artifacts from this url. Users will fetch artifacts using the repo_3 url.
When artifacts are staged, the repository of the staged artifacts will be in the staging group under repo_4. This is useful to help verify your staged artifacts are as desired before promoting them.
Some example config here:
http://search.maven.org/remotecontent?filepath=org/sonatype/oss/oss-parent/7...
Many projects using this repository actually make this their parent, but you don't need to do that if you don't want.
Oh, also keep in mind that you *must* GPG sign everything deployed, or NX will reject the artifacts.
--jason
Thanks for the information Jason. I suppose it is possible to grant privileges to sub-trees of "ch.qos" to specified users? The docs mention a "privileges" button in the UI but I can't see one. I guess I would need to file a jira issue and request privilege changes.
Cheers, -- Ceki http://twitter.com/#!/ceki _______________________________________________ logback-dev mailing list logback-dev@qos.ch (mailto:logback-dev@qos.ch) http://mailman.qos.ch/mailman/listinfo/logback-dev
I would suggest downloading the community version of Nexus and just starting it up and then going to the UI as an admin with full rights. You won't see everything as there is some stuff in the commercial version that isn't in the community version. But it should give you a better idea of how it works and what it is capable of. You should also look at http://www.sonatype.com/books/nexus-book/reference/. Ralph
On Mon, Mar 12, 2012 at 6:30 PM, ceki <ceki@qos.ch> wrote:
Thanks for the information Jason. I suppose it is possible to grant privileges to sub-trees of "ch.qos" to specified users? The docs mention a "privileges" button in the UI but I can't see one. I guess I would need to file a jira issue and request privilege changes.
Hi Ceki, Any updates on this? I'm antsy to deploy logback-android (to knock out my last TODO item :). Thanks, Tony
On 23.03.2012 03:40, Tony Trinh wrote:
On Mon, Mar 12, 2012 at 6:30 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Thanks for the information Jason. I suppose it is possible to grant privileges to sub-trees of "ch.qos" to specified users? The docs mention a "privileges" button in the UI but I can't see one. I guess I would need to file a jira issue and request privilege changes.
Hi Ceki,
Any updates on this? I'm antsy to deploy logback-android (to knock out my last TODO item :).
Hi Tony, Assuming you wish to deploy under the ch.qos.logback.* subtree, I suggest that the group ID of your artifacts be ch.qos.logback.android. Does that sound OK/good?
Thanks, Tony
-- Ceki http://twitter.com/#!/ceki
On Fri, Mar 23, 2012 at 3:11 AM, ceki <ceki@qos.ch> wrote:
On 23.03.2012 03:40, Tony Trinh wrote:
On Mon, Mar 12, 2012 at 6:30 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>>
wrote:
Thanks for the information Jason. I suppose it is possible to grant privileges to sub-trees of "ch.qos" to specified users? The docs mention a "privileges" button in the UI but I can't see one. I guess I would need to file a jira issue and request privilege changes.
Hi Ceki,
Any updates on this? I'm antsy to deploy logback-android (to knock out my last TODO item :).
Hi Tony,
Assuming you wish to deploy under the ch.qos.logback.* subtree, I suggest that the group ID of your artifacts be ch.qos.logback.android. Does that sound OK/good?
Sounds good.
On Mon, Mar 12, 2012 at 1:44 PM, ceki <ceki@qos.ch> wrote:
On 12.03.2012 18:08, ceki wrote:
As stated by Joel Orlina in OSSRH-3121 [1], configuration has been prepared for hosting a repository for logback on oss.sonatype.
He writes:
Configuration has been prepared, now you can:
repo_1) Deploy snapshot artifacts into repository https://oss.sonatype.org/**content/repositories/snapshots<https://oss.sonatype.org/content/repositories/snapshots>
repo_2) Deploy release artifacts into the staging repository https://oss.sonatype.org/**service/local/staging/deploy/**maven2<https://oss.sonatype.org/service/local/staging/deploy/maven2>
Promote staged artifacts into repository 'Releases'
repo_3) Download snapshot and release artifacts from group https://oss.sonatype.org/**content/groups/public<https://oss.sonatype.org/content/groups/public>
repo_4) Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/**content/groups/staging<https://oss.sonatype.org/content/groups/staging>
I can see use for repo_1 for deploying snapshots and repo_2 for releasing artifacts (to be subsequently synced with Maven Central). However, what use is there for repo_3 and repo_4?
https://oss.sonatype.org/index.html#view-repositories provides some help in understanding this. Repo 3 and 4 are both group repositories, which generally mean they are an aggregation of other repositories and don't actually hold content on their own. User's generally use these to limit the number of repositories they have to point to. As the comment indicates, repo 3 is where most users would go to get the actual release artifacts (if they don't go to Central) and it also includes the snapshot repository. Repo 4 contains the artifacts that have been staged. From the comments it apparently also includes the release and snapshot repos as well as staging. Repositories that actually hold content are "hosted" while others are proxies for other Maven repositories hosted somewhere else. Repo 1 and Repo 2 are where you will deploy to. Repo 2.5 (The Releases repository mentioned) is actually https://oss.sonatype.org/content/repositories/releases/ and is included in Repo 3 and 4. IOW (at least if I understand the comments in your note correctly) - Repo 3 is the aggregation of the Releases and Snapshots repositories while Repo 4 is the aggregation of the Releases, Snapshots and Staging repositories.
On Sun, Mar 11, 2012 at 9:44 AM, ceki <ceki@qos.ch> wrote:
On 11.03.2012 10:08, Tony Trinh wrote:
Ok, I see. I imagine it would be something like:
scp foo.jar tony19@qos.ch:/path/to/**staging/area/.
Yes. For the web-site would upload a folder. As for artifacts, it is not clear to me how logback-android integrates with Maven if at all. We'd have to discuss that.
True, logback-android doesn't use Maven at all at the moment, but it's on my TODO list. If I understand correctly, the artifacts uploaded to a Maven repo don't necessarily have to be built with Maven. Ideally, I'd switch from Ant to Maven, but AFAIK, Ant is the choice build tool for Android SDK.
On 11.03.2012 23:50, Tony Trinh wrote:
True, logback-android doesn't use Maven at all at the moment, but it's on my TODO list. If I understand correctly, the artifacts uploaded to a Maven repo don't necessarily have to be built with Maven. Ideally, I'd switch from Ant to Maven, but AFAIK, Ant is the choice build tool for Android SDK.
Indeed, artifacts need not be created by Maven in order to be hosted on a Maven repository. -- Ceki http://twitter.com/#!/ceki
participants (7)
-
ceki -
Jason Dillon -
Joern Huxhorn -
Les Hazlewood -
Ralph Goers -
ralph.goers ＠dslextreme.com
-
Tony Trinh