[
https://issues.apache.org/jira/browse/BUILDR-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15727083#comment-15727083
]
Peter Donald commented on BUILDR-274:
-------------------------------------
I am not sure that the size of the buildr download should really be something
that limits our adoption of LockJar. It offers a bunch of great features that
would really benefit Buildr. Even if we did not adopt LockJar wholly I think
buildr itself should ditch all artifact resolution code and just rely in aether
or via your naether (https://github.com/mguymon/naether). This would get a lot
of advantages - version ranges, real processing of poms, correct traversal of
dependencies etc.
I have in the past had some thought experiments with how we could use LockJar.
One way I did come up with was that each buildr project ends up with 3 separate
groups within LockJar (development, test and provided) all with some sort of
naming convention. (i.e. the buildr project 'myproject:server' may end up with
groups 'myproject:server::development', 'myproject:server::test' and
'myproject:server::provided') and all the buildr tasks would start using the
dependencies out of LockJar moving forward.
Of course the question arises how we could populate the LockJar configuration
and I thought there is probably a few scenarios:
1) A build process neither wants nor cares about LockJar, uses existing syntax
to add dependencies to an in memory `Jarfile`, no `Jarfile.lock` is
read/written to the filesystem.
2) A build process want to generate lock file but uses existing syntax to add
dependencies to an in memory `Jarfile`, `Jarfile.lock` is read as part of build
and a task is available to perform the lock.
3) A build process want to use filesystem based `Jarfile`, `Jarfile.lock` is
read as part of build and a task is available to perform the lock. If `Jarfile`
is present then a lock will be written if no lock is present.
I think an approach similar to this has significant advantage. We get all
advantages of a real dependency manager, can continue to use the existing
buildr dependency syntax if wanted.
However I suspect that this is a lot of work to implement which is why I never
got around to prototyping it. It may be easier to start experimenting with
integrating naether first to do all resolution. After that beds down it may be
more feasible to look at how we could integrate LockJar.
> Support dependency version ranges for transitive dependencies
> -------------------------------------------------------------
>
> Key: BUILDR-274
> URL: https://issues.apache.org/jira/browse/BUILDR-274
> Project: Buildr
> Issue Type: New Feature
> Components: Dependency management
> Reporter: Martin Grotzke
> Fix For: Wish List
>
>
> It seems that right now dependency version ranges as shown here [1] are not
> supported.
> A version range is e.g. used by ehcache-web ([2]), so that when I use
> transitive('net.sf.ehcache:ehcache-web:jar:1.6.0-beta2')
> buildr fails with this error:
> Failed to download net.sf.ehcache:ehcache:pom:[1.6.0-beta4,], tried the
> following repositories...
> It would be great to have support for version ranges, otherwise some libs
> cannot be used with transitive().
> [1]
> http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-version-ranges.html
> [2]
> http://repo1.maven.org/maven2/net/sf/ehcache/ehcache-web/1.6.0-beta2/ehcache-web-1.6.0-beta2.pom
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
