Re: installing non-archive artifacts

[Greg Lucas <gr...@gmail.com>]

Just in case anyone else is looking to do the same (produce an XML  
artifact as build output):

I ended up defining a new package type for this after all. The  
artifact.from approach works (thanks for the fix!) but behaves a bit  
differently than I'd like - for example the file gets generated when you  
do 'buildr artifacts'.

So now I'm doing it this way:

def package_as_file(file_name)
   file file_name  => [...] do
     ... #generate the file
   end
end
def package_as_file_spec(spec)
   spec.merge({ :type=>:xml })
end

package(:file)

In my case generating the file means copying a template file and replacing  
various tokens. I wonder if there should be a built-in package type for  
files to simplify this a bit, so you could specify a src file and define a  
block to produce the target file?

~Greg


On Tue, 20 Oct 2009 02:44:43 -0400, Alex Boisvert  
<al...@gmail.com> wrote:

> 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 <gr...@gmail.com> 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  
>> <al...@gmail.com>
>> 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 <gr...@gmail.com>
>>> 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

Re: installing non-archive artifacts

[Greg Lucas <gr...@gmail.com>]

> Yes, I think a built-in support is warranted. Do you want to provide a  
> patch? Otherwise, I can take care of it.

I'm new to ruby so it'll require some trial and error, but I'll take a  
stab at it.

Thanks,

-- 
Greg Lucas

Re: installing non-archive artifacts

[Alex Boisvert <al...@gmail.com>]

On Thu, Nov 19, 2009 at 8:34 AM, Greg Lucas <gr...@gmail.com> wrote:

> Just in case anyone else is looking to do the same (produce an XML artifact
> as build output):
>
> I ended up defining a new package type for this after all. The
> artifact.from approach works (thanks for the fix!) but behaves a bit
> differently than I'd like - for example the file gets generated when you do
> 'buildr artifacts'.
>
> So now I'm doing it this way:
>
> def package_as_file(file_name)
>  file file_name  => [...] do
>    ... #generate the file
>  end
> end
> def package_as_file_spec(spec)
>  spec.merge({ :type=>:xml })
> end
>
> package(:file)
>
> In my case generating the file means copying a template file and replacing
> various tokens. I wonder if there should be a built-in package type for
> files to simplify this a bit, so you could specify a src file and define a
> block to produce the target file?
>

Yes, I think a built-in support is warranted.   Do you want to provide a
patch?  Otherwise, I can take care of it.

alex