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 <buck.rober...@gmail.com>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 > > * 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 <arc...@dellroad.org> wrote: > > On Wed, Jun 23, 2010 at 7:13 AM, Robert Buck <buck.rober...@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 > > > -- Archie L. Cobbs
