Re: Don't prepend the parent id to the subproject id

[Rhett Sutphin]

On Aug 25, 2009, at 11:44 PM, Assaf Arkin wrote:

On Tue, Aug 25, 2009 at 7:48 PM, Rhett Sutphin <rh...@detailedbalance.net >wrote:

Hi,


On Aug 25, 2009, at 3:05 PM, Assaf Arkin wrote:

On Tue, Aug 25, 2009 at 12:01 PM, Rhett Sutphin

<rh...@detailedbalance.net>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 <

rh...@detailedbalance.net>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

https://issues.apache.org/jira/browse/BUILDR-304

Patch coming shortly.

Rhett

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 <
rh...@detailedbalance.net

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 <
rh...@detailedbalance.net

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 <
rh...@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