Notes from Call

[Josh Suereth]

• Introduction to build process (Josh)
• Primary Concerns
• Don't publish Scala version until verified with community projects builds
• Able to be distributed/parallelized
• Basic Flow
• Per Project
• Resolve build configuration + Scala libraries/project dependencies from staging repo
• execute build
• publish to staging repo
• Fire off next build
• Global
• Run scala-fresh build
• intiialize scala-fresh staging repo for distributed build.   Deploy configuration information for this currently executing build for projects to resolve.
• Fire project builds
• On total success -> publish scala artifacts (but not projects unless opt-in)
• On failure -> dump staging repo, or give particular projects a chance to fix bugs/analyze results and continue staging.
• Leveraging Nexus -> Could be a huge benefit or great downfall.
• Concerns for Scala IDE (Miles)
• Don't want a "non-IDE owner" to determine when/how to publish artifacts.
• Need a way to "push" notifications for scala IDE to do its own build/release *or* a "pull" mechanism.
• Maven infrastructure setup (Indrajit)
• We can create a parent project that automatically configures maven build for scala fresh.   Projects can opt-int
• Define set of conventions for other projects
• Simple Build Tool
• Need to override boot configuration to resolve scala versions appropriately
• Provide a plugin that projects can opt-in for easier Scala-fresh integration (Indrajit)
• scalatest
• Need to work on resolving dependencies instead of checking them out of source control
• Be tactful!  Try lightweight ant-based approach.   If this fails, create external script that resolves/replaces jars in the lib folder.
• Concerns over using Hudson for dependency mapping (Josh)
• Used for a few months/at work and it works great (Indrajit/Kevin)
• Action Items
• Nexus Configuration (Josh)
• Maven Integration (Indrajit)
• scalatest Build Adjustments (Kevin)
• Simple Build Tool (Josh/Indrajit)
• Permissions (Derek/Josh)
• Push/Pull build completion notifications (Miles/Josh)

Let me know if I missed anything.  Thanks for the time guys!

- Josh

[Josh Suereth]

I think I also missed the concern over what groupId scala-fresh will live in.  I'm going to contact Mark Harrah about what in SBT would have to be tweaked for this (I hope it's not what my initial investigation suggests).

- Josh

[Kevin Wright]

I have the scalaprojects.org and scalaprojects.com domains, if they're any use; though I do have other (related) plans for these.

My gut feeling though?

We should probably just register scala-fresh in its own right, maybe even point it back to the same server as scala-tools and use a spot of virtual hosting.

--
You received this message because you are subscribed to the Google Groups "Scala Fresh" group.
To post to this group, send email to scala...@googlegroups.com.
To unsubscribe from this group, send email to scala-fresh...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scala-fresh?hl=en.

--
Kevin Wright

mail/google talk: kev.lee...@gmail.com
wave: kev.lee...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

[Josh Suereth]

scala fresh does have it's own domain.   I need to ensure the build tools can support scala-library/scala-compiler in a different domain.   Most of them are hard-coded to org.scala-lang.* artifacts.

[Maxime Lévesque]

i)  How will the source code of various project be fetched ?

ii) Does anyone see any value in having staging source repositories ?

What I mean by this is that each tool could have a GIT fork (on github for example)
that get updated at each important realease. These forks could have an altered
version of their build code (SBT, Maven, etc...) that is configured and or altered to meet the needs of
ScalaFresh. There could be a special build hook (in the form of a trait) for
projects having non standard builds.

 The value I would see in doing this is that :

 - each project owner can control which version goes in the Fresh repos. It could also sub
 - projects that have hardcoded build configs can continue to do so, the fork will just
   have overriden value for these configs.
 - ScalaFresh only needs to specify how a build behavior needs to be altered, and project owners
   can do this alteration in the Fork.

 Max

On Wed, Jun 23, 2010 at 1:11 PM, Josh Suereth <joshua....@gmail.com> wrote:

--

[Maxime Lévesque]

 Perhaps the word staging source repository is not the right word,
the idea is to add a level of indirection (an intermediate repo) betweed a
project's origin repo and the one that ScalaFresh will feed from,
this intermediate repo can be a place where a build is altered to
work in a recursive build.

2010/6/24 Maxime Lévesque <maxime....@gmail.com>

[Daniel]

Just reading along, but:

There are a couple of source driven automatic build system which use
foreign sources. For instance: MacPorts & Portage (Gentoo APT). Also
the same problem has to be solved by every Linux distribution to build
their binary packages. The usual approach is that you have a source
release (for these technologies in the form of an archive), and then
you apply a patch on top of that which takes care of the necessary
customizations for the environment you want to build for.

I think that a similar approach based on patches might be better than
a fork of the whole source:
* Any necessary modifications for build/dependency configuration are
really easy with a patch
* You can also easily add an alternate build system (the new file is
in the patch)
* The patch can be independently version controlled! Although using
git as an SCM for your fork is easy, if you are yourself already on
git, if you use something else as SCM, you might not be very happy
about having a complete fork of your sources just for changing one or
two files.

Actually if you guys would agree on a standard way to build
Scala-Fresh components, then either you put the patches in a
Scala-Fresh repository and all of the maintainers are contributors to
that repository (MacPorts & Portage work like this), or even better,
you define how to look up the patch within a source archive of the
component (eg '.scala-fresh/build.patch') which gets applied to the
base of the archive, and then you don't even need to have a separate
repository, as every library can bootstrap itself from the sources.

Just my 2 cents.

Cheers,
Daniel

2010/6/24 Maxime Lévesque <maxime....@gmail.com>:

[Josh Suereth]

2010/6/24 Maxime Lévesque <maxime....@gmail.com>

i)  How will the source code of various project be fetched ?

We plan to fetch them from an "approved location", determined by the project.   We will support git, hg and svn (for now, perhaps more later).

 

ii) Does anyone see any value in having staging source repositories ?

What I mean by this is that each tool could have a GIT fork (on github for example)
that get updated at each important realease. These forks could have an altered
version of their build code (SBT, Maven, etc...) that is configured and or altered to meet the needs of
ScalaFresh. There could be a special build hook (in the form of a trait) for
projects having non standard builds.

 The value I would see in doing this is that :

 - each project owner can control which version goes in the Fresh repos. It could also sub
 - projects that have hardcoded build configs can continue to do so, the fork will just
   have overriden value for these configs.
 - ScalaFresh only needs to specify how a build behavior needs to be altered, and project owners
   can do this alteration in the Fork.

Currently any artifact wishing for "public consumption" will have to deploy on their own time schedule.   The idea here is that we use their builds to validate the "fresh scala" build, but allow them to release on their own schedule (otherwise you tie a whole bunch of projects to the scala-fresh release schedule).

Using nexus we can filter out non-scala artifacts and temporarily stage them for the build process, then discard them afterwards.  I think this will be the initial plan, and we can allow projects to "opt-in" a release schedule with scala-fresh.

I actually like the later suggested idea of using MacPorts like "patch" system where we can host a patch for each project to enter into our build.  The key here is the feedback between scala core developers and library developers.   We want to have scala developers get a chance to see what/how changes are affecting the community during the development life-cycle.   This means the interaction between projects and scala-fresh is expected to be moderate-high ( hopefully only high during breakages).  Projects will be able to configure their scala-fresh build to the extent they need (e.g. changing SCM branch).  

This places us in a somewhat different place than MacPorts, e.g., but we can definitely learn some good practices from them.

- Josh

[David Pollak]

On Thu, Jun 24, 2010 at 6:53 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

I have the scalaprojects.org and scalaprojects.com domains, if they're any use; though I do have other (related) plans for these.

My gut feeling though?

We should probably just register scala-fresh in its own right, maybe even point it back to the same server as scala-tools and use a spot of virtual hosting.

First, it's Fresh Scala, not Scala Fresh. ;-)

I've registered most of the variants of Fresh Scala and Scala Fresh already as part of this project.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Kevin Wright]

I like "Scala Fresh", reminds me of other common phrases with a trailing adverb...

Like "Ice Cold" or "Snow White"