ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Buck <>
Subject Re: Ivy Roundup Fork at GitHub
Date Sat, 26 Jun 2010 00:37:58 GMT
I'd kindly provide diffs for the major portions: platform support and

I do have a few other priorities I have to address first, namely
getting a personal product ready for release, and ramping up on the
new Product Owner position at my full-time job, but I will get back to


 Fri, Jun 25, 2010 at 6:52 PM, Archie Cobbs <> wrote:
> Thanks for the run-down. I'd like to handle this in small chunks to minimize
> the disruption at each step (and make it easier to verify everything still
> works after the change).
> One general note: the primary goal of Ivy RoundUp is to be an online public
> repository. The goal of being able to generate repositories from it is also
> important, but secondary to the first goal. This is why "porting" to Mac OS,
> Windows, etc. has been lower priority.
> So for example, removing all references to SVN is a problem because SVN is
> how the public repo is hosted, so you want e.g. the modules.xml file to
> contain within it the SVN revision number, etc.
> I am curious about your motivations... in particular, why you need to
> duplicate the whole repository locally, rather than just having your local
> repository contain only additions (or changes) to Ivy RoundUp, and then
> prioritizing your local repo ahead of Ivy RoundUp in the resolver chain.
> Note that eliminating network access is not a real reason, because you can
> just (a) svn checkout Ivy RoundUp to a local machine and publish via HTTP on
> your local intranet, and (b) use the resourceURL attribute in your resolver
> definition to have the packager resolver pull all archives from a local
> machine as well. And Ivy RoundUp is secure to the extent you trust the SHA1
> checksums and instructions in the packager.xml files (which are easily
> reviewed).
> Anyway, as far as merging changes... let's start first with the stuff that
> makes build.xml work on non-UNIX systems. If you don't mind I'd love to see
> a (minimal impact) patch that accomplishes this.
> Thanks,
> -Archie
> On Wed, Jun 23, 2010 at 6:39 PM, Robert Buck <>wrote:
>> 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
>> * 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
>>; 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 <> wrote:
>> > On Wed, Jun 23, 2010 at 7:13 AM, Robert Buck <
>> >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
>> >
> --
> Archie L. Cobbs

View raw message