buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rhett Sutphin <rh...@detailedbalance.net>
Subject Re: Don't prepend the parent id to the subproject id
Date Tue, 25 Aug 2009 18:51:57 GMT
Hi Assaf,

On Aug 25, 2009, at 12:47 PM, Assaf Arkin wrote:

> 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?

That makes sense as a reason why package(:jar) would always return a  
new task.  I thought I had seen things like  
project('foo').package(:jar) in the documentation as examples of how  
to access an already-defined package, which is why I wondered about  
the apparent conflict.  Glancing through the docs again, I don't see  
anything like that, so I'm satisfied that this behavior is not a bug.

Also, a closer look at the packaging documentation reminds me about  
the "manifest" attribute of Project.  If Antoine is using that to  
build the manifest, it would explain why multiple jar package tasks  
have the same manifest attributes.

Thanks,
Rhett

> 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
View raw message