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 09:48:42 UTC
ant-ivy git commit: Salvage documents outside of xooki2asciidoc
migration scope
Repository: ant-ivy
Updated Branches:
refs/heads/master 2d109dece -> 4450542a0
Salvage documents outside of xooki2asciidoc migration scope
Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/4450542a
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/4450542a
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/4450542a
Branch: refs/heads/master
Commit: 4450542a0bb71eb1a396bd9071e436f5c18d8beb
Parents: 2d109de
Author: Gintas Grigelionis <gi...@apache.org>
Authored: Tue Mar 13 10:48:30 2018 +0100
Committer: Gintas Grigelionis <gi...@apache.org>
Committed: Tue Mar 13 10:48:30 2018 +0100
----------------------------------------------------------------------
asciidoc/dev/apache-proposal.adoc | 121 +++++++++++++++++++++++++++
asciidoc/dev/conflict-solving-algo.adoc | 112 +++++++++++++++++++++++++
asciidoc/dev/ideas.adoc | 78 +++++++++++++++++
xooki2asciidoc.xml | 43 ----------
4 files changed, 311 insertions(+), 43 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/4450542a/asciidoc/dev/apache-proposal.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/apache-proposal.adoc b/asciidoc/dev/apache-proposal.adoc
new file mode 100644
index 0000000..0a748a3
--- /dev/null
+++ b/asciidoc/dev/apache-proposal.adoc
@@ -0,0 +1,121 @@
+= Ivy Proposal =
+
+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.
+
+== Proposal ==
+Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies. It is characterized by the following:
+ 1) flexibility and configurability - Ivy is essentially process agnostic and is not tied to any methodology or structure. Instead it provides the necessary flexibility and configurability to be adapted to a broad range of dependency management and build processes.
+ 2) tight integration with Apache Ant - while available as a standalone tool, Ivy works particularly well with Apache Ant providing a number of powerful Ant tasks ranging from dependency resolution to dependency reporting and publication.
+
+== 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.
+
+The maintainers of Ivy are interested in joining the Apache Software Foundation for several reasons:
+ * Ivy has been hosted since its beginning in 2004 by a private company, which make people feel like it's a corporate product, thus slowing the contribution by the community. We strongly believe in the open source movement, and would like to make Ivy independent from Jayasoft.
+ * We'd like to enjoy the benefits of utilizing Apache's infrastructure and legal protection.
+ * It might open the door for cooperation with other projects, such as Ant or Maven.
+ * We strongly believe in Apache philosophy, especially Meritocracy.
+
+== Current status ==
+=== Meritocracy ===
+
+Ivy was originally created by Xavier Hanin in September 2004. Since then more than 20 users have contributed patches, and one of them has been promoted to the status of committer based on his merit through patch contribution.
+
+=== Community ===
+
+Ivy already has a growing user community, with more than 10,000 downloads since its 1.0 version and more than 500 users registered on the forum.
+
+=== Core Developers ===
+
+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.
+
+=== 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.
+
+== Known risks ==
+
+=== Orphaned products ===
+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.
+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.
+
+=== Reliance on Salaried Developers ===
+Maarten is not paid to work on Ivy.
+Xavier's case is more complex, as a co founder of Jayasoft, part of his time in Jayasoft was dedicated to Ivy and other open source developments. He now works mainly as an independent consultant, and thus is not a salaried developer.
+
+=== Relationships with Other Apache Products ===
+Ivy has a strong relationship with Apache Ant, and is often seen as a good companion of Ant. Being part of Apache could help for a closer collaboration between the two projects.
+
+=== A Excessive Fascination with the Apache Brand ===
+Even if we recognize the strong value of the Apache Brand, the purpose of joining Apache is not focused on improving the visibility of the project. The main focus of this proposition is to make Ivy a more open project, with a closer integration with Apache Ant. Even if Ivy does not join the ASF, Ivy will move out of Jayasoft umbrella and try to attract more developers.
+
+== Documentation ==
+Further reading on Ivy can be found at:
+http://www.jayasoft.org/ivy
+
+== Initial Source ==
+The initial code base can be found at:
+http://svn.jayasoft.org/projects/tools/ivy
+
+== External Dependencies ==
+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)
+
+== Required Resources ==
+
+=== Mailing lists ===
+ * ivy-private (with moderated subscriptions)
+ * ivy-dev
+ * ivy-user
+
+=== Subversion Directory ===
+https://svn.apache.org/repos/asf/incubator/ivy
+
+=== Issue Tracking ===
+JIRA Ivy (IVY)
+An import from existing JIRA issues at http://jira.jayasoft.org/ would also be very much appreciated
+
+== Initial Committers ==
+Xavier Hanin (xavier dot hanin at gmail dot com)
+Maarten Coene (maarten_coene at yahoo dot com)
+
+== Affiliations ==
+As stated in the Reliance on salaried developers section, Xavier is a co founder of Jayasoft which used to host the project. However, Jayasoft is shifting its focus to local consulting and thus won't be involved anymore in open source development. The participation of Xavier in the project is thus made as an individual, not as a member of Jayasoft. He also strongly believe in the meritocracy principle, and he's ready to see it applied to the project whatever the consequence are for his own weight in the project.
+
+== Sponsors ==
+
+=== Champion ===
+Antoine Levy-Lambert
+Sylvain Wallez
+
+=== Nominated Mentors ===
+Antoine Levy-Lambert
+Stephane Baillez
+Steve Loughran
+
+=== Sponsoring Entity ===
+The Ant PMC has voted the following resolution:
+The Ant PMC sponsors Ivy moving to the Apache Incubator.
+If the Ivy community wishes to move Ivy to become an Ant subproject
+after successful incubation, and if the ASF board agrees to it, Ant
+will welcome Ivy as a subproject after the incubation period.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/4450542a/asciidoc/dev/conflict-solving-algo.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/conflict-solving-algo.adoc b/asciidoc/dev/conflict-solving-algo.adoc
new file mode 100644
index 0000000..e144f1f
--- /dev/null
+++ b/asciidoc/dev/conflict-solving-algo.adoc
@@ -0,0 +1,112 @@
+////
+ 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
+
+ http://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.
+////
+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. +
+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.
+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. +
+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
+node parent, since a node can have several parents in the graph, but there is also one *node.parent*
+during the visit.
+
+Let's say that a conflict manager is able to filter a collection of nodes to return only those
+that are not evicted. Let's call that *cm.resolveConflicts(collection)*.
+
+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.
+
+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
+to configurations management.
+
+```
+resolve(node) {
+ node.resolved(node.mid) = <i>collection</i>(node);
+ resolveConflict(node, node.parent, empty);
+ if (!node.evicted && !node.alreadyResolved) {
+ node.loadData();
+ resolveConflict(node, node.parent, empty);
+ if (!node.evicted) {
+ // actually do resolve
+ foreach (dep in node.dependencies) {
+ resolve(dep);
+ }
+ }
+ }
+}
+
+resolveConflict(node, parent, toevict) {
+ if (node.revision.exact && parent.resolved(node.mid).revision.contains(node.revision)) {
+ // exact revision already in resolved
+ // => job already done
+ return;
+ }
+ if (parent.resolved(node.mid).containsAny(toevict)) {
+ // parent.resolved(node.mid) is not up to date:
+ // recompute resolved from all sub nodes
+ resolved = parent.cm(node.mid).resolveConflicts(
+ parent.dependencies.resolved(node.mid));
+ } else {
+ resolved = parent.cm(node.mid).resolveConflicts(<i>collection</i>(node, parent.resolved(node.mid)));
+ }
+ if (resolved.contains(node)) {
+ // node has been selected for the current parent
+ // we update its eviction... but it can still be evicted by parent !
+ node.evicted = false;
+
+ // handle previously selected nodes that are now evicted by this new node
+ toevict = parent.resolved(node.mid) - resolved;
+ foreach (te in toevict) {
+ te.evicted = true;
+ }
+
+ // it's very important to update resolved BEFORE recompute parent call
+ // to allow it to recompute its resolved collection with correct data
+ // if necessary
+ parent.resolved(node.mid) = resolved;
+ if (parent.parent != null) {
+ resolveConflict(node, parent.parent, toevict);
+ }
+ } else {
+ // node has been evicted for the current parent
+
+ // it's time to update parent resolved with found resolved...
+ // if they have not been recomputed, it does not change anything
+ parent.resolved(node.mid) = resolved;
+
+ node.evicted = true;
+ }
+}
+```
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/4450542a/asciidoc/dev/ideas.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/ideas.adoc b/asciidoc/dev/ideas.adoc
new file mode 100644
index 0000000..392aea5
--- /dev/null
+++ b/asciidoc/dev/ideas.adoc
@@ -0,0 +1,78 @@
+- 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
+
+- 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 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.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/4450542a/xooki2asciidoc.xml
----------------------------------------------------------------------
diff --git a/xooki2asciidoc.xml b/xooki2asciidoc.xml
deleted file mode 100644
index 0bb98f0..0000000
--- a/xooki2asciidoc.xml
+++ /dev/null
@@ -1,43 +0,0 @@
-<!--
- 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
-
- http://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.
--->
-<project default="generate-asciidoc" name="xooki2asciidoc" xmlns:xooki="antlib:xooki">
- <import file="build-release.xml"/>
-
- <target name="generate-asciidoc">
- <!-- requires java 6 jdk in path and Apache Ant 1.7 -->
- <taskdef uri="antlib:xooki" file="${basedir}/doc/xooki2asciidoc/antlib.xml" />
- <xooki:toAsciidoc destDir="${doc.src.dir}" checkUpToDate="true" xookidir="${basedir}/doc/xooki2asciidoc">
- <fileset dir="${basedir}/doc">
- <include name="**/*.html"/>
- <exclude name="template*.html"/>
- <exclude name="*Template.html"/>
- <exclude name="conflict-solving-algo.html"/>
- <exclude name="use.html"/>
- <exclude name="samples/**"/>
- <exclude name="js/**"/>
- <exclude name="reports/**"/>
- <exclude name="xooki/**"/>
- </fileset>
- </xooki:toAsciidoc>
- <copy todir="${doc.src.dir}">
- <fileset dir="${basedir}/doc" includes="toc.json,images/**,style/**,samples/**,js/**,ivy.xsd" />
- </copy>
- </target>
-
-</project>