buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <as...@labnotes.org>
Subject Re: Don't prepend the parent id to the subproject id
Date Tue, 25 Aug 2009 17:47:48 GMT
On Tue, Aug 25, 2009 at 8:18 AM, Rhett Sutphin <rhett@detailedbalance.net>wrote:

> Hi Antoine,
>
> On Aug 25, 2009, at 9:57 AM, Antoine Toulme wrote:
>
>  Rhett, thanks for putting together this code.
>> One quick note: if I do:
>>
>> project('subp').package(:jar).manifest
>>
>> I will see all the options set before on the manifest.
>>
>> I believe that's how it should be done.
>>
>
> That is interesting to know.  My experience had been with wars and their
> includes/excludes, which didn't seem to be preserved when you subsequently
> called package(:war).  My guess is, then, that the fact that buildr doesn't
> preserve the options (:file, :id, etc.) on subsequent package(:jar) calls is
> a bug.  Would any of the buildr developers care to chime in about the
> intended behavior?


If you had:
package(:jar, :id=>'api').include( .... )
pacakge(:jar, :id=>'impl').exclude( ... )

what should pacakge(:jar) return?

Assaf


>
>
> Rhett
>
>
>  In my case, I'm already working on an extension, and it is best for me to
>> depend on a manifest field in the end (Bundle-SymbolicName), rather than
>> on
>> the project id.
>>
>> Thanks for your patience.
>>
>> Antoine
>>
>> On Tue, Aug 25, 2009 at 16:07, Rhett Sutphin <rhett@detailedbalance.net
>> >wrote:
>>
>>  Hi Antoine,
>>>
>>> On Aug 25, 2009, at 3:19 AM, Antoine Toulme wrote:
>>>
>>> Thanks Rhett.
>>>
>>>> It works for individual projects.
>>>>
>>>> But if in the final bundling project, I call
>>>> project('subp').package(:jar).to_s, it uses the default path.
>>>>
>>>>
>>> I think that when you invoke project.package(:jar) you are actually
>>> defining another package task.  That works fine as a shortcut to get the
>>> name in the default mode, but not (as you've seen) if you're trying to
>>> get
>>> at some configuration element of the package as defined in the project.
>>> (This is not only a problem for the artifact name, but also if you are
>>> trying to extract includes/excludes, etc.)
>>>
>>> Here is an alternative:
>>>
>>> project('subp').packages.first
>>>
>>> Or, if you have multiple packages in a project and don't want to assume
>>> the
>>> order:
>>>
>>> project('subp').packages.detect { |p| p.to_s =~ /jar$/ }
>>>
>>> Here's a sample buildfile that proves this works:
>>>
>>> define "top" do
>>> project.version = '0.0.0'
>>>
>>> define "A" do
>>>  package(:jar, :file => _("target/a.jar"))
>>> end
>>>
>>> puts "  From package(:jar): #{project("A").package(:jar).to_s}"
>>> puts " From packages.first: #{project("A").packages.first.to_s}"
>>> puts "With packages.detect: #{project("A").packages.detect { |p| p.to_s
>>> =~
>>> /jar$/ }.to_s}"
>>> end
>>>
>>> Output:
>>>
>>> $ buildr
>>> (in /private/tmp, development)
>>> From package(:jar): /private/tmp/A/target/top-A-0.0.0.jar
>>> From packages.first: /private/tmp/A/target/a.jar
>>> With packages.detect: /private/tmp/A/target/a.jar
>>> Building top
>>> Completed in 1.136s
>>>
>>>
>>> So I guess I'm back to my original question. I need to override the id of
>>>
>>>> the project to avoid the parent prepending its id.
>>>> I'll look into the code.
>>>>
>>>>
>>> If you don't like any of those workarounds, I do think you could write a
>>> small extension to do what you want more declaratively.
>>>
>>> Rhett
>>>
>>>
>>>
>>>  Thanks,
>>>>
>>>> Antoine
>>>>
>>>> On Tue, Aug 25, 2009 at 04:15, Rhett Sutphin <rhett@detailedbalance.net
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> Hi Antoine,
>>>>
>>>>>
>>>>> Checking my buildfile, the name of the parameter is actually "file" not
>>>>> "name".  That's what I get for trying to answer from memory.
>>>>>
>>>>> Rhett
>>>>>
>>>>>
>>>>> On Aug 24, 2009, at 6:58 PM, Antoine Toulme wrote:
>>>>>
>>>>> Looks like it doesn't work for jars:
>>>>>
>>>>>
>>>>>> package(:jar, :name =>
>>>>>> "org.eclipse.stp.bpmn.validation_#{project.version}.jar")
>>>>>>
>>>>>> no such option: name
>>>>>> /Users/antoine/w/stp/org.eclipse.stp.bpmn/trunk/buildfile:33
>>>>>>
>>>>>>
>>>>>>
>>>>>> /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:405:in
>>>>>> `raw_load_buildfile'
>>>>>>
>>>>>>
>>>>>>
>>>>>> /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:218:in
>>>>>> `load_buildfile'
>>>>>>
>>>>>>
>>>>>>
>>>>>> /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:213:in
>>>>>> `load_buildfile'
>>>>>>
>>>>>> On Tue, Aug 25, 2009 at 00:38, Rhett Sutphin <
>>>>>> rhett@detailedbalance.net
>>>>>>
>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>> Hi Antoine,
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Aug 24, 2009, at 5:18 PM, Antoine Toulme wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> for plenty of good reasons, I use a parent project to organize
my
>>>>>>>
>>>>>>>> projects.
>>>>>>>>
>>>>>>>> However I am in dire need to not have the parent project
id be
>>>>>>>> prepended
>>>>>>>> to
>>>>>>>> the project id, and to the project produced artifacts, as
they must
>>>>>>>> match
>>>>>>>> the Eclipse standard for Eclipse plugins.
>>>>>>>>
>>>>>>>> Here is my buildfile:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.bpmn-modeler/org.eclipse.stp.bpmn/trunk/buildfile
>>>>>>>>
>>>>>>>> Is there a trick for this ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Do you mean that you want the jar names not to include the
prefix?
>>>>>>>>
>>>>>>> For
>>>>>>> wars I've done
>>>>>>>
>>>>>>> package(:war, :name => "another-name.war")
>>>>>>>
>>>>>>> I presume the same thing works for jars, too.
>>>>>>>
>>>>>>> If you're looking to modify the task names, I don't know if that's
>>>>>>> possible.
>>>>>>>
>>>>>>> Rhett
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message