Wishlist: Maven integration
TC is a great product, but IMHO lacks a lot of (some very simple) features for better integration with Maven:
- provide tight builtin integration with coverage reporting (as done for Emma)
- provide "snapshot-remote-run-across-multiple-configurations": run a remote build for a SNAPSHOT project on which other projects depend on (e.g. internal library used in multiple "real" projects) -> possibility to check regressions etc. across multiple projects/run configurations -- probably a bit tricky to implement, but should be possible (creating "temporary" M2-repository to pull current SNAPSHOT-build from?) -- this would be a killer feature IMHO
- show pom.xml related dependencies automatically on project configuration page, suggest to add triggers on dependent build configurations
- provide pom.xml content in separate tab, e.g. link to project's website, issue tracking (add patterns automatically in TC from this), etc.
- show groupId/artifactId/version in some common places
- new result tab: dependency tree to visualize dependencies across TC projects
I'm sure there's more to wish for - comments or additions?
Yann
Please sign in to leave a comment.
Hello Yann,
You read our mind. :)
For 5.0 we're going to address Maven integration much more intensively than
we've done so far.
Your wishlist is quite reasonable and we'll pay much attention to it.
There is a dedicated issue related to the subject - http://jetbrains.net/tracker/issue/TW-2390.
Post your comments directly into there and you can be sure they'll be carefully
considered.
Thank you!
--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hello Sergey,
glad to see this is going to be adressed in TC5, I have added my comments to the issue.
Did anyone succeed setting up something like the "snapshot-remote-run-across-multiple-configurations" with TC4? Does this sound like a feasible feature for TC5?
Regards,
Yann
Hello Yann,
In TC4 you can reach the similar effect if your build configurations have
properly configured dependencies.
Your remote run for the base configuration will trigger all dependent builds
as remote runs as well.
In TC5 we'll try to make this possible for Maven projects too.
--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Yes, I do have this setup - but dependent builds won't use the "current" remote-run result, but the most current one from repository. Basically I'm trying to simulate "artifact dependency from current remote run build" with Maven.
If your build A depends by snapshot dependency on build B and by artifact dependency on last finished build of B then in build A you will get artifacts from the B built from the same (or synchronized sources if VCS roots are different). Note that for artifact dependencies it is important to use "last finished" rule in this case. This will work for personal builds too.
But if your build A is Maven build which takes artifacts of build B published to the Maven repository for the moment there is no easy way to get correct artifacts. You can try to workaround this problem if you will provide correct build number of build B to build A. If you can instruct Maven to get artifacts by build number this should work. For this in build configuration A you can create property or environment variable which will reference build number from the build B, take a look here for correct syntax: http://www.jetbrains.net/confluence/display/TCD4/How+To...#HowTo...-Sharethebuildnumberforbuildsinachainbuild
Unfortunately, the second case ;-)
If you can instruct Maven to get artifacts by build number this should work#
I guess that's the big problem - I don't know of any possibility to override the "SNAPSHOT" version identifier with a "local" or passed-through version.
I do not know what we can do in this case. Probably we can write a plugin for Maven or something like this. Or maybe TeamCity should act as Maven repository and provide correct artifacts in this case like it is done for Ivy.
Exactly, Teamcity "pretending" to host a build-local repository was my basic idea/request - unless anybody succeeded in setting this up with some other magic.