Menu
▾
▴
jython-dev
|
From: Jeff A. <ja...@fa...> - 2019-08-19 07:30:40
|
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 |
|
From: Jeff A. <ja...@fa...> - 2019-08-19 20:51:50
|
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 > |
|
From: Jim B. <jim...@py...> - 2019-08-19 21:05:47
|
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 > |
|
From: <fwi...@gm...> - 2019-08-20 21:19:01
|
On Mon, Aug 19, 2019 at 2:06 PM Jim Baker <jim...@py...> 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. > FWIW I can confirm that it was on CVS, one of my earliest contributions was helping to move to SVN. -Frank |
|
From: Adam B. <ada...@gm...> - 2019-08-20 02:55:01
|
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 > |
|
From: Jim B. <jim...@py...> - 2019-08-20 04:19:50
|
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 >> > |
|
From: <fwi...@gm...> - 2019-08-20 21:21:12
|
On Mon, Aug 19, 2019 at 7:55 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. I'm also all for this approach, it would be nice to slowly move to gradle. -Frank |
|
From: Jeff A. <ja...@fa...> - 2019-08-28 22:04:48
|
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 <ja...@fa... > <mailto: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... >> <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 >> > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Oti <oh...@gm...> - 2019-08-21 05:34:53
|
Hi Jeff I think you are completely right that checking out makes only sense for doing a release full build. If you want a full build from your local sources, without a checkout, you can define # - set this to false if you want the full build run from the checked out sources has.repositories.connection=false in the file 'ant.properties' just beside 'build.xml'. Thats the way I always did it. I hope this still works for you. Best wishes, Oti. On Mon, Aug 19, 2019 at 9:31 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 > -- http://ohumbel.me |
|
From: Jeff A. <ja...@fa...> - 2019-08-21 19:09:25
|
Oti: Nice to hear from you as I know your prints are on this from way back. As I understand it, -Dhas.repositories.connection=false would let me use the checked-out copy from an initial full-build. I think that does still work, in itself, but a few other things don't, and I find them hard to debug in that configuration. I'm pursuing the idea that the build should occur in normal checkout directory: a fresh one, not where I've previously done development. I tend to do these from a local, never-modified, clone of hg.python.org/jython, to spare the upstream server and for reliability. Being clear in the instructions that a build properly for release must be from fresh, and putting in some simple safeguards, will control the risk of building from a polluted state (is the idea I'm testing). Meanwhile I can hack at it and run full-build as much as I like, breaking the above rule (making only snapshot installers), knowing that I'm testing the release process we eventually use when building seriously. I only see a few small obstacles (e.g. the checked-out README.txt is modified in situ) and I know what to do about them. Jeff Allen On 21/08/2019 06:34, Oti wrote: > Hi Jeff > > I think you are completely right that checking out makes only sense > for doing a release full build. > If you want a full build from your local sources, without a checkout, > you can define > > > # - set this to false if you want the full build run from the checked > out sources > > has.repositories.connection=false > > > in the file 'ant.properties' just beside 'build.xml'. > > Thats the way I always did it. > I hope this still works for you. > > Best wishes, > Oti. > > On Mon, Aug 19, 2019 at 9:31 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 > > > > -- > http://ohumbel.me |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X