build.xml selection should be part of workspace
Hi all,
We're in the process of refactoring our project into many small modules, each with its own build.xml. It seems the current choice of build.xml files to display in the ant window should be part of the workspace file, not the project file. We're adding and removing them a lot, and it's annoying to have to update the project all the time and resolve conflicts for something that's really user state.
Thoughts?
Colin
请先登录再写评论。
Hello Colin,
On the other hand, a typical project has a small number of well-established
build.xml files, and most developers work with all of them, so it's more
convenient to keep them in .ipr.
Perhaps some kind of "shared" flag should be introduced here, similar to
how it works for run configurations.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
Ok, that would work, I think. I appreciate it's a side case, it's the first time I've found it to be a problem.
Cheers,
Colin
Is there any way that the filters applied on build files could be shared in the ipr file as well?
Our build files are huge, but only have a few runnable targets, so it would be great to be able to eliminate the dross for all developers.
http://www.jetbrains.net/jira/browse/IDEA-14463
http://www.jetbrains.net/jira/browse/IDEA-14464
An alternative way to do this would be for IDEA to support annotations in the build.xml, e.g.
@hide in xml comment above the target name. Then when IDEA parses the build.xml, if it finds any of these hidden targets, it should then automatically turn on the filter, and filter out all the targets marked as "@hide".
+10
This would be great.
I'd prefer to keep it as part of the IPR or IML files, as we're a cross-IDE company and I don't want to start adding in IDE specific content to the build files.
Still, if it's in a comment it shouldn't matter, right?
It shouldn't matter, but I'll get moans from the Eclipse and Netbeans crowds for polluting their lovely code :)