On Tue, Aug 25, 2009 at 7:48 PM, Rhett Sutphin <[email protected]>wrote:
> Hi, > > > On Aug 25, 2009, at 3:05 PM, Assaf Arkin wrote: > > 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 >> > > 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 < >>>>>>> [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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>> >
