Heya Tammo,
So the goal LockJar is to provide a list of transitive dependencies that
is consistent over time. This is why the dependency information is
stored in the Jarfile.lock. Every dependency for a project should be
resolved to the Jarfile.lock. This prevents conflicts that can appear
from ad hoc resolution of dependencies when their transitive
dependencies overlap.
LockJar already has the concept of group. There is always the default
group, but you can add any additional group you want. All of LockJar's
actions (list,load,etc) can handle group.
The perk of the LockJar integration is it automatically populates the
compile and test task classpaths. That being said, the integration with
LockJar does not have to be used. I am a bit basis, but I like seeing
the dependency information in the buildfile. You can actually skip the
locking and have LockJar resolve every time using something along the
lines of:
dependencies = LockJar.list ( :resolve = true ) do
jar 'org.eclipse.jetty:example-jetty-embedded:jar:8.1.2.v20120308'
end
compile.with project('api'), dependencies
Or if you want to use a single Jarfile for all projects, than you could call
dependencies = LockJar.list(['test'])
...
test.with project('api'), dependencies
So, uh, I should point out I have not updated LockJar's buildr
integration lately, since I have been in the land RoR. Mostly I have not
put much time into it, since there does not appear to be a lot of
interest in it.
thanks,
Michael
On 11/10/2012 06:46 AM, Tammo van Lessen wrote:
Hi Michel,
I did have a look at lock_jar and I really like the idea. Since I like on
one hand Mavens magic resolution for bootstrapping a projects, on the other
hand I also want to have the control over the dependencies. What I usually
do is running something like
pp transitive(LOGBACK).map {|a| a.to_spec}
and copy the result into my buildfile. lockjar could automate this for me,
right?
However, it was difficult to me to grok how a real-world multi-project
buildr file would look like. If I'm not mistaken, I would need to add all
dependencies separately to the projects using the lock_jar dsl? I'd love if
there would be a more unobtrusive way like saying
compile.with project('api'), lock(AXIS2, AXIOM, OPENJPA)
test.with lock(TESTNG)
and lockjar would use this information to create the lockfile
(automatically if not there, otherwise on demand) and return a resolved set
of dependencies. The lock method could also take an optional group
parameter in order to define independent resolution groups. Still open
would be the question how excludes or pinned versions could be expressed.
Do you think such an integration would useful or feasible?
Thanks,
Tammo
On Sat, Nov 10, 2012 at 5:13 AM, Michel Guymon michael.guy...@gmail.comwrote:
Hi,
I figure I would pile onto the Buildr vs Maven discussion, this will be a
little non sequitur.
What I have been doing is using Maven for project info, mostly defining
dependencies and where to deploy to. This is what Maven is actually good
at, project markup. The perk is all the existing tools can continue to work
with the Project's POM. Everything else I do is handled by Buildr. Using
LockJar[1] to import the deps and deployment info from the POM, I am able
to build and deploy my artifacts from Buildr.
I find this is the sweet spot, being able to live in a Maven world but
still able to build my artifacts the way I need to with Buildr. God help me
if I ever have to use and XML build tool again. . .
thanks,
Michael
[1]
https://github.com/mguymon/**lock_jar#buildr-integrationhttps://github.com/mguymon/lock_jar#buildr-integration
https://github.com/mguymon/**lock_jarhttps://github.com/mguymon/lock_jar
On 11/09/2012 10:04 PM, Peter Donald wrote:
Huya,
On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen tvanles...@gmail.com
wrote:
First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
which I held just yesterday.
congrats!
I got a lot of positive feedback, people seem
to like the buildr idea although it also seems that Maven improved since
the inception of Buildr and some things are less worse. The most visible
argument against buildr was, however, that people are used to use Maven
and
that, if they want to make their project accessible for a broad audience,
they think they'd need to stick to Maven.
That does seem to be a common view.
I guess Gradle tries to address
this issue by providing a gradle-wrapper, which is a small jar file
along
a shell script that you can include into your project and that will
bootstrap a gradle installation automatically. I also figured, that still
many Java developers don't have rubies at hand and don't know how to
easily
install a gem.
And one stage, Antoine was working on the all-in-one distribution
that essentially bundled a version of jruby with buildr and all it's
dependencies in one easy installer. I wonder if we could work on this
to ease
