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.
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:
"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
