Re: Reworking build.xml
Jeff Allen <[email protected]>
| Newsgroups | gmane.comp.lang.jython.devel |
|---|---|
| Message-ID | <[email protected]> |
I did a fair amount with the Gradle build, but then got stuck. Gradle has a strong principle of "configuration by convention", which in this contrext means if we lay out our work the Gradle way, then default behaviours will automatically do a lot we want. Our layout is nothing like that. I think I'm stuck because with the layout we have, one has to work hard against Gradle, which means understanding a lot of options and features of the DSL. I concluded that restructuring of the code is a pre-requisite for the transition to Gradle. In that case, the change may be easier as a "big bang", where we stop using Ant abruptly. That or we have to rewrite the Ant build for the new layout so it can continue to be the workhorse. I would have judged the latter impractical a few weeks ago, but have got to know Ant and build.xml quite well lately, putting gradual back as a possibility. Jeff Allen On 20/08/2019 03:54, Adam Burke 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > _______________________________________________ > Jython-dev mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/jython-dev > _______________________________________________ Jython-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev