Re: [Jython-dev] Reworking build.xml

[Jeff A. <ja...@fa...>]

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... 
> <mailto: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...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>