Ivy integreation

Hi,

first of all I have to say that I'm very happy about the fact that
JetBrains decided to include Ivy as dependency manager in TeamCity, but
the integration is IMHO far from perfect (or in my case far from being
usable).

All of my modules contain ivy.xml files. As of now TeamCity just
plain ignores them and generates it's own ivy.xml. As a result of that
all the dependencies that the module has by itself are ignored.

If an ivy.xml file exists in the same directory as the build.xml file
(for instance) use the organization and module values declared in that
file instead of this cryptic build identifier (bt*).

Ivy is very powerful and using chain resolvers one can easily cascade
different repositories. Say I've my release builds in a repository of
it's own and want to switch to a CI build of a specific module for
further development. If TeamCity would reuse existing organization &
module declarations all I would have to do is change the rev attribute
from say "latest.release" to "latest.lastFinished". Ivy then could
automatically resolve this module dependency from the TeamCity repository.

Another annoyance is the revision number in the ivy.xml file
generated by TeamCity. "13.lastFinished" for instance is absolutely
unnecessary. "lastFinished" is already set as the status of the build.
It doesn't have to pollute the revision number.

One last thing... The access to the integrated ivy repository seems
not to be protected. So if anybody runs a TeamCity server on the
internet the Ivy repository is accessible by anyone.


Sascha

2 comments
Comment actions Permalink

Hello,

first of all I have to say that I'm very happy about the fact that
JetBrains decided to include Ivy as dependency manager in TeamCity, but
the integration is IMHO far from perfect (or in my case far from being
usable).


It would be good if you took part in our EAP program, I guess in this case
the Ivy integration would be much better and complete ;)

All of my modules contain ivy.xml files. As of now TeamCity just plain
ignores them and generates it's own ivy.xml. As a result of that all the
dependencies that the module has by itself are ignored.


I see your point. Please watch for this issue:
http://www.jetbrains.net/jira/browse/TW-2392

If an ivy.xml file exists in the same directory as the build.xml file
(for instance) use the organization and module values declared in that
file instead of this cryptic build identifier (bt*).

>

Ivy is very powerful and using chain resolvers one can easily cascade
different repositories. Say I've my release builds in a repository of it's
own and want to switch to a CI build of a specific module for further
development. If TeamCity would reuse existing organization & module
declarations all I would have to do is change the rev attribute from say
"latest.release" to "latest.lastFinished". Ivy then could automatically
resolve this module dependency from the TeamCity repository.


In TeamCity Ivy module is mapped to build configuration, and to allow
TeamCity recognize from which build configuration to download file we have
to have build configuration id in the URL. What if we will allow to
configure mapping between your organizations and module names and build
configurations on the server side?

Another annoyance is the revision number in the ivy.xml file generated
by TeamCity. "13.lastFinished" for instance is absolutely unnecessary.
"lastFinished" is already set as the status of the build. It doesn't have
to pollute the revision number.


This should be fixed in the next release.

One last thing... The access to the integrated ivy repository seems not
to be protected. So if anybody runs a TeamCity server on the internet the
Ivy repository is accessible by anyone.


Yes, this is true. We could probably protect it by basic HTTP authorization
with password specified in some UI on the server side. Looks like we need
some UI for configuring Ivy settings...

Watch for http://www.jetbrains.net/jira/browse/TW-2393

Thank you for your feedback!

--
Pavel Sher



0
Comment actions Permalink

Hi,

Pavel Sher wrote:

It would be good if you took part in our EAP program, I guess in this case
the Ivy integration would be much better and complete ;)


Maybe... To be honest I had no real interest in TeamCity until I heard
of the Ivy integration.

In TeamCity Ivy module is mapped to build configuration, and to allow
TeamCity recognize from which build configuration to download file we have
to have build configuration id in the URL. What if we will allow to
configure mapping between your organizations and module names and build
configurations on the server side?


I think that would work.

Sascha

0

Please sign in to leave a comment.