有没有办法让 FlexBuilder 3 将项目视为应用程序和库?

发布于 2024-07-05 06:19:38 字数 463 浏览 3 评论 0原文

我的团队为其他(内部)软件开发团队构建可重用的库。 我们使用 FlexBuilder 3 作为我们的开发环境。 我们的 SCM 标准规定这些项目必须包括测试工具和单元测试运行程序,并且(当然)我们希望能够使用调试器。 因此,所有项目都是应用程序。

我们的构建脚本(主要由 CI 系统使用并用于发布部署)构建了我们实际的库,效果很好。 使用这种方法使得 FlexBuilder 不需要实际构建我们的生产工件(在命令行上)。

问题是这样的 - 为了将 FlexBuilder 项目添加到应用程序的库路径中,它必须是库项目。 我尝试过向我们想要包含的项目添加一种性质,但尚未使其发挥作用。 如果您想调试另一个项目中的源文件,您可能会想要这样做。

一个简单(但烦人)的解决方法是将“库项目”的源文件夹作为“应用程序项目”中的源文件夹包含在内。 这很烦人,因为需要多个步骤才能在“库项目”的 SWC 和项目本身的源文件夹之间进行交换。

My team builds reusable libraries for other (internal) software development teams. We use FlexBuilder 3 as our development environment. Our SCM standards state that these projects must include test harnesses and a unit test runner, and (of course) we want to be able to use the debugger. For that reason, all the projects are Applications.

Our build scripts (used primarily by the CI system and for release deployment) build our actual libraries which works great. This approach is used so that FlexBuilder is not required to actually build our production artifacts (on the command line).

The problem is this - in order to have add a FlexBuilder Project to the Library Path for an Application it must be a Library Project. I have tried adding a nature to the project that we want included, but haven't gotten it to work yet. You would want to do that if you wanted to debug source files in another project.

A simple (yet annoying) work around is to include the source folder of the "library project" as a source folder in the "application project." It's annoying because it takes multiple steps to swap between a swc of the "library project" and the source folder of the project itself.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

独行侠 2024-07-12 06:19:38

我还建议将其分成两个项目。 有 1 个库项目和 1 个用于测试和测试运行程序的应用程序。

旁注:FlexBuilder 4 将支持在 IDE 中运行 FlexUnit 测试,适用于 Flex 应用程序和 Flex 库项目。 因此,您不必仅仅为了运行测试而维护应用程序。

I would also suggest breaking this up into 2 projects. Have 1 library project and 1 application for the tests and the testrunner.

On a sidenote: FlexBuilder 4 will have support for running FlexUnit tests in the IDE, for both Flex applications and Flex library projects. So you won't have to maintain an application just for the sake of running the tests.

罪歌 2024-07-12 06:19:38

假设有可能,我建议调整您的 SCM 标准,以允许测试工具和单元测试运行程序存在于其他项目中。 只需要求任何库项目都必须包含一个配套的测试项目。

Assuming it is possible, I'd suggest adjusting your SCM standards to allow test harnesses and unit test runners to exist in other projects. Simply mandate that any library project must include a companion test project.

相权↑美人 2024-07-12 06:19:38

我不知道这会让事情变得更容易,但实际上我会让库和测试工具成为单独的项目。 这将允许您对每个项目进行源代码控制,并使用 flexbuilder 解决您的问题。 它不会让它更容易使用,但它会更干净并且最容易更新。

I don't know that this is going to make it any easier, but I would actually make the library and the testing harness seperate projects. This would allow you to source control each and would solve your problem with flexbuilder. Its not going to make it easier to work with, but it will be cleaner and the easiest to update.

北城半夏 2024-07-12 06:19:38

我不完全理解您的情况描述,但如果有帮助,我将描述我们如何组织我们的 Flex 项目。 我们的大部分应用程序代码都包含在 SWC(“库”)项目中。 然后,我们创建两个 SWF(“应用程序”)项目 - 一个代表最终输出 SWF 的“shell”应用程序,以及一个测试工具 FlexUnit 2 应用程序。 这两个 SWF 项目都使用源路径引用 SWC 项目。 使用这种方法可以轻松地在 SWC 中启用应用程序代码库的单元测试。

I didn't totally understand the description of your situation, but if it's helpful, I'll describe how we have organized our Flex projects. The majority of our application code is contained within a SWC ("library") project. We then create two SWF ("application") projects - a "shell" application which represents the final output SWF, and a test harness FlexUnit 2 application. Both of these SWF projects reference the SWC project using a source path. Using this approach has made it trivial to enable unit testing for the application codebase in the SWC.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文