- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: [sbt] Leveraging the Scala tool chain (cross-post)
Sat, 2010-04-24, 04:48
FYI Buckminster (part of the Eclipse build tool-chain) can be used to
'materialize' a dependency as a source checkout. That would solve the
'download the sources if not already downloaded' part. Maven 3 can be
used in a similar way, but so far I only know about the m2eclipse
plugin that has it as a documented feature.
Buckminster was built with the scenario you outlined above in mind
(bugfixing). It's a 'component resolution & materialization
framework', and has a bunch of XML descriptors which are pretty
flexible to describe how the sources are laid out, and how to acquire
them. Apart from that it can act as a meta-build tool, which delegates
the build process to whatever tool is actually setup in the sources,
so it's possible to build projects which use ant, maven, sbt, buildr
etc. all in one chain. IIRC it's something like v3 or v4 of a tool
originating at IBM, which uses it to build it's commercial Java
applications, including different builds for different target hardware
etc.
Maven only uses the information given in the pom and capabilities of
the maven-scm-plugin.
IMHO component materialization is not exactly trivial to solve.
Especially the problem of discovering source locations, checkout and
build, assuming different SCMs and different build tools is not fun.
Maybe one of the available implementations could be used (only for the
materializing part) to achieve the desired effect and avoid doing all
the work again. Otherwise they can at least be used for inspiration.
More information can be found at:
(in order of usefulness)
- Why Buckminster?
http://wiki.eclipse.org/Why_Buckminster_%3F
- A *simple* materialization example with Buckminster
http://stackoverflow.com/questions/2243578/buckminster-rcp-simple-projec...
- Buckminster Quick Tech Overview
http://wiki.eclipse.org/Buckminster_Quick_Tech_Overview
- Buckminster Home (docs are a PDF book)
http://www.eclipse.org/buckminster/
- Materializing a Project with m2eclipse
http://www.sonatype.com/books/m2eclipse-book/reference/eclipse-sect-mate...
HTH
Cheers,
Daniel
On Sat, Apr 24, 2010 at 3:41 AM, Mark Harrah wrote:
> Hi David,
>
> On Friday 23 April 2010 12:29:48 pm David Pollak wrote:
>> Folks,
>>
>> There's a lot of challenge around reproducing complex defects (e.g., Scala
>> defects in Lift or stuff that builds on top of Lift) and verifying fixes is
>> a long cycle and has occasionally led to inter-team friction.
>>
>> Last night, I realized that there's a potential solution... and it's based
>> on everyone (Scala, ScalaCheck, ScalaTest, Specs, Lift, ScalaZ, Akka,
>> Stambecco, etc.) using sbt and sbt implementing two features: artifact
>> aliasing and dependency chaining.
>>
>> Basically, the workflow for someone working on the compiler would look like
>> "change the Scala compiler, go to the thing causing the problem, do an "sbt
>> chain-compile alias=scala_280->scala_280_current_local_build_number" That
>> would cause sbt to determine the scala dependencies for the given project,
>> download the source (if it's not already downloaded) for the dependency,
>> check its dependencies, compile the dependency substituting the current
>> Scala built for the named build (compiler and library). This would happen
>> until all the pieces parts were compiled. Yes, the whole build-chain could
>> take a few hours, but for the hard to replicate defects (e.g., the
>> multi-library trait pickling problem) it gives folks a way to validate
>> against the compound, complex library structure that's starting to appear
>> in Scala-land.
>>
>> The secondary (or perhaps primary benefit) of such a scheme is that it
>> would allow easy set-up of a very complex continuous integration cycle.
>> Basically, as SNAPSHOT artifacts were published, the entirety of what
>> depends on the new artifacts could be recompiled and tested without any
>> pom.xml or whatever munging.
>>
>> It also means that the CI servers that are publishing snapshot artifacts
>> can keep SNAPSHOT current across the whole tool chain rather than, for
>> example, Lift 2.8 SNAPSHOT building against 2.8 Beta1.
>>
>> So, I'm committed to migrating Lift to sbt post Lift 2.0 and Stambecco to
>> sbt ASAP. Akka is already on sbt.
>>
>> What does EPFL think? What does the sbt team think? Can we use the
>> awesomeness of sbt to make all of our lives better and easier?
>
> Since Ismael brought it up a month or two ago, I've been seriously considering
> what building dependencies from sources would look like. I don't have a
> timeline or anything, but it is something I am working on.
>
> Note that Ivy has something similar with its Packager resolver[1].
>
> -Mark
>
> [1] http://ant.apache.org/ivy/history/2.1.0/resolver/packager.html
>
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To post to this group, send email to simple-build-tool@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-tool+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>
>
Sat, 2010-04-24, 11:47
#2
Re: Re: [sbt] Leveraging the Scala tool chain (cross-post)
I will also say this:
Buckminster is a very very neat interesting piece of technology. However, it seems to be designed with the rather complex goals in mind, and does not make the simple projects easy to set up. As such, the overhead to entrance was quite high. I did very much like the technology, however as Miles states, I think it needs a little bit more time to stabilize or more help in simplifying easy tasks. I haven't looked in-depth at it since I moved off the Eclipse RCP project I was working on.
- Josh
On Sat, Apr 24, 2010 at 5:38 AM, Miles Sabin <miles@milessabin.com> wrote:
Buckminster is a very very neat interesting piece of technology. However, it seems to be designed with the rather complex goals in mind, and does not make the simple projects easy to set up. As such, the overhead to entrance was quite high. I did very much like the technology, however as Miles states, I think it needs a little bit more time to stabilize or more help in simplifying easy tasks. I haven't looked in-depth at it since I moved off the Eclipse RCP project I was working on.
- Josh
On Sat, Apr 24, 2010 at 5:38 AM, Miles Sabin <miles@milessabin.com> wrote:
On Sat, Apr 24, 2010 at 4:47 AM, Daniel <dan.in.a.bottle@gmail.com> wrote:
> FYI Buckminster (part of the Eclipse build tool-chain) can be used to
> 'materialize' a dependency as a source checkout. That would solve the
> 'download the sources if not already downloaded' part. Maven 3 can be
> used in a similar way, but so far I only know about the m2eclipse
> plugin that has it as a documented feature.
Eclipse-specific build tools seem to be in a bit of a state of flux at
the moments. B3, buckminster and Tycho/Maven 3.0 all seem to have a
fair amount of momentum. I've decided to go with Tycho/Maven 3.0 for
the Scala IDE's new build infrastructure.
For the core Scala toolchain I think that buckminster is too Eclipse
specific ... I'd suggest either something completely generic (ie.
Maven) or something very idiomatic for Scala (ie. sbt).
Given the above, you can expect Scala+Maven support in Eclipse to get
*much* better very soon.
Cheers,
Miles
--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
Sat, 2010-04-24, 13:47
#3
Re: Re: [sbt] Leveraging the Scala tool chain (cross-post)
On Sat, Apr 24, 2010 at 3:45 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I will also say this:
Buckminster is a very very neat interesting piece of technology. However, it seems to be designed with the rather complex goals in mind, and does not make the simple projects easy to set up. As such, the overhead to entrance was quite high. I did very much like the technology, however as Miles states, I think it needs a little bit more time to stabilize or more help in simplifying easy tasks. I haven't looked in-depth at it since I moved off the Eclipse RCP project I was working on.
Personally, I was thinking of something less ambitious. I was expecting that all the source would already be checked out of the target machine and that there would be some local (not checked into scm) reference to the source... and perhaps by default sbt would look in .. (the directory up from the current project directory) for named projects (e.g., ../liftweb, ../specs, ../scalacheck)
- Josh
On Sat, Apr 24, 2010 at 5:38 AM, Miles Sabin <miles@milessabin.com> wrote:
On Sat, Apr 24, 2010 at 4:47 AM, Daniel <dan.in.a.bottle@gmail.com> wrote:
> FYI Buckminster (part of the Eclipse build tool-chain) can be used to
> 'materialize' a dependency as a source checkout. That would solve the
> 'download the sources if not already downloaded' part. Maven 3 can be
> used in a similar way, but so far I only know about the m2eclipse
> plugin that has it as a documented feature.
Eclipse-specific build tools seem to be in a bit of a state of flux at
the moments. B3, buckminster and Tycho/Maven 3.0 all seem to have a
fair amount of momentum. I've decided to go with Tycho/Maven 3.0 for
the Scala IDE's new build infrastructure.
For the core Scala toolchain I think that buckminster is too Eclipse
specific ... I'd suggest either something completely generic (ie.
Maven) or something very idiomatic for Scala (ie. sbt).
Given the above, you can expect Scala+Maven support in Eclipse to get
*much* better very soon.
Cheers,
Miles
--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Sat, 2010-04-24, 14:37
#4
Re: Re: [sbt] Leveraging the Scala tool chain (cross-post)
On Saturday 24 April 2010 13:38:10 Miles Sabin wrote:
> For the core Scala toolchain I think that buckminster is too Eclipse
> specific ... I'd suggest either something completely generic (ie.
> Maven) or something very idiomatic for Scala (ie. sbt).
+1
And, Miles, it is very pleasure to see such point of view especially from you
- taking in account your efforts (and special interest) on Eclipse way :-)
Thanks!
Sat, 2010-04-24, 16:37
#5
Re: Re: [sbt] Leveraging the Scala tool chain (cross-post)
Inline
On Sat, Apr 24, 2010 at 5:45 PM, Josh Suereth wrote:
> I will also say this:
>
> Buckminster is a very very neat interesting piece of technology. However,
> it seems to be designed with the rather complex goals in mind, and does not
> make the simple projects easy to set up. As such, the overhead to entrance
> was quite high. I did very much like the technology, however as Miles
> states, I think it needs a little bit more time to stabilize or more help in
> simplifying easy tasks. I haven't looked in-depth at it since I moved off
> the Eclipse RCP project I was working on.
I second that sentiment. I have the same feeling about Buckminster and
it always bugged me that the setup is quite complex. From a quick peek
at the B3 docs it seems like it's going to supersede Buckminster (same
core developers). I hope that it gets easier in the process.
But as David stated in another message, he was looking for a simpler
solution where the checkout is manual and only the build has to be
coordinated in some fashion. In light of that, B3 and Buckminster are
not interesting.
Cheers,
Daniel
PS: I would still love to be able to materialize dependencies, and it
could probably be accomplished by replacing Ivy with B3 as the
resolution mechanism. It would very likely also take care of
multiversion resolution problems as the artifact resolver is p2 (the
eclipse provisioning platform) and uses SAT4J (satisfiability library
- recently adopted by Maven 3/Mercury to accomplish the same task).
Just thinking out loud.
>
> On Sat, Apr 24, 2010 at 5:38 AM, Miles Sabin wrote:
>>
>> On Sat, Apr 24, 2010 at 4:47 AM, Daniel wrote:
>> > FYI Buckminster (part of the Eclipse build tool-chain) can be used to
>> > 'materialize' a dependency as a source checkout. That would solve the
>> > 'download the sources if not already downloaded' part. Maven 3 can be
>> > used in a similar way, but so far I only know about the m2eclipse
>> > plugin that has it as a documented feature.
>>
>> Eclipse-specific build tools seem to be in a bit of a state of flux at
>> the moments. B3, buckminster and Tycho/Maven 3.0 all seem to have a
>> fair amount of momentum. I've decided to go with Tycho/Maven 3.0 for
>> the Scala IDE's new build infrastructure.
>>
>> For the core Scala toolchain I think that buckminster is too Eclipse
>> specific ... I'd suggest either something completely generic (ie.
>> Maven) or something very idiomatic for Scala (ie. sbt).
>>
>> Given the above, you can expect Scala+Maven support in Eclipse to get
>> *much* better very soon.
>>
>> Cheers,
>>
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel: +44 (0)7813 944 528
>> skype: milessabin
>> http://www.chuusai.com/
>> http://twitter.com/milessabin
>
>
On Sat, Apr 24, 2010 at 4:47 AM, Daniel wrote:
> FYI Buckminster (part of the Eclipse build tool-chain) can be used to
> 'materialize' a dependency as a source checkout. That would solve the
> 'download the sources if not already downloaded' part. Maven 3 can be
> used in a similar way, but so far I only know about the m2eclipse
> plugin that has it as a documented feature.
Eclipse-specific build tools seem to be in a bit of a state of flux at
the moments. B3, buckminster and Tycho/Maven 3.0 all seem to have a
fair amount of momentum. I've decided to go with Tycho/Maven 3.0 for
the Scala IDE's new build infrastructure.
For the core Scala toolchain I think that buckminster is too Eclipse
specific ... I'd suggest either something completely generic (ie.
Maven) or something very idiomatic for Scala (ie. sbt).
Given the above, you can expect Scala+Maven support in Eclipse to get
*much* better very soon.
Cheers,
Miles