Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

以前、Gradle3におけるJavaプロジェクトのビルドについてのエントリーを書きましたが、Gradle3のJVM component modelって、まあ、わりと、Java9のJigsawみたいなものなんですね。で、Jigsaw自体知っている人が多いと思いますが、あらためてJigsawが解決したい問題(と僕が勝手に認識しているもの)とその解決方法について、雑にまとめてみることにしました。 なお、Gradle3のJVM component modelでのビルドについてはこちらを参照。 mike-neck.hatenadiary.com JVM component modelとJigsawとの関連について、少し言及があるエントリーについてはこちらを参照。 mike-neck.hatenadiary.com あと、Jigsawについて一番よくまとまっている資料見れば、このエントリーを見る必要は
前回は、JVM component modelによるJavaプロジェクトのビルドの入門をおこなった。 mike-neck.hatenadiary.com これまでのjavaプラグインに比べると記述量が増えてしまうが、遜色ないビルドができることは示せたと思う。 複数ライブラリー(コンポーネント) 前回、簡単にするためにmainというライブラリーだけに限ってプロジェクトのビルドを行いましたが、複数のライブラリー(コンポーネント)を指定することも可能でした。そこで、今回はまず複数のライブラリーを作成するプロジェクトを構築してみたいと思います。 前回用いたMainクラスとResクラスをそれぞれ別のライブラリーに分けることにします。 クラス ライブラリー sample.Main main sample.Res res また、resources/app.propertiesファイルはmainライブラリ
Post published:July 4, 2014 Post Author:Mattias Severson Post Category:Java / Testing / Web Post Comments:80 Comments Spring Boot brings about some welcome defaults configurations that significantly decreases the development time of Spring projects. It also has some useful additions when it comes to simplified integration testing. Traditionally, one would use the build script to fire up an embedde
以前、Spring MVC 3.2のSpring MVC Testを触ったでSpring MVC 3.2から導入されたSpring MVCのテストを紹介しましたが、今回はJSONのテストについて紹介します。 今回のアプリケーションもGitHubに上げています。いろいろなSpringのサンプルをまとめています。 https://github.com/kuwalab/SpringSample Eclipse 4.3でMaven+WTPのプロジェクトとして作成していますので、その環境であればプロジェクトをimportすることですぐに使えます。 サンプル中のspring_mvc32_json_testフォルダをEclipseのプロジェクトとしてインポートしてください。 テスト用のアプリケーション テスト用のアプリケーションとして、簡易書籍管理アプリケーションを作ります。今回はJSONのテストのため
Recently I had the opportunity to rewrite an existing Spring Boot application as a Ratpack application at my current client. The application is a sort of security proxy to pass through requests from the wild, untamed internet to sane, internal services. We decided to try Ratpack over Spring Boot for the potential performance gains that Ratpack should provide. If you’ve been living under a rock and
Guice で、@ImplementedBy を使用してインジェクションしているときの 簡単な動作検証。 (親)Main → Service → Logic → Dao という親子関係で構築されているクラス群を作成した。以下ソースを子から順に。 まず、Dao。実装は、DaoImpl と DaoImpl2。 package test.dao; import com.google.inject.ImplementedBy; @ImplementedBy(DaoImpl.class) public interface Dao { public String getName(int key); } package test.dao; public class DaoImpl implements Dao { private DaoImpl() { System.out.println(this);
factory系で生成したオブジェクトをDIしましょうという機能らしい。 やり方は2通りで、Providerを実装するか、@Providesインスタンスで指定するか。 ただのhogeを返すProvider. public class SampleProvider implements Provider<String> { public String get() { return "hoge"; } }こちらは、上の"hoge"を返すプロバイダーを"sample"という名前付きでStringにbindする例と、@Providesを利用して、"Checkout"という名前付きでbindする例。 @Providesを利用した場合は、メソッドの戻り値のクラスにbindする。 public class SampleProviderModule extends AbstractModule { @Ov
ジェネリクスでは、「型」を変数にした「型変数」というものを取り扱う。型変数で何が嬉しいかというと、メジャーな例ではコレクションAPIが挙げられる。java.util.Listとかjava.util.Mapとかのデータを格納するタイプのユーティリティクラスのことだ。 2004年にJavaのバージョンが5.0となるまでは、Javaにはジェネリクスの機能はなかった。なので、Listにデータを格納し、取得する場合は List list = new ArrayList(); list.add("hello!"); String str = (String) list.get(0); といったソースコードになる。 add()の引数はObject型で宣言されており、どんな参照型でもadd()することができた。 get()の戻り値もObject型で宣言されておりキャストが必要だった。このキャストはプログラ
Guice(ジュースと読む)は、GoogleのエンジニアBob Lee氏(ブログ)などによって開発されたDIフレームワークです。バージョン1.0が2007年3月8日にApache License 2.0の下で公開されました(公開時のブログ)。実行環境としてJava 5が必要です。 DIとは依存性の注入(Dependency Injection)のことで、同じインターフェースを持つ具象クラスを、設定によって入れ替え可能にする方法を指し、IoC(Inversion of Control - 制御の反転)と呼ばれることもあります。これにより、たとえばテスト用のモッククラスと、実際の業務ロジックが組み込まれたクラスとの、必要に応じた入れ替えがしやすいというメリットがあり、システム開発の生産性を向上させる技術して注目されています。同様のしくみを持つものとして、Spring Framework、Pic
Gradle にも大分慣れてきたし、そろそろ 実際にプロジェクトで使えるように準備しないと... まずは Jenkins CI で Gradle が利用できるように準備しようかな。 今時のプロジェクトでは Jenkins CI ぐらい当たり前ですよね。 と言うことで、今回は Jenkins CI で Gradle する最も簡単な (と思われる) 方法です。 実は Jenkins CI で Gradle を利用するために 必要な準備なんて何もありません。 インストールレスで Gradle してみる でも紹介した 『Gradle Wrapper』 さえ使えば、一般的なジョブの設定をするだけでいいんです。 もし、Jenkins CI 上で環境構成を変更する必要があるのであれば Gradle で環境ごとに構成を変更する Gradle で環境ごとに構成を変更する その2 Gradle で環境ごとに構
Spock は Java で BDD (Behavior Driven Development) するためのフレームワークです。 もちろん、Groovy でも... Java の開発では おなじみの IDE (Eclipse) や ビルドツール (Ant, Maven, Gradle) にも対応しているので、プロジェクトへの導入はとっても簡単です。 既に JUnit を使っているのであれば、ぜひ Spock を導入してみてください。その違いに驚くはずです。 と言うことで... 早速、Gradle で Spock してみました。 Gradle で Spock するのはとっても簡単です。 apply plugin: 'eclipse' apply plugin: 'groovy' repositories { mavenCentral() } dependencies { groovy "or
blog1.mammb.com では CoreMatchers についてでしたが、こちらでは org.hamcrest.Matchers についてまとめます。 org.hamcrest.Matchers JUnit についてくるのは org.hamcrest.CoreMatchers で基本的な Matcher が提供されています。org.hamcrest.Matchers は CoreMatchers を機能拡張したものとなってます。CoreMatchers にあるメソッドは、Matchers にもあります。 hamcrest-core − org.hamcrest.Matchers が入ってる hamcrest-library − org.hamcrest.Matchers が入ってる hamcrest-library は以下のようなパッケージ構成となっており、各用途に応じた Ma
blog1.mammb.com のついでに hamcrest の CoreMatchers についてまとめます。 Matchers については blog1.mammb.com まずは基本の is と not 全体的にはこんな感じ。 import static org.hamcrest.CoreMatchers.is; import static org.junit.Assert.assertThat; import org.junit.Test; public class FooTest { @Test public void testFoo() { String actual = "foo"; assertThat(actual, is("foo")); } } not はこう。 String actual = "foo"; assertThat(actual, not("bar"));
DI:依存性の注入とは何か?:Spring Frameworkで理解するDI(1)(1/3 ページ) Javaのエンジニアであれば最近、「Dependency Injection」や「DIコンテナ」「Spring」、または「Seaser2」といった名前を目にしたことがあるのではないでしょうか。これらは次世代のEJB(EJB 3.0)に取り込まれる動きがあるなど、最近非常に注目されているキーワードであり、今後のJava開発を語るうえで避けては通れない概念の1つになるとされています。 この連載は、「Spring」というフレームワークを利用して、J2EE開発における「Dependency Injection(DI)」というデザインパターンから得られるメリットを紹介し、J2EEの今後の方向性を理解する助けとしていただくことを目的としています。 Dependency Injection:依存性の注入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く