Return-Path: Delivered-To: apmail-buildr-users-archive@www.apache.org Received: (qmail 22814 invoked from network); 25 Aug 2009 17:48:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Aug 2009 17:48:14 -0000 Received: (qmail 15129 invoked by uid 500); 25 Aug 2009 17:48:39 -0000 Delivered-To: apmail-buildr-users-archive@buildr.apache.org Received: (qmail 15098 invoked by uid 500); 25 Aug 2009 17:48:39 -0000 Mailing-List: contact users-help@buildr.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@buildr.apache.org Delivered-To: mailing list users@buildr.apache.org Received: (qmail 15088 invoked by uid 99); 25 Aug 2009 17:48:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Aug 2009 17:48:39 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of assaf@labnotes.org does not designate 209.85.132.246 as permitted sender) Received: from [209.85.132.246] (HELO an-out-0708.google.com) (209.85.132.246) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Aug 2009 17:48:29 +0000 Received: by an-out-0708.google.com with SMTP id c3so1047428ana.17 for ; Tue, 25 Aug 2009 10:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.129.9 with SMTP id g9mr6353918ann.115.1251222488267; Tue, 25 Aug 2009 10:48:08 -0700 (PDT) In-Reply-To: <1F0367DD-A075-49D6-A027-530DECBDFAEA@detailedbalance.net> References: <80A31EB9-A1D9-4B99-AF0E-7DF7BF006E55@detailedbalance.net> <72C99AD6-A0AB-488D-9865-4AC3CD9C673E@detailedbalance.net> <0BE76515-D392-4039-95E7-00125FF99E77@detailedbalance.net> <1F0367DD-A075-49D6-A027-530DECBDFAEA@detailedbalance.net> From: Assaf Arkin Date: Tue, 25 Aug 2009 10:47:48 -0700 Message-ID: <5037b6e40908251047m6630acd8ucfc1d4bf63489172@mail.gmail.com> Subject: Re: Don't prepend the parent id to the subproject id To: users@buildr.apache.org Content-Type: multipart/alternative; boundary=0016368e2b7cf2bd880471faefe8 X-Virus-Checked: Checked by ClamAV on apache.org --0016368e2b7cf2bd880471faefe8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Aug 25, 2009 at 8:18 AM, Rhett Sutphin 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? 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 > >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 >>> >>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> > --0016368e2b7cf2bd880471faefe8--