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 20:05:00 GMT
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

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message