Publish dbfit jars to Maven Central by MMatten · Pull Request #384 · dbfit/dbfit

MMatten · 2015-07-04T14:18:40Z

To resolve #173.

uploadArchives task creates additional JAR files instead of using the existing JAR output libraries: -

dbfit-x.y.z[-SNAPSHOT].jar
dbfit-x.y.z-sources[-SNAPSHOT].jar
dbfit-x.y.z-javadoc[-SNAPSHOT].jar

then signs the archives and uploads to the appropriate (SNAPSHOT or release staging) Sonatype Maven repository.

All dependencies are published in the associated POM file. The exception is FitLibrary as the version currently used by DbFit isn't available from public repositories (a point for discussion).

MMatten · 2015-07-17T19:57:59Z

@benilovj , @javornikolov - I've tidied up the commits on this one now.

Any views on this PR yet?

javornikolov · 2015-07-17T20:08:36Z

I wonder if we can have some of the changes not related to maven central publishing as separate PR (dependencies configuration refactoring, etc.)

javornikolov · 2015-07-17T20:09:50Z

dbfit-java/build.gradle

Sometimes (almost always) we're using an intermediate fitnesse build (not the official one published to maven). Would it be still possible to do that with the updated notation?

I think we can pull dev snapshots from the central repo as I've seen them on the Sonatype staging repo.

BTW why do we use intermediate/snapshot versions of FitNesse? Can we use release versions instead?

Regarding FitNesse dev snapshots - if we want to pin our dependencies to a specific FitNesse dev snapshot then I'm not sure that this is supported. I'd have to play with it. A release version would be better if possible.

Intermediate versions might be useful e.g. to pick some fixes. But maybe the release versions are usually good enough.

I wonder if we can have some of the changes not related to maven central publishing as separate PR (dependencies configuration refactoring, etc.)

Certainly. I'm not sure what's not directly related to publishing though. Any ideas welcomed.

MMatten · 2015-07-17T23:10:55Z

Another point of discussion needs to be that more recent FitLibrary versions haven't been published (to Sonatype) as far as I can see. Therefore our dependencies can't be resolved only from public repositories which breaks the model.

One option would be to publish FitLibrary (the version we're using) under the com.github.dbfit groupId.

MMatten · 2015-07-24T17:50:45Z

Summary of the outstanding discussion points so far: -

is there anything that needs to be sliced off onto another PR?
can we agree to use FitNesse release versions instead of dev/build snapshots?
are we OK to include an example/sample gradle.properties to show how to set up Sonatype credentials (and a key pair for signing)?
should/must the list of developers be removed from the POM generation?
are we happy with the approach used to generate dependencies, in the POM file, for the aggregated JAR? (If not we could look to publish a fat JAR. I.e. dbfit-X.Y.Z-standalone.jar though it would be nice to not have to).
are we OK to publish FitLibrary under com.github.dbfit.fitlibrary? Do we want a fork of it anyway, seeing as it appears to be dead?

MMatten · 2015-07-24T18:07:22Z

My view on where we are with each of the above: -

is there anything that needs to be sliced off onto another PR?

I think all of the changes directly related to publishing the JARs.

can we agree to use FitNesse release versions instead of dev/build snapshots?

I think that we think that this is OK.

are we OK to include an example/sample gradle.properties to show how to set up Sonatype credentials (and a key pair for signing)?

I think a sample file would be OK.

should/must the list of developers be removed from the POM generation?

Your opinions required please.

are we happy with the approach used to generate dependencies, in the POM file, for the aggregated JAR? (If not we could look to publish a fat JAR. I.e. dbfit-X.Y.Z-standalone.jar though it would be nice to not have to).

Your opinions required please.

are we OK to publish FitLibrary under com.github.dbfit.fitlibrary? Do we want a fork of it anyway, seeing as it appears to be dead?

If we don't fork and publish then a fat JAR is the only option really. Are there any issues with that relating to breaking people's class paths by introducing additional and potentially conflicting JAR versions?

javornikolov · 2015-07-24T20:13:03Z

are we OK to include an example/sample gradle.properties to show how to set up Sonatype credentials (and a key pair for signing)?

Yes, let's include one but with with a different name. (We can rebase onto master first - it already has gradle.properties in .gitignore).

should/must the list of developers be removed from the POM generation?

I think we can try removing them for now. There is a list to github anyway.

can we agree to use FitNesse release versions instead of dev/build snapshots?

Seems OK at the moment.

are we OK to publish FitLibrary under com.github.dbfit.fitlibrary? Do we want a fork of it anyway, seeing as it appears to be dead?

Whatever would work best now. I think it's OK to fork if needed to get approval for publishing the required fitlibrary version to a public repo.

Are we happy with the approach used to generate dependencies, in the POM file, for the aggregated JAR? (If not we could look to publish a fat JAR. I.e. dbfit-X.Y.Z-standalone.jar though it would be nice to not have to).

Let's try to get a thin version. If needed we can add a fat one in addition to it later.

The rest looks fine to me.

MMatten · 2015-07-24T21:00:54Z

Great.

For:

are we OK to publish FitLibrary under com.github.dbfit.fitlibrary? Do we want a fork of it anyway, seeing as it appears to be dead?

Whatever would work best now. I think it's OK to fork if needed to get approval for publishing the required fitlibrary version to a public repo.

FitLibrary seems to have been abandoned. Very surprising seeing as how prominent it was it the FitNesse world. I tried contacting Darren a while ago but no response. I don't think we're likely to hear from him or Rick but I could try him too. For a thin JAR we'll need all dependencies resolvable from public artefact repos.

FitLibrary used to be published under the fitnesse groupId up until 20080822.

Should I persevere with Rick and Darren or fork FitLibrary 20091020 from SourceFirge under the DbFit GitHub organisation?

MMatten · 2015-07-24T23:04:29Z

Interestingly v1 seems to also have been published:

http://mvnrepository.com/artifact/net.sf.dbfit/dbfit/1.1.2.2

javornikolov · 2015-07-25T09:39:22Z

Should I persevere with Rick and Darren or fork FitLibrary 20091020 from SourceFirge under the DbFit GitHub organisation?

I guess we can do both. If we get support for publishing under the original domain - we can switch to it (and abandon our fork).

MMatten · 2015-07-25T16:28:03Z

A query for a potential later PR....

So, we'll publish the DbFit executables as a single JAR. In that case what value is there in maintaining the current gradle project structure and build targets?

javornikolov · 2015-07-25T20:38:29Z

So, we'll publish the DbFit executables as a single JAR. In that case what value is there in maintaining the current gradle project structure and build targets?

Hmm. Should it be single JAR or we could keep them separate?

MMatten · 2015-07-25T21:37:58Z

Hmm. Should it be single JAR or we could keep them separate?

I'm not sure of the benefits of the existing model. More JARs = more hassle, or just smaller footprint?

Would anyone ever mix versions of DbFit JARs?

javornikolov · 2015-07-25T22:15:50Z

I can imagine: smaller footprint, ability to swap just a part with customized/different version, multiple files can be copied in parallel. I don't say multiple jars is necessarily better, I'm not sure (up to know it hasn't been a huge problem).

I got wondering about the possible use cases/benefits of having dbfit on maven central? Do we need to take care about the binary utility scripts?

MMatten · 2015-07-25T22:48:44Z

My main reason for working on this issue was so that I could create a PR against the FitNesse project to help detect breaking changes like the ill-fated PR 281.

Im not sure why the DbFit 2.0 build switched to having multiple JARs. Maybe driven by the introduction of Maven but guessing really.

The published 1.1 versions were a single JAR.

Do you the encryption utils? Could we bundle them as resources in the JAR? Not perfect.

MMatten · 2015-07-26T21:31:36Z

Some updates applied: -

FitLibrary-20091020 is now available on Maven Central under the com.github.dbfit groupId (http://central.maven.org/maven2/com/github/dbfit/fitlibrary/20091020/).
Developer details removed (but it looks like the <developers> section is still required in the POM by Sonatype).

MMatten · 2015-07-26T21:52:39Z

I've also updated the version number for DbFit in the parent build.gradle so I can test uploading dev snapshots. I guessed at 3.2.0. Is that next (some enhancenents have been added) or would it be a patch release?

MMatten · 2015-07-26T21:57:27Z

There have been some user requests too:

https://groups.google.com/forum/m/#!searchin/dbfit/Maven$20central/dbfit/9-IE8ieuWLU

MMatten · 2015-07-26T22:02:56Z

Also now renamed the skeleton gradle properties file.

javornikolov · 2015-07-26T22:16:22Z

Cool!

3.2.0 is OK for the version number.

I'm not sure why the DbFit 2.0 build switched to having multiple JARs.

I think that's just the default and simplest in case of multiple sub-projects, also seems better in terms of modularity. But it should be OK to have a single jar for Maven Central (as is) if that makes things simpler.

Do you the encryption utils? Could we bundle them as resources in the JAR? Not perfect.

Just the Java classes (as is) looks to be enough to me for now. We're publishing dbfit as a library.

MMatten · 2015-07-26T22:22:29Z

Great!

I think I've no more updates to make then unless you spot anything else.

You can use it to publish 3.2.0 when you release it.

javornikolov · 2015-07-26T22:29:24Z

dbfit-java/build.gradle

What is the default artifact and why do we want to remove it?

The default artefact (artifact) for this project is dbfit-java-X.Y.Z.jar which has no class files in it as there are no Java source files in this project.

The artefact would get signed and published, by default, along with the additional aggregate JARs we create. I can enhance the comments if needed.

I wonder if we could identify the default artifact in a bit more straightforward way (now we rely it's at the end of the list, has 'jar' in the name, etc.). I don't know if it's possible.

Or if using the same logic - maybe can be implemented a bit shorter, e.g. something like:

remove(configurations.archives.artifacts.archives.reverse().find { it.getType() == 'jar' })

now we rely it's at the end of the list

We could simply remove every artifact:

configurations.archives.artifacts.with { archives -> archives.each { remove(it) } }

Do we need to even check the file type/name at all?

If we don't mind relying on the configuration only ever having one default artefact then yes let's condense to a one-liner.

In your snippet, how does the reverse.find work? What does it do?

Ok, so reverse() is just to get at the last element in the List and find() finds the first matching element (in just that last element). So both of these mean that this will work only if the last default artefact is a JAR (which it would be for our specific case).

Or shall we just remove all of the default artefacts?

After some digging into forums (perhaps I should read the docs at some point :-)):

Looks like removing all defaults artifacts would give the same result right now: configurations.archives.artifacts.clear()

If a need emerges to have non-JAR which we need to keep:
configurations.archives.artifacts.removeAll { it.archiveTask.is jar }

perhaps I should read the docs at some point :-)):

Me too. There does seem to be endless ways in which to do any one thing in Gradle. Very flexible but having not really sat down to learn it properly yet it feels a bit hit and miss still.

configurations.archives.artifacts.clear()

Looks good to me!

MMatten · 2015-07-27T20:47:10Z

I've applied the clear() method now.

Anything else to address?

javornikolov · 2015-07-27T20:52:13Z

dbfit-java/build.gradle

Can we have the commas at the end of lines.

Ok. Coming up.

javornikolov · 2015-07-27T21:08:40Z

dbfit-java/build.gradle

What about using the default it param here and in the source (the definitions would be able to fit in single lines).

MMatten · 2015-07-28T10:33:38Z

Horizontal tabs removed and I've replaced the iterator with the default it.

Do you think the code should be squashed to fewer lines still?

MMatten · 2015-07-28T10:35:25Z

dbfit-java/build.gradle

I'm not sure if I can replace this iterator with it because of use in the inner iteration.

Well, it does seem to work (see below) but is it (use of it in outer and inner iterations) too confusing?

task allJar(type: Jar, dependsOn: subprojects.build) { baseName = 'dbfit' subprojects.each { from it.configurations.archives.allArtifacts.files.collect { zipTree(it) } } }

javornikolov · 2015-07-28T22:03:17Z

and I've replaced the iterator with the default it.

Do you think the code should be squashed to fewer lines still?

Yes, it looks a bit better to me if we squash these to one-liners.

MMatten · 2015-07-29T08:06:57Z

Converted to one liners now. What do you think of the formatting?

javornikolov · 2015-07-29T08:33:10Z

Converted to one liners now. What do you think of the formatting?

It looks good to me now 👍

javornikolov · 2015-07-29T10:11:17Z

@MMatten - can we try to publish an initial snapshot version to Maven Central from this branch?

MMatten · 2015-07-29T10:51:32Z

Yes, no problem.

I can do it (I already have a Sonatype login) or would you like to try (so that we can prove the process)?

You can create a login instantly. You'll need to create a support issue in order to get upload access to the com.github.dbfit groupId. They turn around support requests very quickly.

MMatten · 2015-07-29T10:54:08Z

You'll need to create your own public/private key pair too and upload it to a public key server:

http://central.sonatype.org/pages/working-with-pgp-signatures.html

javornikolov · 2015-07-29T11:23:28Z

OK, I can try to register tonight.

javornikolov · 2015-07-30T17:18:00Z

I published via uploadArchives. Now I guess the artifacts are on the staging site, I'm trying to examine how to do the publishing to the central site: http://central.sonatype.org/pages/releasing-the-deployment.html. But I cannot see our project in the list of staging repositories. @MMatten, any idea what needs to be done next?

MMatten · 2015-07-30T17:47:19Z

I can see the 3.2.0-SNAPSHOT snapshot JARs in the search results.

Let me take a look...

MMatten · 2015-07-30T17:48:39Z

Have you removed the -SNAPSHOT from the version number in build.gradle and uploaded a 3.2.0 set of JARs too?

That is if you're ready to publish 3.2.0. Once they're in the target repo we can't delete them.

javornikolov · 2015-07-30T17:53:25Z

No, I haven't changed the version number - it's not for final release yet. I just wondered if we should publish the snapshot to the target repo, but if it's not possible to delete/replace later - it doesn't seem a good idea.

MMatten · 2015-07-30T17:56:19Z

Ok. Cool.

Once you uploaded the release version you should be able to publish it manually via the UI.

You should be able to automatically download the artifacts from the snapshot repo though if you wanted to test including that in a test build.

MMatten · 2015-07-30T19:52:26Z

I've just spotted that I've not updated the publicly available dependencies to include com.github.dbfit.fitlibrary-20091020.jar.

I'll do that now.

…l repo

javornikolov · 2015-07-30T21:32:40Z

Cool, I'm merging. Thank you @MMatten for this great contribution!

Publish dbfit jars to central

javornikolov · 2015-07-30T21:37:06Z

BTW, there is one special thing to consider - JDK version used to build the archives matters (I'm not sure if there is easy way to maintain e.g. both jvm7 and jvm8 artifacts).

MMatten · 2015-07-31T07:22:31Z

Won't the archives be usable with Java 7 when built with Java 8 as long as the compatibility was set to 7 (1.7)?

Also, I'm trying to find out what the minimum Java version for FitNesse is. I can't find any info on the web site but Fitnesse starts up OK with Java 6.

If I create that PR against the FitNesse project, to include basic/smoke testing of DbFit, there will be issues if they're still using Java 6 for their CI.

Should we try to stay aligned with them and potentially go back to supporting Java 6!?

MMatten force-pushed the publish-dbfit-jars-to-central branch from 920d451 to 31175ef Compare July 17, 2015 19:56

javornikolov reviewed Jul 17, 2015
View reviewed changes

MMatten force-pushed the publish-dbfit-jars-to-central branch from 31175ef to 8c7192d Compare July 26, 2015 21:27

javornikolov reviewed Jul 26, 2015
View reviewed changes

MMatten force-pushed the publish-dbfit-jars-to-central branch from 8c7192d to 41335e4 Compare July 27, 2015 20:43

javornikolov reviewed Jul 27, 2015
View reviewed changes

MMatten force-pushed the publish-dbfit-jars-to-central branch from a698250 to 7ad52a6 Compare July 28, 2015 10:31

MMatten reviewed Jul 28, 2015
View reviewed changes

MMatten force-pushed the publish-dbfit-jars-to-central branch from 7ad52a6 to 33d868d Compare July 29, 2015 08:04

Configure build to be able to publish Jars to Sonatype (Maven) Centra…

9902316

…l repo

MMatten force-pushed the publish-dbfit-jars-to-central branch from 33d868d to 9902316 Compare July 30, 2015 20:06

javornikolov added a commit that referenced this pull request Jul 30, 2015

Merge pull request #384 from dbfit/publish-dbfit-jars-to-central

4da3293

Publish dbfit jars to central

javornikolov merged commit 4da3293 into master Jul 30, 2015

javornikolov deleted the publish-dbfit-jars-to-central branch July 30, 2015 21:35

javornikolov added the enhancement label Aug 12, 2015

javornikolov added this to the 3.2.0 milestone Aug 12, 2015

javornikolov mentioned this pull request Aug 15, 2015

Release 3.2.0 #413

Merged

javornikolov changed the title ~~Publish dbfit jars to central~~ Publish dbfit jars to Maven Central Aug 15, 2015

Conversation

MMatten commented Jul 4, 2015

Uh oh!

MMatten commented Jul 17, 2015

Uh oh!

javornikolov commented Jul 17, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MMatten commented Jul 17, 2015

Uh oh!

MMatten commented Jul 24, 2015

Uh oh!

MMatten commented Jul 24, 2015

Uh oh!

javornikolov commented Jul 24, 2015

Uh oh!

MMatten commented Jul 24, 2015

Uh oh!

MMatten commented Jul 24, 2015

Uh oh!

javornikolov commented Jul 25, 2015

Uh oh!

MMatten commented Jul 25, 2015

Uh oh!

javornikolov commented Jul 25, 2015

Uh oh!

MMatten commented Jul 25, 2015

Uh oh!

javornikolov commented Jul 25, 2015

Uh oh!

MMatten commented Jul 25, 2015

Uh oh!

MMatten commented Jul 26, 2015

Uh oh!

MMatten commented Jul 26, 2015

Uh oh!

MMatten commented Jul 26, 2015

Uh oh!

MMatten commented Jul 26, 2015

Uh oh!

javornikolov commented Jul 26, 2015

Uh oh!

MMatten commented Jul 26, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MMatten commented Jul 27, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MMatten commented Jul 28, 2015

Uh oh!

Choose a reason for hiding this comment