ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: Ivy Roundup Fork at GitHub
Date Sat, 26 Jun 2010 00:59:13 GMT
No hurry. Thanks for offering to help!

-Archie

On Fri, Jun 25, 2010 at 7:37 PM, Robert Buck <buck.robert.j@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 <archie@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.robert.j@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 <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
> >> >
> >>
> >
> >
> >
> > --
> > Archie L. Cobbs
> >
>



-- 
Archie L. Cobbs

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message