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 19:01:05 GMT
Hi again,

On Aug 25, 2009, at 1:51 PM, Rhett Sutphin wrote:

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

I found the documentation I was talking about.  It's in the rdoc for  
the packages method:

"If you want to return a specific package, it is often more convenient  
to call package with the type."

Thanks,
Rhett

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