I'd kindly provide diffs for the major portions: platform support and java.io.tmpdir.
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 this. Cheers, Fri, Jun 25, 2010 at 6:52 PM, Archie Cobbs <arc...@dellroad.org> 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 <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 >
