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?
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
