Publish to Maven Central via Sonatype

[nblair]

• Register ability to publish under org.bedework groupId with Sonatype.
• Add necessary configuration for maven-release-plugin to publish to Sonatype.

[nblair]

I had actually setup access with sonatype to publish to the groupId org.bedework some time ago for the exchange-ws-client. I've opened https://issues.sonatype.org/browse/OSSRH-16401 to grant @EricWittmann access.

I've started a branch with changes to distributionManagement, and successfully published a -SNAPSHOT yesterday. We are going to run into some issues though publishing a release:

1. The ical4j and ical4j-vcard dependencies currently reference -SNAPSHOT versions; you can't release a project with a -SNAPSHOT dependency, the release plugin simply won't let you do this (for good reason).
2. Those same dependencies appear to be forks of the core ical4j projects that are hosted in a repository at http://repository.bedework.org/maven2/. It use to be the case that Sonatype prevented you from releasing artifacts that referenced external repositories. That directive appears to be scaled back:

In addition we discourage the usage of and and instead publish any required components to the Central Repository.

(see http://central.sonatype.org/pages/requirements.html). The wording seems to imply they'll let a release now with a block, but I haven't ever actually done that, so I guess we'll just have to try.

@douglm what are the nature of the changes in those snapshots? Is there a chance that we could get those changes into the upstream project and formally released?

[douglm]

That's going to be a long job - which is why it gets put off.

I've added a bunch of stuff as we try out calendar features.

We could do a bedework release version and pursue gettig them back into
the main project.

The other complication was he moved repositories and was bringing out a
new release of ical4j with significant changes

On 7/4/15 09:41, Nicholas Blair wrote:

I had actually setup access with sonatype to publish to the groupId
org.bedework some time ago for the exchange-ws-client. I've opened
https://issues.sonatype.org/browse/OSSRH-16401 to grant @EricWittmann
https://github.com/EricWittmann access.

I've started a branch with changes to distributionManagement, and
successfully published a -SNAPSHOT yesterday. We are going to run into
some issues though publishing a release:

1. The ical4j and ical4j-vcard dependencies currently reference
   -SNAPSHOT versions; you can't release a project with a -SNAPSHOT
   dependency, the release plugin simply won't let you do this (for
   good reason).
2. Those same dependencies appear to be forks of the core ical4j
   projects that are hosted in a repository at
   http://repository.bedework.org/maven2/. It use to be the case that
   Sonatype prevented you from releasing artifacts that referenced
   external repositories. That directive appears to be scaled back: >
   In addition we discourage the usage of and and instead publish any
   required components to the Central Repository. (see
   http://central.sonatype.org/pages/requirements.html). The wording
   seems to imply they'll let a release now with a block, but I
   haven't ever actually done that, so I guess we'll just have to try.

@douglm https://github.com/douglm what are the nature of the changes
in those snapshots? Is there a chance that we could get those changes
into the upstream project and formally released?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[nblair]

@douglm if those changes are not likely to go upstream, what about importing those forks as sub-modules of this project? Alternatively, if the changes are largely just additive to ical4j, you could slice just those bits out into a module. I'd be happy to help with that - where is the source for those changes?

[douglm]

Hi.

I was out in Nova Scotia with no internet (almost) but some time to
think about these issues.

I think at this stage our fork of ical4j is sufficiently different that
it would be a significant job to merge them. A desirable task eventually
but I think we should just call it what it is and make it a bedework
release of ical4j.

I think he actually moved repository (twice) since I downloaded it.

If we just accept that merging is a desirable future aim is just calling
it bedework-ical4j-1.0 enough to satisfy sonatype?

On 7/4/15 09:41, Nicholas Blair wrote:

I had actually setup access with sonatype to publish to the groupId
org.bedework some time ago for the exchange-ws-client. I've opened
https://issues.sonatype.org/browse/OSSRH-16401 to grant @EricWittmann
https://github.com/EricWittmann access.

I've started a branch with changes to distributionManagement, and
successfully published a -SNAPSHOT yesterday. We are going to run into
some issues though publishing a release:

1. The ical4j and ical4j-vcard dependencies currently reference
   -SNAPSHOT versions; you can't release a project with a -SNAPSHOT
   dependency, the release plugin simply won't let you do this (for
   good reason).
2. Those same dependencies appear to be forks of the core ical4j
   projects that are hosted in a repository at
   http://repository.bedework.org/maven2/. It use to be the case that
   Sonatype prevented you from releasing artifacts that referenced
   external repositories. That directive appears to be scaled back: >
   In addition we discourage the usage of and and instead publish any
   required components to the Central Repository. (see
   http://central.sonatype.org/pages/requirements.html). The wording
   seems to imply they'll let a release now with a block, but I
   haven't ever actually done that, so I guess we'll just have to try.

@douglm https://github.com/douglm what are the nature of the changes
in those snapshots? Is there a chance that we could get those changes
into the upstream project and formally released?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[nblair]

Let's confirm the license on ical4j allows for forking, renaming, and
publishing in this fashion. If so, let's publish it under the
'org.bedework' groupId, which we already have setup and can publish a
release.

On Thu, Jul 23, 2015 at 11:47 PM Mike Douglass notifications@github.com
wrote:

Hi.

I was out in Nova Scotia with no internet (almost) but some time to
think about these issues.

I think at this stage our fork of ical4j is sufficiently different that
it would be a significant job to merge them. A desirable task eventually
but I think we should just call it what it is and make it a bedework
release of ical4j.

I think he actually moved repository (twice) since I downloaded it.

If we just accept that merging is a desirable future aim is just calling
it bedework-ical4j-1.0 enough to satisfy sonatype?

On 7/4/15 09:41, Nicholas Blair wrote:

I had actually setup access with sonatype to publish to the groupId
org.bedework some time ago for the exchange-ws-client. I've opened
https://issues.sonatype.org/browse/OSSRH-16401 to grant @EricWittmann
https://github.com/EricWittmann access.

I've started a branch with changes to distributionManagement, and
successfully published a -SNAPSHOT yesterday. We are going to run into
some issues though publishing a release:

1. The ical4j and ical4j-vcard dependencies currently reference
   -SNAPSHOT versions; you can't release a project with a -SNAPSHOT
   dependency, the release plugin simply won't let you do this (for
   good reason).
2. Those same dependencies appear to be forks of the core ical4j
   projects that are hosted in a repository at
   http://repository.bedework.org/maven2/. It use to be the case that
   Sonatype prevented you from releasing artifacts that referenced
   external repositories. That directive appears to be scaled back: >
   In addition we discourage the usage of and and instead publish any
   required components to the Central Repository. (see
   http://central.sonatype.org/pages/requirements.html). The wording
   seems to imply they'll let a release now with a block, but I
   haven't ever actually done that, so I guess we'll just have to try.

@douglm https://github.com/douglm what are the nature of the changes
in those snapshots? Is there a chance that we could get those changes
into the upstream project and formally released?

—
Reply to this email directly or view it on GitHub
#1 (comment).

—
Reply to this email directly or view it on GitHub
#1 (comment).

[EricWittmann]

My thoughts exactly. We need to check the license of the original repo. It's possible ical4j has changed license since the bedework fork of it was made.

@douglm - do you have the original unchanged sources around? or access to the original in some fashion?

[EricWittmann]

The current ical4j license is fascinating!

https://github.com/ical4j/ical4j/blob/master/LICENSE

Pretty rare to see a custom license. :)

[nblair]

There's a note at the end of the project's README, which is easy enough to
accomplish (we'd drop LICENSE.ical4j in src/main/resources/META-INF I
think):

Redistribution:

If you intend to use and distribute iCal4j in your own project please
follow these very simple guidelines:

Make a copy of the LICENSE, rename it to LICENSE.ical4j, and save it to
the directory where you are re-distributing the iCal4j JAR.

I don't recommend extracting the iCal4j classes from its JAR and package
in another JAR along with other classes. It may lead to version
incompatibilites in the future. Rather I would suggest to include the
ical4j.jar in your classpath as required.

On Fri, Jul 24, 2015 at 10:32 AM Eric Wittmann notifications@github.com
wrote:

The current ical4j license is fascinating!

https://github.com/ical4j/ical4j/blob/master/LICENSE

Pretty rare to see a custom license. :)

—
Reply to this email directly or view it on GitHub
#1 (comment).

[douglm]

I'm also going to take a look at the dependencies and see if I can't
split the util stuff up a bit.

I'm thinking along the lines of a calutil module that has the ical4j
dependencies.

On 7/24/15 11:44, Nicholas Blair wrote:

There's a note at the end of the project's README, which is easy enough to
accomplish (we'd drop LICENSE.ical4j in src/main/resources/META-INF I
think):

Redistribution:

If you intend to use and distribute iCal4j in your own project please
follow these very simple guidelines:

Make a copy of the LICENSE, rename it to LICENSE.ical4j, and save it to

the directory where you are re-distributing the iCal4j JAR.

I don't recommend extracting the iCal4j classes from its JAR and package
in another JAR along with other classes. It may lead to version
incompatibilites in the future. Rather I would suggest to include the
ical4j.jar in your classpath as required.

On Fri, Jul 24, 2015 at 10:32 AM Eric Wittmann notifications@github.com
wrote:

The current ical4j license is fascinating!

https://github.com/ical4j/ical4j/blob/master/LICENSE

Pretty rare to see a custom license. :)

—
Reply to this email directly or view it on GitHub
#1 (comment).

—
Reply to this email directly or view it on GitHub
#1 (comment).

[nblair]

Per @douglm the source we need is available here:

https://github.com/Bedework/bw-ical4j-cl

We have 2 paths from here:

1. Keep 'bw-ical4j-cl' as a separate project in a separate repository with a separate release cycle.
2. Import the source of bw-ical4j-cl as a sub-module of this project and repository, and include it with bw-util release cycle.

Is there any reason we would want to isolate bw-ical4j-cl's release cycle from bw-util?

[douglm]

I'd prefer to keep it separate.

There is the potential that some of the changes might be used by others
without wanting to be encumbered by the bedework util stuff.

It also reflects the state of the ical4j project that eventually we
might merge into.

On 10/6/15 10:03, Nicholas Blair wrote:

Per @douglm https://github.com/douglm the source we need is available
here:

https://github.com/Bedework/bw-ical4j-cl

We have 2 paths from here:

1. Keep 'bw-ical4j-cl' as a separate project in a separate repository
   with a separate release cycle.
2. Import the source of bw-ical4j-cl as a sub-module of this project
   and repository, and include it with bw-util release cycle.

Is there any reason we would want to isolate bw-ical4j-cl's release
cycle from bw-util?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[nblair]

I'm cool with that, opening a few issues we'll need to tackle in bw-ical4j-cl before we circle back here:

• https://github.com/Bedework/bw-ical4j-cl/issues/1
• https://github.com/Bedework/bw-ical4j-cl/issues/2

Once we've got releases of bw-ical4j-cl shipped to Maven Central, we'll circle back here and drop any references to net.fortuna.ical4j ical4j artifacts in bw-util poms and replace them with org.bedwork bw-ical4j-cl.