On Tue, Aug 25, 2009 at 12:01 PM, Rhett Sutphin <[email protected]>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 < >>> [email protected]>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 < >>>>> [email protected] >>>>> >>>>>> 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 < >>>>>>> [email protected] >>>>>>> >>>>>>> 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 < >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >
