On 3/16/06, Mark Hindess wrote: > > On 3/16/06, Stepan Mishura wrote: > > Hi Mark, > > > > > > > >I will submit patches to improve the download process for the few > > >people that don't have (transparent proxy) internet access. > > > > > > > Please add property IdontHappyWithNetworkBuildUseLocalCopies :-) > > See thread "svn commit: r38617" for a brief outline of what I intend > or just give me an hour or so to submit something to JIRA. ;-) > > Rest assured my proposed solution will only attempt network access > *if* the files are missing.
Agree. > > > > >Can you provide more details of the test failures? I only have one > > >which only affects the eclipse compiler which (probably correctly) > > >doesn't like the non-ASCII characters in the URITest.java source. > > > > > > > The problem is signed BC provider jar. May be it makes sense to update > the > > ant script to download BC provider's jar, remove signature and copy > unsigned > > jar file to deploy/jre/lib/ext. > > I'm surprised the old tests worked for you. Old tests don't depend on this jar except security and x-net. Currently in x-net module such tests are excluded and the ant script for security module adds explicitly provider's jar to the bootclasspath as work around. We don't currently automate that at all. Personally, I'm copying an > unsigned bcprov.jar in to my tree between build and test. I assumed > this had already been covered on the list and that others were doing > something similar already. > > I created the unsigned jar manually using: > > zip -d bcprov.jar META-INF/BCKEY.SF > > I'd need to check to see if this could be acheived using the ant zip task. > > It would be good to automate the download and removal of the key. I > wonder if we are allowed to do this I understand that we have to be > careful what we include in the default build - will need to check the > license. If license forbids automating this process what about not removing unsigned jar during clean up? So unsigning by hands will be done only once. Don't expect this in my first attempt at cleaning up the depends process, > but it > is certainly something we need to work on. > > > Mark, you don't need to excuse for your work - everybody does mistakes. > You > > did great job with contributions integration! I only worried about how > to > > make process of tracking commits to repository more transparent and > easy. > > I'm not sure it's ever going to be easy to handle commits of > contributions. Even for a committer I still feel that the approach of > checking in and then fixing is the approach that gives the most > clarity with respect to provenance. Agree with small addition - new code should try gently expend existing codebase rather then change everything dramatically. The only exception I made to this was renaming tests because I know > how much of a headache renaming can be ... specifically how patches > get out of date when things move around before they get committed. Yes, it is problem. May be it makes sense to specify dependencies between patches? JIRA allows this. So if one patch makes another patch out of date then JIRA let committer to know and she/he will try to apply patches in the right order. Thanks, Stepan. Regards, > Mark. > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > -- Thanks, Stepan Mishura Intel Middleware Products Division
