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 Wed, 26 Aug 2009 04:44:12 GMT
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

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