Play 2.0应用程序的依赖性管理 [英] Dependency Management with Play 2.0 Applications

查看:101
本文介绍了Play 2.0应用程序的依赖性管理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于基于JVM的开发,我们的团队有些陌生.我们正在开发由许多其他库组成的应用程序.

Our group is somewhat new to JVM based development. We are developing applications that are composed of many other libraries.

我们发现Play框架对于开发Web应用程序非常有吸引力.该框架很棒,但是对我们本地开发的库的依赖管理有些麻烦.我们正在使用Play 2.0的RC2,虽然我们能够将库中的更改加载到Play中,但这绝对是一个笨拙的过程,会中断通常正常的Play过程.

We find the Play framework to be very appealing for developing web applications. The framework is great, but the dependency management for our locally developed libraries is somewhat vexing. We're using the RC2 of Play 2.0 , and while we are capable of getting changes in our libraries loaded into Play, it is definitely an awkward process that interrupts the normally smooth Play process.

我们正在做的是将库推送到本地(在每个开发人员的计算机上)Maven存储库,然后将这些库重新导入到Play项目中.它有效,但是正如我所说,这很尴尬.

What we are doing is pushing our libraries to our local (on each developer's machine) Maven repository and then importing those same libraries back into the Play project. It works, but as I said, it's awkward.

我们应该采用什么最佳实践来使这项工作更加顺利吗?

Are there any best practices that we should be employing that will make this work a little more smoothly?

FWIW,我们使用的是IntelliJ 11.0(旗舰版)

FWIW, we're using IntelliJ 11.0 (Ultimate)

============编辑==========

============EDIT============

关于如何改进我的Maven构建过程,我获得了很好的答案,对此我表示感谢.但是,这并不是我要找的答案.

I'm getting good answers about how to improve my Maven build process, and I do appreciate that. However, this is not quite the answer that I am looking for.

要具体说起,假设我同时构建了服务和用于监视/管理服务的Web应用程序.该服务是一个简单的Java/Scala项目,而Web App是一个Play!项目.我们将其称为服务"和应用程序". (请不要对这种提议的结构轻描淡写,我是出于问题的考虑而将其简化)

To make this concrete, assume that I am building both a Service and a Web Application for monitoring/managing the service. The Service is a plain Java/Scala project and the Web App is a Play! project. We'll call these 'Service' and 'App'. (Please don't nitpick about this proposed structure, I'm simplifying it for the purposes of the question)

在Eclipse或IntelliJ中,我可以将服务"模块(或Eclipse项目)添加为"App"项目的依赖项.在服务"库中进行更改时,这可以使开发人员快速周转(例如,向模型添加属性).重新编译和运行比编译,打包,部署,导入和重新加载浏览器快几个数量级.

In Eclipse or IntelliJ, I can add the 'Service' Module (or Project for Eclipse) as a dependency of the 'App' project. This allows very fast developer turnaround when making changes in the 'Service' library (for example, I add a property to a model). Recompile and run is a couple of orders of magnitude faster than compile, package, deploy, import, and reload browser.

根据我对Play 2.0和SBT文档的阅读,我唯一的真实答案是将服务"作为应用"的子项目.有更好的答案吗?

Based upon my reading of the Play 2.0 and SBT documentation, my only real answer is to make 'Service' a sub project of 'App'. Is there a better answer to this?

推荐答案

您有2个选择.

第一个,如Rich提到的,是一个本地存储库.这并不意味着maven在您的开发机器中创建的本地文件夹将用作本地缓存.这意味着您的局域网中的中央服务器,您可以在其中存储应用程序的版本以供Play稍后使用. Rich推荐的 Nexus 是一个不错的选择.

The first one, as Rich mentioned, is a local repository. That doesn't mean the local folder in your dev machine that maven creates as a local cache and you are using. It means a central server in your LAN where you store the versions of the applications for Play to retrieve later on. Nexus, as recommended by Rich, is a great option.

第二个选择是简单地构建您的jar,并将其作为非托管库部署到您的"lib"文件夹中.然后,您可以将其提交到源管理系统,所有开发人员将拥有相同的资源.

The second option is to simply build your jars and deploy them as unmanaged libraries in your "lib" folder. You can then commit that to your source-management system and all devs will have the same.

我建议第一种方法,长期来看会更好,但这是您的选择.

I recommend the first approach, much better long term, but it's your choice.

编辑评论 您说您不想管理依赖项.我可以想象的唯一第三种情况是您希望将所有代码作为一个块.在这种情况下,您可以使用子项目.我看不到其他选择.

EDIT ON COMMENT you say that you don't want to manage dependencies. The only 3rd scenario I can imagine is that you want to have all the code as a block. In that case you can use subprojects. I don't see other alternatives.

这篇关于Play 2.0应用程序的依赖性管理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆