サブプロジェクト

ウィキペディア小見出し辞書

サブプロジェクト

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/09 01:48 UTC 版)

「Apache Commons」の記事における「サブプロジェクト」の解説

BCEL - Javaバイトコードを扱うライブラリ。 BeanUtils - Java Beansをサポート。 BSF Chain - GoFデザインパターンの一つ、Chain of Responsibility パターンをサポート。 CLI Codec Collections - java.utilパッケージにあるコレクションフレームワークを拡張するクラス群。 Compress - tar, ZIP, bzip2をサポート。 Configuration - Propertiesクラスのような設定ファイルを弄るクラス群。 CSV Daemon DBCP - 関係データベースのコネクションプーリングをサポート。 DBUtils - JDBCをサポートする。 Digester Discovery EL Email - メールライブラリ Exec FileUpload - Java Servlet/JSPでのファイルアップロードをサポート。 IO - java.ioパッケージをサポート。 JCI Jelly Jexl JXPath Lang - java.langパッケージを拡張する。StringUtilsほか、Object#equals(), Object#hashCode(), Object#toString(), Comparable#compareTo()メソッドのオーバーライドを支援するクラスなどが存在する。 Launcher Logging - ひとつのプログラムでJava Logging API(java.util.loggingパッケージ)やJakarta Log4Jを併用し、簡単に複数のロギングAPIを切り替えるときに便利なAPI。 Math - Mathクラスやjava.mathパッケージにはない数学ライブラリを提供。複素数や行列演算、統計学などのライブラリが揃っている。 Modeler Net - java.netパッケージを拡張する。FTPなどのプロトコルを扱うことができる。 Pool - Javaでのオブジェクトプーリングをサポート。 Primitives Proxy SCXML Validator VFS Weaver

サブプロジェクト

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/11/24 16:11 UTC 版)

「Meson (ソフトウェア)」の記事における「サブプロジェクト」の解説

CMakeと同様に、Mesonは主にpkg-configを使用して外部の依存関係を見つける。依存関係の解決はユーザーが行うので、これ自体は依存関係の解決策ではない。別の方法として、依存関係にある他のMesonプロジェクトをサブプロジェクトとして取り込むかリンクすることができる。この方法は、一般的な依存関係の場合にソフトウェアの肥大化に繋がるという欠点がある。Linuxパッケージ作成者が好む妥協案は、サブプロジェクトを外部の依存関係の代替として使用することである。 問題は、MesonがMesonサブプロジェクトだけに対応していることである。一般的な依存関係の場合、WrapDBサービスからmeson.buildをパッチとして適用することで解決する。 異なるビルドシステムにおける依存関係解決の使用例の比較使用例MesonCMakeCargoインストール済みの依存関係の検索 pkg-config CMakeモジュール、pkg-config 不明 依存関係の自動ダウンロード subproject ExternalProject Cargo dependency インストール済みの依存関係の検索と、されていない場合の自動ダウンロード pkg-config + subproject CMakeモジュール、pkg-config + ExternalProject 不明 pkg-configの生成 Yes No No 自動インストールによる依存関係解決を容易にする方法 Mesonサブプロジェクトとして使用可能 No crates.io

サブプロジェクト

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/11/17 15:55 UTC 版)

「React」の記事における「サブプロジェクト」の解説

サブプロジェクトの状態についてはプロジェクトのwikiで利用可能だった。

サブプロジェクト

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/07/28 07:02 UTC 版)

「TRONプロジェクト」の記事における「サブプロジェクト」の解説

「TRONプロジェクト」とは、OSの開発だけでなく、ハードウェアやインターフェースの開発も含めた様々なサブプロジェクトを総称するための名称であり、その下に様々なサブプロジェクトが存在する。 1984年に坂村が開始し、1986年発足のTRON協議会（1988年に「トロン協会」に改称）が中心となって推進した初期のTRONプロジェクトにおいては、組み込み向けOSの「ITRON」、ビジネス向け（現代で言うパソコン向け）OSの「BTRON」、メインフレーム向け（現代で言うサーバー向け）OSの「CTRON」、TRONにおけるヒューマンインターフェイスをデザインする「トロン電子機器HMI研究会」、TRON構想を実現するためのハードウェアを策定する「トロンチップ」、これらを統括する（現代で言う分散コンピューティングに相当する）「MTRON」、の6つが主なプロジェクトとされていた。 「ITRON」プロジェクトの成功を受け、坂村は2000年に開かれたトロン協会の第12回通常総会において、TRONプロジェクトが第2ステージに入ったことを宣言。ITRONの標準化を進めた「μITRON4.0」を継承し、組み込みシステムの高性能化・高機能化に対応した、OSのより強い標準化を進めるため、2001年に次世代のTRONプロジェクト「T-Engineプロジェクト」が発足。2002年発足のT-Engineフォーラムが推進する初期のT-Engineプロジェクトおいては、コミュニケーションマシン（携帯情報端末、携帯電話など）向けの「BTRON3」、旧世代のOSながら依然として広く使われる「μITRON4.0」、などの従来からのサブプロジェクトに加えて、BTRON3で使われるファイル形式の「TAD(TRON Application Databus)」、TRONで16万字以上を扱える多文字環境を実現する「多言語処理環境」、次世代組込みOSの「T-Kernel」、T-Kernelの開発環境として標準化された「T-Engine」、電子伝票システム（現代で言う公開鍵暗号方式）の「eTRON」が主なサブプロジェクトであった。 2011年、T-Kernel2.0の発表と同時にT-Engineプロジェクトの「Step2」が宣言され、それ以前のT-Engineプロジェクトが「Step1」、μITRON4.0が「Step0」と位置付けられた。2015年にT-Engineフォーラムは「トロンフォーラム」と改称され、IoT時代を見据えてTRON本来の役割に立ち返るべく、再び各種のサブプロジェクトの構想が活発化している。 なお、T-Engineプロジェクトの開始後も、レガシー向けに旧来のITRONの需要がまだ残っていたことから、ITRONを推進するトロン協会とT-Kernelを推進するT-Engineフォーラムはしばらく併存していた。トロン協会は2010年に解散したが、ITRONは未だ広く使われており、サポートはT-Engineフォーラム（現・トロンフォーラム）が継承している。