子类化开源库

时间:2012-04-25 08:35:36

标签: java maven open-source subclass

我正在使用一个大型开源库,需要生成一些类的个人子类。什么是最好的策略?我想保持原始库不变,并且在更新时可以轻松地重新配置。我的代码不太可能值得为该项目做出贡献(尽管我很乐意以允许这样做的方式编写代码)。

这个问题很普遍,但我会以我的例子来说明。我正在使用Apache PDFBox,其中有一个例程可以写入java.awt.Graphics2D。我已经用Apache Batik工具包取代了它,它提供了Graphics2D(org.apache.batik.svggen.SVGGraphics2D)的子类,因此我可以捕获SVG表示。我创建了一个实例

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我已编辑以允许新图形:

    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();
    }
}

我有工作(这不是问题)。我担心的是,我不得不破解/编辑和重新编译许多分布式PDFBox类,只是为了生成和使用子类。我最终在与库相同的包中使用PMRPDFReader等类。它非常混乱 - 我无法立即记住我编辑的位置等等。

我觉得我应该能够按原样使用库,只需添加/链接我的子类。我使用maven所以也许有一种方法可以排除原来的类。

2 个答案:

答案 0 :(得分:1)

如果库没有提供简单的子类挂钩,那么你没有太多选择。鉴于他们有一个git镜像,我只是将它分叉(保持你的镜像安全并备份,最好是靠近你的正常SCM)。我通常的策略是将-companyName附加到版本号(在Maven中),这样我就能记住它是一个修补版本。您可以轻松查看自您在修订历史记录中所做的修改。

你也可以调查使用maven shade插件来改变/替换类,但这有点骇人听闻。

答案 1 :(得分:1)

以下是我将如何做到这一点:

  • 创建一个包含源代码更改的单独项目。将其检入源代码/版本控制(SVN,Git,无论您使用的是什么)。此项目仅包含您的更改。
  • 确保它是Maven项目。使用与原始开源项目相同的版本号,但在版本中添加附录。如果您使用的是版本 1.2 ,请创建项目以使其版本为 1.2-Peter-1 或类似内容。这样,您将始终知道它所基于的版本,您还可以提供更改的多个版本/修订版。它也不会与官方版本冲突。使用与官方ID相同的组/工件ID。
  • 将原始项目用作您自己的依赖项。

对于部署,您有两个选择: