Jeffery, thank you for taking the time to explain the potential source of error. I am considering putting some macros on github. So a lot of the issues will be avoided. And by properly labeling each revision (changes), I should be ok with backward compatibility.
Thank you for the advice, Jeffery. On Thu, Mar 8, 2012 at 9:20 PM, Jeffrey E Care <ca...@us.ibm.com> wrote: > Don't misunderstand: I think a shared, common process is a good thing & > should be encouraged. My problem is more about how that sharing is > implemented by people who only "play" at being release engineers. > > Example: > > 1) Do you care about being able to recreate your builds a week from now? A > month? A year? Five years? Ten years? (Yes, we still service product > releases that have been in the field for 10+ years.) > 2) Who owns the infrastructure where that remote, shared resource lives? > 2a) Do you know who has write access to it? > 2b) What policies are in place for auditing access & modification? > 2c) What happens to your build when the URL changes? > 2d) What disaster recovery & business continuity policies are in place > in case the server hosting the remote resource gives up the ghost? > 3) Are changes make in a backwards compatible fashion? > > This is just off the top of my head. > > Now, for some projects none of this is a concern. For other projects these > are inviolable constraints that are necessarily at the forefront of > everything we do. > > Are there ways to mitigate these concerns with using a remote resource in > a build? Absolutely: you can clamp down on write access, use versioning, > have SLAs and backups, etc. The take-away message is that there's a lot > more complexity involved to properly support a remote resource than just > chunking it up on a some random web server. > > ____________________________________________________________________________________________ > Jeffrey E. (Jeff) Care > *ca...@us.ibm.com* <ca...@us.ibm.com> > IBM WebSphere Application Server > WAS Release Engineering > > [image: WebSphere Mosiac] > [image: WebSphere Brandmark] > > > > Mansour Al Akeel <mansour.alak...@gmail.com> wrote on 03/08/2012 05:42:56 > PM: > > > From: Mansour Al Akeel <mansour.alak...@gmail.com> > > To: Ant Developers List <dev@ant.apache.org> > > Date: 03/08/2012 05:43 PM > > Subject: Re: import remote file > > > > Jeffery, > > thank you. I will try it soon. > > Can you please let me know what makes you think it's terrible idea ? > > > > > > On Thu, Mar 8, 2012 at 3:01 PM, Jeffrey E Care <ca...@us.ibm.com> wrote: > > > Mansour Al Akeel <mansour.alak...@gmail.com> wrote on 03/08/2012 > 02:53:55 > > > PM: > > > > > >> I am looking for a functionality to allow me to import remote files > > >> that contains tasks to be used in multiple projects. Something like: > > >> > > >> <import file="http://path/to/reusable/file.xml > " /> > > > >> > > >> I know I can include this in an antlib inside a jar, ant download it > > >> through ivy, but importing a remote file, seems to be easier way to > > >> share this macros with other > > >> projects. > > >> > > >> I didn't find this functionality, and looking to open a jira ticket. > > >> Just making sure it doesn't exist. > > > > > > You should be able to do this today using a nested url resource. > > > > > > Of course I'm on record as thinking this is a TERRIBLE idea, so use at > > > your own risk. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > >
