blocks|key|3112332|text|我不建议将Maven作为遗留源代码基础。它可能会给你带来很多令人头疼的事情，仅仅是试图让所有的东西都与之配合工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3112333|我想你需要的是为你的项目做一个架构布局。工具可能会有所帮助，但最重要的部分是组织模块的逻辑视图。|3112334|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I wouldn't recommend Maven for a legacy source code base. It could give you many headaches just trying to adapt everything to work with it.

I suppose what you need is to do an architectural layout of your project. A tool might help, but the most important part is to organize a logical view of the modules.

blocks|key|341161|text|使用OSGi可能非常适合您。它将允许在应用程序之外创建模块。您还可以以更好的方式组织依赖项。如果您正确定义了不同模块之间的接口，则可以使用持续集成，因为您只需重新构建签入时受影响的模块。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|341162|OSGi提供的机制将帮助您理清现有代码。由于类加载的工作方式，它还可以帮助您以一种更容易的方式处理补丁。|341163|Some+concepts+of+OSGi+that+seem+to+be+a+good+match+for+you,+as+shown+from+wikipedia:|341164|该框架在概念上分为以下几个区域：|341165|Java+headers.|341166|Services是具有额外清单的普通jar组件-服务层通过为普通的老JavaAPI注册表提供发布-查找-绑定模型以动态方式连接|unordered-list-item|341167|
|341168|-用于管理服务的API+(ServiceRegistration、ServiceTracker和API+-用于生命周期管理的API(安装、启动、停止、更新，卸载bundles).|341169|341170|Modules+-定义依赖项的封装和声明的层(捆绑包如何导入和导出code).|341171|341172|Security+-通过将捆绑包功能限制为预定义的capabilities.|341173|
来处理安全方面的层|341174|entityMap|0|LINK|mutability|MUTABLE|url|http://www.osgi.org/Main/HomePage|1|http://en.wikipedia.org/wiki/OSGi^0|2|4|0|0|0|0|2C|1|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]]|C|$]]|$1|H|3|I|5|6|7|1J|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1K|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|1L|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1M|8|@]|9|@]|C|$]]|$1|Q|3|R|5|N|7|1N|8|@]|9|@]|C|$]]|$1|S|3|P|5|6|7|1O|8|@]|9|@]|C|$]]|$1|T|3|U|5|N|7|1P|8|@]|9|@]|C|$]]|$1|V|3|P|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|W|3|X|5|N|7|1R|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|1S|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]]|11|$12|$5|13|14|15|C|$16|17]]|18|$5|13|14|15|C|$16|19]]]]

Using <a href="http://www.osgi.org/Main/HomePage" rel="noreferrer">OSGi</a> could be a good fit for you. It would allow to create modules out of the application. You can also organize dependencies in a better way. If you define your interfaces between the different modules correctly, then you can use continuous integration as you only have to rebuild the module that you affected on check-in.

The mechanisms provided by OSGi will help you untangle the existing code. Because of the way the classloading works, it also helps you handle the patches in an easier way.

<a href="http://en.wikipedia.org/wiki/OSGi" rel="noreferrer">Some concepts of OSGi that seem to be a good match for you, as shown from wikipedia:</a>

The framework is conceptually divided into the following areas:

<ul>
<li>Bundles - Bundles are normal jar components with extra manifest headers.</li>
<li>Services - The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects(POJO).</li>
<li>Services Registry - The API for management services (ServiceRegistration, ServiceTracker and ServiceReference).</li>
<li>Life-Cycle - The API for life cycle management (install, start, stop, update, and uninstall bundles).</li>
<li>Modules - The layer that defines encapsulation and declaration of dependencies (how a bundle can import and export code).</li>
<li>Security - The layer that handles the security aspects by limiting bundle functionality to pre-defined capabilities.</li>
</ul>

blocks|key|3112441|text|首先:祝你好运&好咖啡。这两个你都需要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3112442|我曾经遇到过类似的问题。具有可怕的循环依赖关系的遗留代码，即使是来自不同包的类之间，如org.example.pkg1.A也依赖于org.example.pk2.B+，反之亦然。|offset|length|style|BOLD|3112443|我从maven2和fresh+eclipse项目开始。首先，我尝试确定最常见的功能(日志层、公共接口、公共服务)，并创建了maven项目。每次我对某个部分感到满意时，我都会将该库部署到中央nexus库中，以便几乎可以立即将其用于其他项目。|3112444|所以我慢慢地做了一层又一层。maven2处理了依赖关系，m2eclipse插件提供了一个有用的依赖关系视图。顺便说一句，将eclipse项目转换成maven项目通常并不太难。m2eclipse可以为您做到这一点，您只需创建一些新文件夹(如src/main/java)并调整源文件夹的构建路径即可。只需要一两分钟。但是，如果您的项目是一个eclipse插件或rcp应用程序，并且您希望maven不仅管理工件，而且还构建和部署应用程序，则会遇到更多困难。|3112445|从观点来看，eclipse、maven和nexus+(或任何其他maven仓库管理器)都是一个很好的起点。您很幸运，如果您对系统体系结构和有很好的文档，那么这个体系结构就真正实现了;)|3112446|entityMap^0|0|2B|6|0|0|3B|0|0|69|0|0|2K|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|O|$]]

First: good luck &amp; good coffee. You'll need both.

I once had a similiar problem. Legacy code with awful circular dependencies, even between classes from different packages like org.example.pkg1.A depends on org.example.pk2.B and vice versa.

I started with maven2 and fresh eclipse projects. First I tried to identify the most common functionalities (logging layer, common interfaces, common services) and created maven projects. Each time I was happy with a part, I deployed the library to the central nexus repository so that it was almost immediately available for other projects.

So I slowly worked up through the layers. maven2 handled the dependencies and the m2eclipse plugin provided a helpful dependency view. BTW - it's usually not too difficult to convert an eclipse project into a maven project. m2eclipse can do it for you and you just have to create a few new folders (like src/main/java) and adjust the build path for source folders. Takes just a minute or two. But expect more difficulties, if your project is an eclipse plugin or rcp application and you want maven not only to manage artifacts but also to build and deploy the application. 

To opinion, eclipse, maven and nexus (or any other maven repository manager) are a good basis to start. You're lucky, if you have a good documentation of the system architecture and this architecture is really implemented ;)

blocks|key|342286|text|对于现有的系统，迁移到Maven是很痛苦的。但是，它可以毫不费力地处理100%2B模块项目。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|342287|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Maven is painful to migrate to for an existing system. However it can cope with 100+ module projects without much difficulty.

blocks|key|339943|text|您需要决定的第一件事是您将迁移到哪种基础结构。它应该是许多独立维护的模块(转换为单独的Eclipse项目)，还是您会认为它是作为一个整体进行版本控制和部署的单个代码块。第一种方法非常适合于迁移到类似Maven的构建环境，而后者则可以一次完成所有源代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|339944|在任何情况下，您都需要一个运行的持续集成系统。您的第一个任务是让代码库自动构建，这样您就可以让CI系统监视您的源代码库，并在您更改内容时重新构建它。我决定在这里使用非Maven方法，并且我们专注于拥有一个简单的Eclipse环境，所以我使用ant4eclipse和团队ProjectSet文件创建了一个构建环境(我们无论如何都要使用它们)。|339945|下一步将是摆脱循环依赖-这将使您的构建更简单，摆脱Eclipse警告，并最终允许您进入“签出，编译一次，运行”阶段。这可能需要一段时间:-(当您迁移方法和类时，不要移动它们，而是提取或委托它们，并保留它们的旧名称，并将它们标记为弃用。这将分离您的重构，并允许“项目外”的代码仍然与项目内的代码一起工作。|339946|您将受益于源代码库，它允许移动文件并保留历史记录。CVS在这方面非常弱。|339947|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The first thing you need to decide is what infra-structure you will move to. Should it be a lot of independently maintained modules (which translates to individual Eclipse projects) or will you consider it a single chunk of code which is versioned and deployed as a whole. The first is well suited for migrating to a Maven like build environment - the latter for having all the source code in at once.

In any case you WILL need a continuous integration system running. Your first task is to make the code base build automatically, so you can let your CI system watch over your source repository and rebuild it whenyou change things. I decided for a non-Maven approach here, and we focus on having an easy Eclipse environment so I created a build enviornment using ant4eclipse and Team ProjectSet files (which we use anyway). 

The next step would be getting rid of the circular dependencies - this will make your build simpler, get rid of Eclipse warnings, and eventually allow you to get to the "checkout, compile once, run" stage. This might take a while :-( When you migrate methods and classes, do not MOVE them, but extract or delegate them and leave their old name lying around and mark them deprecated. This will separate your untangeling with your refactoring, and allow code "outside" your project to still work with the code inside your project.

You WILL benefit from a source repository which allows for moving files, and keeping history. CVS is very weak in this regard.

blocks|key|344821|text|它不是免费的，但Structure101将在工具支持方面为您提供尽可能好的工具支持，以达到您的所有要点。但需要说明的是，我是有偏见的，所以你可能也想看看SonarJ和Lattix。;-)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|344822|entityMap|0|LINK|mutability|MUTABLE|url|http://structure101.com/products/structure101/^0|8|C|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

It's not free but <a href="http://structure101.com/products/structure101/" rel="nofollow noreferrer">Structure101</a> will give you as good as you will get in terms of tool support for hitting all your bullet points. But for the record I'm biased, so you might want to check out SonarJ and Lattix too. ;-)

I have a rather large (several MLOC) application at hand that I'd like to split up into more maintainable separate parts. Currently the product is comprised of about 40 Eclipse projects, many of them having inter-dependencies. This alone makes a continuous build system unfeasible, because it would have to rebuild very much with each checkin. 

Is there a "best practice" way of how to

<ul>
<li>identify parts that can immediately be separated</li>
<li>document inter-dependencies visually</li>
<li>untangle the existing code</li>
<li>handle "patches" we need to apply to libraries (currently handled by putting them in the classpath before the actual library)</li>
</ul>

If there are (free/open) tools to support this, I'd appreciate pointers.

Even though I do not have any experience with Maven it seems like it forces a very modular design. I wonder now whether this is something that can be retrofitted iteratively or if a project that was to use it would have to be layouted with modularity in mind right from the start.

Edit 2009-07-10

We are in the process of splitting out some core modules using <a href="http://ant.apache.org/ivy" rel="noreferrer">Apache Ant/Ivy</a>. Really helpful and well designed tool, not imposing as much on you as maven does. 

I wrote down some more general details and personal opinion about why we are doing that on my blog - too long to post here and maybe not interesting to everyone, so follow at your own discretion: <a href="http://www.danielschneller.com/2009/07/modularizing-software-with-antivy-and.html" rel="noreferrer">www.danielschneller.com</a>

How to modularize a (large) Java App?

我手头有一个相当大的(几个MLOC)应用程序，我想将其拆分成更易维护的独立部分。目前，该产品由大约40个Eclipse项目组成，其中许多项目具有相互依赖关系。这本身就使得持续构建系统变得不可行，因为它必须在每次签入时进行大量的重建。有没有一种“最佳实践”的方法？识别可以立即成为依赖关系的部分现有代码处理我们需要应用到库...

问如何模块化一个(大型) Java应用程序？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何模块化一个(大型) Java应用程序？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何模块化一个(大型) Java应用程序？
EN