[
https://issues.apache.org/jira/browse/BUILDR-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567160#action_12567160
]
Assaf Arkin commented on BUILDR-44:
-----------------------------------
Teach a person how to select {} and they'll be able to use it on dependencies,
packages, projects, directories, repositories, test cases and what not. Create
a selector API and you're doomed to reinvent them all over the place each time
someone has a non-trivial issue.
The risk here is that once we add all these edge-case conveniences we end up
with documentation the size of the J2EE spec that no one can master, and
there's really no point for using Ruby. But if we teach people basic skills --
and we have a place to do that in the documentation -- they can handle all edge
cases and one-off themselves and not depend on us releasing these features.
Separately:
package(:zip, :classifier => 'addons', :type => :jar) # using package(:jar)
again would add compiled classes, resources, We don't want that
Why don't we change this so Buildr does the right thing:
a) Add clean method to ArchiveTask, so you can do package(:jar,
:classifier=>'addons').clean.include(whatever) (This was asked for before)
b) Identify patterns of usage. For example, if classifier is hardly ever used
for the main JAR, why not change package_as_jar so it doesn't include anything
by default when specifying a classifier?
package(:ear).add :war => project('foo').package(:classifier => 'addons')
This should work since the default packaging is :jar and nothing gets included
on the second reference.
> Project#packages selector improvement
> -------------------------------------
>
> Key: BUILDR-44
> URL: https://issues.apache.org/jira/browse/BUILDR-44
> Project: Buildr
> Issue Type: Improvement
> Components: Packaging
> Affects Versions: 1.3
> Reporter: Victor Hugo Borja
> Priority: Minor
> Fix For: 1.3
>
> Attachments:
> 0001-Project-packages-can-now-take-a-selectors-argument.patch
>
>
> Currently, the Project#packages method returns all the packages defined for a
> project. However it would be useful to provide a way to easily narrow
> returned packages without having the user(mainly ruby newcomers) to use the
> select ruby idiom
> project.packages.select { |p| p.type == :war }
> It would be nicer to have something like:
>
> project.packages(:type => :war) # actually comparing :war with the type
> attribute of each package
> project.packages(JarTask) # select all Jar kind packages
> For more advanced stuff, users may still need to provide a Proc/Method or
> select the full packages array the ruby way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
