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 16:28:26 GMT

On Aug 25, 2009, at 11:44 PM, Assaf Arkin wrote:

> On Tue, Aug 25, 2009 at 7:48 PM, Rhett Sutphin <rhett@detailedbalance.net 
> >wrote:
>
>> 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.
>
>
> or define it as package(:jar, :id=>project.name)
>
>>
>>
>> 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:
>
>
> +1

https://issues.apache.org/jira/browse/BUILDR-304

Patch coming shortly.

Rhett

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