Publish to Maven Central about logback-extensions

+1

ping?

[lhazlewood]

I agree - we just need to get this set up on oss.sonatype.org first. This repo will push to Maven Central automatically after a release.

[ceki]

There is the question of CLAs which needs to be addressed first.

[trutzonline]

I suggest to use

[x] Yes, logback-extensions should be released under the QOS.ch banner.
[] No, it should be released under a different banner.
[] Maybe (please explain)

@ceki what CLA questions are still open?

[trutzonline]

+1 for publishing on Maven central

[dmitryreznik]

+1

[davidkarlsen]

Any news on the CLA issue?

[tony19]

Would logback-extensions be released in Maven under the ch.qos.logback.extensions group ID? The pom suggests that, but I'm double-checking.

Even with an unresolved CLA issue, I think we could at least start the process of creating the Sonatype project for logback-extensions. I'll open a Sonatype ticket unless someone objects.

UPDATE: See OSSRH-4265

[tony19]

Hi @ceki, Sonatype requires your approval of using the top-level ch.qos group ID. Can you please comment on the ticket? Thanks.

[ceki]

We need to sort out our CLA policy. I have asked Les Hazlewood for the CLA but so far he has not replied. In the absence of a response, we should assume that he does not wish to sign the CLA (which is perfectly fine). In that case, I think we should have different paths for code with CLAs on file and code without CLA, e.g. logback-extensions and respectively logback-sandbox.

[lhazlewood]

Hi guys - sorry for the delay. I'm absolutely slammed and this has been low priority for me.

I will review the CLA ASAP. I've been a bit quiet on the matter because I usually oppose the concept of CLAs. The idea of the extensions project when I created it (and what I hoped it would be) was to be community supported and community led - stuff outside of the core Logback team's core focus and something they didn't have to officially support. Anyone should be able to contribute and issue pull requests without barriers IMO.

Forcing a CLA on a community-led project seems extremely heavyweight. Can someone tell me why this is required for a non-core project founded and contributed to by non-core team members? Thousands of community-focused projects worldwide do just fine without CLAs - Grails Plugins is a great example of non-CLA community with tons of extensions that are quite successful and used in corporations worldwide.

Assuming there are good reasons for forcing a CLA on people, I will probably sign the CLA (I care about the community members that might be affected by this delay). However, Is there an email address to which a signed PDF can be sent? The linked CLA states that it should be mailed via traditional means overseas, which is quite odd in the modern electronic era IMO.

FInally, my opinions on CLAs are mutually exclusive of my opinions about Ceki and the rest of the logback team, for whom I respect and appreciate.

[ceki]

There is no denying that the CLA requirement adds overhead. The CLA offers several advantages:

advantage 1) having a CLA on file for all contributors provides reassurance to downstream users. For example, IP officers from Eclipse contact me at regular intervals asking whether QOS.ch has CLA for all SLF4J and logback contributions.

advantage 2) allows QOS.ch to change the software license as long as the change is not contrary to public interest. This allowed QOS.ch to add Eclipse Public License 1.0 (in addition to LGPL) in logback version 0.9.18. This was undoubtedly a net gain for those wishing to use logback and it was a fairly painless process. Without the CLA on file, dual-licensing logback would have been near impossible.

advantage 3) by virtue of clause 3 of the CLA, the contributor vouches for his/her contributions as his/her own. Thus, QOS.ch takes a lesser risk when distributing software because QOS.ch can claim that some vetting has been performed (due dillegence).

(For example, Les presumably would not have contributed the code in logback-extensions/spring because it contains software written by others without CLAs on file, namely Juergen Hoeller and Bryan Turner.)

A more neutral discussion of CLAs can be found at [1].

BTW, the CLA can be sent to me directly by email (a scanned copy is fine).

Anyway, Les makes a valid point about CLAs and I think we should support software contributions with a lower entry-barrier.

As such, I propose two umbrella projects for hosting logback-extensions. One project called "logback-extensions" reserved for software contributed by people with CLAs on file and another project called "logback-stuff" where developers without CLAs can conribute. (These names are mere suggestions or starting points for discussion. I would be OK with any set of names enjoying majority support.)

In order to minimize the risk taken by QOS.ch, the code in "logback-stuff" should live in a namespace other than "ch.qos" whereas the "logback-extensions" project is welcome to use the "ch.qos.logback.ext" (or similar) namespace. By analogy, similar restrictions should apply to Maven groupId and artifactId of these projects.

Please let me know if you find the above reasonable.

[1] http://www.oss-watch.ac.uk/resources/cla.xml

[lhazlewood]

Ceki thanks very much for your thoughtful and detailed response - this helps me better understand intent.

I've signed and emailed the PDF directly to you privately. Cheers.

[ceki]

Thank you Les. I've created a list for people with CLAs on file [1]. This will help volunteers to sort out which contributions go in logback-extensions and which contributions go in "logback-stuff" (project name still up for discussion).

Looking at the projects under logback-extensions, it looks like eclipse/, jackson/, json/ and mongodb/ have been developed by contributors with CLAs on file whereas loggly/ and spring/ contain some contributions by developers without CLAs. Thus, loggy/ and spring/ should be moved to "logback-stuff" (name still up for discussion).

I would like to start a more public/formal discussion about this migration on the logback-dev mailing list.

[1] https://github.com/qos-ch/logback/blob/master/src/main/clas/signed-clas.txt

[lhazlewood]

I'm fairly certain we don't need CLAs for the loggly and spring modules.

Bryan Turner used to work for me at Stormpath. He did that work under my supervision and with my request as my employee. In fact, his name was on the source code only after copying my original version. I.e. he copied my work, but , in his minor edits, added his name to the @authors tag.

Jeurgen Hoeller is a contributor to the Spring Framework. The Spring framework is Apache 2.0 licensed and freely usable in any business context. I cherry picked some very minor functionality from the Spring framework and included it in the logback-extensions Spring module in accordance with their license. I only included his name in the code to pay respect for his original work. The license doesn't state that I need to do that, and if I didn't, no one would ever have known and we wouldn't be having this discussion.

In any event, the code acquired was done in full accordance with the Apache 2.0 license - we're allowed to use code from that project in any means we desire as long as our distribution is in accordance with the ASL 2.0 (which it is via the EPL). Additionally, Spring has a CLA process that they adhere to as well, providing the same downstream protection to end users. With the ASL 2.0 + the Spring CLA, I can assure you that the loggly and spring module code is 'safe' for inclusion in logback-extensions.

The strongest reason for me even creating the logback-extensions project was because of loggly and spring. As such, I strongly oppose removing them.

Regards,

Les

[ceki]

The code in Log4jWebConfigurer and the code in WebLogbackConfigurer display significant commonality. Keeping the @author tag was indeed the decent thing to do and I agree that the Apache license did not oblige you to do that. I also agree that the Apache license would allow us to modify Log4jWebConfigurer.java and redistribute the modified version under a different name, i.e. WebLogbackConfigurer. However, you can not claim that WebLogbackConfigurer is your original creation as section 5 of the CLA requires you to do.

I am eager to figure out a way for contributions such as spring/ and loggly/ to exist within our community. The best solution so far seems to move these two into a separate umbrella project. The only restrictions on this umbrella project is the use of the ch.qos namespace. It seems like a reasonable compromise to me. We can still link to logback-etcetera/logback-contribs (or watever name we ultimately adopt) from the main logback site. I don't think there are reasons to view logback-etcetera/logback-contribs as some sort of purgatory.

[1] http://tinyurl.com/cgc9hrs
[2] http://tinyurl.com/c9se82g

[lhazlewood]

I was able to have a good discussion with Ceki yesterday and we came up with the following ideas together:

logback-extensions will still be community-run/community-managed and a CLA will not be required. The base package name will need to be changed to something other than ch.qos (e.g. maybe org.logbackext ?).

A new umbrella project will be created if needed: logback-contrib (or whatever else Ceki may wish to call it), and that will be still open to the community for contributions, but each contributor must have a CLA on file. The base package will still be ch.qos and can potentially be officially supported by Qos.ch if they choose to do so.

logback-extensions will always be community supported. If you or your company company requires the guarantees made by Qos.ch's CLA, you might not be able to use artifacts from logback-extensions. However, if all you or your company requires is a valid business-friendly open-source license (e.g. EPL or ASL 2.0), you can use artifacts from logback-extensions as you see fit.

Logback will still be a separate core project maintained by the core Logback team. The core Logback team might migrate modules from logback-contrib into Logback core if/when that might make sense for them to do so.

Ceki, if I've misrepresented anything, please correct me!

[ceki]

I've sent a message on logback-dev mailing list to move things forward.

As far as I am concerned, the two umbrella projects would differ only by CLA requirements and namespace. Needless to say, CLA and namespace bear no obvious relation to code quality or community health. No such relation should be assumed.

[1] http://mailman.qos.ch/pipermail/logback-dev/2012-September/007957.html

[davidkarlsen]

Any movement on this? Will the artifact pop up in the central soon?

[trutzonline]

Has someone something against publishing logback-extensions/mongodb to Maven Central under ch.qos namespace? If not, I wil do it ...

[tony19]

Shouldn't they be all published together? I had started a ticket with Sonatype a while ago: OSSRH-4265

[trutzonline]

@tony19 I agree with you, but this call is now about 5 month old and nothing happens ... I need logback-ext/mongodb in one of my projects and I need it on Maven Central ...

Go for it.
I'd really like to see the logback extensions.

---

From: Christian Trutz [[email protected]]
Sent: Wednesday, December 05, 2012 10:36 PM
To: qos-ch/logback-extensions
Cc: Karlsen David
Subject: {Disarmed} Re: [logback-extensions] Publish to Maven Central (#1)

Has someone something against publishing logback-extensions/mongodb to Maven Central under ch.qos namespace? If not, I wil do it ...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11061688.

[trutzonline]

@ceki can you please create a qos.ch project for non-CLA logback-extensions projects, so we can publish the other projects to Maven Central.

[tony19]

I can put logback-extensions under my group in Central (com.github.tony19) if you want to pull from there -- at least until Ceki decides where to put things. That's currently where I have logback-android, so it's still related to logback. :) Thoughts?

Sounds good. Then it will at least be available! ;-)

From: Tony Trinh [mailto:[email protected]]
Sent: 6. desember 2012 04:38
To: qos-ch/logback-extensions
Cc: Karlsen David
Subject: {Disarmed} Re: [logback-extensions] Publish to Maven Central (#1)

I can put logback-extensions under my group in Central (com.github.tony19) if you want to pull from there -- at least until Ceki decides where to put things. That's currently where I have logback-android, so it's still related to logback. :) Thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11072028.

[trutzonline]

@tony19 for me a compromise solution because only temporally valid. The best way would be to push lb-extensions unter ch.qos namespace.

[tony19]

I agree this is a temporary solution. When Ceki approves the use of the namespace in Sonatype, we'll have logback-extensions in the right place.

[ceki]

I'll look into this tomorrow.

[tony19]

Thanks Ceki. I'll hold off on any further action then (it won't be under my group in Central).

[ceki]

Postponed until Wednesday the 12th.

[trutzonline]

@tony19 logback-contrib (https://github.com/qos-ch/logback-contrib) is now ready to be published to Maven Central. It contains:

• eclipse
• json
• jackson
• mongodb

modules. All other modules remain to logback-extensions.

[ceki]

I would like to change the licence to match logback (EPL+LGPL). However, I'll wait until we have a chance to discuss this topic . In the mean time, we can go forward and release under the Apache licence.

On another register, we should open a ticket at https://issues.sonatype.org/browse/OSSRH for logback-contrib under the groupId "ch.qos.logback.contrib". I propose that ceki, tony19 and belaso (userid?) should have deploy rights.

Christian, if you wish to have the right to deploy under the "ch.qos.logback.contrib" groupId and do not have one a userid with https://issues.sonatype.org could you please create a user id?

[trutzonline]

+1 for changing license to EPL+LGPL

[tony19]

I've opened a Sonatype JIRA (OSSRH-4959) for logback-contrib. The ticket for logback-extensions (OSSRH-4265) is still pending. Ceki can you comment on both tickets? Thanks.

[ceki]

Once logback-contrib is released, we'll tackle logback-extensions.

[ceki]

According to OSSRH-4959, users {ceki, tony19, belaso} have deployer permission on ch.qos.logback.contrib groupId.

[trutzonline]

@tony19 I tagged logback-contrib 0.1.0 in Github but I don't have now the rights to deploy it via

mvn clean deploy -Prelease

to Maven Central (see also https://issues.sonatype.org/browse/OSSRH-4959?focusedCommentId=177132&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-177132)

[tony19]

Ok, I'll give it a try in a couple hours.

[tony19]

I also don't have permission. I've commented on the Sonatype JIRA.

[ceki]

I added a section in logback-contrib/pom.xml.

Could you please

1. check that you have sonatype-nexus-staging defined as a server in your MAVEN_HOME/conf/settings.xml file
2. use the following step-by-step procedure for a release
   mvn versions:set -DnewVersion=${VERSION_NUMBER} -DgenerateBackupPoms=false
   mvn clean
   mvn install
   mvn deploy -P release-sign-artifacts

If it all goes well, you can then drop the staged repository from OSS Nexus and declare victory.

Let me know how it goes.

[ceki]

The above procedure which worked for me. BTW, Joel Orlina modified OSS Nexus setting and asked us to retry. Tony, Chistian would you oblige?

[trutzonline]

unfortunately, still no success 👎. I still get a "Access denied" when executing

mvn deploy -P release-sign-artifacts

[trutzonline]

ironically I can deploy SNAPSHOT versions like 0.1.1-SNAPSHOT but no release versions like 0.1.0

[tony19]

I still get "Access denied" on the release repo, but I'm granted access to the snapshot repo (same as Christian).

[trutzonline]

👍 victory! I can now deploy on ch.qos.logback.contrib

[ceki]

It's show time.

[trutzonline]

one mouse click and version 0.1.1 will be deployed to Maven Central (artifacts are signed, sources and javadocs ok, closed on staging repository). @ceki please say "fire" :-)

[tony19]

(Oops, I keep accidentally hitting Close.)

[ceki]

Christian, please go ahead.

[ceki]

Christian, would you like to post an announcement message? If so, please post it on logback-dev and to QOS.ch announce@ mailing list.

[davidkarlsen]

Is it intended that the logback-spring extension was left out?
http://repo1.maven.org/maven2/ch/qos/logback/contrib/logback-spring

[ejain]

Was hoping to see the loggly extension included... License issues?

[tony19]

Indeed, it was intentional to separate the extensions -- excluding the ones for spring and loggly -- mainly due to license issues.

Will they be released under some other scheme?

Sendt fra en Samsung Mobil

-------- Opprinnelig melding --------
Fra: Tony Trinh [email protected]
Dato:
Til: qos-ch/logback-extensions [email protected]
Ko: Karlsen David [email protected]
Emne: {Disarmed} Re: [logback-extensions] Publish to Maven Central (#1)

Indeed, it was intentional to separate the extensions -- excluding the ones for spring and loggly -- mainly due to license issues.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11817667.

[tony19]

I think we need input from other developers on that. I had assumed the extensions would be under ch.qos.logback.extensions, but I'm not sure that lines up with others' visions.

In the meantime, I've deployed snapshots to Sonatype under com.github.tony19. Let me know if it works for you.

<dependency>
    <groupId>com.github.tony19</groupId>
    <artifactId>logback-ext-loggly</artifactId>
    <version>0.1.0-SNAPSHOT</version>
</dependency>
<dependency>
    <groupId>com.github.tony19</groupId>
    <artifactId>logback-ext-spring</artifactId>
    <version>0.1.0-SNAPSHOT</version>
</dependency>

[davidkarlsen]

Yes, that looks good, but I have to rely on final release-numbers in my
apps.
Any chance to release it under your com.github.tony19 groupId?

2013/1/2 Tony Trinh [email protected]

I think we need input from other developers on that. I had assumed the
extensions would be under ch.qos.logback.extensions, but I'm not sure
that lines up with others' visions.

In the meantime, I've deployed snapshots to Sonatypehttps://oss.sonatype.org/content/repositories/snapshots/under
com.github.tony19. Let me know if it works for you.

com.github.tony19 logback-ext-loggly 0.1.0-SNAPSHOT com.github.tony19 logback-ext-spring 0.1.0-SNAPSHOT

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11818525.

David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

[tony19]

It turns out we're not allowed to delete releases from the Central Repository (which makes sense), so I prefer to release logback-extensions under the final group ID instead of my own to minimize potential confusion. I assume "ch.qos" won't be part of the group ID. Does anyone object to "logback-extensions" as the group ID?

[ceki]

Tony, thank you for pursuing this. I think the groupID should be "logback-extensions.org".

[tony19]

How about "org.logback.extensions"?

I was thinking "logback-extensions" because it uses the same naming schema as the one used in the group ID for "ant-contrib". "org.logback.extensions" would follow the Maven naming conventions for group ID, which also works for me.

[ceki]

"ant-contrib" dates back to 2005, I doubt the maven-central folks would allow a groupId without an org, com or similar prefix but I am just guessing. So, if "logback-extensions" is good for them, it's good for me. As for "org.logback.extensions", I would prefer "org.logback-extensions" as "org.logback" runs the chance of confusing end-users with "ch.qos.logback".

[tony19]

Ok. I had initially requested "org.logback.extensions" (OSSRH-5194), but I've updated the request. I've also registered the domains "logback.org" and "logback-extensions.org" (both redirected to logback.qos.ch).

You make a good point about the potential confusion. Sonatype indeed follows the Maven naming conventions for group ID, which means the ID must be of a domain you own and follow Java's package naming rules. In our case, the domain "logback-extensions.org" translates to a package name of "org.logback_extensions" (the dash is not allowed in Java identifiers and is thus converted to an underscore as recommended by Oracle). I still requested the dash, but we'll see what happens.

I have to say I'm not a fan of mixing dots and dashes in the domain name, and I'm even more opposed to domains with underscores (simply because it's ugly IMO); but I'll roll with it :)

[tony19]

logback-extensions v0.1.1 is now in Maven Central under the groupId org.logback-extensions. While mvn will resolve the dependencies immediately, it may take a few hours before the newly published artifacts appear in http://search.maven.org.

<dependency>
    <groupId>org.logback-extensions</groupId>
    <artifactId>logback-ext-loggly</artifactId>
    <version>0.1.1</version>
</dependency>

<dependency>
    <groupId>org.logback-extensions</groupId>
    <artifactId>logback-ext-spring</artifactId>
    <version>0.1.1</version>
</dependency>

[tony19]

@keyuraashra, please create a new GitHub issue for your question, since it has nothing to do this with this ticket. Thanks

[keyuraashra]

@tony19 Thanks Tony, will create new one.