mirror of https://github.com/apache/ant-ivy
71 lines
4.5 KiB
Plaintext
71 lines
4.5 KiB
Plaintext
- messages
|
|
it is quite difficult to know exactly what messages should be output to the console or not, and it often
|
|
depends on the user profile: beginner, expert, build manager, simple user, ...
|
|
|
|
Being able to define the messages output in a single and homogeneous way could be a good thing.
|
|
|
|
To allow this, maybe a solution could be to output messages in the code only by using keys:
|
|
LOGGER.debug("unhandled.revision", mrid.getRevision());
|
|
|
|
The LOGGER would be a constant initialised with the class name.
|
|
|
|
a profile wold consist in a message.properties file, associating each key (prefixed by the FQCN) to a
|
|
message for the given profile. A key with no mapping result in no message at all.
|
|
|
|
it would be possible to disable all messages of a class or activate only a certain level per class
|
|
(as in log4j for instance) to customize a profile at runtime
|
|
|
|
shifting is costly, about 400 calls to messages
|
|
|
|
- promote task to update an already published module with a new status
|
|
this task would also automatically update compatiblity data (see below)
|
|
- tag task to add one or several tags to an already published module
|
|
tag could be added in a simple properties file next to the module ivy file
|
|
this properties would be updated by this task
|
|
every time ivy parses an ivy file, it would try to locate corresponding tag file,
|
|
and if any load tags in the module descriptor instance
|
|
- compatiblity data
|
|
tags could be used for to indicate that a module has some compatibility level
|
|
with another one: if module A 2.0 has been tested successfully with B 1.0 and thus obtain status milestone,
|
|
then a tag "compatible.with.A.2.0=milestone" is put on B 1.0
|
|
then latest version matcher code could be updated to handle something like this:
|
|
latest.compatible.milestone
|
|
to be able to get the latest version of a dependency with at least a tag like
|
|
compatible.with.A.[any revision]=milestone
|
|
|
|
since all tags should be inspected to know that, maybe using an xml file like this would be better:
|
|
<compatible>
|
|
<module org="orga" name="A">
|
|
<revision name="2.0" status="milestone"/>
|
|
</module>
|
|
</compatible>
|
|
This would be cleaner, but less simple, and less flexible than using a tags system, which could be used
|
|
for other use cases.
|
|
|
|
Another solution would be to put two tags on B 1.0: one with A revision, and one without. The tag without
|
|
the revision could be used for latest.compatible.*, meaning that the last compatiblity status only would
|
|
be used. For instance, A 2.0 is said to be release compatible with B 1.0. using latest.compatible.release
|
|
is thus resolved to B 1.0. But now A 2.1 is built, and a first test tell that it is (at least) milestone
|
|
compatible with B 1.0. The compatibility status of B is thus decreased to milestone, and
|
|
latest.compatible.release is not resolved anymore to B 1.0, but maybe B 0.9... at least until the release
|
|
compatibility tests are done on A. Then if it is release compatible, the tag is put back to the good status,
|
|
and if it isn't compatible, the compatiblity status is left to milestone, which is ok.
|
|
Consequently the main problem with this solution is the time before all the tests are run. So maybe a module
|
|
should be promoted (and thus compatiblity status updated) only when all tests are done, or when an incompatible
|
|
level is reached. Note that this solution is only acceptable in case of automatic tests. When the promotion is
|
|
done by a QA team several days or even weeks after the previous status, maybe we can't wait for these tests
|
|
to be done...
|
|
Another solution would be to promote the module at eeach step, but only update the tag if the compatibility level
|
|
is better than the previous one. Another task woudl then allow to indicate an incompatibility, if some level of
|
|
tests then fails.
|
|
|
|
|
|
switching between latest compatible and latest version could also be done without any modification in ivy file:
|
|
use latest.* dependency revision, and configure your resolve task to use compatible only versions.
|
|
|
|
this way testing absolute latest version for a continuous integration server would be easy, and if the latest
|
|
version fails, latest compatible could be used easily, to test the module in a relative isolation of dependency
|
|
changes. In this case the continuous integration server should notify of the first failure before notifying of
|
|
the success of the compatible build: integration of latest modules has failed, but not the module itself.
|
|
It would thus allow to have more often a latest successful build, even in case of api breaks.
|