ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Buck <buck.rober...@gmail.com>
Subject Re: Ivy Roundup Fork at GitHub
Date Wed, 23 Jun 2010 23:39:46 GMT
Hi Archie,

Glad to chat....

Motivation:

I'd prefer to patch back to the original. We can talk about what
changes you want and those you don't. I detail some of the categories
of changes below. Feel free to inquire for more detail on any of the
changes, what my motivations were, etc. I'd be happy to share my
thoughts.

A little history, I already had a solution that I had created, but you
had a way for me to **generate** a repository rather than manually do
all that work which is what I had done, and with roundup came a whole
boatload more modules than I had. So that was great. The first goal
for me was to stand up a repository on my mac quickly so I could wrap
up a product of mine that my employer may be interested in licensing
from me. Also, I have been discussing the use of Ivy repositories at
work, and using RoundUp to stand them up in a farm for internal
secured use only. But we must have cross platform support for standing
up repos. So it was a win-win to just do all this work myself and then
share it. Timing.

Putting it out there into open-source is a vehicle to help others in
the same camp. So yes, better to get as much of this into the original
project as possible, I prefer to build upon someone else's work than
replace it if at all possible, but in this one case there was no
alternative than to fix it immediately so I could use it to help build
my own products. It would be nice if my project became a git-oriented
mirror of yours.

Further Ideas for Improvement:

There probably are more ways to clean this up further, like move that
ant:script definition into a separate .java file and compile it rather
than build it automatically in ant-space. I'd like to see more use of
'uptodate' in the build file to do as little work as possible. It
would be nice to minimize how much copying occurs. Lastly, it would be
nice to have in the resolver chain the address of an ivyrep that one
already has in-house to avoid the calls out to the internet; this
would help stand up new repos as you'd imagine, lots faster than
hitting the sourceforge pig, since it's faster to stay on the same
subnet.

Changes:

The buckets in order of usefulness are:

* RCS-style tags
    * rid the ivy & package files of those pesky RCS style $Id tags.
This was a personal preference because they serve the same purpose as
blame, so there is no reason to use these this day and age.
    * change the xsl files to only use ivyauthor if one is defined,
don't key off subversion / rcs tags. otherwise the author field is
just the repo.

* build.xml
    * use only ant tasks and java scripts; no awk, sed, etc...
    * don't call into subversion, stay SCM neutral
        * this means you lose the timestamps, which impacts the ivy-doc.xsl file

* java.io.tmpdir changes
    * scope the writes to tmp to roundup subdirectories
    * cleanup afterwards

* manual modules (big change here, related to tmpdir above)
    * rather than have the manual modules in a flat directory
namespace, use the same directory structure as that in src/modules,
namely [organisation]/[module]/[version]/...
    * expect manual modules to be placed in src/modules-staged , in
mac snow leopard java (hence ant) does not observe the TMPDIR
variable, so its VERY hard for anyone to figure out where tmp actually
exists (its actually down under /var/folders and has a sha1 hash of
the username (i think) as the directory name. odd, but its mac. so for
this reason i expect the manual modules to be put along side the
modules directory.
    * this impacts build.xml; i copy over src/modules-staged to
java.io.tmpdir; java.io.tmpdir is still necessary, i found no
workaround to eliminate the copy; ivy does not pass down system
properties to the packager infrastructure apparently.

* user.home changes
    * moved the cache into the output directory; personal preference
but if this were to be run under an automated system, they really
should be kept out of user space as much as possible so that after a
clean there are no stray side-effects

* modules
    * jna sha1 checksum wrong
    * robocode beta no longer available
    * added aspectj 1.6.8, different jars now
    * wattdepot sha1 checksums wrong

* misc unnecessary, but personal preferences, trimming
    * moved all copyrights to one central copyrights file
    * normalized all xml files under modules using the sed scripts i checked in
        * strip whitespace, trailing, empty lines, multiple contiguous
whitespace (xml-strip.sed)
        * rid comments (xml-comments.sed)
        * rid $Id tags (ivy-xml.sed)
        * rid 'rev' (packager-xml.sed)

On Wed, Jun 23, 2010 at 4:50 PM, Archie Cobbs <archie@dellroad.org> wrote:
> On Wed, Jun 23, 2010 at 7:13 AM, Robert Buck <buck.robert.j@gmail.com>wrote:
>
>> Have a gander. I posted an issue at the existing roundup project
>> requesting the merge of the changes to it, how much makes its way back
>> into the original project remains to be seen. Hope this helps those
>> interested in RoundUp but were unable to use it based on the issues
>> listed above.
>>
>
> Looks interesting! I'd like to see some of these fixes merged back.
>
> Your git project contains more than simple fixes though and I'm a bit
> unclear on your level of interest in the original Ivy RoundUp project. Do
> you have a proposed patch or set of patches you'd like to suggest for Ivy
> RoundUp? If not that's fine, just trying to clarify.
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>

Mime
View raw message