Consumes and produces CycloneDX Software Bill of Materials (SBOM) Consumes and produces CycloneDX Vulnerability Exploitability Exchange (VEX) Component support for: Applications Libraries Frameworks Operating systems Containers Firmware Files Hardware Services Tracks component usage across every application in an organizations portfolio Quickly identify what is affected, and where Identifies multi
下記のような記事を書いていて、 blog.s64.jp 恐怖を煽りすぎてもよくないから本体には書くべきでないと思ったけど こういうこともあるよね、みたいなパターンをいくつか思いついてしまった為ここに書いていく。 みんながみんなGitHub Packages等に移転したら？ BintrayやGitHub Packagesは、利用者ごとにリポジトリの名前空間を分けている。そのため別のユーザが作成したリポジトリからライブラリを参照する場合、それらは都度都度参照元のリポジトリとして書き足していくことになる。 もしあらゆるライブラリ作者がそうしたサービスに移転した場合どうなるか？当然参照先リポジトリ一覧はライブラリの数だけ記述が増える。 参照先リポジトリが増えることには弊害があって、 URLが異なれば同じartifact idを持つライブラリを公開できる（場合が多い）。みんな好きにやったら衝突してし
最近Scalaの勉強も兼ねてjoda-time-fakeというScalaライブラリをMaven Central Repositoryにリリースしてみた。今回はその手順を忘れないようにメモとして残しておく。 今回の手順でできたこと com.github.shibayu36 organizationにjoda-time-fakeとしてライブラリをリリースする Scalaの2.11と2.12でクロスコンパイルして両方共リリースする 最終的にsbt-releaseでリリースを自動化できるようにする 参考資料 自作のScalaライブラリをMaven Central Repositoryにリリースする - Qiitaが一番参考になった。少しハマりどころはあったものの、これを見て一つずつやっていったらリリースまで出来たので感謝。今回の僕の記事はクロスコンパイルして複数バージョン上げるという点が違うだけで
The last time I used Android Studio, it generated .gradle files with mavencentral() buildscript repositories whereas now there's jcenter(). Could anyone explain the issues connected with this. Are there any other repos? When should we switch them? What impact do they have on projects, modules, libs? Any other essentials for Android developers? Who's responsible for maintaining those repos?
AAR パッケージを Maven Central に公開している人は結構いるけど、build.gradle をどういう感じに書けばいいのかわかりづらかったので書き残しておきます。 使用するリポジトリとビルドツール Maven リポジトリ: Sonatype OSS Maven Repository ビルドツール: Gradle AAR パッケージの作成には Android Gradle プラグイン (android-library) を使用 Sonatype OSS Maven Repository の使用について Maven Central Repository にパッケージを公開する方法の 1 つに、Sonatype OSS Maven Repository にパッケージを公開し、それを Maven Central Repository に同期するという方法があります。 これは Apa
今回は "optional" な依存性について見ていきましょう（一覧）。 どんな時に使う？ 他のライブラリへの依存性には、以前書いた「依存性のスコープ」とは別に、その依存性が "optional" かどうかを設定することが出来ます。 これは、対象となっているライブラリを使う際に、そこに指定されているライブラリが必ずしも必要ないということを示しています。 もう少し具体的に言うと、[Library X] が [Library Y] に対して "optional" な依存性を持っているとすると、[Library X] を（自分の）プロジェクト内で使う際に、必ずしも [Library Y] を取得する必要がないということです。 勿論完全に不必要というわけではなく、何らかの機能を使用する際には手動でそのライブラリに依存性を含めなければいけないこともあります。 例えば、dom4j というライブラリにお
Add it in your root settings.gradle at the end of repositories: dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() maven { url 'https://jitpack.io' } } } Add it in your settings.gradle.kts at the end of repositories: dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { m
保育園のおゆうぎ会を見て、我が子の成長ぶりに不覚にもほろっときて歳取ったなと実感している中村です。こんにちは。 今日は、一般に利用できるライブラリをGithubなどで外部に公開しつつ、内部のビジネスに関わるところは非公開リポジトリで開発を進めているようなケースでの、Backlogの事例を紹介します。 Backlog APIに関連する3つのプロジェクト Backlogでは、数ヶ月ほど前からBacklog APIバージョン2とそのJavaラッパーライブラリであるBacklog4J v2を提供開始しました。内部では、Backlog4Jを用いて記述した、APIバージョン2の結合テストを用意しています。これらの関連を図に表すと、下記のようになります。 apiプロジェクトはgit push後、自動的に社内ステージングサーバにデプロイされる Backlog4JはGitHub上で公開されており、artif
前置き：このエントリはJavaおよびJava周辺の*1開発環境に全く縁の無い人間が、可能な限り依存ソフトウェアを少なく手順をシンプルに保ったままやろうとしたものであり、知識・経験のある人にとっては全く最適な手段でなかろうことをお断りします。 先日のエントリ で書いたとおり woothee 1.0.0 をリリースした。Perl, Ruby, Node.js および PHP などはそれぞれの言語毎のモジュールリポジトリに登録されている。 が、Javaについては自分が Maven Central の勝手がわからず、されてると便利だよなーとは思いつつ放置していた。 が、なんと @making さんからMaven Central登録用の pull requestがきた 。きてしまった。これで最大の問題(xmlを書く)はおおむね解決されてしまったので、覚悟を決めて登録作業をすることにした。 せっかくや
JCenter is the place to find and share popular Apache Maven packages for use by Maven, Gradle, Ivy, SBT, etc. For the most comprehensive collection of artifacts, point your Maven at: http://jcenter.bintray.com Want to distribute your own packages through JCenter? You can link your package by clicking the "Include My Package" button. And if you're into legacy, you can even synchronize your packages
何か驚くほどに（日本語の）情報が少ない。めぼしいものといえば、ぐらい？なので、ちょっと書いてみます。 概要 リポジトリ管理ツールとは リポジトリ管理ツールとは、Mavenなどのビルド結果の生成物（アーティファクト）を突っ込むためのリポジトリ（インハウスリポジトリ）を簡単に立てることができるツールです。まあぶっちゃけインハウスリポジトリはWebDAVでも構わないので、Apacheとか使うと簡単に構築することはできます。ただ、ツールとして作られている以上、単純なWebDAVにはない機能も備えているわけでして。 いくつかあげると、 セントラルリポジトリをはじめとした、リモートリポジトリのキャッシュ リポジトリの分割・分割されたリポジトリの仮想的な統一 デプロイされているアーティファクトの検索 Jarの内部を参照可能 セキュリティをロールに応じて細かく設定可能 のような、細かいながらも便利な機能を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
