[
https://issues.apache.org/jira/browse/BUILDR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586212#action_12586212
]
Assaf Arkin commented on BUILDR-59:
-----------------------------------
There are two problems with the solution we have right now:
1. If the package comes from a different resource, as described above.
2. If the package comes from the same buildfile, but used in multiple places
(e.g. EAR and WAR), one of the manifests will be wrong.
I'm thinking what it really needs is a way to clone the original package, and
create a clone that is only used for the EAR task (i.e. doesn't show up when
calling project.packages, never gets installed, lives somewhere in target
directory).
If it's coming from the local repository, the clone would just create a ZIP
that copies all files/directories from another ZIP, and transforms the
manifest. If it's coming from the same buildfile, we can optimize by cloning
the original packaging task.
> EarTask: component type cannot be specified for Artifact
> --------------------------------------------------------
>
> Key: BUILDR-59
> URL: https://issues.apache.org/jira/browse/BUILDR-59
> Project: Buildr
> Issue Type: Bug
> Components: Packaging
> Affects Versions: 1.3
> Environment: Windows XP SP2, JRuby 1.1, buildr trunk (rev 645177)
> Reporter: Tomas Carlsson
> Assignee: Victor Hugo Borja
> Priority: Minor
>
> Trying to specify component type for Artifact when packaging ear:s fails with:
> undefined method `manifest' for #<Buildr::Artifact:0x1202d8a>
> Example buildfile:
> repositories.remote << "http://repo1.maven.org/maven2";
> define 'myproj' do
> project.version=1
> project.group = "foo"
> define 'this_works' do
> package(:ear).add "log4j:log4j:jar:1.2.14"
> end
> define 'does_not_work' do
> package(:ear).add :ejb => "log4j:log4j:jar:1.2.14"
> end
> end
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
