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 <gin...@apache.org>
Authored: Tue Mar 13 21:11:22 2018 +0100
Committer: Gintas Grigelionis <gin...@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]
 ----

Reply via email to