ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs" <arc...@dellroad.org>
Subject Re: Open source ivy files project?
Date Wed, 02 Apr 2008 15:30:43 GMT
Thanks for all the comments so far regarding this idea. The first step was
to get a discussion going and so far that's worked :-)

Some more thoughts... please let me know what you think makes sense and what
doesn't...

*Organizations.* Regarding choice of "organization" for each module: why not
use the name of the project as the organization for all of the ivy modules?
That is what we do internally in our "enterprise repository".

This seems obvious to me, but maybe I'm misunderstanding what "organization"
is supposed to be for. I've always thought of it as referring to the people
that created the *module* (not the *artifacts*).

If you don't do it that way, you eliminate the possibility of multiple
packagers of the same stuff, which would be bad (e.g., think about how many
different Linux distributions there are).

*Volunteers. *Regarding finding volunteers: there is no problem here. Either
there will be enough interest and volunteers and the project will succeed,
or there won't and it will die. This is the way open source is supposed to
work!

Also: regarding the question of whether Ivy developers should be spending
their time on this idea. Answer: what a flattering idea :-) This project
would however be separate from Ivy. Ivy developers would of course be
welcome and encouraged but there would hopefully be plenty of other "random"
people involved (like me). The best would be if a developer of each java
project was maintaining their own project's meta-data.

*Configurations. *Regarding defining configurations: I think the general
approach with each module should be to start simple, then refine over time,
and plan an "additive" evolution. That is to say, it's much less disruptive
for a module to add a new configuration than it is to change or remove an
existing one. So the general evolution should be that new, more precise
configurations are added over time as necessary/desired.

Example: you have "production" and "test" and want to refine along the JDK14
vs JDK15 dimension. Then you leave "production" and "test" alone but add
"production-jdk14", "test-jdk14", "production-jdk15", and "test-jdk15". This
way things stay backward compatible.

*Public vs. Internal.* While it's true that an internal private repository
is always going to be safer and more secure than a public one, I think we
can be smart here, and it doesn't have to be "all or none", i.e., you can
choose where along the spectrum you want to live.

First, the meta-data instructions that knows how to retrieve the archive
from wherever would be required to confirm integrity via checksums. This
eliminates one source of potential "poisoning".

Secondly, this project would really be composed of two separate things:

   1. Meta-data/instructions describing how to retrieve and/or build each
   module's ivy.xml file and artifacts (with integrity checksums for all
   external resources)
   2. A new ivy resolver that knows how to use the meta-data in #1 to
   resolve ivy modules

So for example there's no reason a paranoid enterprise couldn't use the
resolver in #2 but replace #1 with their own meta-data, etc.

*Name. *We'd need a name for this project. I suggest "Ivy Roundup".

*SVN Repository.* The project would have its own SVN repository.

This would contain meta-data (in whatever form) describing how, for each
module, to retrieve and/or build the ivy.xml and artifacts in that module.
This meta-data could be as simple as an ant build.xml, or perhaps an XML
file in a simple domain-specific language (<extract url="http://.../foobar.zip"
file="dist/foobar.jar"/>) or whatever.

If a source project includes its own ivy.xml file, it can be used directly
(possibly with changes applied via XSLT). Otherwise the likely common case
would be that the ivy.xml is just included directly in the meta-data.

We would optimize for projects published via maven, where we can derive some
or all of our meta-data from the maven meta-data (<maven-project
url="..."/>).

The SVN repository would also contain Java code that defines an ivy resolver
that knows how to utilize the above meta-data to resolve Ivy modules
(someday if there is great success this could be merged into ivy itself).
This resolver would be configurable so that it could work with propely
formed meta-data from any source, not just this project's version of it.

*Website. *The project web site must provide an easy way to visually inspect
the (styled HTML) meta-data for each module using a web browser (perhaps
using direct SVN HTTP access). Also it should have a simple search
capability.

Now what is the end result of this project, i.e., the product produced by
this project? What exactly do you download and how do you use it?

One possibility is that the output of this project would be an ivy module,
containing the meta-data and resolver.

The project would also have its own public Ivy repository, but containing
only one module: itself.

To make use of this, users would then:

   1. Add the project's ivy repository to their settings
   2. Use ivy to download the project module normally
   3. Update their ivy settings to use the project's resolver, configured
   to point at the project's website

Of course steps #1 and #2 could be done manually as well.

Thanks,
-Archie

P.S. I apologize for the duplicate original email (got tricked by gmail
email aliasing problem)

-- 
Archie L. Cobbs

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message