On 2/12/02 6:24 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
> on 2/12/02 1:18 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote: > >> All that was required for me was the addition of the xmlrpc jar. I updated >> the deps.list so all you have to do is update-jars. > > Clearly that was something broken, right? That build didn't work, but I don't think that means the build processes are broken. By that I mean the methods we're using to build and the ones I want to move toward. Sure, it didn't build. I've fixed tons of things like that. Would have taken you less time to fix it than it would have to complain about it. > >> I have received nothing but thanks since the update-jars target went into >> the build file. If you have specific complaints I will address them, but as >> far as I know the build process is working and it will be better over the >> next few days. The work in the rundata_branch is evidence of that. > > I'm not running off a branch, I'm running off of head. I merely suggested looking at it as it prevents problems like what just happened in Stratum. Adding a jar requires changes in too many places, which I admit is my doing, and it will be fixed. >> I take gump warnings with a very huge grain of salt. Gump helps but is still >> jar from any certain indication that there is actually anything wrong. > > Honestly, the fact that Gump is failing is a HUGE error No it's not, I'm sorry but it's not. Gump has been failing on Stratum because JGL couldn't be found, and it couldn't be found because Sam removed it, and Sam removed it because he is publicly nudging us away from products with licenses that aren't 100% clear. That is not a build problem, that is Sam's opinion. An opinion I'm not averse to but not willing to move on as quickly as Gump wants. Gump is a useful tool, but it is also a public coercion mechanism which Sam is fully cognizant of. Again, it doesn't bother me but call a spade a spade. Sometimes the Gump errors are a direct result of what Sam feels we should do. Everyone jumps to fix stratum and it fucks up all over the place. Or Aaron takes your suggestion at trying to put in XMLRPC and he typo'd, it's a simple mistake. The world isn't going end because of it, just fix it and go about your business. Just because Gump can't build it doesn't mean the rest of the world can't. > I'm *still* waiting for Gump to produce javadocs for Turbine3...it has been > about a month now... > > http://nagoya.apache.org/gump/ Time for you to pull out one of those magic shell scripts to do the trick :-) >> Other than the JAR available on the website I don't really see anything >> wrong. I'm not having huge problems I just built stratum after adding xmlrpc >> and I just built everything else. > > As far as I know, the jdbc*ext*.jar is also not supposed to be on there. Ok, I will update the deps.list files to account for that. >> Remember the build systems are for building turbine products and will move >> away from being oriented toward someone trying to build absolutely >> everything under the sun. If you want to do that then use gump. I agree that >> the build systems are a bit of a mess but they are working and when I'm >> finished with some changes in the t3 branch that I'm working it will be much >> cleaner. > > They aren't working, you admit that yourself above...you just had to fix > something to get it working again... Yes, I had to fix something. I think this is a natural process of decoupling, things get messier. I'm trying to make a single build.xml file that will work for all of our projects (I actually have it working, it's not vapourware this time) so that the errors are reduced, building is easy while not having to keep JARs in CVS and moving toward a build system that we can share with other projects. I am used to you but do you think you could try to be a tad more supportive. You of all people are smart enough to fix these little glitches. Maybe you don't feel you should have to anymore, maybe I should be more diligent with the build files but the glitches are always going to be there. > -jon > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
