You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by gi...@apache.org on 2018/03/13 20:11:34 UTC
ant-ivy git commit: Spelling check…
Repository: ant-ivy
Updated Branches:
refs/heads/master e536c35a9 -> 44d800e1c
Spelling check…
Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/44d800e1
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/44d800e1
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/44d800e1
Branch: refs/heads/master
Commit: 44d800e1cc264634252aa61d656d58b98fa463de
Parents: e536c35
Author: Gintas Grigelionis <gi...@apache.org>
Authored: Tue Mar 13 21:11:22 2018 +0100
Committer: Gintas Grigelionis <gi...@apache.org>
Committed: Tue Mar 13 21:11:22 2018 +0100
----------------------------------------------------------------------
asciidoc/dev/apache-proposal.adoc | 28 ++++++++---------
asciidoc/dev/conflict-solving-algo.adoc | 14 ++++-----
asciidoc/dev/ideas.adoc | 46 ++++++++++++++--------------
asciidoc/dev/makerelease.adoc | 2 +-
4 files changed, 45 insertions(+), 45 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/44d800e1/asciidoc/dev/apache-proposal.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/apache-proposal.adoc b/asciidoc/dev/apache-proposal.adoc
index 04d1ede..fc8cedb 100644
--- a/asciidoc/dev/apache-proposal.adoc
+++ b/asciidoc/dev/apache-proposal.adoc
@@ -3,7 +3,7 @@
The following presents the proposal for creating a new Ivy project within the Apache Software Foundation.
== Abstract ==
-Ivy (http://www.jayasoft.org/ivy) is a java based tool for tracking, resolving and managing project dependencies.
+Ivy (http://www.jayasoft.org/ivy) is a Java based tool for tracking, resolving and managing project dependencies.
== Proposal ==
Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies. It is characterized by the following:
@@ -13,7 +13,7 @@ Ivy is a tool for managing (recording, tracking, resolving and reporting) proje
== Rationale ==
-Software development is increasingly characterized by leveraging externally provided components/capabilities and by a rapid release cycle. As a result it is not unusual for a project to depend on numerous third-party components which themselves may be dependent on a multitude of third-party of different or identical third-party components. Managing these dependencies - determining what the dependencies are, how they are used, the impact of a change, conflicts among dependencies, etc. - is extremely difficult and absolutely necessary. Ivy is one of a handful of tools addressing this need. While often compared to Maven - which has similar Ant tasks - Ivy differs from Maven in both its focus and philosophy. Ivy is solely focused on dependency management and is designed from the ground up to adapt to a wide range of requirements and scenarios. Examples include multiple aritfacts per module, plugin resolvers, configurable repository configurations and conflict managers.
+Software development is increasingly characterized by leveraging externally provided components/capabilities and by a rapid release cycle. As a result it is not unusual for a project to depend on numerous third-party components which themselves may be dependent on a multitude of third-party of different or identical third-party components. Managing these dependencies - determining what the dependencies are, how they are used, the impact of a change, conflicts among dependencies, etc. - is extremely difficult and absolutely necessary. Ivy is one of a handful of tools addressing this need. While often compared to Maven - which has similar Ant tasks - Ivy differs from Maven in both its focus and philosophy. Ivy is solely focused on dependency management and is designed from the ground up to adapt to a wide range of requirements and scenarios. Examples include multiple artifacts per module, plugin resolvers, configurable repository configurations and conflict managers.
The maintainers of Ivy are interested in joining the Apache Software Foundation for several reasons:
@@ -35,12 +35,12 @@ Ivy already has a growing user community, with more than 10,000 downloads since
Ivy has only two core developers for the moment, but we hope joining the ASF will help increase this number.
-Xavier Hanin is the creator of the project, is an independant consultant and co founder of Jayasoft. He has an experience of 9 years in Java software development, uses open source projects intensively, and started his real participation in open source development with Ivy.
-Maarten Coene has joined the committer team in may 2006. He has an experience of 9 years in java development, is co-administrator of dom4j, ex-committer for scarab, has contributed patches to several open-source projects and is a user of a lot of open-source projects.
+Xavier Hanin is the creator of the project, is an independent consultant and co founder of Jayasoft. He has an experience of 9 years in Java software development, uses open source projects intensively, and started his real participation in open source development with Ivy.
+Maarten Coene has joined the committer team in May 2006. He has an experience of 9 years in Java development, is co-administrator of dom4j, ex-committer for scarab, has contributed patches to several open-source projects and is a user of a lot of open-source projects.
=== Alignment ===
-Ivy has no mandatory dependencies except java 1.4. However, it is strongly recommended to be used with Ant. Ivy uses also other Apache projects, especially from Jakarta Commons.
+Ivy has no mandatory dependencies except Java 1.4. However, it is strongly recommended to be used with Ant. Ivy uses also other Apache projects, especially from Jakarta Commons.
== Known risks ==
@@ -48,11 +48,11 @@ Ivy has no mandatory dependencies except java 1.4. However, it is strongly recom
Due to its small number of committers, there is a risk of being orphaned. The main knowledge of the codebase is still mainly owned by Xavier Hanin. Even if Xavier has no plan to leave Ivy development, this is a problem we are aware of and know that need to be worked on so that the project become less dependent on an individual.
=== Inexperience with Open Source ===
-While distributed under an open source license, access to Ivy was initially limited with no public access to the issue tracking system or svn repository. While things have changed since then - the svn repository is publicly accessible, a JIRA instance has been setup since june 2005, many new features are first discussed on the forum or JIRA - experience with a true open source development model is currently limited.
+While distributed under an open source license, access to Ivy was initially limited with no public access to the issue tracking system or svn repository. While things have changed since then - the svn repository is publicly accessible, a JIRA instance has been setup since June 2005, many new features are first discussed on the forum or JIRA - experience with a true open source development model is currently limited.
However, Maarten has already a good experience with true open development process, and bring his experience to the project.
-=== Homogenous Developers ===
-With only two core developers, at least they are not homogenous! Xavier and Maarten knew each other only due to their common interest in Ivy.
+=== Homogeneous Developers ===
+With only two core developers, at least they are not homogeneous! Xavier and Maarten knew each other only due to their common interest in Ivy.
=== Reliance on Salaried Developers ===
Maarten is not paid to work on Ivy.
@@ -76,12 +76,12 @@ http://svn.jayasoft.org/projects/tools/ivy
Ivy has no mandatory dependencies at runtime.
For compilation, it requires: +
-apache ant +
-apache commons-httpclient +
-apache commons-cli +
-apache oro +
-apache commons-vfs +
-jcraft jsch (BSD, already used by commons-vfs and by ant)
+Apache Ant +
+Apache Commons-HttpClient +
+Apache Commons-CLI +
+Apache ORO +
+Apache Commons-VFS +
+JCraft JSch (BSD, already used by Commons-VFS and by Ant)
== Required Resources ==
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/44d800e1/asciidoc/dev/conflict-solving-algo.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/conflict-solving-algo.adoc b/asciidoc/dev/conflict-solving-algo.adoc
index 51437cb..911e2ea 100644
--- a/asciidoc/dev/conflict-solving-algo.adoc
+++ b/asciidoc/dev/conflict-solving-algo.adoc
@@ -21,19 +21,19 @@ Here are some explanations about the conflict management algorithm in Ivy.
First, one should have a good understanding on how Ivy resolves dependencies, and especially
transitive dependencies.
-During the resolve process, ivy visits each module of the dependency graph. +
+During the resolve process, Ivy visits each module of the dependency graph. +
Let's call each module a *node*, including the module we are trying to resolve dependencies for.
Each node should be able to give a conflict manager for a particular ModuleId. +
Let's name it *node.cm(mid)*.
-Each node should be able to matain a map from ModuleId to a resolved Collection of nodes.
+Each node should be able to maintain a map from ModuleId to a resolved Collection of nodes.
This resolved collection will never contain any evicted node FOR the concerned node as far
-as ivy knows, dependening on where it is in graph visit. +
+as Ivy knows, depending on where it is in graph visit. +
Let's call this map resolved, and the corresponding resolved collection *node.resolved(mid)*.
-During the visit, ivy should always know from which node it came to visit another node. Let's call
-the first node from which ivy came *node.parent*. Note that this concept is slightly different from
+During the visit, Ivy should always know from which node it came to visit another node. Let's call
+the first node from which Ivy came *node.parent*. Note that this concept is slightly different from
node parent, since a node can have several parents in the graph, but there is also one *node.parent*
during the visit.
@@ -44,8 +44,8 @@ Let's call *node.dependencies* the collection of direct dependencies of a node.
Let's call *node.revision* the module revision id of a node.
-And now for the algo. This algo attempts to evict nodes on the fly, i.e. during the ivy visit,
-to minimize the number of resolved modules, and thus the number of ivy files to download.
+And now for the algo. This algo attempts to evict nodes on the fly, i.e. during the Ivy visit,
+to minimize the number of resolved modules, and thus the number of Ivy files to download.
It is presented in a very simplified description language, far away from the whole real complexity,
but giving a good understanding of how it works. In particular, it completely hides some complexity due
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/44d800e1/asciidoc/dev/ideas.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/ideas.adoc b/asciidoc/dev/ideas.adoc
index 392aea5..03bce23 100644
--- a/asciidoc/dev/ideas.adoc
+++ b/asciidoc/dev/ideas.adoc
@@ -1,6 +1,6 @@
- messages
+
-it is quite difficult to know exactly what messages should be output to the console or not, and it often
+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.
@@ -10,36 +10,36 @@ 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
+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
+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
+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)
+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
+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,
+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
+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 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
+`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
+`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:
+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">
@@ -51,28 +51,28 @@ This would be cleaner, but less simple, and less flexible than using a tags syst
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
+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
+`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.
+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 compatiblity status updated) only when all tests are done, or when an incompatible
+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 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
+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.
+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
+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.
+It would thus allow to have more often a latest successful build, even in case of API breaks.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/44d800e1/asciidoc/dev/makerelease.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/makerelease.adoc b/asciidoc/dev/makerelease.adoc
index ca03c53..4aaf379 100644
--- a/asciidoc/dev/makerelease.adoc
+++ b/asciidoc/dev/makerelease.adoc
@@ -44,7 +44,7 @@ git clean -d -x -f
==== 3. Add Ivy xsd file.
-You need to store the current ivy xml schema in the documentation, so that it will later be accessible on public web site. To do so, run the following command in the directory in which you checked out the release branch:
+You need to store the current Ivy XML schema in the documentation, so that it will later be accessible on public web site. To do so, run the following command in the directory in which you checked out the release branch:
[source,shell]
----