2012-04-25 13 views
6

大きなオープンソースライブラリを使用しており、いくつかのクラスの個人的なサブクラスを生成する必要があります。最高の戦略は何ですか?私は元のライブラリを変更せずに維持し、更新時に簡単に再構成できるようにしたいと考えています。私のコードはプロジェクトに寄与する価値があるとは思えませんが(私はこれを許す方法で書くことができます)。オープンソースライブラリのサブクラス化

問題は一般的な問題ですが、私の例で説明します。私はjava.awt.Graphics2Dに書き込むルーチンを持っているApache PDFBoxを使用しています。私はこれをGraphics2D(org.apache.batik.svggen.SVGGraphics2D)のサブクラスを提供するApache Batikツールキットに置き換えて、SVG表現をキャプチャすることができます。私はそれが動作するようになってきた

protected void showPage(int pageNumber) 
{ 
    try 
    { 
     PageDrawer drawer = new PageDrawer(); 
     PageWrapper wrapper = new PageWrapper(this); 
     PDPage page = (PDPage)pages.get(pageNumber); 
     wrapper.displayPage(page); 
     PDRectangle cropBox = page.findCropBox(); 
     Dimension drawDimension = cropBox.createDimension(); 
     svg = PDFPagePanel.createSVG();   // MY EDIT!!!!!!!!! 
     drawer.drawPage(svg, page, drawDimension); 
     writeSVG(pageNumber); 
    } 
    catch (IOException exception) 
    { 
     exception.printStackTrace(); 
    } 
} 

(それは問題ではない):私は

public static org.apache.batik.svggen.SVGGraphics2D createSVG() { 
    org.w3c.dom.DOMImplementation domImpl = 
    org.apache.batik.dom.GenericDOMImplementation.getDOMImplementation(); 
     org.w3c.dom.Document document = 
      domImpl.createDocument("http://www.w3.org/2000/svg", "svg", null); 
     return new org.apache.batik.svggen.SVGGraphics2D(document); 
    } 

PDFBoxは、グラフィックスを使用する場所である私は、新しいグラフィックスを可能にするために編集したorg.apache.pdfbox.PDFReaderインスタンスを作成します。私の関心事は、分散クラスのPDFBoxクラスをハック/編集して再コンパイルしてサブクラスを生成して使用するだけで済むということです。私は、ライブラリと同じパッケージにPMRPDFReaderのようなクラスを作ります。それは非常に面倒です - 編集した場所などはすぐには思い出せません。

ライブラリをそのまま使用してサブクラスを追加/リンクするだけでいいはずです。私はmavenを使うので、元のクラスを除外する方法があるかもしれません。

答えて

1

は、私はこれを行うだろう方法は次のとおりです。

  • は、ソースコードの変更が含まれている別のプロジェクトを作成します。それをソースコード/リビジョンコントロール(SVN、Git、あなたが使っているもの)にチェックしてください。このプロジェクトには変更内容のみが含まれます。
  • Mavenプロジェクトであることを確認してください。元のオープンソースプロジェクトと同じバージョン番号を使用しますが、バージョンに付録を追加してください。バージョン1.2を使用している場合は、バージョン1.2-Peter-1などのプロジェクトを作成してください。この方法では、あなたはいつでもあなたの変更の複数のバージョン/リビジョンを提供することができることに基づいているバージョンを知るでしょう。それは公式のバージョンと矛盾しないでしょう。公式のものと同じグループ/アーティファクトIDを使用してください。
  • 元のプロジェクトを独自の依存関係として使用します。展開のために

、あなたは、2つのオプションがあります。

+0

+1便利な提案 –

1

ライブラリが簡単なサブクラスフックを提供していない場合は、あまり選択肢がありません。彼らはgitミラーを持っているので、私はちょうどそれをフォークします(あなたのミラーをどこか安全に保ち、好ましくはあなたの通常のSCMの近くに置いておいてください)。私の通常の戦略は、バージョン番号(Maven内)に-companyNameを追加して、パッチ版であることを思い出すことです。編集履歴には編集内容が簡単に表示されます。

また、maven shadeプラグインを使用してクラスを変更/置き換えて調べることもできますが、それはちょっとハッキーなIMHOです。ここで

+0

ありがとう:

  • は、元のクラスと、独自のものをミックス1つのjarファイルを作成するために、Mavenのシェードプラグインを使用します。彼らは明らかに人々がサブクラス化することを期待していますが、明確なフック(インターフェース、依存性注入など)は見ていません。 –

    +0

    フックを作成するだけの場合は、パッチを受け入れる意思があります。 – artbristol

    +0

    私はそれを整然と働かせたら、私は確かに彼らのリストでそれを言及します –