Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (nike.apache.org: domain of buck.robert.j@gmail.com
 designates 74.125.82.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=c+cUrzIcNb1oQv8MRDAKu9+ZfryzysFov9DdYhAHyNYQqkcwuhGmpWWRE8EZqw7jiI
         qQ1rJPnlnvvZqIJVa0b+i8qGszu7JGVL0bMVGr3OHCr8v44QJt4p4aP0h0BtbZZtHGZI
         WJnbvukfWcfdUXS2AKl1XZuUCfYPXzatU4zJo=
MIME-Version: 1.0
In-Reply-To: <AANLkTilLyIZOXr-AtWHY03WonSNTwcYxsStmqXt2xrnV@mail.gmail.com>
References: <AANLkTilytKQN5tun2IXyYATZe2KtVHYagSZKH5H6RKc9@mail.gmail.com>
	<AANLkTimCRo9GzAVRpMssi8Jm8p_FHmO7ou37lWXouj0t@mail.gmail.com>
	<AANLkTinh58bfQY0BMuEEyb8_cc402nhR9D-AnywkFfOw@mail.gmail.com>
	<AANLkTilLyIZOXr-AtWHY03WonSNTwcYxsStmqXt2xrnV@mail.gmail.com>
Date: Fri, 25 Jun 2010 20:37:58 -0400
Message-ID: <AANLkTimyuCjFyNHlIvZaFR0W3uk_E6ewxwYBeWLQkHhS@mail.gmail.com>
Subject: Re: Ivy Roundup Fork at GitHub
From: Robert Buck <buck.robert.j@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 minim=
ize
> the disruption at each step (and make it easier to verify everything stil=
l
> works after the change).
>
> One general note: the primary goal of Ivy RoundUp is to be an online publ=
ic
> repository. The goal of being able to generate repositories from it is al=
so
> 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 i=
s
> 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 loca=
l
> 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 ca=
n
> 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 resolv=
er
> 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 SH=
A1
> 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 tha=
t
> makes build.xml work on non-UNIX systems. If you don't mind I'd love to s=
ee
> 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>wro=
te:
>
>> 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
>> =C2=A0 =C2=A0* 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.
>> =C2=A0 =C2=A0* change the xsl files to only use ivyauthor if one is defi=
ned,
>> don't key off subversion / rcs tags. otherwise the author field is
>> just the repo.
>>
>> * build.xml
>> =C2=A0 =C2=A0* use only ant tasks and java scripts; no awk, sed, etc...
>> =C2=A0 =C2=A0* don't call into subversion, stay SCM neutral
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* this means you lose the timestamps, which i=
mpacts the ivy-doc.xsl
>> file
>>
>> * java.io.tmpdir changes
>> =C2=A0 =C2=A0* scope the writes to tmp to roundup subdirectories
>> =C2=A0 =C2=A0* cleanup afterwards
>>
>> * manual modules (big change here, related to tmpdir above)
>> =C2=A0 =C2=A0* 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]/...
>> =C2=A0 =C2=A0* 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.
>> =C2=A0 =C2=A0* 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
>> =C2=A0 =C2=A0* moved the cache into the output directory; personal prefe=
rence
>> 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
>> =C2=A0 =C2=A0* jna sha1 checksum wrong
>> =C2=A0 =C2=A0* robocode beta no longer available
>> =C2=A0 =C2=A0* added aspectj 1.6.8, different jars now
>> =C2=A0 =C2=A0* wattdepot sha1 checksums wrong
>>
>> * misc unnecessary, but personal preferences, trimming
>> =C2=A0 =C2=A0* moved all copyrights to one central copyrights file
>> =C2=A0 =C2=A0* normalized all xml files under modules using the sed scri=
pts i checked
>> in
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* strip whitespace, trailing, empty lines, mu=
ltiple contiguous
>> whitespace (xml-strip.sed)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* rid comments (xml-comments.sed)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* rid $Id tags (ivy-xml.sed)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* rid 'rev' (packager-xml.sed)
>>
>> On Wed, Jun 23, 2010 at 4:50 PM, Archie Cobbs <archie@dellroad.org> wrot=
e:
>> > 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 bac=
k
>> >> 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
>