Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Maven Repository ... #11

Open
jamesladd opened this issue Oct 7, 2017 · 17 comments
Open

Maven Repository ... #11

jamesladd opened this issue Oct 7, 2017 · 17 comments

Comments

@jamesladd
Copy link
Owner

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
Copy link
Owner Author

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
Copy link
Contributor

TheSecretSquad commented Oct 16, 2017 •
edited
Loading

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
Copy link
Owner Author

jamesladd commented Oct 16, 2017 via email

@TheSecretSquad
Copy link
Contributor

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
Copy link
Owner Author

jamesladd commented Oct 16, 2017 via email

@TheSecretSquad
Copy link
Contributor

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>[email protected]:redline-smalltalk/redline-smalltalk.git</url>
    <developerConnection>scm:git:[email protected]:redline-smalltalk/redline-smalltalk.git</developerConnection>
    <connection>scm:git:[email protected]:redline-smalltalk/redline-smalltalk.git</connection>
</scm>

@jamesladd
Copy link
Owner Author

jamesladd commented Oct 21, 2017 via email

@TheSecretSquad
Copy link
Contributor

Aye, captain :)

@jamesladd
Copy link
Owner Author

jamesladd commented Oct 22, 2017 via email

@TheSecretSquad
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Owner Author

jamesladd commented Oct 23, 2017 via email

@jamesladd
Copy link
Owner Author

jamesladd commented Oct 23, 2017 via email

@TheSecretSquad
Copy link
Contributor

TheSecretSquad commented Oct 24, 2017 •
edited
Loading

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
Copy link
Owner Author

jamesladd commented Oct 24, 2017 via email

@TheSecretSquad
Copy link
Contributor

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
Copy link
Contributor

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) <[email protected]>
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jamesladd @TheSecretSquad