[ http://issues.apache.org/jira/browse/VELOCITY-502?page=comments#action_12454099 ] Henning Schmiedehausen commented on VELOCITY-502: -------------------------------------------------
Hm. That is a *very* specific patch. I tried ant -Dforce.jar.loading=1 and force.jar.loading=0 with no success until I found out that it's -Dforce.jar.loading=true that works. It is a good and useful idea, but I'm not sure if we don't already have that semantics. We don't have them automatically, I agree. I'm actually -1 on that patch. I would agree to a patch that removes -Dskip.jar.loading and adds the following property and behaviour: velocity.jar.download never ---> Never go to the internet. Like skip.jar.loading= true once ---> Proposed behaviour. Check for presence, if missing download. If existing, do nothing. check ---> Current behaviour. Check for presence, if missing download, if existing, check timestamp. always ---> Like "force.jar.loading" We can argue whether "once" or "check" should be the default. Building the jar is a rare case for our users. They only do it if the want to debug a patch or a change. In that case, you want the build succeed and not chase a wild goose because of a stale jar. If ibiblio gets in your way, add -Dskip.jar.loading to your .build.properties. But I don't want to have a second (different named, booo!) property whose semantics are different from skip.jar.loading (here, presence is enough, for the proposed change the property must actually contain the 'True' value) which muddles the options that an user must go through. > Skip jar verification unless "force.jar.loading" is true > -------------------------------------------------------- > > Key: VELOCITY-502 > URL: http://issues.apache.org/jira/browse/VELOCITY-502 > Project: Velocity > Issue Type: Improvement > Components: Build > Affects Versions: 1.5 beta2 > Environment: all > Reporter: Claude Brisson > Priority: Minor > Fix For: 1.5 > > Attachments: jar-downloading.patch > > > When the www.iblibo.org/maven repository is down (as it seems right now, at > least from here), or when you want to work form an unconnected place (yes, it > still exists...), build fails because ant wants to check every jar timestamp. > The attached patch modifies this behaviour: if a jar file is already present, > the repository is not hit at all (why would we have to check any timestamp > anyway since version numbers are present inside filenames?!). > The new force.jar.loading property forces reloading of jar files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
