search

jamesladd / stc

stc
Other
3 stars 2 forks source link

Maven Repository ... #11

Open jamesladd opened 6 years ago

jamesladd commented 6 years ago

Redline Smalltalk needs to create a Maven Repository JAR when mvn deploy is run.

This will enable anyone wanting to use Redline Smalltalk to include the necessary JAR by including the Maven dependency into their Maven project.

Of course only core commiters should be able to run mvn deploy and have the result pushed to the Maven repository.

jamesladd commented 6 years ago

Later there may be a Maven Redline Smalltalk Architype to create a standard Maven JAR project that automatically includes the Redline Smalltalk dependency so developers can start writing Smalltalk and have their project built and packaged into a JAR they can run or use elsewhere.

TheSecretSquad commented 6 years ago

Since I'm a Maven noob, I've been reading the Maven docs to try to understand more about how it works. I have a lot more to learn, but I think I found the basic things needed to deploy to a remote repo. The pom.xml needs a <distributionManagement> section, and we need a settings.xml with the server authentication information which would be stored on the build server. The <distributionManagement> section can have release and snapshot configurations. EDIT: I see the parent pom from sonatype includes a <distributionManagement> section.

I still need to figure out how the deploy phase chooses to deploy the snapshot vs the release version. I think as long as the pom version contains the text "SNAPSHOT", it uploads to the snaphot repo automatically. Apparently there is a release plugin that does a whole bunch things required to deploy a release instead of a snapshot, such as changing the version in pom.xml.

I'll need to test the deployment. I'm thinking I can install Nexus Repository Manager OSS locally to test deploying to a local repo. Am I on the right track?

jamesladd commented 6 years ago

Peter,

That sounds like a good approach.

I have not yet released a Maven Plugin to a Repository. However, I got close with the following Plugin which may serve as informational to you:

https://github.com/jamesladd/jaws-maven-plugin/blob/master/pom.xml

I was at the stage of having to ask the Repo managers to accept my deployment key (PGP).

Doing stuff locally first is a very good idea.

Hope this helps.

On Mon, Oct 16, 2017 at 11:03 AM, Pete DiSalvo notifications@github.com wrote:

Since I'm a Maven noob, I've been reading the Maven docs to try to understand more about how it works. I have a lot more to learn, but I think I found the basic things needed to deploy to a remote repo. The pom.xml needs a section, and we need a settings.xml with the server authentication information which would be stored on the build server. The section can have release and snapshot configurations.

I still need to figure out how the deploy phase chooses to deploy the snapshot vs the release version. I think as long as the pom version contains the text "SNAPSHOT", it uploads to the snaphot repo automatically. Apparently there is a release plugin that does a whole bunch things required to deploy a release instead of a snapshot, such as changing the version in pom.xml.

I'll need to test the deployment. I'm thinking I can install Nexus Repository Manager OSS locally to test deploying to a local repo. Am I on the right track?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesladd/stc/issues/11#issuecomment-336751885, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGKBKts1Vxpa9GILWxmxbuIMC9TNlC2ks5ssp00gaJpZM4PxOmj .

TheSecretSquad commented 6 years ago

Thanks. That should serve as a good example.

Do we need to make a maven plugin for this, or is this only to upload the redline jar to the repo that can be included as a compile time dependency, e.g. similar to the junit dependency.

jamesladd commented 6 years ago

Do we need to make a maven plugin for this, or is this only to upload the redline jar to the repo that can be included as a compile time dependency, e.g. similar to the junit dependency.

This.

On Mon, Oct 16, 2017 at 12:12 PM, Pete DiSalvo notifications@github.com wrote:

Thanks. That should serve as a good example.

Do we need to make a maven plugin for this, or is this only to upload the redline jar to the repo that can be included as a compile time dependency, e.g. similar to the junit dependency.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesladd/stc/issues/11#issuecomment-336756527, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGKBHSX_PwpCQvp_1iWOTng0z4xREhmks5ssq2OgaJpZM4PxOmj .

TheSecretSquad commented 6 years ago

Hey James. I think we need to update the pom.xml scm element to point to the stc repo under your account for the maven release plugin to do its business. Would you like me to make that change? Currently pointing to the redline account:

<scm>
    <url>git@github.com:redline-smalltalk/redline-smalltalk.git</url>
    <developerConnection>scm:git:git@github.com:redline-smalltalk/redline-smalltalk.git</developerConnection>
    <connection>scm:git:git@github.com:redline-smalltalk/redline-smalltalk.git</connection>
</scm>
jamesladd commented 6 years ago

Please make it so ;)

On Sat, Oct 21, 2017 at 2:09 PM, Pete DiSalvo notifications@github.com wrote:

Hey James. I think we need to update the pom.xml scm element to point to the stc repo under your account for the maven release plugin to do its business. Would you like me to make that change? Currently pointing to the redline account:

git@github.com:redline-smalltalk/redline-smalltalk.git scm:git:git@github.com:redline-smalltalk/redline-smalltalk.git scm:git:git@github.com:redline-smalltalk/redline-smalltalk.git

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesladd/stc/issues/11#issuecomment-338359841, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGKBBmkTiEh99XlgABRKhWQ9NxyYINsks5suWBVgaJpZM4PxOmj .

TheSecretSquad commented 6 years ago

Aye, captain :)

jamesladd commented 6 years ago

Oh, eventually all the work in Stc repo will replace the redline repo

Sent from my Commodore 64

On 21 Oct 2017, at 2:46 pm, Pete DiSalvo notifications@github.com wrote:

Aye, captain :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

TheSecretSquad commented 6 years ago

Does that mean the Stc repo will become the main repo, or will Stc be copied over the redline repo and redline will be the main repo?

TheSecretSquad commented 6 years ago

I notice your jaws maven plugin project uses maven-versions-plugin and nexus-staging-maven-plugin. It looks like these would be used instead of the maven-release-plugin. Is that correct?

jamesladd commented 6 years ago

Yes, eventually my Stic repo will be deleted in favour of using the proper Redline-Smalltalk repo.

On Mon, Oct 23, 2017 at 7:47 AM, Pete DiSalvo notifications@github.com wrote:

Does that mean the Stc repo will become the main repo, or will Stc be copied over the redline repo and redline will be the main repo?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesladd/stc/issues/11#issuecomment-338507875, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGKBNGJ50_eBnY4ZEU2rWSqqTKW9VGaks5su6n8gaJpZM4PxOmj .

jamesladd commented 6 years ago

I’m not sure or fussed which plugins to use as long as we get the result we are looking for which is a JAR uploaded that anyone including the dependency in their POM can fetch.

Sent from my Commodore 64

On 23 Oct 2017, at 3:23 pm, Pete DiSalvo notifications@github.com wrote:

I notice your jaws maven plugin project uses maven-versions-plugin and nexus-staging-maven-plugin. It looks like these would be used instead of the maven-release-plugin. Is that correct?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

TheSecretSquad commented 6 years ago

Hey James. I'm trying to configure the maven-gpg-plugin to sign the artifacts. I generated a gpg key using gpg2, but the plugin is failing during the verify phase with the error: gpg: signing failed: No secret key. I'm having trouble finding information online about this error. I'm thinking I'm using the wrong input for the gpg.keyname, but I can't find anything online that says what the key name should be. Any ideas?

Update: I figured out why it couldn't find the key. I had the gpg.homedir set incorrectly. Now I need to figure out why it's prompting me to enter a passphrase even though I have it configured in settings.xml.

I'm using these for instructions: http://central.sonatype.org/pages/requirements.html http://central.sonatype.org/pages/working-with-pgp-signatures.html

jamesladd commented 6 years ago

Hi Pete,

I think that is where I got stumped too, maybe you could ask a forum ?

I think you have to tell sonotype the passphrase or something like.

Wish I could be more help.

On Tue, Oct 24, 2017 at 2:31 PM, Pete DiSalvo notifications@github.com wrote:

Hey James. I'm trying to configure the maven-gpg-plugin to sign the artifacts. I generated a gpg key using gpg2, but the plugin is failing during the verify phase with the error: gpg: signing failed: No secret key. I'm having trouble finding information online about this error. I'm thinking I'm using the wrong input for the gpg.keyname, but I can't find anything online that says what the key name should be.

I'm using these for instructions: http://central.sonatype.org/pages/requirements.html http://central.sonatype.org/pages/working-with-pgp-signatures.html

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesladd/stc/issues/11#issuecomment-338862444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGKBO6YsZ3XIWWHYXji3REXHCDXRyEsks5svVofgaJpZM4PxOmj .

TheSecretSquad commented 6 years ago

I was able to deploy signed artifacts 😵. It doesn't seem to accept the passphrase from the settings.xml, or from passing on the command line, e.g., mvn deploy -Dgpg.passphrase=something. It always prompts for the passphrase, but doesn't ask for it again after entering it once. I think it's storing it in gpg-agent, and the maven-gpg-plugin is defaulting to the gpg-agent. The problem is gpg-agent only stores it for the current session. We'll need to address this issue in the future if we want to automate deployment.

TheSecretSquad commented 6 years ago

Settings.xml

You will need to update your ~/.m2/settings.xml as follows:

<settings>
    <servers>
        <server>
            <id>ossrh</id>
            <username><!-- Nexus username --></username>
            <password><!-- Nexus password --></password>
        </server>
        <server>
            <id>github</id>
            <privateKey><!-- Path to SSH private key (Typically: ~/.ssh/id_rsa) --></privateKey>
            <passphrase><!-- SSH key passphrase --></passphrase>
        </server>
    </servers>
    <profiles>
        <profile>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <gpg.executable>gpg2</gpg.executable>
                <gpg.keyname><!-- GPG key name --></gpg.keyname>
            </properties>
        </profile>
    </profiles>
</settings>

You can find the GPG key name as follows: The key name from this example (from http://central.sonatype.org/pages/working-with-pgp-signatures.html) is C6EED57A.

$ gpg2 --list-keys

/home/juven/.gnupg/pubring.gpg
------------------------------
pub   1024D/C6EED57A 2010-01-13
uid                  Juven Xu (Juven Xu works at Sonatype) <juven@sonatype.com>
sub   2048g/D704745C 2010-01-13

Deploying

The nexus-staging-maven-plugin is configured to auto release after close via the <autoReleaseAfterClose>true</autoReleaseAfterClose> setting. We can change this value to false if you want to manually manage releasing from staging using command line via mvn nexus-staging:release or from the online repo UI.

All of the commands require the release profile to generate javadoc, sources, and perform signing.

GPG key generation instructions are here http://central.sonatype.org/pages/working-with-pgp-signatures.html. (I tried every settings.xml configuration listed at http://maven.apache.org/plugins/maven-gpg-plugin/usage.html to get the gpg plugin to accept the passphrase without prompting, but none of them worked for me.)

Detailed info on releasing is available at http://central.sonatype.org/pages/apache-maven.html

Deploying Snapshots

  1. Update version in POM, ensuring version value ends with -SNAPSHOT.
  2. Commit POM change in git.
  3. Run mvn deploy -Prelease.

Deploy Release (manual)

  1. Update version in POM, ensuring version value does not end with -SNAPSHOT.
  2. Commit POM changes and any other changes to git repo (e.g., create release branch, tag branch, etc.)
  3. Run mvn deploy -Prelease.

Deploy Release (maven-release-plugin)

The release profile is automatically activated by maven-release-plugin via the <releaseProfiles>release</releaseProfiles> setting.

You can run any of these commands with the -DdryRun=true argument to test them.

  1. Run mvn release:prepare.
  2. Follow versioning prompts.
  3. Run mvn release:perform.

If you don't want maven-release-plugin to prompt for versions, use mvn --batch-mode release:prepare This will use the current snapshot version as the release version, will auto-tag the branch using the same version, and update the development snapshot version to the next minor version. For example, if you have <version>0.6-SNAPSHOT</version> batch mode will create a release version 0.6, with git tag redline-0.6, and new development snapshot 0.7.

You can also pass them on the command line: mvn --batch-mode -Dtag=redline-1.0 release:prepare -DreleaseVersion=1.0 -DdevelopmentVersion=1.1-SNAPSHOT

More info on non-interactive release at http://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html

maven-release-plugin default behavior tags the current branch with the release version. There is another way to configure it to create branches for each release instead; if you prefer.