Eclipse WTPとsydeo、「公開せずにモジュールを提供」


103

Eclipseの統合プラグインWTPを使用してプラグインsysdeoのパフォーマンスを見つけるのに問題があります。

移行、つまり比較を行うために、Eclipse内の別々のプロジェクトに両方をインストールしました。

私が理解したことによると、生産性の違いに気づきました。Tomcatがソースを配置できるように、WTPはディレクトリビルドでソースを公開する必要があります。この「磨き」は長く、変更が表示されるようにコンテキストを再充電する必要があります。(5ヤードで最も乾燥している15秒-最長で20秒)。

Sysdeo no; ファイルによって変更が行われるとすぐに、ディレクトリEclipseのターゲットがプロジェクト内でビルドされ、Eclipseビルドとこれらの変更がすぐに利用可能になります(ブラウザーでF5キーを押すと、結果がすぐに表示されます)。

これが私のサーバー設定です:

「公開せずにモジュールを提供する」オプションを使用すると、sydeoの作成内容を正確に作成できます。実行中のプロジェクトのビルドディレクトリを選択できます。この構成は、コンテキストファイルで表現されます。(「XMLの行を分離するためにPublish modulates contexts」をチェックしたことを元に戻すことができます)

これらのファイルの比較:

  • sysdeoが生成するコンテキストファイルは次のとおりです
< Context path="/tatoile _syseo" reloadable="false" docBase="D:\32bit\serveur32bit\workspace\tatoile _syseo" workDir="D:\32bit\serveur32bit\workspace\tatoile _syseo\work" />
  • WTPによって生成するファイルコンテキスト

<?xml version = "1.0" encoding = "UTF-8"?> <Context docBase = "D:\ 32bit \ serveur32bit \ workspace \ tatoile \ web" path = "/ tatoile" reloadable = "true" source = "org .eclipse.jst.jee.server:tatoile "> <リソースclassName =" org.eclipse.jst.server.tomcat.loader.WtpDirContext "extraResourcePaths =" / WEB-INF / classes | D:\ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes "virtualClasspath =" D:\ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes "/> <Loader className =" org.eclipse.jst.server.tomcat.loader.WtpWebappLoader "useSystemClassLoaderAsParent =" false " virtualClasspath = "D:\ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes" /> <JarScanner scanAllDirectories = "true" /> </ Context>

後で、これらの2つのファイルを分析します。

ここで問題に戻りましょう。私は同じサーバーを使用しているため、上記のコンテキストの両方のファイルがこのサーバー用に定義されています。経験:私はプラグインsysdeoによってtomcatを起動します。2つのコンテキストでのロードは、WTPを設定する方法と、sysdeoによってもう一方の方法で構成されます。どちらの当局も同じように反応し、変更はtatoile _syseoとtatoileで即座に行われます。

一方、EclipseでプラグインWTP(タブサーバーなど)を介してTomcatを起動すると、tatoile _syseoとtatoileの両方のプロジェクトですぐに変更が行われません。注:変更が考慮されるように、自動リロードを必ず有効にする必要があります。(サーバーがコンテキストを再読み込みしたことをサーバーが示すと、変更を確認できます。)

ここに画像の説明を入力してください

そこから、コンテキストの構成が理由ではなく、プラグインがTomcatを起動する方法であると推測します。そこか私が乾いて…

ここにWTPプロジェクトがあります:

ここに画像の説明を入力してください


5
SysdeoまたはWTPに問題がありますか?OTOH確かに、WTPは変更のためにさらに時間が必要です。これは、これらが再発行するための処理であるためです:(1)ビルドクラス(2)古いWebアプリのアンデプロイ(3)ビルド結果をTomcatのデプロイフォルダーにコピー(4)Tomcatはアプリ。一方、sysdeoでは、変更が行われるとすぐに、RAM内のクラスがその場で変更されます(クラスファイル内の新しい日付によって識別されます)。次に、その場で行うことができない変更のいくつかの制限があります(新しいメソッドを追加すると、クラス構造も変更されます)。この場合、警告が表示されます。

同じプロジェクトでSysdeoとWTPの両方を使用しました。私が気付いた最も重要な違いは、Sysdeoの構成の方が簡単に見えたが、これには偏りがあるかもしれないということでした。
Markus

2
この問題は、WTPデプロイメントでMAVENを追加することで解決されました。パフォーマンスの問題はありません。パフォーマンスの問題はなく、「公開せずにモジュールを提供する」をアクティブにしない
Vsplit 14

1
問題を解決した場合、回答を投稿できますか?
Anubian Noob、2014

@AnubianNoobはい、以前の投稿で説明しました。Maven構成を使用して問題を解決しました。
Vsplit 2014年

回答:


3

@Vsplitから引用された答え

この問題は、WTPデプロイメントでMAVENを追加することで解決されました。パフォーマンスの問題はありません...そして公開せずにサーブモジュールをアクティブにしません


-1これは答えではありません。詳細を含めて回答を追加してください。
Isaac G Sivaa 2014年

1
こんにちは、私は私の遅い答えを申し訳ありません。しかし、あなたが気づかなければならないように、私はSysdeoプラグインの問題の問題を解決できません。しかし、WTP deデプロイメントでMavenプラグインを使用しています。このサンプルチュートリアルyoutube.com/watch?v=YeC7XQho-O0
Vsplit

2

プラグインマーケットプレイスでm2e-wtpという無料のプラグインを探してください。これにより、提供されたスコープの問題が処理されます。デプロイされていないクラスについては、私がよく見る場所は、デプロイメントアセンブリやJavaビルドパスです。エントリ(および依存モジュール)がすべて存在し、適切な場所に配置されていることを確認してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.