No hurry. Thanks for offering to help! -Archie
On Fri, Jun 25, 2010 at 7:37 PM, Robert Buck <buck.rober...@gmail.com>wrote: > 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 > > > -- Archie L. Cobbs
