I created a tracker for this issue at https://issues.apache.org/jira/browse/BUILDR-330
alex On Mon, Oct 19, 2009 at 5:41 PM, Greg Lucas <[email protected]> wrote: > Thanks! I'm working around the issue for now by just doing e.g. 'buildr > uninstall install', but I'll poke around for another solution that doesn't > require the caller to be aware of this behavior. > > By the way, the approach I'm using came from here: > > http://buildr.apache.org/artifacts.html#install_upload > > It may be worth adding a note about this to that example as it was not > intuitive (to me, at least). > > Thanks, > > ~Greg > > > > > > On Mon, 19 Oct 2009 17:39:37 -0400, Alex Boisvert <[email protected]> > wrote: > > I think that's a bug in the install task. It should re-install even if >> the >> target already exists (same as upload) to follow existing Maven >> conventions. >> >> alex >> >> >> On Mon, Oct 19, 2009 at 11:29 AM, Greg Lucas <[email protected]> >> wrote: >> >> I've got a build that needs to install/upload an XML file as an artifact. >>> I'm doing the following in my Rakefile: >>> >>> # produce the XML file >>> filter('src/...').into('target/...').using(...) >>> >>> # define an artifact and hook in to install/upload >>> xml_artifact = artifact(...).from('target/...') >>> install xml_artifact >>> upload xml_artifact >>> >>> >>> This works fine the first time, but any subsequent time a run the build >>> the >>> artifact is never updated in my local m2 repo. It looks like install only >>> works if the artifact is not already there. That's not consistent with >>> the >>> behavior using package. >>> >>> I suppose I could define a new packaging type for this but that seems >>> like >>> overkill. Is this the intended behavior of install? Is there a better way >>> to >>> deal with artifacts that are not in fact packaged archives? >>> >>> I'm using buildr 1.2.10 (as currently dictated by the Apache ODE 1.x >>> branch). >>> >>> -- >>> Greg Lucas >>> >>> > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >
