Re: [Jython-dev] Reworking build.xml

[Jim B. <jim...@py...>]

Adam, agreed with this approach. I had hoped we would do it for 2.7.2 but
clearly I was too ambitious given the time I had available!

On Mon, Aug 19, 2019, 8:54 PM Adam Burke <ada...@gm...> wrote:

> Over time, $0.02 in hand, I would suggest cutting pieces out of the ant
> build and moving them into the gradle build. As gradle can invoke ant, it
> does not need to be done in one big hit, but can be tackled task-by-task.
> Have gone through a similar process in the past with maven wrapping ant,
> then finally discontinuing the use of ant after multiple iterations.
>
> Eg one starting point could be to make gradle clean the definitive clean
> job.
>
> Can't remember if this was the stated direction in the past, but have seen
> it work.
>
> Cheers
> Adam
>
> On Tue, 20 Aug 2019 at 06:52, Jeff Allen <ja...@fa...> wrote:
>
>> Jim:
>>
>> Maybe the distinct checkout was necessary with SVN. It doesn't seem to be
>> now.
>>
>> Regarding snapshots, you may find the current tip (just pushed)
>> interesting as one can now easily make a snapshot installer. We could
>> (maybe should) label the JAR with the version, but at present, that's the
>> job of the separate maven/build.xml.
>>
>> Also, I finally figured out how branding the README is supposed to work.
>> :)
>>
>> Jeff Allen
>>
>> On 19/08/2019 21:38, Jim Baker wrote:
>>
>> Jeff,
>>
>> Your cleanup and observations make sense to me. I don't know the exact
>> history, but certain decisions in build.xml were no doubt prompted by
>> earlier VCS aspects - at the very least, Jython has been on Subversion and
>> Mercurial while I have worked on it, but surely it was even earlier on
>> something like CVS.
>>
>> Looking forward: We can clearly can snapshot the build more readily and
>> reduce overhead. Ideally it's built purely in a fresh container, etc, as
>> part of an overall CI, but let's not get ahead of ourselves, especially
>> given testing realities on Windows, OSX, and Linux.
>>
>> - Jim
>>
>> On Mon, Aug 19, 2019 at 1:30 AM Jeff Allen <ja...@fa...> wrote:
>>
>>> There are swathes of build.xml I've never really understood. Many are
>>> bits that have to work to make a release (full-build). A lot of this is
>>> good, but somewhat buggy, and it has been "particularised" to releases
>>> in the past, by which I mean what might have been general-purpose logic
>>> has become hard-coding of the answer for that particular release,
>>> presumably to work around some shortcoming in the logic.
>>>
>>> It is difficult to debug the full-build target because it checks out a
>>> fresh copy of the repo and works on that. This is slow, and in my
>>> experience frail. It also means that when testing some hacky idea, it
>>> (or parts of it) have to be pushed to the official repo. I think this is
>>> how the particularisations got into the official copy.
>>>
>>> So I'm trying the idea of full-build without the checkout. It's quite a
>>> big change to build.xml. Building a release from the directory where you
>>> do development is a bad idea, I know, because there are always extra
>>> files lying around that can get incorporated, or might be necessary to
>>> make it work, but you didn't check in. For the same reason, it is good
>>> routinely to have an integration workspace to which you pull before you
>>> push: with git it is a topic branch of your personal repo.
>>>
>>> I think that for a release, one would always check out to a clean
>>> workspace, so it is not necessary to have the script do it. I have
>>> incorporated tests to warn us when it is not clean (hg status, etc.),
>>> and then one can only build a "SNAPSHOT". Apart from these tests, the
>>> whole script gets somewhat simpler. Or maybe I just understand it better.
>>>
>>> I may have missed an important reason why we did the checkout elsewhere:
>>> do say if you know it.
>>>
>>> As always, this is turning up lots of things I never knew or noticed.
>>> E.g. have you noticed "ant clean" doesn't do a complete job these days?
>>> Not for me, anyway. I'm left with some editor droppings that have
>>> accumulated in my build/dist directories. They prevent a complete clean
>>> because of https://ant.apache.org/manual/dirtasks.html#defaultexcludes
>>> .
>>> And I have figured out the intended template processing of README.txt so
>>> it need not be kept in sync manually.
>>>
>>> I just thought I'd say on the list what I'm up to.
>>>
>>> --
>>> Jeff Allen
>>>
>>>
>>>
>>> _______________________________________________
>>> Jython-dev mailing list
>>> Jyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>