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 Wed, 26 Aug 2009 02:48:38 GMT
Hi,

On Aug 25, 2009, at 3:05 PM, Assaf Arkin wrote:

> On Tue, Aug 25, 2009 at 12:01 PM, Rhett Sutphin
> <rhett@detailedbalance.net>wrote:
>
>> 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."
>
>
> The common case is to have one package per project, where the  
> variant is the
> package type (mostly jar, sometimes war, zip for sources), etc.  I  
> like
> being able to do project.package(:jar) and get the JAR I previously  
> defined,
> while ignoring the doc/sources ZIP packages created for that same  
> project.
>
> But with great flexibility comes the responsibility knowing how to  
> use it:
>
> A single project can create multiple packages. For example, a Java  
> project
>> may generate a JARpackage for the runtime library and another JAR  
>> containing
>> just the API; a ZIP file for the source code and another ZIP for the
>> documentation. Make sure to always call package with enough  
>> information to
>> identify the specific package you are referencing. Even if the  
>> project only
>> defines a single package, calling the package method with no  
>> arguments
>> does not necessarily refer to that one.
>
>
> http://buildr.apache.org/packaging.html#referencing

Meaning no offense, "make sure to always call package with enough  
information to identify the specific package you are referencing" is  
pretty vague.  If you have

define 'foo' do
   package(:jar, :file => 'custom.jar')
end

it seems like project('foo').package(:jar) is enough information to  
identify the package -- after all, there aren't any other jars  
defined.  Looking at the source of the package method, it seems like  
"enough information" means "enough information for buildr to  
reconstruct the filename".  It seems, then, that the current  
implementation works great unless you use the :file option.

What if we make it so that package(type) returns the first defined  
package of that type (if there is one), so long as no other options  
are specified?  That would be less surprising way for it to behave and  
would fit the common case better than matching on filename.

I believe the only backwards-incompatibility this change would  
introduce would be in this case:

define 'bar' do
   package(:jar, :id => 'api')
   package(:jar)
   package(:jar, :id => 'impl')
end

With the proposed change, the second package wouldn't be defined --  
I'm not sure if this is a common case or not.  The fix would be to  
define the no-id jar first.

If that's an acceptable change, I'd be happy to supply a patch to  
implement it.  If it's not, then may I suggest the documentation be  
updated?  Perhaps like so:

"Make sure to always call package with the same options you used when  
originally defining the package you are referencing.  If this is  
impractical, consider using the packages method as outlined below."

Thanks for the pointer,
Rhett

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