オープンソースERPのADempiereには、強力で実用的なMRP機能が備わっていますが、
何がどこまでできるのかその実態をまとめてみたいと思います。
また、ここでは、ADempiereのオリジナルとしてもともと実装されている機能をまず紹介し
それに加えて、SMBアソシエイツ株式会社により、追加実装した機能を紹介したいと思います。
■オリジナル機能
ADempiereのLibero Manufacturingにもともと実装され動作している機能の主なものは以下のとおりです。
・MRPの基本機能
受注による所要、先行生産による所要、在庫量、仕掛量、安全在庫などを考慮して、正味所要量計算をおこないます。
生産の必要があれば製造指図伝票を作成し、購買の必要があれば購買依頼伝票を作成します。
また、製造指図伝票を作成した場合、その指図で生産される製品の構成品(BOM)から、下位部品や原材料への所要を発生させます。
下位部品や原材料についても同様に正味所要量計算をおこない、必要があれば製造指図や購買依頼を発生させます。
・先行生産
受注に依存しない独立所要を登録する方法と
受注伝票の伝票タイプとして実装する方法があります。
受注はなくても、生産を先行して行いたいケースに利用できます。
・注文パック数量
受注などから発生した需要をこの単位で認識するよう設定できます。
ex.
10個の注文があるが、100個単位の需要として処理するなど。
・注文最大数量
いわゆるバッチ生産数量。
正味所要量計算の結果、算出された生産量がこの値より小さい場合、この数量単位での生産が提案されます。
ある機械を稼動すれば必ず100個単位で生産される場合や、
ある製品は10個20個といった少ない単位では生産せず、300個単位でしか生産しないといった場合に
この値を利用することができます。
・安全在庫量
MRPパラメータとして設定できる。
主に定量発注品などに利用。
・MRP対象期間
MRPの対象となる期間を設定できます。
ex.
未来30日までの所要(受注)だけを対象とするなど。
(30日後以降の受注予定があっても対象としない)
・歩留まり考慮
歩留まり率、歩留まり量を考慮した生産量が提案されます。
・生産リードタイム考慮
生産リードタイムを考慮した、日程を提案します。
・配送日数考慮
配送日数を考慮したリードタイムを計算し、日程を提案します。
・原価計算
工程ごとの作業実績に応じた自動原価計算がおこなわれます。
標準原価計算として、各工程の直接労務費や間接費、その他経費を登録することで自動で工程にかかったコストが計算されます。
また、品目に対して標準原価を登録しておくことで、各工程のコストとの差異が計算され、記録されます。
・MRPのまわしかた
どこ(倉庫)でまわすのか?
どうまわすのか?(MRPリソース)の2つにより、
対象となる製品のBOMが決定され、この組み合わせに対するMRPパラメータを設定できます。
この設計には、知識とテクニックが必要ですが、
要はADempiereのMRPは、設定しだいでMRPのまわしかた、MRPの対象をいろいろと変更できる柔軟性をもっているということです。
各社のMRP運営方法(いつまわすのか、どの頻度でまわすのか、どの部署の誰がまわすのかなど)によってさまざまな設定方法が可能でそれぞれの要件によって決定されていきます。
ex.
前工程だけでまわす、後工程だけでまわす、特定の製品だけでまわす、あるときは別工場で生産するように設定してまわしてみるなど
■独自追加機能
上記に加えて、SMBアソシエイツ(株)では、ADempiereのオリジナルのMRP機能を拡張しています。
(2015年12月現在のもの、今後も随時機能追加予定)
ここでは、そのリストをまず紹介します。
詳細は、別の記事で詳しく紹介していく予定です。
・バッチ生産に対応した指図の分割
・複数工場(マルチプラント)での生産計画の自動認識による所要量計算
・工程ごとの能力を考慮した生産リードタイム計算と負荷積上計算
・工程ごとの稼働日、非稼働日を考慮した生産計画日程の提案
・工程外注への対応
・取引先、出荷先、品目などの組み合わせに対応した配送日数の設定
・複数ロットへの払い出し
・各工程の詳細作業結果など入力機能
・構成品の払い出しロット選択と管理
・構成品の払い出しロットの結合、分割
・安全在庫計算の適正化
2015年12月30日水曜日
2015年12月12日土曜日
ADempiere 会計仕訳の勘定科目表(備忘録)
ADempiereでどのタイミングで、どの勘定科目が使われて仕訳が作成されるかが表にまとめられています。
データベースとの対比がよくわかります。
http://www.adempiere.com/ADempiere_Accounting
データベースとの対比がよくわかります。
http://www.adempiere.com/ADempiere_Accounting
2015年10月27日火曜日
BigDecimalの落とし穴
BigDecimalの比較をおこなうときは、注意が必要。
BigDecimal bigA = new BigDecimal(0.00);
if( bigA == BigDecimal.ZERO )
{
System.out.println("bigA=ZERO");
}
else
{
System.out.println("bigA is not ZERO");
}
実行結果:bigA is not ZERO
上記の条件式「bigA == BigDecimal.ZERO」は、falseとなります。
「==」演算子で比較をおこなうと、BigDecimalの「0.00」と「0」は、違うものと判断されました。
BigDecimalの値そのものを比較したい場合は、CompareToメソッドを使わなければなりません。
BigDecimal bigA = new BigDecimal(0.00);
if( bigA == BigDecimal.ZERO )
{
System.out.println("bigA=ZERO");
}
else
{
System.out.println("bigA is not ZERO");
}
実行結果:bigA is not ZERO
上記の条件式「bigA == BigDecimal.ZERO」は、falseとなります。
「==」演算子で比較をおこなうと、BigDecimalの「0.00」と「0」は、違うものと判断されました。
BigDecimalの値そのものを比較したい場合は、CompareToメソッドを使わなければなりません。
ZK FrameworkのJavascriptを修正してみる
ZKFrameworkを使えば、開発者はサーバプログラミングを記述するだけで
メンテナンス性の悪いJavaScriptを見る必要はない。
まるで、スタンドアローンアプリケーションを作っているような感覚で
イベント駆動処理をしながら、Webアプリケーションを開発できる。
っていうのが、ZKFrameworkの売り文句のひとつだろうけど
(ひと昔前のASP.Netと同じこと言ってるわけで)
やっぱり、顧客要件によっては、JavaScriptを見なきゃいけない場合も出てくる。
で、いざZKFrameworkのJavaScriptを見ようとすると、複雑怪奇で何のことかさっぱりなんてことになる。
そんなときに、役立つのがChromeの開発者ツール。
これがあれば、ZKFrameworkのJavaScriptのデバッグやカスタマイズもだいぶ楽になる。
難読化コードを整形したり、ステップ実行、ウォッチ、コールスタック表示なども普通にしてくれる。
JavaScriptのデバッグも、ついにここまでできるようになったようだ。
ちなみに、今回は顧客要望により、日付をスラッシュなしで入力しても、YYYY/MM/DDに自動変換するように、修正してみた。
メンテナンス性の悪いJavaScriptを見る必要はない。
まるで、スタンドアローンアプリケーションを作っているような感覚で
イベント駆動処理をしながら、Webアプリケーションを開発できる。
っていうのが、ZKFrameworkの売り文句のひとつだろうけど
(ひと昔前のASP.Netと同じこと言ってるわけで)
やっぱり、顧客要件によっては、JavaScriptを見なきゃいけない場合も出てくる。
で、いざZKFrameworkのJavaScriptを見ようとすると、複雑怪奇で何のことかさっぱりなんてことになる。
そんなときに、役立つのがChromeの開発者ツール。
これがあれば、ZKFrameworkのJavaScriptのデバッグやカスタマイズもだいぶ楽になる。
難読化コードを整形したり、ステップ実行、ウォッチ、コールスタック表示なども普通にしてくれる。
JavaScriptのデバッグも、ついにここまでできるようになったようだ。
ちなみに、今回は顧客要望により、日付をスラッシュなしで入力しても、YYYY/MM/DDに自動変換するように、修正してみた。
EGitで競合を解決する
コミットで競合が発生した場合、マージ作業をおこなわなければいけないのは
他のソース管理と同じだが、
EGitでは、マージを修正完了したファイルを自ら『索引に追加』をおこなうことで
競合を解決したことを認識させる必要があるようだ。
他のソース管理と同じだが、
EGitでは、マージを修正完了したファイルを自ら『索引に追加』をおこなうことで
競合を解決したことを認識させる必要があるようだ。
2015年10月20日火曜日
ZKのアーキテクチャの基本シーケンス図
ZKのAPIをADempiereで触っているけど、どうもしっくりこない。
何のサーブレットがあって、実際どういう役割を担っているのかとか、
まずは、アーキテクチャのシーケンス図的なものがほしかった。
やっとそれを説明してくれているページを見つけた。
http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2008/0802/080101as01/080101as01.html
サーブレットは、zkLoaderとauEngineってのがあって、
zkLoaderがレイアウトを作成し、auEngineがAjaxのEventの入出力口になっているようだ。
何のサーブレットがあって、実際どういう役割を担っているのかとか、
まずは、アーキテクチャのシーケンス図的なものがほしかった。
やっとそれを説明してくれているページを見つけた。
http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2008/0802/080101as01/080101as01.html
サーブレットは、zkLoaderとauEngineってのがあって、
zkLoaderがレイアウトを作成し、auEngineがAjaxのEventの入出力口になっているようだ。
2015年9月7日月曜日
Atmosphereって、なんだ?
iDempiereがZKバージョンアップ対応で使用しているAtmosphereというライブラリ。
これは、いったい何なのか?
少し調べてみると、どうやら非同期通信のためのライブラリのようで
特にAjaxでは実現できないサーバ側からのイベント発生、いわゆるサーバからのPUSHをサポートするようだ。
HTTPアーキテクチャの歴史を整理すると、その位置づけはわかりやすく、
現在の2015年は、Ajaxの問題点が顕在化し、新たなアーキテクチャが求められている時期にあるといえるようだ。
Atmosphereも、そんな中、必要とされるであろうライブラリのようだ。
<HTTPアーキテクチャの歴史概略とAtomosphere>
①Webウェブページは、かつてページを丸ごと更新するのが主流。
スタンドアローンアプリケーションのように、特定のラベルだけを書き換えるなどの処理が難しく
ボタンを押下すると、ページを丸ごと更新する必要があった。
②2006年ごろからAjaxの流行、ページ上の一部だけを更新することが可能になり
リッチなWebページが増えていった。
Ajaxの技術はもともとJavaScriptに存在したもので新しいものではなかったが、
この時期まで使われることはほとんどなかった。
しかし、ネットワークのスピードが速くなったなどの外部要因とのマッチもあり、この時期から急に使われるようになった。
同時にJavascriptの重要性が増したり、Javascriptコードが複雑化してきたことを機に、jQueryを筆頭にJavaScriptのライブラリが充実していくこととなる。
③Ajaxの問題点が顕在化。新たなアーキテクチャが求められる。
Ajaxを使ったウェブページへのバージョンアップが一段落し、その問題点が顕在化してくる。
中でも、HTTPのコネクションのアーキテクチャ上、サーバからイベント発生ができないため、
たとえば、他のユーザの更新情報などをサーバからクライアントへ直接PUSHすることができず、
その代替として、ブラウザ側からサーバの更新を定期的にチェックするなどのコーディングが必要というのは大きな問題として認識された。(ネットワーク負荷やサーバ負荷の増大)
この問題への解決策として以下のようなアーキテクチャが生まれてきた。
・Cometを利用したWebSocket
とにかく接続をひらきっぱなしのストリーミング状態にして、サーバはこの接続を使ってクライアントへのイベントを発生させる。
接続がひらっきぱなしのため、リソースを非常に使ってしまうという問題がある。
CometというアーキテクチャをWebSocketという標準仕様で定義しようとしたが、
このWebSocketのAPI自体が各WebServerのAPIに依存してしまい、ベンダーロックインを引き起こす可能性があるようだ。
・Atmosphere
上記のような問題を解決するべく、WebSocketなどをベンダーロックインにならないように抽象化したりして
非同期通信のライブラリをまとめている。
具体的なコーディング方法や詳細は、これからまた調べていきたいと思う。
これは、いったい何なのか?
少し調べてみると、どうやら非同期通信のためのライブラリのようで
特にAjaxでは実現できないサーバ側からのイベント発生、いわゆるサーバからのPUSHをサポートするようだ。
HTTPアーキテクチャの歴史を整理すると、その位置づけはわかりやすく、
現在の2015年は、Ajaxの問題点が顕在化し、新たなアーキテクチャが求められている時期にあるといえるようだ。
Atmosphereも、そんな中、必要とされるであろうライブラリのようだ。
<HTTPアーキテクチャの歴史概略とAtomosphere>
①Webウェブページは、かつてページを丸ごと更新するのが主流。
スタンドアローンアプリケーションのように、特定のラベルだけを書き換えるなどの処理が難しく
ボタンを押下すると、ページを丸ごと更新する必要があった。
②2006年ごろからAjaxの流行、ページ上の一部だけを更新することが可能になり
リッチなWebページが増えていった。
Ajaxの技術はもともとJavaScriptに存在したもので新しいものではなかったが、
この時期まで使われることはほとんどなかった。
しかし、ネットワークのスピードが速くなったなどの外部要因とのマッチもあり、この時期から急に使われるようになった。
同時にJavascriptの重要性が増したり、Javascriptコードが複雑化してきたことを機に、jQueryを筆頭にJavaScriptのライブラリが充実していくこととなる。
③Ajaxの問題点が顕在化。新たなアーキテクチャが求められる。
Ajaxを使ったウェブページへのバージョンアップが一段落し、その問題点が顕在化してくる。
中でも、HTTPのコネクションのアーキテクチャ上、サーバからイベント発生ができないため、
たとえば、他のユーザの更新情報などをサーバからクライアントへ直接PUSHすることができず、
その代替として、ブラウザ側からサーバの更新を定期的にチェックするなどのコーディングが必要というのは大きな問題として認識された。(ネットワーク負荷やサーバ負荷の増大)
この問題への解決策として以下のようなアーキテクチャが生まれてきた。
・Cometを利用したWebSocket
とにかく接続をひらきっぱなしのストリーミング状態にして、サーバはこの接続を使ってクライアントへのイベントを発生させる。
接続がひらっきぱなしのため、リソースを非常に使ってしまうという問題がある。
CometというアーキテクチャをWebSocketという標準仕様で定義しようとしたが、
このWebSocketのAPI自体が各WebServerのAPIに依存してしまい、ベンダーロックインを引き起こす可能性があるようだ。
・Atmosphere
上記のような問題を解決するべく、WebSocketなどをベンダーロックインにならないように抽象化したりして
非同期通信のライブラリをまとめている。
具体的なコーディング方法や詳細は、これからまた調べていきたいと思う。
2015年7月6日月曜日
ADempiere WorkFlowのシーケンス図
ADempiereWorkFlowのシーケンス図をまとめてみた。
MWFProcessとMWFActivitityの間で、次のノードをチェックしながら処理が繰り返されているようだ。
もっと大きいのは、以下。
MWFProcessとMWFActivitityの間で、次のノードをチェックしながら処理が繰り返されているようだ。
もっと大きいのは、以下。
2015年5月10日日曜日
Eclipseでよく使うショートカットキー
Eclipseで、よく使うショートカットキー
特に、プログラム解析をするときには、知っているのと知らないのでは作業効率に大きく影響する。
■Ctrl + F
文字列を検索する。
■「F3」
メソッド名やクラス名などの上で押下すると、そのメソッドやクラス、変数などの定義にワンタッチで移動できる。
■Alt + ←
メソッドの定義に移動したあとなどに、元の場所へ戻りたいときに使用する。
■Alt + →
Alt + ← の逆。
■Ctrl + T
クラスの継承元や継承先が階層で表示される。
インターフェースを多用しているソース(ポルモルフィズム)を解析するときなどは、重宝する。
メソッドの定義にジャンプすると、インターフェースにジャンプしてしまい、
メソッドの実態がない場合などに実際に呼ばれるであろうクラスを探すときに使用できる。
■Ctrl + Shift + G
メソッド名の上で押下すると、そのメソッドがどこから呼び出されているかがわかる。
■Ctrl + O
メソッドの一覧が表示され、閲覧したいメソッドにワンタッチでジャンプできる。
■Ctrl + スペース
メソッド名などの最初の何文字かを入力したあとに押下すると、候補を表示してくれる。
■Ctrl + L
ダイアログが表示されるので、行番号を入力すると、その行番号へジャンプできる。
■Ctrl + /
コメントアウト、コメントアウトの解除。
特に、プログラム解析をするときには、知っているのと知らないのでは作業効率に大きく影響する。
■Ctrl + F
文字列を検索する。
■「F3」
メソッド名やクラス名などの上で押下すると、そのメソッドやクラス、変数などの定義にワンタッチで移動できる。
■Alt + ←
メソッドの定義に移動したあとなどに、元の場所へ戻りたいときに使用する。
■Alt + →
Alt + ← の逆。
■Ctrl + T
クラスの継承元や継承先が階層で表示される。
インターフェースを多用しているソース(ポルモルフィズム)を解析するときなどは、重宝する。
メソッドの定義にジャンプすると、インターフェースにジャンプしてしまい、
メソッドの実態がない場合などに実際に呼ばれるであろうクラスを探すときに使用できる。
■Ctrl + Shift + G
メソッド名の上で押下すると、そのメソッドがどこから呼び出されているかがわかる。
■Ctrl + O
メソッドの一覧が表示され、閲覧したいメソッドにワンタッチでジャンプできる。
■Ctrl + スペース
メソッド名などの最初の何文字かを入力したあとに押下すると、候補を表示してくれる。
■Ctrl + L
ダイアログが表示されるので、行番号を入力すると、その行番号へジャンプできる。
■Ctrl + /
コメントアウト、コメントアウトの解除。
2015年5月5日火曜日
ADempiereのインストール
ここでは、ADempiereのインストール手順をざっくりと紹介します。
詳細な説明は、以下のサイトより、スターターキット(無料)を申し込めば、
インストールマニュアルや各モジュールをダウンロードでき、もっと容易にADempiereをインストールできます。
ADempiereスターターキット(マニュアルや日本商習慣対応モジュール)
http://adempiere-japan.com/starterkit_download/
■前準備
Javaのインストール
Postgresのインストール
以下、Windowsにインストールするものとして説明しますが、Linuxの場合は、.batを.shに読み替えてください。手順はほぼ同じです。
■インストール手順
①インストールパッケージを入手する。
本家のオリジナルのものは、SourceForgeからダウンロードできます。
②インストールパッケージの配置
①のインストールパッケージを配置します。(C直下とかで問題ない)
③ADempiereフォルダのADempiereEnvTemplate.propertiesを編集する。
JavaのバージョンやDBの設定、WebPortの設定などのこのファイルに記述しておきます。
④③のファイルをADempiereEnv.propertiesとしてコピーする。
⑤インストールの実行
RUN_setup.batを実行すれば、GUIでインストールができます。
(デフォルト値は④で作成したファイルの値になる)
RUN_silentsetup.batを実行すれば、④のファイルの値によって、インストールがGUI画面なしに実行されます。
⑥DBのインポート
ADempiereのデフォルトのDBデータをインポートする場合(初めての方はだいたいこちら)
ADEMPIERE_HOME/utils/RUN_ImpoertAdempiere.batを実行します。
自分で用意したDBデータをインポートする場合
ADEMPIERE_HOME/dataフォルダに、ExpDat.dmpファイルを配置して、ADEMPIERE_HOME/utils/RUN_DBRestore.batを実行。
(ExpDat.dmpは、postgres用のインポートデータファイルです。)
⑦サーバ起動
ADEMPIERE_HOME/utils/RUN_Server2.batを実行する
⑧ブラウザでログインページを起動
http://HOSTNAME:PORT/webui/ にアクセスする。
詳細な説明は、以下のサイトより、スターターキット(無料)を申し込めば、
インストールマニュアルや各モジュールをダウンロードでき、もっと容易にADempiereをインストールできます。
ADempiereスターターキット(マニュアルや日本商習慣対応モジュール)
http://adempiere-japan.com/starterkit_download/
■前準備
Javaのインストール
Postgresのインストール
以下、Windowsにインストールするものとして説明しますが、Linuxの場合は、.batを.shに読み替えてください。手順はほぼ同じです。
■インストール手順
①インストールパッケージを入手する。
本家のオリジナルのものは、SourceForgeからダウンロードできます。
②インストールパッケージの配置
①のインストールパッケージを配置します。(C直下とかで問題ない)
③ADempiereフォルダのADempiereEnvTemplate.propertiesを編集する。
JavaのバージョンやDBの設定、WebPortの設定などのこのファイルに記述しておきます。
④③のファイルをADempiereEnv.propertiesとしてコピーする。
⑤インストールの実行
RUN_setup.batを実行すれば、GUIでインストールができます。
(デフォルト値は④で作成したファイルの値になる)
RUN_silentsetup.batを実行すれば、④のファイルの値によって、インストールがGUI画面なしに実行されます。
⑥DBのインポート
ADempiereのデフォルトのDBデータをインポートする場合(初めての方はだいたいこちら)
ADEMPIERE_HOME/utils/RUN_ImpoertAdempiere.batを実行します。
自分で用意したDBデータをインポートする場合
ADEMPIERE_HOME/dataフォルダに、ExpDat.dmpファイルを配置して、ADEMPIERE_HOME/utils/RUN_DBRestore.batを実行。
(ExpDat.dmpは、postgres用のインポートデータファイルです。)
⑦サーバ起動
ADEMPIERE_HOME/utils/RUN_Server2.batを実行する
⑧ブラウザでログインページを起動
http://HOSTNAME:PORT/webui/ にアクセスする。
2015年4月26日日曜日
ADempiereのJapserReportでIPAフォントを使う
ADempiereの帳票は、JasperReportを使うことで多様なデザインの帳票を作成することができる。
JasperReportとは、OSSの帳票作成プログラムのことである。
.NetやVBに精通している人であれば、GrapeCity社のActiveReportをご存知かと思うが、それと同じような機能を持っているJava用のしかもオープンソースの帳票処理プログラムである。
このJapserReportをADempiereで使うときに、問題となるのがフォントである。
特にLinuxサーバに実装するとき、マイクロソフト系のフォントが使えないという問題がある。
そこで、IPAフォントを使うというのが解決策となる。
また、ADempiereのEARにIPAフォントを含ませることで、OSにIPAフォントをインストールしたりする手間が省けたり、違うOSにEARを持っていったときにフォントなしエラーが出るなどの問題がなくなる。
ここでは、IPAフォントをEARに含める方法をご紹介する。
■IPAフォントを使う設定(EAR内にIPAフォントを含める)
①クラスパスを通したフォルダに、jasperreports_extension.propertiesを用意して、中身を以下にする
net.sf.jasperreports.extension.registry.factory.fonts=net.sf.jasperreports.engine.fonts.SimpleFontExtensionsRegistryFactory
net.sf.jasperreports.extension.simple.font.families.ireport=org/compiere/fonts/fonts_extend.xml
②fonts_extend.xmlを以下のフォルダに作成する。
org/compiere/fonts
中身を以下にして、UTF-8で保存する。
<?xml version="1.0" encoding="UTF-8"?>
<fontFamilies>
<fontFamily name="IPA Pゴシック">
<normal>org/compiere/fonts/ipagp.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPAゴシック">
<normal>org/compiere/fonts/ipag.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPAexゴシック">
<normal>org/compiere/fonts/ipaexg.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPA P明朝">
<normal>org/compiere/fonts/ipamp.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPA明朝">
<normal>org/compiere/fonts/ipam.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPAex明朝">
<normal>org/compiere/fonts/ipaexm.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
</fontFamilies>
③②と同じフォルダに、②のxml内で指定したIPAのttfファイルを配置する。
■フォント変更作業(JasperReport内)
Jrxmlのソースを開いて、fontNameとpdfFontNameでIPAフォントを使用するように置換する。fontNameはフォント名、pdfFontNameはjarファイル名(パス不要)を指定。
<font fontName="MS 明朝" size="16" pdfFontName="HeiseiMin-W3" pdfEncoding="UniJIS-UCS2-HW-H"/>
↓↓
<font fontName="IPA明朝" size="16" pdfFontName="HeiseiMin-W3" pdfEncoding="UniJIS-UCS2-HW-H" isPdfEmbedded="true"/>
JasperReportとは、OSSの帳票作成プログラムのことである。
.NetやVBに精通している人であれば、GrapeCity社のActiveReportをご存知かと思うが、それと同じような機能を持っているJava用のしかもオープンソースの帳票処理プログラムである。
このJapserReportをADempiereで使うときに、問題となるのがフォントである。
特にLinuxサーバに実装するとき、マイクロソフト系のフォントが使えないという問題がある。
そこで、IPAフォントを使うというのが解決策となる。
また、ADempiereのEARにIPAフォントを含ませることで、OSにIPAフォントをインストールしたりする手間が省けたり、違うOSにEARを持っていったときにフォントなしエラーが出るなどの問題がなくなる。
ここでは、IPAフォントをEARに含める方法をご紹介する。
■IPAフォントを使う設定(EAR内にIPAフォントを含める)
①クラスパスを通したフォルダに、jasperreports_extension.propertiesを用意して、中身を以下にする
net.sf.jasperreports.extension.registry.factory.fonts=net.sf.jasperreports.engine.fonts.SimpleFontExtensionsRegistryFactory
net.sf.jasperreports.extension.simple.font.families.ireport=org/compiere/fonts/fonts_extend.xml
②fonts_extend.xmlを以下のフォルダに作成する。
org/compiere/fonts
中身を以下にして、UTF-8で保存する。
<?xml version="1.0" encoding="UTF-8"?>
<fontFamilies>
<fontFamily name="IPA Pゴシック">
<normal>org/compiere/fonts/ipagp.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPAゴシック">
<normal>org/compiere/fonts/ipag.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPAexゴシック">
<normal>org/compiere/fonts/ipaexg.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPA P明朝">
<normal>org/compiere/fonts/ipamp.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPA明朝">
<normal>org/compiere/fonts/ipam.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
<fontFamily name="IPAex明朝">
<normal>org/compiere/fonts/ipaexm.ttf</normal>
<pdfEncoding>Identity-H</pdfEncoding>
<pdfEmbedded>true</pdfEmbedded>
</fontFamily>
</fontFamilies>
③②と同じフォルダに、②のxml内で指定したIPAのttfファイルを配置する。
■フォント変更作業(JasperReport内)
Jrxmlのソースを開いて、fontNameとpdfFontNameでIPAフォントを使用するように置換する。fontNameはフォント名、pdfFontNameはjarファイル名(パス不要)を指定。
<font fontName="MS 明朝" size="16" pdfFontName="HeiseiMin-W3" pdfEncoding="UniJIS-UCS2-HW-H"/>
↓↓
<font fontName="IPA明朝" size="16" pdfFontName="HeiseiMin-W3" pdfEncoding="UniJIS-UCS2-HW-H" isPdfEmbedded="true"/>
2015年4月24日金曜日
Gitサイズが大きいレポジトリのクローンエラー②
EGitでいつものように、クローンをしようとしたら、意味深なメッセージが出た。
aborting due to possible repository corruption on the remote side
ネットを検索すると、Gitのデータが破損している可能性があるとかなんとか・・・
また、面倒くさいことになったなと思いながら、
ふと思いついた。
サーバーのメモリーが足りていないのでは?
SSHでログインして、freeをすると、
案の定、8Gの物理メモリを7.5G以上も使用中ではないか!!!
rebootして、再度クローン。
調子よく動いているとおもっていたら、今度は
なにやらタイムアウトメッセージが・・・
ウィンドウ設定で
チーム=>Git=>リモート接続タイムアウトを500秒にしてもう一度実行。
今度は、問題なくいけた。
面倒なことにならなくてよかった、よかった。
aborting due to possible repository corruption on the remote side
ネットを検索すると、Gitのデータが破損している可能性があるとかなんとか・・・
また、面倒くさいことになったなと思いながら、
ふと思いついた。
サーバーのメモリーが足りていないのでは?
SSHでログインして、freeをすると、
案の定、8Gの物理メモリを7.5G以上も使用中ではないか!!!
rebootして、再度クローン。
調子よく動いているとおもっていたら、今度は
なにやらタイムアウトメッセージが・・・
ウィンドウ設定で
チーム=>Git=>リモート接続タイムアウトを500秒にしてもう一度実行。
今度は、問題なくいけた。
面倒なことにならなくてよかった、よかった。
2015年4月21日火曜日
ADempiere3.8のDB Migrate
ADempiere3.8では、DBのマイグレートバッチが追加された。
ADempiere3.7までは、デフォルトのデータをDBへインポートする場合、
ADempiereをインストール後、RUN_ImportAdempiereを実行すれば、可能だった。
ADempiere3.8では、2つのバッチ(シェル)を使う。
①RUN_ImportReference
②RUN_Migrate
いったん、Referenceスキーマにデータを生成しておいて、ターゲットのスキーマとReferenceスキーマの差分をアップグレードしてくれるようなイメージ。
ADempiere3.7までは、デフォルトのデータをDBへインポートする場合、
ADempiereをインストール後、RUN_ImportAdempiereを実行すれば、可能だった。
ADempiere3.8では、2つのバッチ(シェル)を使う。
①RUN_ImportReference
②RUN_Migrate
いったん、Referenceスキーマにデータを生成しておいて、ターゲットのスキーマとReferenceスキーマの差分をアップグレードしてくれるようなイメージ。
2015年4月17日金曜日
EGitでのRevertでコミットを戻す
EGitで、Revertするとどうなるのかメモ。
EGitで、Gitのヒストリーを表示して、一覧のどれかを右クリックすると
Revertメニュー(コミットを戻す)が表示される。
これをおこなうと、一覧で選択しているコミットを打ち消すためのコミットが作成されるようだ。
それ以外のコミットには、影響しない。
一覧で選択しているコミット時点まで戻るということではないので注意。
<手順詳細>
①プロジェクト全体を指定して、チーム=>ヒストリーを表示。
②ヒストリーの一覧から、戻したいコミットを選択して右クリック
(ここで選択したコミットだけが削除される)
③コミットを戻すをクリックする
④②で選択したコミットだけを戻すための打ち消し用コミットができる。
⑤この状態でPUSHすれば、サーバ側にも反映される。
☆コミットを戻すの実際☆
実際には、「コミットを戻す」というのは、そのコミットを打ち消すソースを自動生成してくれるものの
そのコミット以降のコミットは考慮してくれないので、競合が発生しマージ作業が発生してしまうのがおちだと思う。
マージ作業は、ミスをすれば他の人の修正を消してしまうこともあるだろうし、意外と神経を使う作業なのでできればやりたくないのがプログラマの本音。
つまり、変更する箇所が明確にわかっているのであれば、この機能を使うよりも、自分の記憶を頼りに最新バージョンに対して修正をおこなったほうが、効率的であるし確実であると思う。
EGitで、Gitのヒストリーを表示して、一覧のどれかを右クリックすると
Revertメニュー(コミットを戻す)が表示される。
これをおこなうと、一覧で選択しているコミットを打ち消すためのコミットが作成されるようだ。
それ以外のコミットには、影響しない。
一覧で選択しているコミット時点まで戻るということではないので注意。
<手順詳細>
①プロジェクト全体を指定して、チーム=>ヒストリーを表示。
②ヒストリーの一覧から、戻したいコミットを選択して右クリック
(ここで選択したコミットだけが削除される)
③コミットを戻すをクリックする
④②で選択したコミットだけを戻すための打ち消し用コミットができる。
⑤この状態でPUSHすれば、サーバ側にも反映される。
☆コミットを戻すの実際☆
実際には、「コミットを戻す」というのは、そのコミットを打ち消すソースを自動生成してくれるものの
そのコミット以降のコミットは考慮してくれないので、競合が発生しマージ作業が発生してしまうのがおちだと思う。
マージ作業は、ミスをすれば他の人の修正を消してしまうこともあるだろうし、意外と神経を使う作業なのでできればやりたくないのがプログラマの本音。
つまり、変更する箇所が明確にわかっているのであれば、この機能を使うよりも、自分の記憶を頼りに最新バージョンに対して修正をおこなったほうが、効率的であるし確実であると思う。
2015年4月9日木曜日
ADempiereのDBデータのバックアップとリストア
<ADempiereのDBデータのバックアップ(エクスポート)>
①ADEMPIERE_HOME/utilsに移動
②DBバックアップコマンド実行
prompt> ./RUN_DBExport.sh
③ADEMPIERE_HOME/dataに移動
ここにできたExpDat.dmpがバックアップデータそのもの(エクスポートデータ)。
バックアップとして持っていれば、いつでもリストアできる。
<ADempiereのDBデータをリストア(インポート)>
①ADEMPIERE_HOME/dataに移動
ここに、ExpDat.dmpという名前でリストア用データ(インポートデータ)を配置する。
②ADEMPIERE_HOME/utilsに移動
③DBリストアコマンド実行
prompt> ./RUN_DBRestore.sh
※注:postgresとの接続をすべて切断しておくこと。
サーバプログラムからの接続や、クライアントのPGAdminからの接続もすべて切断しておく。
①ADEMPIERE_HOME/utilsに移動
②DBバックアップコマンド実行
prompt> ./RUN_DBExport.sh
③ADEMPIERE_HOME/dataに移動
ここにできたExpDat.dmpがバックアップデータそのもの(エクスポートデータ)。
バックアップとして持っていれば、いつでもリストアできる。
<ADempiereのDBデータをリストア(インポート)>
①ADEMPIERE_HOME/dataに移動
ここに、ExpDat.dmpという名前でリストア用データ(インポートデータ)を配置する。
②ADEMPIERE_HOME/utilsに移動
③DBリストアコマンド実行
prompt> ./RUN_DBRestore.sh
※注:postgresとの接続をすべて切断しておくこと。
サーバプログラムからの接続や、クライアントのPGAdminからの接続もすべて切断しておく。
ADempiereサーバの起動と停止
<ADempiere サーバ起動>
①ADEMPIERE_HOME/utilsに移動
②サーバ起動コマンド実行
prompt> nohup ./RUN_Server2.sh &
<ADempiere サーバ停止>
①ADEMPIERE_HOME/utilsに移動
②サーバ停止コマンド実行
prompt> ./RUN_Server2Stop.sh
①ADEMPIERE_HOME/utilsに移動
②サーバ起動コマンド実行
prompt> nohup ./RUN_Server2.sh &
<ADempiere サーバ停止>
①ADEMPIERE_HOME/utilsに移動
②サーバ停止コマンド実行
prompt> ./RUN_Server2Stop.sh
iDempiereサーバーの起動と停止
<iDempiere サーバ起動>
nohup ./idempiere-server.sh &
<iDempiere サーバ停止>
telnet localhost 12612
close
※12612ポートは、idempiere.iniで記述したポート。
nohup ./idempiere-server.sh &
<iDempiere サーバ停止>
telnet localhost 12612
close
※12612ポートは、idempiere.iniで記述したポート。
iDempiereに、Eclipseなしで新しいプラグインをインストールする方法
■プラグインのインストール方法(Eclipseなし)
①jarをpluginsフォルダに配置する
idempiere-server/plugins/
②サーバを起動
nohup ./idempiere-server.sh &
③OSGIコンソールに接続
telnet localhost 12612
(idempiere.iniで指定しているポート番号)
④プラグインををインストール
osgi> install file:①のプラグインファイル名
ex.
osgi> install file:/usr/local/adempiere/idempiere-server/plugins/org.libero.manufacturing_3.0.0.201503181333.jar
※ssと入力して、インストールしたプラグインが出てきたらOK。
ex.
osgi> ss
182 INSTALLED org.libero.manufacturing_3.0.0.201503181333
⑤④のIDの部分(182)を使って、インストールしたプラグインを開始する。
osgi> start 182
※もういちど、ssと入力してACTIVEになったらOK
ex.
osgi> ss
182 ACTIVE org.libero.manufacturing_3.0.0.201503181333
⑥telnet切断
osgi> CTRL+]
telnet> quit
①jarをpluginsフォルダに配置する
idempiere-server/plugins/
②サーバを起動
nohup ./idempiere-server.sh &
③OSGIコンソールに接続
telnet localhost 12612
(idempiere.iniで指定しているポート番号)
④プラグインををインストール
osgi> install file:①のプラグインファイル名
ex.
osgi> install file:/usr/local/adempiere/idempiere-server/plugins/org.libero.manufacturing_3.0.0.201503181333.jar
※ssと入力して、インストールしたプラグインが出てきたらOK。
ex.
osgi> ss
182 INSTALLED org.libero.manufacturing_3.0.0.201503181333
⑤④のIDの部分(182)を使って、インストールしたプラグインを開始する。
osgi> start 182
※もういちど、ssと入力してACTIVEになったらOK
ex.
osgi> ss
182 ACTIVE org.libero.manufacturing_3.0.0.201503181333
⑥telnet切断
osgi> CTRL+]
telnet> quit
2015年2月16日月曜日
ADempiere と iDempiereの違い
ADempiereとiDempiereの違いについて、
ネットでの情報、特に日本語情報の中に勘違いされやすい情報が多くありますので
ここで、私が知っている範囲で、できるだけ正確にまとめておきます。(2015年2月現在)
■iDempiereは、ADempiereの後継ではない
iDempiereは、ADempiereから派生したプロジェクトであり、後継というわけではありません。
ADempiereプロジェクトも今もなお活動中です。
2015年1月1日付けで3.8.0のLTSがリリースされたばかりで、
かなりたくさんの機能が追加され、生産管理のLiberoモジュールがデフォルト装備となったりしました。
iDempiereだけが活動しているというのは間違いで、どちらも今なお活動中であり
また、ADempiere、iDempiereにそれぞれの特徴があり、これらを比較しても、必ずしもどちらがよいといえる状況ではないといえます。
むしろ、現時点では、先に世に出て動作検証が多くされているADempiereのほうが優れている部分が多い状況であるともいえます。
一方で、ADempiereもiDempiereも、7割8割ぐらいは、Compiereというパッケージのソースコードからできており、同じDNAを持つパッケージであるため、兄弟のようなものともいえます。
■iDempiereは、プラグイン構造になっている
iDempiereは、OSGIによるプラグイン構造をもっており、サードパティがプラグインを開発して追加できる構造を持っています。
これにより、たくさんのサードパーティプラグインが増えていけば、いろいろな機能がプラグインとして提供されることが期待されていますが、現時点ではまだそのような状態にはなく、ADempiereから存在しているモジュールをiDempiere用にプラグイン化していく過程にあるといえます。
■iDempiereは、生産管理機能を持っている??
iDempiereの生産管理には、「Manufactureing Lite」と
ADempiereでの実績がある「Libero Manufacturing」があります。
・Manufactureing Lite
Manufactureing Liteについて、私は詳しくはありませんが、
現在は、MRPがないという状況のようです。
というより、下記のサイトの文言から、むしろMRPは、必要ないという考え方を持っているようで、今後も提供されることはないと考えられます。
http://wiki.idempiere.org/en/NF1.0_Manufacturing_Light
<上記サイト文言抜粋>
Please note that manufacturing methodologies like Theory of constraints or Lean don't require (and even don't recommend) the usage of MRP/CRP.
訳:メモしてください。リーンやTOC理論のような開発手法では、MRP/CRPを必要としない。MRP/CRPをお勧めさえしない。ということを。
この考え方は、個人的には疑問が残ります。
少なからず、日本の製造業企業に生産管理を導入する場合、多くの場合、MRPは必須であると考えますし、ニーズも要件も厳しいと感じているからです。
・Libero Manufacturing
一方、Libero Manufacturing についてです。
Libero Manufacturingは、MRPを実装しており、ADempiereでも実績があるため、
iDempiereでも動作するのではないかと思われる方もいるかもしれませんが
実際に、iDempiereに実装し動作させようとすると、容易にはいかないようです。
少し手直しをしたりしなければいけない部分もありますし
まだまだ動作確認が必要な部分が多くあるように思います。
私のほうでは、本流フローが動作するところまで手直しを加えており
引き続き動作検証中です。
iDempiereの生産管理に指図入庫画面がない
※Liberoは、バグが多いという情報がよくありますが、私はそういう印象を全くもっておりません。
確かにマニュアルや情報が少ないために、正常動作を確認するまでに時間がかかる部分はあり、その途中段階においてバグと判断される嫌いがあるのかもしれませんが、作者の意図を理解し利用方法の習得にいたれば、品質の高いものであることが理解できます。
また、ソースコードを見れば、非常に技術力の高い方が作成されたことも理解できます。
■JBossとTomcat
ADempiereは、もともとJBoss4で動作しています。
iDempiereは、Tomcatで動作します。そのため、JBoss4の数倍軽くなりました。
しかし、軽快さを手に入れた分、スケーラビリティという点ではJBossに劣ります。
TomcatとEquinoxというEclipseのプラグインアーキテクチャがどこまでの規模のシステムに耐えられるかには、疑問が残る部分です。
一方、ADempiereは、JBossを採用しており、スケーラビリティの不安はありませんが、少し重たい印象はあります。
それを改善するために、日本ADempiereの会では、ADempiereをJBoss7に対応しており、JBoss4に比べて起動時間が大幅に短縮されました。
また、WebLogicやWASなどその他のJ2EEサーバでの開発も可能なようにカスタマイズをしています。
■UI
ADempiereもiDempiereも、ZKFramworkというUIのフレームワークを採用しております。
ADempiereは、まだzk3.6で、iDempiereは、zk6までバージョンアップさせています。
iDempiereでは、グリッド列を動的に並べ替えたり、非表示にしたりが可能になっており、とても便利です。
ADempiere3.8では、テーマを変えることができ、サイトの雰囲気をワンタッチで切り替えることができます。
■技術者のデリバリー
今後、ADempiereやiDempiereの導入プロジェクトが増えていったときに考えるべきことは、技術者のデリバリーの観点です。
この点では、どちらもJavaを採用しており、技術者のデリバリーは比較的容易と思われます。
ただ、ひとつ気になる点は、iDempiereでの開発は、Eclipseプラグイン開発が必須となる点です。
プラグイン開発を経験しているJava技術者は、かなり少数であると思われ、どの技術者も最初は多少の戸惑いがあると思われます。
全体ボリュームからいけば、プラグインの知識を深く必要とする開発は一部であり、大きな課題にはならないと思われますが、観点としては考慮すべき点と思われます。
■現時点での考察(2015年2月現在)
先行者利益という部分で、ADempiereのほうが機能が充実しており、また実績もありますので信頼性も高いといえます。
iDempiereの安定感としては、ADempiereには劣りますが、サードパーティのプラグインが増えていけば、かなりの機能充実が期待されますし、このタイミングで先行して、多少の検証フェーズを加味しながら導入するというのも可能な時期になっていることは確かです。
また、もともとのコミッターの多くがiDempiereにいることも心強いことです。
このように、ADempiere、iDempiereを比較したとき、絶対こっちがいいということを今しばらくは言い切れない状況にあると思います。
ADempiere、iDempiereの特徴を理解した上で、それぞれの要件にあったほうを賢明に選択することが重要であると考えられます。
ネットでの情報、特に日本語情報の中に勘違いされやすい情報が多くありますので
ここで、私が知っている範囲で、できるだけ正確にまとめておきます。(2015年2月現在)
■iDempiereは、ADempiereの後継ではない
iDempiereは、ADempiereから派生したプロジェクトであり、後継というわけではありません。
ADempiereプロジェクトも今もなお活動中です。
2015年1月1日付けで3.8.0のLTSがリリースされたばかりで、
かなりたくさんの機能が追加され、生産管理のLiberoモジュールがデフォルト装備となったりしました。
iDempiereだけが活動しているというのは間違いで、どちらも今なお活動中であり
また、ADempiere、iDempiereにそれぞれの特徴があり、これらを比較しても、必ずしもどちらがよいといえる状況ではないといえます。
むしろ、現時点では、先に世に出て動作検証が多くされているADempiereのほうが優れている部分が多い状況であるともいえます。
一方で、ADempiereもiDempiereも、7割8割ぐらいは、Compiereというパッケージのソースコードからできており、同じDNAを持つパッケージであるため、兄弟のようなものともいえます。
■iDempiereは、プラグイン構造になっている
iDempiereは、OSGIによるプラグイン構造をもっており、サードパティがプラグインを開発して追加できる構造を持っています。
これにより、たくさんのサードパーティプラグインが増えていけば、いろいろな機能がプラグインとして提供されることが期待されていますが、現時点ではまだそのような状態にはなく、ADempiereから存在しているモジュールをiDempiere用にプラグイン化していく過程にあるといえます。
■iDempiereは、生産管理機能を持っている??
iDempiereの生産管理には、「Manufactureing Lite」と
ADempiereでの実績がある「Libero Manufacturing」があります。
・Manufactureing Lite
Manufactureing Liteについて、私は詳しくはありませんが、
現在は、MRPがないという状況のようです。
というより、下記のサイトの文言から、むしろMRPは、必要ないという考え方を持っているようで、今後も提供されることはないと考えられます。
http://wiki.idempiere.org/en/NF1.0_Manufacturing_Light
<上記サイト文言抜粋>
Please note that manufacturing methodologies like Theory of constraints or Lean don't require (and even don't recommend) the usage of MRP/CRP.
訳:メモしてください。リーンやTOC理論のような開発手法では、MRP/CRPを必要としない。MRP/CRPをお勧めさえしない。ということを。
この考え方は、個人的には疑問が残ります。
少なからず、日本の製造業企業に生産管理を導入する場合、多くの場合、MRPは必須であると考えますし、ニーズも要件も厳しいと感じているからです。
・Libero Manufacturing
一方、Libero Manufacturing についてです。
Libero Manufacturingは、MRPを実装しており、ADempiereでも実績があるため、
iDempiereでも動作するのではないかと思われる方もいるかもしれませんが
実際に、iDempiereに実装し動作させようとすると、容易にはいかないようです。
少し手直しをしたりしなければいけない部分もありますし
まだまだ動作確認が必要な部分が多くあるように思います。
私のほうでは、本流フローが動作するところまで手直しを加えており
引き続き動作検証中です。
iDempiereの生産管理に指図入庫画面がない
確かにマニュアルや情報が少ないために、正常動作を確認するまでに時間がかかる部分はあり、その途中段階においてバグと判断される嫌いがあるのかもしれませんが、作者の意図を理解し利用方法の習得にいたれば、品質の高いものであることが理解できます。
また、ソースコードを見れば、非常に技術力の高い方が作成されたことも理解できます。
■JBossとTomcat
ADempiereは、もともとJBoss4で動作しています。
iDempiereは、Tomcatで動作します。そのため、JBoss4の数倍軽くなりました。
しかし、軽快さを手に入れた分、スケーラビリティという点ではJBossに劣ります。
TomcatとEquinoxというEclipseのプラグインアーキテクチャがどこまでの規模のシステムに耐えられるかには、疑問が残る部分です。
一方、ADempiereは、JBossを採用しており、スケーラビリティの不安はありませんが、少し重たい印象はあります。
それを改善するために、日本ADempiereの会では、ADempiereをJBoss7に対応しており、JBoss4に比べて起動時間が大幅に短縮されました。
また、WebLogicやWASなどその他のJ2EEサーバでの開発も可能なようにカスタマイズをしています。
■UI
ADempiereもiDempiereも、ZKFramworkというUIのフレームワークを採用しております。
ADempiereは、まだzk3.6で、iDempiereは、zk6までバージョンアップさせています。
iDempiereでは、グリッド列を動的に並べ替えたり、非表示にしたりが可能になっており、とても便利です。
ADempiere3.8では、テーマを変えることができ、サイトの雰囲気をワンタッチで切り替えることができます。
■技術者のデリバリー
今後、ADempiereやiDempiereの導入プロジェクトが増えていったときに考えるべきことは、技術者のデリバリーの観点です。
この点では、どちらもJavaを採用しており、技術者のデリバリーは比較的容易と思われます。
ただ、ひとつ気になる点は、iDempiereでの開発は、Eclipseプラグイン開発が必須となる点です。
プラグイン開発を経験しているJava技術者は、かなり少数であると思われ、どの技術者も最初は多少の戸惑いがあると思われます。
全体ボリュームからいけば、プラグインの知識を深く必要とする開発は一部であり、大きな課題にはならないと思われますが、観点としては考慮すべき点と思われます。
■現時点での考察(2015年2月現在)
先行者利益という部分で、ADempiereのほうが機能が充実しており、また実績もありますので信頼性も高いといえます。
iDempiereの安定感としては、ADempiereには劣りますが、サードパーティのプラグインが増えていけば、かなりの機能充実が期待されますし、このタイミングで先行して、多少の検証フェーズを加味しながら導入するというのも可能な時期になっていることは確かです。
また、もともとのコミッターの多くがiDempiereにいることも心強いことです。
このように、ADempiere、iDempiereを比較したとき、絶対こっちがいいということを今しばらくは言い切れない状況にあると思います。
ADempiere、iDempiereの特徴を理解した上で、それぞれの要件にあったほうを賢明に選択することが重要であると考えられます。
2015年2月11日水曜日
ADempiere とは
ADempiereは、オープンソースコミュニティから生まれたERPパッケージです。
販売・購買・在庫・生産・会計の各業務を統合したパッケージで以下のような特徴があります。
■オープンソースである
オープンソースのため、ライセンスが無料です。
また、ソースが公開されているため、拡張やカスタマイズが可能です。
■ノンプログラミングでカスタマイズができる
画面追加や変更、画面項目の追加や変更がノンプログラミングでGUIからできます。
そのため、画面が足りない、レポートが足りない、画面項目が足りないなどといったことがあっても
GUIから簡単に追加することができ、誰でも簡単にカスタマイズができるため、コストをおさえることができます。
■開発初期からグローバルを想定している
マルチ言語、マルチ通貨、マルチ会計など、プロジェクトの立ち上げ当初からグローバルを意識したつくりになっており、グローバル対応に強いパッケージといえます。
■各業務機能が充実している
販売・購買・在庫・生産・会計の各業務を備えています。
また、人事給与、固定資産管理なども追加モジュールとして提供されています。
受注伝票、発注伝票、出荷伝票、仕入れ伝票など各伝票登録画面、
自動仕訳、入金、消しこみ処理はもちろん、
生産管理では、MRPによる所要量計算・指図作成や原価計算機能、
見込み生産のための独立所要登録機能なども備えています。
■レポートや帳票
レポートや帳票も充実しており、
注文書、納品書、請求書など標準のものが実装されています。
必要があれば、JasperReportによりカスタマイズが可能で、個別の帳票フォーマットを作成することも可能です。
オンラインレポート機能では、ノンプログラミングで自由に出力するレポートを構成することができます。
■サブシステムとの連携
サブシステムとの連携として、インポート画面を装備しており
注文データ、会計データ、ワークフローなどさまざまなデータのインポートを想定しています。
また、アウトプットとしては、レポート出力機能によりCSV、Excel、HTML、PDFとさまざまな形式でデータを出力できます。
さらに、リアルタイムな連携として、追加モジュールによりWebServiceを使用した連携にも対応が可能です。
WebServiceを使用すれば、ADempiereのデータをインポートなどの処理をはさまずに、サブシステムからリアルタイムに即時に閲覧、更新することが可能です。
販売・購買・在庫・生産・会計の各業務を統合したパッケージで以下のような特徴があります。
■オープンソースである
オープンソースのため、ライセンスが無料です。
また、ソースが公開されているため、拡張やカスタマイズが可能です。
■ノンプログラミングでカスタマイズができる
画面追加や変更、画面項目の追加や変更がノンプログラミングでGUIからできます。
そのため、画面が足りない、レポートが足りない、画面項目が足りないなどといったことがあっても
GUIから簡単に追加することができ、誰でも簡単にカスタマイズができるため、コストをおさえることができます。
■開発初期からグローバルを想定している
マルチ言語、マルチ通貨、マルチ会計など、プロジェクトの立ち上げ当初からグローバルを意識したつくりになっており、グローバル対応に強いパッケージといえます。
■各業務機能が充実している
販売・購買・在庫・生産・会計の各業務を備えています。
また、人事給与、固定資産管理なども追加モジュールとして提供されています。
受注伝票、発注伝票、出荷伝票、仕入れ伝票など各伝票登録画面、
自動仕訳、入金、消しこみ処理はもちろん、
生産管理では、MRPによる所要量計算・指図作成や原価計算機能、
見込み生産のための独立所要登録機能なども備えています。
■レポートや帳票
レポートや帳票も充実しており、
注文書、納品書、請求書など標準のものが実装されています。
必要があれば、JasperReportによりカスタマイズが可能で、個別の帳票フォーマットを作成することも可能です。
オンラインレポート機能では、ノンプログラミングで自由に出力するレポートを構成することができます。
■サブシステムとの連携
サブシステムとの連携として、インポート画面を装備しており
注文データ、会計データ、ワークフローなどさまざまなデータのインポートを想定しています。
また、アウトプットとしては、レポート出力機能によりCSV、Excel、HTML、PDFとさまざまな形式でデータを出力できます。
さらに、リアルタイムな連携として、追加モジュールによりWebServiceを使用した連携にも対応が可能です。
WebServiceを使用すれば、ADempiereのデータをインポートなどの処理をはさまずに、サブシステムからリアルタイムに即時に閲覧、更新することが可能です。
2015年2月9日月曜日
iDempiereにWebFormプラグインを作成する Page5
前回に続いて、iDempiereにWebFormプラグインを作成する方法を説明する。
Page1
Page2
Page3
Page4
⑤実行構成とデプロイ設定にプラグインを追加
ここまでで、ソースの追加や設定はほぼ完了している。
残りは、実行構成のプラグインの設定と、パッケージとしてデプロイするときのプラグイン設定である。
以下の設定をする前に、一度プロジェクト全体をコンパイルしておくことをお勧めする。
1.実行構成にプラグインを追加
2.デプロイ設定にプラグインを追加
Page1
Page2
Page3
Page4
⑤実行構成とデプロイ設定にプラグインを追加
ここまでで、ソースの追加や設定はほぼ完了している。
残りは、実行構成のプラグインの設定と、パッケージとしてデプロイするときのプラグイン設定である。
以下の設定をする前に、一度プロジェクト全体をコンパイルしておくことをお勧めする。
1.実行構成にプラグインを追加
2.デプロイ設定にプラグインを追加
iDempiereにWebFormプラグインを作成する Page4
前回に続いて、iDempiereにWebFormプラグインを作成する方法を説明する。
Page1
Page2
Page3
このページでは、OSGI.INFの設定をおこなう。
④OSGI.INFの設定
ここでは、OSGI.INFを編集して、IFormFactoryの拡張ポイントを設定する。
この設定により、iDempiereのコアから、このプラグインのクラスが呼ばれるようになる。
Page1
Page2
Page3
このページでは、OSGI.INFの設定をおこなう。
④OSGI.INFの設定
ここでは、OSGI.INFを編集して、IFormFactoryの拡張ポイントを設定する。
この設定により、iDempiereのコアから、このプラグインのクラスが呼ばれるようになる。
1.org.idempiere.lieromfg_webformsプロジェクトのフォルダ内に 「OSGI_INF」フォルダを作成する。 2.「OSGI_INF」フォルダを右クリックして、新規=>その他をクリック 3.上記のウィンドウが表示されるので、 コンポーネント定義を選択して、次へをクリック |
1.親フォルダに先ほど作成した「OSGI_INF」フォルダを選択 2.ファイル名を入力 3.名前を入力 4.完了をクリック |
1.名前を入力 2.Classを入力 3.プロパティを追加をクリック 4.ダイアログで、名前に「service.ranking」を入力 5.ダイアログで、型に「Integer」を入力 6.ダイアログで、値に「1」を入力 7.ダイアログで、OKをクリック 8.サービスタブをクリック |
1.下のほうのProvidedServicesで追加をクリック 2.ダイアログで、「org.adempiere.webui.factory.IFormFactory」 を入力して選択 3.ダイアログで、OKをクリック 4.このファイルを保存する Page5へ続く |
2015年2月8日日曜日
iDempiereにWebFormプラグインを作成する Page3
前回に続いて、iDempiereにWebFormプラグインを作成する方法を説明する。
Page1
Page2
このページでは、MANIFEST.MFの設定をおこない、プラグインの概要や依存関係などを設定する。
③MANIFEST.MFの設定
ここでは、MANIFEST.MFの設定をしていく。
MANIFEST.MFについては、こちらを参照
Page1
Page2
このページでは、MANIFEST.MFの設定をおこない、プラグインの概要や依存関係などを設定する。
③MANIFEST.MFの設定
ここでは、MANIFEST.MFの設定をしていく。
MANIFEST.MFについては、こちらを参照
1.liberomfg_webformsのMANIFEST.MFをダブルクリックして開く。 3.プラグインのID、バージョン、名前を入力する 4.アクティベータで、org.adempiere.plugin.utils.AdempiereActivator を選択する 5.このプラグインはシングルトンにチェック |
1.依存関係に画像のように構成する。 これを設定すればコンパイルが通るようになる |
Page4へ |
iDempiereにWebFormプラグインを作成する Page2
前回に続いて、iDempiereにWebFormプラグインを作成する方法を説明する。
前回はこちら
このページでは、指図入庫のソースファイル「WOrderReceiptIssue」とIFormFactoryを実装したクラスの追加をおこなう。
②ソースコードを作成する。
1.WOrderReceiptIssueクラスをorg.eevolution.formに作成する。
このクラスは、ADempiereのLiberoに存在するクラスだが
iDempiere用に少しカスタマイズする必要がある。
2.IFormFactoryを実装したクラスを作成する。
これが、WebFormプラグインを作成するときにポイントとなるクラス。
このクラスがOSGIの拡張ポイントに設定され、iDempiereのコアから呼ばれるようになる。
そして、指定されたWebFormインスタンスを生成する役割を持っている。
IFromFactoryのnewFormInstanceメソッドが新しいFormを作成するメソッドで
かつiDempiereのコアから呼ばれるメソッドで、
ここで新しいWebFormを作成するコードを記述すればよい。
ここでは、LiberoWebFormFactoryクラスを作成した。
また、WebForm作成時に使用するクラスローダーは、
新規プラグインのパッケージのスコープのものでなければならず、
DefaultFormFactoryを継承するだけでは、うまく動作しないので注意が必要。
参考:New zk Form in iDempiere: ClassNotFoundException
この状態で、コンパイルをしてもまだエラーが出てしまう。 依存関係の設定をしていないからである。 次回は、そのあたりを説明していく。
Page3
前回はこちら
このページでは、指図入庫のソースファイル「WOrderReceiptIssue」とIFormFactoryを実装したクラスの追加をおこなう。
②ソースコードを作成する。
1.WOrderReceiptIssueクラスをorg.eevolution.formに作成する。
このクラスは、ADempiereのLiberoに存在するクラスだが
iDempiere用に少しカスタマイズする必要がある。
2.IFormFactoryを実装したクラスを作成する。
これが、WebFormプラグインを作成するときにポイントとなるクラス。
このクラスがOSGIの拡張ポイントに設定され、iDempiereのコアから呼ばれるようになる。
そして、指定されたWebFormインスタンスを生成する役割を持っている。
IFromFactoryのnewFormInstanceメソッドが新しいFormを作成するメソッドで
かつiDempiereのコアから呼ばれるメソッドで、
ここで新しいWebFormを作成するコードを記述すればよい。
ここでは、LiberoWebFormFactoryクラスを作成した。
また、WebForm作成時に使用するクラスローダーは、
新規プラグインのパッケージのスコープのものでなければならず、
DefaultFormFactoryを継承するだけでは、うまく動作しないので注意が必要。
参考:New zk Form in iDempiere: ClassNotFoundException
この状態で、コンパイルをしてもまだエラーが出てしまう。 依存関係の設定をしていないからである。 次回は、そのあたりを説明していく。
Page3
iDempiereにWebFormプラグインを作成する Page1
前回の投稿で、iDempiereの生産管理には、指図入庫のWEB用画面がないと説明した。
ここでは、この画面の作成方法を順をおって、説明する。
また、この作成方法は、WebFormのプラグインの作成方法としても参考可能である。
☆参考サイトは、こちら☆
WebFormプラグインの作成方法(英語)
新規プラグインの作成方法(英語)
このページでは、まずプラグインプロジェクトの作成をウィザードでおこなう。
①プラグインプロジェクトの作成
ここでは、この画面の作成方法を順をおって、説明する。
また、この作成方法は、WebFormのプラグインの作成方法としても参考可能である。
☆参考サイトは、こちら☆
WebFormプラグインの作成方法(英語)
新規プラグインの作成方法(英語)
このページでは、まずプラグインプロジェクトの作成をウィザードでおこなう。
①プラグインプロジェクトの作成
1.Eclipseメニューのファイル=>新規=>その他をクリック 2.プラグインプロジェクトをクリック |
1.プロジェクト名を入力 2.実行ターゲットで、OSGIフレームワークを選択、かつEquinoxを選択 3.次へをクリック |
1.IDを入力:org.idempiere.liberomfg_webforms 2.バージョンを入力 3.名前を入力:Liberomfg_webforms 4.アクティベータを生成のチェックをはずす 5.次をクリック |
1.以下のテンプレートを使用して・・・のチェックをはずす 2.完了をクリック Page2へ続く |
2015年2月6日金曜日
iDempiereの生産管理に指図入庫画面がない
ADempiereでは、生産管理モジュールにLibero Manufacturingを使うことで、
MRPや製造指図管理、作業実績報告、指図入庫など生産管理機能は充実しており問題なく動作するし、
さらにADempiere 3.8ではデフォルトパッケージ内にLiberoの生産管理が含まれている。
しかし、iDempiereの生産管理は、まだまだADempiereの生産管理の完成度に追いついていないようだ。
そのひとつの理由が、iDempiereの生産管理には、現時点(2015年2月現在)で指図入庫画面(WEB版)が提供されていないこと。
指図入庫画面は、原材料や部品を払いだして製造指図を完成させる画面で、生産管理では本流フローのひとつの画面。
iDempiereでは、これがまだ提供されていない。
この本流フローのひとつの画面がないと、どうしようにも使えないので
本家でリリースされる前にこちらで作ってみた。
作成方法をこちらでご紹介しよう。
MRPや製造指図管理、作業実績報告、指図入庫など生産管理機能は充実しており問題なく動作するし、
さらにADempiere 3.8ではデフォルトパッケージ内にLiberoの生産管理が含まれている。
しかし、iDempiereの生産管理は、まだまだADempiereの生産管理の完成度に追いついていないようだ。
そのひとつの理由が、iDempiereの生産管理には、現時点(2015年2月現在)で指図入庫画面(WEB版)が提供されていないこと。
指図入庫画面は、原材料や部品を払いだして製造指図を完成させる画面で、生産管理では本流フローのひとつの画面。
iDempiereでは、これがまだ提供されていない。
この本流フローのひとつの画面がないと、どうしようにも使えないので
本家でリリースされる前にこちらで作ってみた。
作成方法をこちらでご紹介しよう。
2015年2月2日月曜日
iDempiere Eclipse開発環境構築 Page3
前回に続いて、iDempiereをEclipseで開発するための環境構築について説明です。
1回目の内容は、Page1
2回目の内容は、Page2
このページでは、Buckminsterを使って、Eclipseへソースの取り込みをおこなう。
⑤ソースの配置
1.1回目でダウンロードしたソースを「c:\workspace_idempiere」に配置
1回目の内容は、Page1
2回目の内容は、Page2
このページでは、Buckminsterを使って、Eclipseへソースの取り込みをおこなう。
⑤ソースの配置
1.1回目でダウンロードしたソースを「c:\workspace_idempiere」に配置
1.上記のような感じで、ソースをワークスペース直下に配置する。 |
⑥Buckminsterでソースを読み込み
1.ファイル=>インポートをクリック 2.上記画像のように、Buckminsterをクリック 3.さらに「Materialize from Buckminster・・・」をクリック 4.次へをクリック 5.org.adempiere.sdk-feature フォルダを選択 6.完了をクリック |
終了後、各プラグインのソースがEclipseにインポートされる。 |
iDempiere Eclipse開発環境構築 Page2
前回に続いて、iDempiereをEclipseで開発するための環境構築について説明です。
前回の内容は、こちら
このページでは、Eclipseプラグイン開発に必要なターゲットプラットフォームの設定をおこなう。
④TargetPlatformの設定
1.エクスプローラから、workspace直下に「targetPlatform」フォルダを作成する。c:\workspace_idempiere\targetPlatform
2.ウィンドウ=>設定をクリックし、以下の設定をおこなう
前回の内容は、こちら
このページでは、Eclipseプラグイン開発に必要なターゲットプラットフォームの設定をおこなう。
④TargetPlatformの設定
1.エクスプローラから、workspace直下に「targetPlatform」フォルダを作成する。c:\workspace_idempiere\targetPlatform
2.ウィンドウ=>設定をクリックし、以下の設定をおこなう
1.プラグイン開発=>ターゲット・プラットフォーム をクリック 2.追加ボタンを押下する ※参考:hengsinさんのページ : https://kenai.com/projects/hengsin/pages/TargetPlatform |
1.「何もありません:空のターゲット定義で開始」を選択して、次へ |
1.名前に、「iDempiere Target Platform」を入力 2.追加ボタンをクリック |
1.ディレクトリーを選択して、次へ |
1.ロケーションに「${workspace_loc}/targetPlatform」を入力 2.完了をクリック |
1.環境タブをクリック |
1.オペレーティング・システムに「*」を入力 2.ウィンドウ操作システムに「*」を入力 3.アーキテクチャに「*」を入力 4.完了をクリック |
1.作成した「iDempiere Target Platform」を選択する 2.OKボタンをクリック ☆☆☆ ページ3へ続く ☆☆☆ |
iDempiere Eclipse開発環境構築 Page1
ここでは、iDempiereをEclipseで開発するための環境構築について説明します。
☆まずは、参考URLを紹介☆
プラグイン開発の目次ページ
http://wiki.idempiere.org/en/Category:Plug-In_Development
Eclipse環境構築方法
http://www.globalqss.com/wiki/index.php/IDempiere/Setting_up_Eclipse
hengsinさんのページ
https://kenai.com/projects/hengsin/pages/Building
☆前準備☆
前準備として、EclipseとiDempiereのSourceCodeのダウンロードをしておく。
①Eclipse keplerのダウンロード
http://mergedoc.sourceforge.jp/
ここで、Eclipse 4.3 keplerのJava Full Versionのダウンロードがベター。
②iDempiereのソースをダウンロード
https://bitbucket.org/idempiere/idempiere
リアルタイムにソースをダウンロードしたい人でなく
区切り区切りのソースがほしいだけの場合は
上記ページで、
1.左下のダウンロードをクリック
2.ページ中央上の「タグ」をクリック
3.適当なバージョンを選んで、zipをダウンロードする
(普通は最新を選ぶ)
の手順でよい。
☆環境構築☆
このページでは、Eclipseの配置、Eclipseプラグインとして利用するBuckminsterのインストールまでをおこなう。
①Keplerを展開=> c:\eclipse_idempiere
ここでは、Cの直下に上記フォルダ名で展開
②workspaceを作成 => c:\workspace_idempiere
ここでは、Cの直下に上記フォルダ名で作成
③buckminsterプラグインのインストール
☆☆☆ ページ2へ続く ☆☆☆
☆まずは、参考URLを紹介☆
プラグイン開発の目次ページ
http://wiki.idempiere.org/en/Category:Plug-In_Development
Eclipse環境構築方法
http://www.globalqss.com/wiki/index.php/IDempiere/Setting_up_Eclipse
hengsinさんのページ
https://kenai.com/projects/hengsin/pages/Building
☆前準備☆
前準備として、EclipseとiDempiereのSourceCodeのダウンロードをしておく。
①Eclipse keplerのダウンロード
http://mergedoc.sourceforge.jp/
ここで、Eclipse 4.3 keplerのJava Full Versionのダウンロードがベター。
②iDempiereのソースをダウンロード
https://bitbucket.org/idempiere/idempiere
リアルタイムにソースをダウンロードしたい人でなく
区切り区切りのソースがほしいだけの場合は
上記ページで、
1.左下のダウンロードをクリック
2.ページ中央上の「タグ」をクリック
3.適当なバージョンを選んで、zipをダウンロードする
(普通は最新を選ぶ)
の手順でよい。
☆環境構築☆
このページでは、Eclipseの配置、Eclipseプラグインとして利用するBuckminsterのインストールまでをおこなう。
①Keplerを展開=> c:\eclipse_idempiere
ここでは、Cの直下に上記フォルダ名で展開
②workspaceを作成 => c:\workspace_idempiere
ここでは、Cの直下に上記フォルダ名で作成
③buckminsterプラグインのインストール
1.ヘルプ=>新規ソフトウェアのインストールをクリック 2.上記のウィンドウで、作業対象に以下のURLを入力 ※URLは、Eclipseのバージョンにあわせる。(updates-xxx) 3.BuckminsterとBuckminster Sourceを選択して、フルインストールしておく |
☆☆☆ ページ2へ続く ☆☆☆
SVNからGitに乗り換えたときに初めて聞くであろう用語
SVNからGitに乗り換えたときに、知らない用語がたくさん出てくる。
そんな用語をここで、まとめておく。
■clone (クローン)
クローンとは、SVNでのチェックアウトとほぼ同じ意味。
簡単に言えば、リポジトリから、ローカルにファイルを落としてくること。
ちなみに、Gitでのチェックアウトは、SVNの意味と違うので注意が必要。
Gitでのチェックアウトとは、作業ブランチを切り替える(決定する)意味。
devブランチからmasterブランチに切り替えるとき、masterブランチをチェックアウトするという。
■push (プッシュ)
リモートのリポジトリへ反映すること。
Gitでは、ローカルにリポジトリをもつので、コミットとはローカルのリポジトリに反映することとなり、その状態では、サーバーに反映されていない。
プッシュして、はじめてリモートに反映されることとなる。
ここがSVNとの大きな違いといえる。
■pull (プル)
プル=コミット+プッシュの反対。
プル=フェッチ+マージ
サーバリポジトリからローカルリポジトリにデータを取得し(これをフェッチという)、さらに作業ブランチへも反映する。(これをマージという)
[注]プルは使うなという人もいるように、実は奥が深いのがこのコマンド。
リスク回避のためには、フェッチしてマージするほうがベターのよう。
■fetch (フェッチ)
プルでおこなわれるうちの最初のほう。
サーバリポジトリからローカルリポジトリにデータを取得するまでをフェッチという。
■merge (マージ)
プルでおこなわれるうちの後のほう。
ローカルリポジトリから作業ブランチへ反映するまでをマージという。
コンフリクトが発生する場合もあるので、手動マージをおこなうなどで対処する。
■HEAD
対象のブランチの先頭のこと。
つまり、最新コミットのこと。
HEADと一言で言っても、どのブランチのHEADなのかを意識しないと危険。
(ブランチがリモートなのかローカルなのかmasterなのかdevなのかなど。)
■origin
リモートをあらわす意味で使われることが多い。
■fast forward
ブランチ元のブランチへマージしようとしたとき、ブランチ元で新たなコミットがないため、コンフリクトなしにそのままマージできること。
細かい話でいうと、HEADの書き換えだけでマージができてしまう状態のこと。
ex.
masterブランチからdevブランチを作成したあと、devブランチでコミットを1回した。
masterでは、コミットされていない。
この状態で、devブランチをmasterブランチにマージしたとき、コンフリクトなしでマージできるので、これをfast forwardという。
■non fast forward
ブランチ元のブランチへマージしようとしたとき、ブランチ元で新たなコミットがあるとき、non fast forwardという。
要は、コンフリクト(競合)しているということ。
そのまま、マージせず、手動マージするなどの対応をするのが普通。
■rebase (リベース)
一度分岐したブランチをマージするときに、分岐した歴史を消すこと
そのブランチでのコミットがあたかも、マスター上(マージ後ブランチ)でコミットされたようになる。
リベース後は、2つの枝だった状態がマスタ(マージ後ブランチ)だけの1つの枝になる。
■cherry-pick (チェリーピック)
あるブランチ上の特定のコミットだけをマスター(他のブランチ)に反映するコマンド。
リベースがブランチ上のすべてのコミットを対象にするのに対し、こちらは特定のコミットだけを対象とする。
■stash (スタッシュ)
作業の途中で、他のブランチに切り替えるときに、作業状態を記憶しておくこと。
stashにプッシュするとかいう。
Gitの場合、これをせずに、ブランチを切り替えると、コミットしていないものとかは消えてしまうので注意が必要。
再び、もとのブランチに戻ってきたときに、プッシュしたものをポップすると元の作業状態に戻すことができる。
保存したブランチと違うブランチでポップする(元に戻す)と、ブランチ違いでも適用されてしまうので注意が必要。
複数stashできて、呼び戻すときも対象のものを選ぶことができる。
stash saveするときに、メッセージもつけれる。
EGitでは、チームメニューおよびGitRepogitoriesパースペクティブでできるよう
stash changeメニューやStashリストから適用、削除を実行する感じ
http://wiki.eclipse.org/EGit/New_and_Noteworthy/2.0
そんな用語をここで、まとめておく。
■clone (クローン)
クローンとは、SVNでのチェックアウトとほぼ同じ意味。
簡単に言えば、リポジトリから、ローカルにファイルを落としてくること。
ちなみに、Gitでのチェックアウトは、SVNの意味と違うので注意が必要。
Gitでのチェックアウトとは、作業ブランチを切り替える(決定する)意味。
devブランチからmasterブランチに切り替えるとき、masterブランチをチェックアウトするという。
■push (プッシュ)
リモートのリポジトリへ反映すること。
Gitでは、ローカルにリポジトリをもつので、コミットとはローカルのリポジトリに反映することとなり、その状態では、サーバーに反映されていない。
プッシュして、はじめてリモートに反映されることとなる。
ここがSVNとの大きな違いといえる。
■pull (プル)
プル=コミット+プッシュの反対。
プル=フェッチ+マージ
サーバリポジトリからローカルリポジトリにデータを取得し(これをフェッチという)、さらに作業ブランチへも反映する。(これをマージという)
[注]プルは使うなという人もいるように、実は奥が深いのがこのコマンド。
リスク回避のためには、フェッチしてマージするほうがベターのよう。
■fetch (フェッチ)
プルでおこなわれるうちの最初のほう。
サーバリポジトリからローカルリポジトリにデータを取得するまでをフェッチという。
■merge (マージ)
プルでおこなわれるうちの後のほう。
ローカルリポジトリから作業ブランチへ反映するまでをマージという。
コンフリクトが発生する場合もあるので、手動マージをおこなうなどで対処する。
■HEAD
対象のブランチの先頭のこと。
つまり、最新コミットのこと。
HEADと一言で言っても、どのブランチのHEADなのかを意識しないと危険。
(ブランチがリモートなのかローカルなのかmasterなのかdevなのかなど。)
■origin
リモートをあらわす意味で使われることが多い。
■fast forward
ブランチ元のブランチへマージしようとしたとき、ブランチ元で新たなコミットがないため、コンフリクトなしにそのままマージできること。
細かい話でいうと、HEADの書き換えだけでマージができてしまう状態のこと。
ex.
masterブランチからdevブランチを作成したあと、devブランチでコミットを1回した。
masterでは、コミットされていない。
この状態で、devブランチをmasterブランチにマージしたとき、コンフリクトなしでマージできるので、これをfast forwardという。
■non fast forward
ブランチ元のブランチへマージしようとしたとき、ブランチ元で新たなコミットがあるとき、non fast forwardという。
要は、コンフリクト(競合)しているということ。
そのまま、マージせず、手動マージするなどの対応をするのが普通。
■rebase (リベース)
一度分岐したブランチをマージするときに、分岐した歴史を消すこと
そのブランチでのコミットがあたかも、マスター上(マージ後ブランチ)でコミットされたようになる。
リベース後は、2つの枝だった状態がマスタ(マージ後ブランチ)だけの1つの枝になる。
■cherry-pick (チェリーピック)
あるブランチ上の特定のコミットだけをマスター(他のブランチ)に反映するコマンド。
リベースがブランチ上のすべてのコミットを対象にするのに対し、こちらは特定のコミットだけを対象とする。
■stash (スタッシュ)
作業の途中で、他のブランチに切り替えるときに、作業状態を記憶しておくこと。
stashにプッシュするとかいう。
Gitの場合、これをせずに、ブランチを切り替えると、コミットしていないものとかは消えてしまうので注意が必要。
再び、もとのブランチに戻ってきたときに、プッシュしたものをポップすると元の作業状態に戻すことができる。
保存したブランチと違うブランチでポップする(元に戻す)と、ブランチ違いでも適用されてしまうので注意が必要。
複数stashできて、呼び戻すときも対象のものを選ぶことができる。
stash saveするときに、メッセージもつけれる。
EGitでは、チームメニューおよびGitRepogitoriesパースペクティブでできるよう
stash changeメニューやStashリストから適用、削除を実行する感じ
http://wiki.eclipse.org/EGit/New_and_Noteworthy/2.0
2015年2月1日日曜日
Eclipseプラグイン開発の初歩
iDempiereの開発で最初のハードルとなるのは、
Eclipseプラグイン開発についての知識。
プラグインの追加は、たびたびしたとしても、
プラグインを開発したことがある人は、かなり少数派と思われる。
iDempiereの開発では、この知識が必須となるので、
最初のハードルとなり、私も例にもれず苦労した。
そこで、Eclipseプラグイン開発の基本についてまとめておきたい。
☆まずは、基本用語について☆
■featureとは?
プラグインのリストを定義するところ。
featureによって、プラグインを束にして、パッケージ化するようなイメージ。
たとえば、iDempiereでは、org.adempiere.server-featureというfeatureがある。
ここには、idempiere-serverで使用されるプラグインのリストが定義されている。
■pluginとは?
プラグインそのものが入っているところ。
ソースファイルやjarは、こちらに入る。
■拡張ポイントとは?
プラグインの最大の特徴は、サードパーティがプラグインを容易に提供できること。
それを実現するのがこの拡張ポイント。
あらかじめ、用意されている拡張ポイントに対して、
プラグインを作成することで
既存のパッケージの動作を拡張することができる。
たとえば、iDempiereには、org.adempiere.webui.Formという拡張ポイントが用意されているが
ここに対して、新たなプラグインを作成することで新しいWebFormを追加することができる。
☆次に、主要なファイルについて☆
■feature.xml
featureの定義を記述するファイル。
featureに含まれるプラグインのリストやfeatureに含まれるfeature(ネストできる)
featureが依存するプラグインなどを記述する。
■plugin.xml
プラグインがもつ拡張ポイントなどを定義する。
(そのプラグインがどこを拡張するのかの情報)
■MANIFEST.MF
プラグインのマニフェスト。
プラグインのID、名前、バージョンや
依存するプラグインなどの情報が記述される
■OSGI.INFと拡張ポイント
独自のプラグインを作成するときには、特にこの理解が必要。
ここにプラグインが提供するインターフェースやプラグインが使用するインターフェースを定義する。
プラグイン間の紐付きを具体的におこなうクラスを定義するイメージ。
☆最後にEclipseのエディタでの設定方法について☆
Eclipseで、feature.xmlやplugin.xmlをダブルクリックすると
専用のエディタが起動して、GUIで各ファイルを意識せずに設定できる。
GUIで設定すれば、上記で設定した各ファイルが変更される。
もちろん、feature.xmlやplugin.xmlなどを直接編集することもできるし、
GUIの設定でどのファイルがどう更新されるかを知っておいたほうがベター。
Eclipseプラグイン開発についての知識。
プラグインの追加は、たびたびしたとしても、
プラグインを開発したことがある人は、かなり少数派と思われる。
iDempiereの開発では、この知識が必須となるので、
最初のハードルとなり、私も例にもれず苦労した。
そこで、Eclipseプラグイン開発の基本についてまとめておきたい。
☆まずは、基本用語について☆
■featureとは?
プラグインのリストを定義するところ。
featureによって、プラグインを束にして、パッケージ化するようなイメージ。
たとえば、iDempiereでは、org.adempiere.server-featureというfeatureがある。
ここには、idempiere-serverで使用されるプラグインのリストが定義されている。
■pluginとは?
プラグインそのものが入っているところ。
ソースファイルやjarは、こちらに入る。
■拡張ポイントとは?
プラグインの最大の特徴は、サードパーティがプラグインを容易に提供できること。
それを実現するのがこの拡張ポイント。
あらかじめ、用意されている拡張ポイントに対して、
プラグインを作成することで
既存のパッケージの動作を拡張することができる。
たとえば、iDempiereには、org.adempiere.webui.Formという拡張ポイントが用意されているが
ここに対して、新たなプラグインを作成することで新しいWebFormを追加することができる。
☆次に、主要なファイルについて☆
■feature.xml
featureの定義を記述するファイル。
featureに含まれるプラグインのリストやfeatureに含まれるfeature(ネストできる)
featureが依存するプラグインなどを記述する。
■plugin.xml
プラグインがもつ拡張ポイントなどを定義する。
(そのプラグインがどこを拡張するのかの情報)
■MANIFEST.MF
プラグインのマニフェスト。
プラグインのID、名前、バージョンや
依存するプラグインなどの情報が記述される
■OSGI.INFと拡張ポイント
独自のプラグインを作成するときには、特にこの理解が必要。
ここにプラグインが提供するインターフェースやプラグインが使用するインターフェースを定義する。
プラグイン間の紐付きを具体的におこなうクラスを定義するイメージ。
☆最後にEclipseのエディタでの設定方法について☆
Eclipseで、feature.xmlやplugin.xmlをダブルクリックすると
専用のエディタが起動して、GUIで各ファイルを意識せずに設定できる。
GUIで設定すれば、上記で設定した各ファイルが変更される。
もちろん、feature.xmlやplugin.xmlなどを直接編集することもできるし、
GUIの設定でどのファイルがどう更新されるかを知っておいたほうがベター。
登録:
投稿 (Atom)