mirror of https://github.com/apache/ant-ivy
98 lines
5.2 KiB
Plaintext
98 lines
5.2 KiB
Plaintext
////
|
|
Licensed to the Apache Software Foundation (ASF) under one
|
|
or more contributor license agreements. See the NOTICE file
|
|
distributed with this work for additional information
|
|
regarding copyright ownership. The ASF licenses this file
|
|
to you under the Apache License, Version 2.0 (the
|
|
"License"); you may not use this file except in compliance
|
|
with the License. You may obtain a copy of the License at
|
|
|
|
https://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing,
|
|
software distributed under the License is distributed on an
|
|
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
KIND, either express or implied. See the License for the
|
|
specific language governing permissions and limitations
|
|
under the License.
|
|
////
|
|
|
|
- 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 compatibility 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
|
|
|
|
- compatibility 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 compatibility 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 compatibility 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 compatibility 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 each step, but only update the tag if the compatibility level
|
|
is better than the previous one. Another task would 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.
|