Skip to content
This repository has been archived by the owner on Dec 12, 2024. It is now read-only.

Commit

Permalink
merge
Browse files Browse the repository at this point in the history
  • Loading branch information
gabe committed Aug 21, 2024
1 parent 09cb07b commit 032abcb
Show file tree
Hide file tree
Showing 9 changed files with 369 additions and 148 deletions.
26 changes: 26 additions & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
# Binaries for programs and plugins
*.exe
*.exe~
*.dll
*.so
*.dylib
.gobincache

# Test binary, built with `go test -c`
*.test

# Output of the go coverage tool, specifically when used with LiteIDE
*.out

# Dependency directories (remove the comment below to include it)
# vendor/

# MacOS
.DS_Store

# IDE
.idea/

# Mobile
*.jar
*.aar
2 changes: 1 addition & 1 deletion CODEOWNERS
View file
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@
# The format is described: https://github.blog/2017-07-06-introducing-code-owners/

# These owners will be the default owners for everything in the repo.
* @GITHUB_USER_NAME_GOES_HERE
* @decentralgabe


# -----------------------------------------------
Expand Down
148 changes: 30 additions & 118 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
# Contribution Guide
# Contribution Guide

There are many ways to be an open source contributor, and we're here to help you on your way! You may:

* Propose ideas in our
* Propose ideas in our
[discord](https://discord.gg/tbd)
* Raise an issue or feature request in our [issue tracker](LINK_HERE) ___***FIX LINK AND REMOVE THIS NOTICE***___
* Raise an issue or feature request in our [issue tracker](https://github.com/TBD54566975/vc-jose-cose-go/issues)
* Help another contributor with one of their questions, or a code review
* Suggest improvements to our Getting Started documentation by supplying a Pull Request
* Evangelize our work together in conferences, podcasts, and social media spaces.
Expand All @@ -17,26 +17,26 @@ ___***UPDATE TABLE OF PROJECT DEPS AND INSTALLATION NOTES***___

| Requirement | Tested Version | Installation Instructions |
|-------------|----------------|------------------------------------------------------|
| Go | 1.17.6 |[go.dev](https://go.dev/doc/tutorial/compile-install) |
| Go | 1.22.6 |[go.dev](https://go.dev/doc/tutorial/compile-install) |
| Mage | 1.12.1 |[magefile.org](https://magefile.org/) |
| Java | 17.0.2 | Below, recommended via [SDKMan](https://sdkman.io) |

### Go

This project is written in Go, a modern, open source programming language.
This project is written in Go, a modern, open source programming language.

You may verify your `go` installation via the terminal:

```
$> go version
go version go1.17.6 darwin/amd64
go version go1.22.6 darwin/amd64
```

If you do not have go, we recommend installing it by:

#### MacOS

##### Homebrew

```
$> brew install go
```
Expand All @@ -56,7 +56,7 @@ $> mage --version
Mage Build Tool 1.12.1
Build Date: 2021-12-15T21:00:02Z
Commit: 2f1ec40
built with: go1.17.6
built with: go1.22.6
```

#### MacOS
Expand All @@ -71,101 +71,13 @@ $> brew install mage

Installation instructions are on the [Magefile home page](https://magefile.org/).

### Java

This project is written in Java, a typesafe, compiled programming language.

You may verify your `java` installation via the terminal by running `java -version`.

If you do not have Java, we recommend installing it
via [SDKMan](https://sdkman.io/install). This is a project which will allow you
to easily install the Java Development Kit (JDK), runtime (JRE), and related frameworks,
build tools, and runtimes.

After you've installed SDKMan, you may install Java:

#### SDKMan (cross-platform instructions)

```shell
$> sdk install java
...
Do you want java 17.0.2-open to be set as default? (Y/n): Y
Setting java 17.0.2-open as default.
```

You may test your installation:

```shell
$> java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
```

---
**NOTE**

You may additionally look for other Java versions to install by running `sdk list java`:

...or other installation candidates like Apache Ant, Apache Maven, etc, by running `sdk list`.

Consult the SDKMan documentation for more info.

---

## Build (Mage)

```
$> mage build
```

## Build (Java / Gradle)

### macOS / Linux
```shell
$> ./gradlew build
```

### Windows
```shell
$> gradlew.bat build
```

## Test (Mage)

```
$> mage test
```

## Test (Java / Gradle)

### macOS / Linux
```shell
$> ./gradlew test
```

### Windows
```shell
$> gradlew.bat test
```

---
**NOTE**

You may also combine Gradle build targets in one call, like:

```shell
$> ./gradlew clean build test
```

---

## Communications

### Issues

Anyone from the community is welcome (and encouraged!) to raise issues via
[GitHub Issues](LINK_HERE) ___***FIX LINK AND REMOVE THIS NOTICE***___.
Anyone from the community is welcome (and encouraged!) to raise issues via
[GitHub Issues](https://github.com/TBD54566975/vc-jose-cose-go/issues)

### Discussions

Expand All @@ -175,40 +87,40 @@ We advocate an asynchronous, written debate model - so write up your thoughts an

### Continuous Integration

Build and Test cycles are run on every commit to every branch on [CircleCI](LINK_HERE).
Build and Test cycles are run on every commit to every branch on [GitHub Actions](https://github.com/TBD54566975/vc-jose-cose-go/actions).

___***FIX LINK ABOVE AND REMOVE THIS NOTICE***___

## Contribution

We review contributions to the codebase via GitHub's Pull Request mechanism. We have
the following guidelines to ease your experience and help our leads respond quickly
We review contributions to the codebase via GitHub's Pull Request mechanism. We have
the following guidelines to ease your experience and help our leads respond quickly
to your valuable work:

* Start by proposing a change either in Issues (most appropriate for small
change requests or bug fixes) or in Discussions (most appropriate for design
and architecture considerations, proposing a new feature, or where you'd
* Start by proposing a change either in Issues (most appropriate for small
change requests or bug fixes) or in Discussions (most appropriate for design
and architecture considerations, proposing a new feature, or where you'd
like insight and feedback)
* Cultivate consensus around your ideas; the project leads will help you
pre-flight how beneficial the proposal might be to the project. Developing early
buy-in will help others understand what you're looking to do, and give you a
greater chance of your contributions making it into the codebase! No one wants to
* Cultivate consensus around your ideas; the project leads will help you
pre-flight how beneficial the proposal might be to the project. Developing early
buy-in will help others understand what you're looking to do, and give you a
greater chance of your contributions making it into the codebase! No one wants to
see work done in an area that's unlikely to be incorporated into the codebase.
* Fork the repo into your own namespace/remote
* Work in a dedicated feature branch. Atlassian wrote a great
* Work in a dedicated feature branch. Atlassian wrote a great
[description of this workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)
* When you're ready to offer your work to the project, first:
* Squash your commits into a single one (or an appropriate small number of commits), and
rebase atop the upstream `main` branch. This will limit the potential for merge
conflicts during review, and helps keep the audit trail clean. A good writeup for
how this is done is
[here](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec), and if you're
having trouble - feel free to ask a member or the community for help or leave the commits as-is, and flag that you'd like
* Squash your commits into a single one (or an appropriate small number of commits), and
rebase atop the upstream `main` branch. This will limit the potential for merge
conflicts during review, and helps keep the audit trail clean. A good writeup for
how this is done is
[here](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec), and if you're
having trouble - feel free to ask a member or the community for help or leave the commits as-is, and flag that you'd like
rebasing assistance in your PR! We're here to support you.
* Open a PR in the project to bring in the code from your feature branch.
* The maintainers noted in the `CODEOWNERS` file will review your PR and optionally
* The maintainers noted in the `CODEOWNERS` file will review your PR and optionally
open a discussion about its contents before moving forward.
* Remain responsive to follow-up questions, be open to making requested changes, and...
You're a contributor!
* And remember to respect everyone in our global development community. Guidelines
* And remember to respect everyone in our global development community. Guidelines
are established in our `CODE_OF_CONDUCT.md`.

34 changes: 5 additions & 29 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,38 +1,14 @@
# $PROJECT_NAME README
# VC JOSE COSE in GO

Congrats, project leads! You got a new project to grow!

This stub is meant to help you form a strong community around your work. It's yours to adapt, and may
diverge from this initial structure. Just keep the files seeded in this repo, and the rest is yours to evolve!

## Introduction

Orient users to the project here. This is a good place to start with an assumption
that the user knows very little - so start with the Big Picture and show how this
project fits into it. It may be good to reference/link the broader architecture in the
`collaboration` repo or the developer site here.

Then maybe a dive into what this project does.

Diagrams and other visuals are helpful here. Perhaps code snippets showing usage.

Project leads should complete, alongside this `README`:
* [CODEOWNERS](./CODEOWNERS) - set project lead(s)
* [CONTRIBUTING.md](./CONTRIBUTING.md) - Fill out how to: install prereqs, build, test, run, access CI, chat, discuss, file issues
* [Bug-report.md](.github/ISSUE_TEMPLATE/bug-report.md) - Fill out `Assignees` add codeowners @names
* [config.yml](.github/ISSUE_TEMPLATE/config.yml) - remove "(/add your discord channel..)" and replace the url with your Discord channel if applicable

The other files in this template repo may be used as-is:
* [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
* [GOVERNANCE.md](./GOVERNANCE.md)
* [LICENSE](./LICENSE)
A lightweight go implementation of the [W3C Verifiable Credentials v2 Data Model](https://www.w3.org/TR/vc-data-model-2.0)
with support for [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/).

## Project Resources

| Resource | Description |
| ------------------------------------------ | ------------------------------------------------------------------------------ |
| [CODEOWNERS](./CODEOWNERS) | Outlines the project lead(s) |
| [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md) | Expected behavior for project contributors, promoting a welcoming environment |
| [CONTRIBUTING.md](./CONTRIBUTING.md) | Developer guide to build, test, run, access CI, chat, discuss, file issues |
| [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md) | Expected behavior for project contributors, promoting a welcoming environment |
| [CONTRIBUTING.md](./CONTRIBUTING.md) | Developer guide to build, test, run, access CI, chat, discuss, file issues |
| [GOVERNANCE.md](./GOVERNANCE.md) | Project governance |
| [LICENSE](./LICENSE) | Apache License, Version 2.0 |
Loading

0 comments on commit 032abcb

Please sign in to comment.