[0.12] plan
Mark Harrah
-Mark
Doug Tangren
Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
-Mark
--
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-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
ijuma
Mark Harrah
On Sun, 15 Jan 2012 16:51:55 -0800 (PST)
ijuma <ism...@juma.me.uk> wrote:
> Hi Mark,
>
> Thanks for sharing. Looks good. Bill Venners mentioned some improvements to
> SBT's testing support[1], are they still planned?
If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
The last time the test interface was enhanced, it was done in a backwards compatible way. I expect the same this time and changes can probably go in without waiting for a .0 release.
-Mark
Doug Tangren
Hey Ismael,
If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
On Sun, 15 Jan 2012 16:51:55 -0800 (PST)
ijuma <ism...@juma.me.uk> wrote:
> Hi Mark,
>
> Thanks for sharing. Looks good. Bill Venners mentioned some improvements to
> SBT's testing support[1], are they still planned?
The last time the test interface was enhanced, it was done in a backwards compatible way. I expect the same this time and changes can probably go in without waiting for a .0 release.
eugene yokota
Mark Harrah
Sometimes there are exceptions, but a full deprecation cycle should be the rule. The old style would need to have been deprecated in 0.11.0 to be removed in 0.12.0.
-Mark
> -eugene
>
Simon Ochsenreither
Would it be possible to make the 0.7 documentation less visible on Google in that timeframe?
E. g. if I search for "sbt dependency" the first three results point to the old code.google site with 0.7.
Especially to new users and people don't working with SBT every day it is hugely annoying and confusing that every SBT serach has some obsolete pages with 0.7 in it.
Could this be fixed?
Thanks!
Simon
Maxime Lévesque
+1
It has happen to me more than once, that while helping a newbie, he was mislead by info from the old site.
Simon
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/7MnX41yhdGkJ.
ijuma
If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
A correction to the jline point: recent Scala versions use their own jline version, so upgrading to jline 1.0 doesn't affect the Scala console for those versions.
-Mark
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Hey Ismael,
>
> On Sun, 15 Jan 2012 16:51:55 -0800 (PST)
> ijuma <ism...@juma.me.uk> wrote:
>
> > Hi Mark,
> >
> > Thanks for sharing. Looks good. Bill Venners mentioned some improvements to
> > SBT's testing support[1], are they still planned?
>
> If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
>
> The last time the test interface was enhanced, it was done in a backwards compatible way. I expect the same this time and changes can probably go in without waiting for a .0 release.
A correction: It is likely that we will need a different interface, which will require a .0 release. I expect this interface is not used in actual builds and is probably rare even in plugins, but it will make sbt binary incompatible and hence the need to include it in a .0 release. We are seeing if this can be done for 0.12.0. I still expect to support the old interface indefinitely as before, so that older test frameworks are supported without changes.
In summary, we are aiming for 0.12.0 and in theory, users won't notice.
-Mark
> > [1] https://groups.google.com/d/msg/scalatest-users/bihrcBtP6eg/01-DTASHNT0J
> >
>
Mark Harrah
On Mon, 16 Jan 2012 06:27:18 -0800 (PST)
Simon Ochsenreither <simon.och...@googlemail.com> wrote:
> Hi,
>
> Would it be possible to make the 0.7 documentation less visible on Google
> in that timeframe?
How do you suggest fixing this?
-Mark
> E. g. if I search for "sbt dependency" the* first three results* point to
ijuma
A correction: It is likely that we will need a different interface, which will require a .0 release. I expect this interface is not used in actual builds and is probably rare even in plugins, but it will make sbt binary incompatible and hence the need to include it in a .0 release. We are seeing if this can be done for 0.12.0. I still expect to support the old interface indefinitely as before, so that older test frameworks are supported without changes.
Simon Ochsenreither
Robots.txt would be a god way to start. If that doesn't help or isn't possible, delete it. Better: Delete the whole Google Code stuff. If there is something important, move it to the current site.
It is doing more harm than good since a long time already. Getting rid of the "x" in "xsbt" would be a good idea, too. One character of difference is relevant enough in a three-letter project name to cause confusion, especially if it is at the beginning of the name and not at the end.
Simon
Josh Suereth
Simon
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/diz0Cai6-qwJ.
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
I worked on cross versioning some more. You can see the modified summary in the above ChangeSummary under Pending and the latest changes on the 0.12 branch.
I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss (it isn't exciting to work on either if it makes you feel any better), but please read the above summary, the following explanation, and provide your opinion.
By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
There are now two ideas of Scala versions:
1. the full version, like 2.10.0-M1
2. the binary version, like 2.10
However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool. Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
"a" % "b" % "1.0" cross CrossVersion.full
in order to get a project built against 2.10.0-M1. This gets more complicated when mixed with features added for flexibility, such as being able to specify a String => String function to remap the Scala version (such as to use a dependency published against 2.9.0 when building against 2.9.1 because it wasn't published against 2.9.1). As a counterpoint, I expect this feature would be used less with binary compatibility within a minor version.
The usual disadvantages from before binary compatibility apply, such as Maven not recognizing that name_2.10 and name_2.11 are the same underlying module and should generate a conflict.
It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place. I don't see users of other build tools doing this, so I expect nothing would replace it.
If you are able to use Ivy metadata, you are probably already capable of solving this problem better with extra attributes (as sbt does now). Most open source users probably publish poms, though. All in all, it seems to me like too much work for the provided benefit, but I'm open to opinions either way.
Thanks,
Mark
Mark Harrah
Simon Ochsenreither <simon.och...@googlemail.com> wrote:
> Hi Mark!
>
> Robots.txt would be a god way to start.
This is a good idea and I looked into it. Unfortunately, I don't control code.google.com/robots.txt (obviously) and I can't generate <meta> tags on the wiki pages (Google automatically generates <meta name="ROBOTS" content="NOARCHIVE"> but that can't be configured).
> If that doesn't help or isn't
> possible, delete it. Better: Delete the whole Google Code stuff. If there
> is something important, move it to the current site.
I don't think this is fair to users. It hasn't even been a year since 0.10.0 was released. Google Code provides archives of previous releases, the source code, and the documentation. Last I checked, the wiki format still wasn't open, so that would require work to move somewhere.
I understand it is a problem that it is still around, but I don't think deleting the project or the wiki pages are net benefits. Josh's suggestion seems to be a decent next step to try.
> It is doing more harm than good since a long time already. Getting rid of
> the "x" in "xsbt" would be a good idea, too. One character of difference is
> relevant enough in a three-letter project name to cause confusion,
> especially if it is at the beginning of the name and not at the end.
I understand, but changing that will invalidate links and probably hurt search results in the short term (but I'm just guessing about search results). However, perhaps this can be done in the way Josh suggests.
-Mark
> Simon
>
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
scala-tools.org has been dropped as a default repository from the 0.12 branch because it is likely that by the time 0.13.0 comes out, scala-tools.org will be gone. I have also renamed sbt's organization from org.scala-tools.sbt to org.scala-sbt. Sorry for any inconvenience this will cause, but obviously I don't have control over this.
Thanks,
Mark
eugene yokota
> I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss
I think it's a fun topic. If this works out && Scala keeps its binary
compat across revisions, library authors don't have to rush to cross
publish every time a minor release comes out.
> By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
Aren't they related?
If I cross publish 2.10.0 and 2.10.1, the second publish would fail
because lib_2.10 is already published. In that case, maybe 2.10.0
should be skipped.
> There are now two ideas of Scala versions:
>
> 1. the full version, like 2.10.0-M1
> 2. the binary version, like 2.10
The term "binary version" is confusing to me.
The version of the binary (jar) is the version of the jar.
I think it's better to use some other term like "contract version",
"signature version", "API version", "header version", "bundle
interface version", etc..
> However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool.
To clarify, you mean that the artifact name becomes "b_2.10.0-M1" here
instead of "b_2.10"?
> Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
>
> "a" % "b" % "1.0" cross CrossVersion.full
>
> in order to get a project built against 2.10.0-M1.
Do you think it would be too confusing if there were
CrossVersion.both, which first checked the full version before
checking the binary version (and %% used CrossVersion.both)? If so, I
can just say
scalaVersion := "2.10.0-M1"
libraryDependencies += "a" %% "b" % "1.0"
This also would free build users from remembering which library
publishes using full instead of binary version.
> I expect this feature would be used less with binary compatibility within a minor version.
While that may be true eventually, I expect the upgrade adoptions to
be slow, especially for those using sbt 0.10 at work.
> It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place.
The alternative would be that the library versions gets hardcoded to a
particular version of Scala and up, which you see often with Ruby apps
etc. That would not be good.
> Most open source users probably publish poms, though.
As long as we publish to Maven repos, pom seems like a good nice-to-have.
-eugene
Daniel Sobral
> On Sun, 15 Jan 2012 18:24:25 -0500
> Mark Harrah <dmha...@gmail.com> wrote:
>
>> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
>
> I worked on cross versioning some more. You can see the modified summary in the above ChangeSummary under Pending and the latest changes on the 0.12 branch.
>
> I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss (it isn't exciting to work on either if it makes you feel any better), but please read the above summary, the following explanation, and provide your opinion.
>
> By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
>
> There are now two ideas of Scala versions:
>
> 1. the full version, like 2.10.0-M1
> 2. the binary version, like 2.10
>
> However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool. Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
I don't understand the issues well here, and I do like the ease which
"%%" brings to library use. As for the specific case above, however,
milestone releases are not meant for general distribution, but for
general evaluation. As such, I don't think any effort should be wasted
in making their use easier -- one can always fully specify the version
with "%", after all. Right?
I fear I might be missing the point here, but this seems important
enough to merit the effort of trying to, so, if I'm in error, please
try again to explain. Maybe the caffeine will have had time to work
its effects the next time! :-)
--
Daniel C. Sobral
I travel to the future all the time.
Mark Harrah
Daniel Sobral <dcso...@gmail.com> wrote:
> > By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
> >
> > There are now two ideas of Scala versions:
> >
> > 1. the full version, like 2.10.0-M1
> > 2. the binary version, like 2.10
> >
> > However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool. Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
>
> I don't understand the issues well here, and I do like the ease which
> "%%" brings to library use. As for the specific case above, however,
> milestone releases are not meant for general distribution, but for
> general evaluation. As such, I don't think any effort should be wasted
> in making their use easier -- one can always fully specify the version
> with "%", after all. Right?
Yes, I would agree, but historically, milestone users still complain. It is true that in the common case, it should just work, but there is more to consider in the general case.
You don't have to ever write the version (like name_2.10.0-M1), you say:
"a" % "b" % "1.0" cross CrossVersion.full
to use the full version instead of the ABI version.
> I fear I might be missing the point here, but this seems important
> enough to merit the effort of trying to, so, if I'm in error, please
> try again to explain. Maybe the caffeine will have had time to work
> its effects the next time! :-)
I think you have it right. The biggest problem is milestone releases may require users to do manual tweaking, but this is only when building against other software using milestone releases.
-Mark
Mark Harrah
eugene yokota <eed3...@gmail.com> wrote:
> On Sun, Jan 22, 2012 at 11:00 PM, Mark Harrah <dmha...@gmail.com> wrote:
> > I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss
>
> I think it's a fun topic. If this works out && Scala keeps its binary
> compat across revisions, library authors don't have to rush to cross
> publish every time a minor release comes out.
>
> > By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
>
> Aren't they related?
> If I cross publish 2.10.0 and 2.10.1, the second publish would fail
> because lib_2.10 is already published. In that case, maybe 2.10.0
> should be skipped.
Yes, they are related, but you wouldn't cross publish against binary compatible releases.
> > There are now two ideas of Scala versions:
> >
> > 1. the full version, like 2.10.0-M1
> > 2. the binary version, like 2.10
>
> The term "binary version" is confusing to me.
> The version of the binary (jar) is the version of the jar.
> I think it's better to use some other term like "contract version",
> "signature version", "API version", "header version", "bundle
> interface version", etc..
Yes, it is short for application binary interface (ABI) version.
> > However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool.
>
> To clarify, you mean that the artifact name becomes "b_2.10.0-M1" here
> instead of "b_2.10"?
Yes.
> > Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
> >
> > "a" % "b" % "1.0" cross CrossVersion.full
> >
> > in order to get a project built against 2.10.0-M1.
>
> Do you think it would be too confusing if there were
> CrossVersion.both, which first checked the full version before
> checking the binary version (and %% used CrossVersion.both)? If so, I
> can just say
>
> scalaVersion := "2.10.0-M1"
>
> libraryDependencies += "a" %% "b" % "1.0"
>
> This also would free build users from remembering which library
> publishes using full instead of binary version.
This is similar to previous suggestions to look for a fallback. This is essentially a dynamic revision and can't be standard practice as discussed previously (mainly, build reproducibility). I don't think this being for milestone releases affects this.
> > I expect this feature would be used less with binary compatibility within a minor version.
>
> While that may be true eventually, I expect the upgrade adoptions to
> be slow, especially for those using sbt 0.10 at work.
I'm not sure what you mean here, but something will change for Scala 2.10 in sbt 0.12. In order to support the new name_2.10 style, you have to use 0.12 or do it manually.
> > It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place.
>
> The alternative would be that the library versions gets hardcoded to a
> particular version of Scala and up, which you see often with Ruby apps
> etc. That would not be good.
This is already what ScalaTest does (did?), even though cross building exists.
-Mark
eugene yokota
>> > I expect this feature would be used less with binary compatibility within a minor version.
>>
>> While that may be true eventually, I expect the upgrade adoptions to
>> be slow, especially for those using sbt 0.10 at work.
>
> I'm not sure what you mean here, but something will change for Scala 2.10 in sbt 0.12. In order to support the new name_2.10 style, you have to use 0.12 or do it manually.
I like jumping on to new sbt versions, but we can't expect all
libraries to go to sbt 0.12 immediately.
Here's a scenario. A popular project is stuck at sbt 0.10/0.11 for
corporate policy or lack of a plugin, and it publishes against Scala
2.10.0 using name_2.10.0 style.
If the libraries users too are also on sbt 0.11, everything works out.
But suppose some users decide to give sbt 0.12 a try.
libraryDependencies += "com.big" %% "name" % "2.0"
They'll get error "name_2.10" was not resolved. This guy would
complain to the library and might come to conclusion that %% was
broken if he has to scalaVersion match {..} just to cross compile, or
revert back to sbt 0.11.
> This is similar to previous suggestions to look for a fallback. This is essentially a dynamic revision and can't be standard practice as discussed previously (mainly, build reproducibility). I don't think this being for milestone releases affects this.
If someone wants to avoid the dynamic nature, they can use %,
CrossVersion.full, or CrossVersion.binary. I thought it's a good
tradeoff, but now I am not sure.
-eugene
Josh Suereth
A few points:
Mark
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
> I like the ideas behind the new binary compatibility concerns.
>
> A few points:
>
> (1) Never drop Maven support (pushing poms, maven style). The minute we
> do, we alienate a lot of potential users and enter our own hole of
> existence. I'd rather see every scala project on maven central and force
> them to recognize the limiting issues of poms in there. We have enough
> projects, I think they'll take notice soon if we all start pushing to
> central.
No one is suggesting dropping pom support. It is only about dropping cross-versioning support because of the limitations of poms.
> (2) Love the custom function idea. This is beautiful. Sometimes, you're
> using such a subset of a library, that you remain binary compatible with
> newer versions even if the library is not "universally" binary compatible
> with a previous version.
This was added by Indrajit in 0.11.0 I think.
> (3) What do you think of potentially altering the current convention of
> adding the scala library to the module name and instead add it to the
> beginning of the organization. This would lead to pushing things onto
> maven central in the following directory structure:
>
> scala/2/9/com/jsuereth/
> pgp-library/
> 0.5/
> pgp-library-05.jar
> ...
>
> This means SBT can add the "base" directory and use cross versioning to
> pull in 2.9.x artifacts. However, you *could* also add a repository like
> so:
>
> "foo 2.9" at "http://foo.com/repo/scala/2/9"
>
> And you would get *just* 2.9 artifacts using the basic identifiers. It
> gives us a lot more niceties than appending the scala version to the name.
> It's kind of like namespacing repositories by version in YUM/Debian.
>
> Note: Idea adapted from Havoc's idea of universes. Also, Sonatype would
> let us publish to maven-central if our POMs matched this format.
Sounds interesting on the surface. I will think about it some more.
-Mark
Mark Harrah
eugene yokota <eed3...@gmail.com> wrote:
> On Mon, Jan 23, 2012 at 9:29 AM, Mark Harrah <dmha...@gmail.com> wrote:
> >> > I expect this feature would be used less with binary compatibility within a minor version.
> >>
> >> While that may be true eventually, I expect the upgrade adoptions to
> >> be slow, especially for those using sbt 0.10 at work.
> >
> > I'm not sure what you mean here, but something will change for Scala 2.10 in sbt 0.12. In order to support the new name_2.10 style, you have to use 0.12 or do it manually.
>
> I like jumping on to new sbt versions, but we can't expect all
> libraries to go to sbt 0.12 immediately.
>
> Here's a scenario. A popular project is stuck at sbt 0.10/0.11 for
> corporate policy or lack of a plugin, and it publishes against Scala
> 2.10.0 using name_2.10.0 style.
> If the libraries users too are also on sbt 0.11, everything works out.
> But suppose some users decide to give sbt 0.12 a try.
>
> libraryDependencies += "com.big" %% "name" % "2.0"
>
> They'll get error "name_2.10" was not resolved. This guy would
> complain to the library and might come to conclusion that %% was
> broken if he has to scalaVersion match {..} just to cross compile, or
> revert back to sbt 0.11.
There isn't an alternative. Automatically detecting the cross-version scheme using dynamic revisions is fragile, a lot of work, unreliable, and leads to unreproducible builds. It simply isn't an option. If changing the scheme to the ABI version is considered impractical, it just won't change or we will migrate away from it by having cross-versioning of the published artifact be disabled by default when building against 2.10 and later (you could still use %%).
The change has to happen across all open source projects. Consuming dependencies isn't affected that much; publishing is what matters the most. I don't think it is avoidable or reversible, which is why I have waited to be very sure Scala is binary compatible within minor versions. It is why this discussion is happening: changing this against again is not really practical, and why I have emphasized a full release cycle for 0.12.0: it needs to be reasonable to migrate to without serious regressions.
> > This is similar to previous suggestions to look for a fallback. This is essentially a dynamic revision and can't be standard practice as discussed previously (mainly, build reproducibility). I don't think this being for milestone releases affects this.
>
> If someone wants to avoid the dynamic nature, they can use %,
> CrossVersion.full, or CrossVersion.binary. I thought it's a good
> tradeoff, but now I am not sure.
Dynamic revisions can never be the default and cannot be a standard practice.
-Mark
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
I don't think this actually works cleanly. The pom would say the organization is scala.2.9.xyz. You would have to use this organization to resolve the module- you can't just use xyz because it is inconsistent. This means that the scala.2.9 would be appended to the repository base and you'd end up with scala/2/9.
Does the version even have to be included in the organization? Can users just declare http://foo.com/repo/scala/2/9 as the new scala-tools.org? Or, does Nexus not like this?
-Mark
Mark McBride
similar at my last company to manage maven dependencies that depended
on native code. A set of "profiles" were set up, each of which pointed
to an architecture specific repo (e.g. nexus/linux/x86_64). At build
time, a profile was activated based on arch system properties. Seems
like a similar scheme could work here, although it greatly complicates
publishing. People either have to manage a (potentially) broad set of
scala versioned repos, or publish to a central system that does so.
FWIW at Twitter we've given up on the cross publishing thing, and we
just snap a major rev when we run into incompatibilities, e.g. ostrich
4.x is 2.8.1 and will always be 2.8.1. Ostrich 1.x is 2.7.7 and will
always be so.
---Mark
Josh Suereth
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
> Nexus would be fine. SBT would be fine. I'm looking for how we can push
> to maven central. The amount of people contributing to it, and the mirrors
> make it a resource we can't ignore. Artifactory has shown some issues with
> speed/uptime for me. Scala-tools.org required a lot of scala-community
> time. If we push to place things on maven central we get to share our
> contributions with many others making the burden much lighter.
>
> That said, if having our own repository with a foo.com/repo/2/9 and
> foo.com/repo/2/10 is a good solution, maybe we do that.
Not sure I understand. Are you saying that we need our own repository to do the foo.com/repo/2/9/ thing? This is what I expected, but I wanted to check.
-Mark
Mark Harrah
ijuma <ism...@juma.me.uk> wrote:
> On Thursday, 19 January 2012 19:34:13 UTC, Mark Harrah wrote:
> >
> > A correction: It is likely that we will need a different interface, which
> > will require a .0 release. I expect this interface is not used in actual
> > builds and is probably rare even in plugins, but it will make sbt binary
> > incompatible and hence the need to include it in a .0 release. We are
> > seeing if this can be done for 0.12.0. I still expect to support the old
> > interface indefinitely as before, so that older test frameworks are
> > supported without changes.
> >
> Excellent, this is great news. The test interface has a large impact on
> user experience, so it's encouraging to see these much needed improvements.
Which improvements are you specifically interested in? ... just to make sure we don't disappoint.
> Now we just need to find some contributors to add support for forking in
> tests. ;)
Right, there is never a shortage of work.
-Mark
Mark Harrah
Mark McBride <mark.m...@gmail.com> wrote:
> Pretty sure nexus can front multiple repositories. We used something
> similar at my last company to manage maven dependencies that depended
> on native code. A set of "profiles" were set up, each of which pointed
> to an architecture specific repo (e.g. nexus/linux/x86_64). At build
> time, a profile was activated based on arch system properties. Seems
> like a similar scheme could work here, although it greatly complicates
> publishing. People either have to manage a (potentially) broad set of
> scala versioned repos, or publish to a central system that does so.
Yeah, I was asking about whether this was possible within a single repository or if it has to be set up by the repository owner as multiple repositories. It sounds like you are saying it is the latter.
> FWIW at Twitter we've given up on the cross publishing thing, and we
> just snap a major rev when we run into incompatibilities, e.g. ostrich
> 4.x is 2.8.1 and will always be 2.8.1. Ostrich 1.x is 2.7.7 and will
> always be so.
Thanks for the feedback.
-Mark
Josh Suereth
Separate repo. This is something we could do. I'm in talks with a few people, so we'll see what comes.
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
> Separate repo. This is something we could do. I'm in talks with a few
> people, so we'll see what comes.
I thought about it a bit and I don't think this will work. There are different repositories with the same metadata but different artifacts. When switching repositories for cross building, either 1) the cache thinks it already has the artifact 2) or it will overwrite the previous artifact with the new one. At least, I expect this is how Ivy and Maven will handle the situation[1].
So, in the end, you still need different metadata, which doesn't require different repositories.
-Mark
[1] From what I've heard about it, Gradle's cache might handle this well. Adopting Gradle's dependency management code would help, but not in the short term and not for Maven users or raw Ivy users.
Josh Suereth
Or we need a dependency management tool that works more like a debian repo/apt then maven....
Mark McBride
the industry standard. Inventing a new system cuts a lot of people out
of the game
---Mark
Josh Suereth
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
> I'm not aiming to cut anyone out of the game, nor to ignore any maven
> folks. I happen to be a maven person, if you look at my past contributions.
>
> In any case, I still advocate what we do to support maven. I had forgotten
> that Maven will still ignore SHA1's, PGP keys etc. and *not* fix your cache
> if you re-point from "Universe 2.9" to "Universe 2.10". That's a good
> reason not to take the suggestion.
>
> However, I still believe that choosing a "universe" (I.e. I want to use
> Scala 2.9.x, only give me those dependencies) *would* solve a lot of issues
> for us.
>
> A few more things we can look at to clean up the maven repos to be less
> ugly:
>
> (1) Scala classifiers. These can be custom strings *and* can be specified
> with dependencies. At least, IIRC this should work.
What do mean by "can be specified with dependencies"? There is only one pom for all of the classifiers, right? How can you declare different dependencies for each classifier?
> (2) Custom packaging names. We still publish jars, but give the package
> type "scala-29" or some such. I can update the maven-scala-plugin to make
> Maven aware of this package type and how to resolve/use it. This may have
> unintended side effects for tooling (like m2e and stuff), so We'd have to
> do a whole realm of tests on maven land, before being able to use it in SBT.
We have one hack right now and I don't think moving to another hack is enough of an improvement to justify the transition. Certainly it can be discussed more, but the current hack is "the devil we know" in some sense.
-Mark
Mark McBride
valid. Trying to upload them to artifactory without disabling pom
consistency checks fails :/
Geoff Reedy
> (1) Scala classifiers. These can be custom strings *and* can be specified
> with dependencies. At least, IIRC this should work.
I too thought that classifiers would be the perfect way to deal with
this issue especially in light of the suggestion in the maven docs that
classifiers java-1.4 and java-1.5 be used to distiguish between jars
appropriate for the respective platform. The fatal flaw seems to be
transitive dependency management. That is, there's no way to choose the
transitive dependency set based on the classifier used to require the
module. We'd need to be able to say that when you're using this module
with the scala-2.10 classifier it brings its own dependencies using the
scala-2.10 classifier and when used with the 2.9 classifier brings in
its own deps with the scala-2.9 classifier.
I think with the jvm versions it's possible to make this work because
jvm versioning has special support in the profile activation which can
can control dependencies.
Of course I'm not a maven expert so maybe there's a way around it with
some feature of maven I'm not aware of or by writing a plugin to make
the right thing happen.
-- Geoff
Harald Meland
> Dynamic revisions can never be the default and cannot be a standard practice.
still: SBT's Ivy conflict manager is "latest-revision"[1], which means
that if any of a project's dependencies have transitive dependencies
that use dynamic revisions, the project will, too.
This was surprising to me. One of my project's direct dependencies in
turn depend on "org.codehaus.jackson" % "jackson-core-asl" % "[1.4,)",
so even if I try to add a direct dependency from my project to the
version of jackson that I want, I'm expecting to get a surprise once
Jackson 2.0 is published on Maven Central.
From reading the descriptions of Ivy's built-in conflict managers (see
http://ant.apache.org/ivy/history/latest-milestone/settings/conflict-managers.html),
the "latest-compatible" variant sounds like a somewhat safer, but
still not overly strict default.
[1] This also seems be the default conflict manager for Ivy, according
to http://ant.apache.org/ivy/history/latest-milestone/ivyfile/conflict.html
-- which is probably why it was chosen to be the default in SBT as
well.
--
Harald
Mark Harrah
On Wed, 1 Feb 2012 23:55:11 -0800 (PST)
Harald Meland <hara...@gmail.com> wrote:
> On Jan 23, 5:21 pm, Mark Harrah <dmhar...@gmail.com> wrote:
> > Dynamic revisions can never be the default and cannot be a standard practice.
>
> I realize I'm taking this statement somewhat out of context, but
> still: SBT's Ivy conflict manager is "latest-revision"[1], which means
> that if any of a project's dependencies have transitive dependencies
> that use dynamic revisions, the project will, too.
Yes, but this isn't due to a particular conflict manager because it can happen without a conflict.
> This was surprising to me. One of my project's direct dependencies in
> turn depend on "org.codehaus.jackson" % "jackson-core-asl" % "[1.4,)",
> so even if I try to add a direct dependency from my project to the
> version of jackson that I want, I'm expecting to get a surprise once
> Jackson 2.0 is published on Maven Central.
Ideally, a dependency shouldn't be published to a release repository with a dynamic revision. I believe Maven has a plugin to verify this during release (or perhaps that is just for -SNAPSHOTs), but sbt does not (as far as I know).
> From reading the descriptions of Ivy's built-in conflict managers (see
> http://ant.apache.org/ivy/history/latest-milestone/settings/conflict-managers.html),
> the "latest-compatible" variant sounds like a somewhat safer, but
> still not overly strict default.
I agree it looks like it would be a good default, but with sbt assuming Scala 2.10.x versions are binary compatible, whenever you have library A depend on Scala 2.10.0 and library B depend on 2.10.1, there is a Scala library conflict.
I don't remember offhand if there is a setting for this already, but a patch to make the conflict manager configurable would be welcome. An enhancement request will also work.
Finally, for the actual, underlying problem, Ivy has an attribute 'force' that can be set on the <dependency> tag that fixes the version of the dependency. sbt doesn't support it in the Scala API (pull request or enhancement request works), but you can set it in ivyXML[1].
> [1] This also seems be the default conflict manager for Ivy, according
> to http://ant.apache.org/ivy/history/latest-milestone/ivyfile/conflict.html
> -- which is probably why it was chosen to be the default in SBT as
> well.
Yes.
-Mark
[1] See Inline Ivy XML on https://github.com/harrah/xsbt/wiki/Library-Management and http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html
> --
> Harald
>
ijuma
Which improvements are you specifically interested in? ... just to make sure we don't disappoint.
SK
I guess I'm late as well.
> Which improvements are you specifically interested in? ... just to make
> sure we don't disappoint.
test-quick
I think that was an amazing feature. Whenever I was asked why I use
SBT the answer was test-quick. It just makes TDD very sweet.
Probably a reason for why it is removed, but if I could get one
feature that would be it.
Stein Kåre
Mark Harrah
SK <skyt...@gmail.com> wrote:
> Hi Mark,
>
> I guess I'm late as well.
>
> > Which improvements are you specifically interested in? ... just to make
> > sure we don't disappoint.
>
> If I could pick one feature to add:
>
> test-quick
The original question was specific to ongoing work with ScalaTest developers to rework the unified test interface. Feedback on test-quick is of course welcome. Adding 'test-quick' isn't as urgent, since it doesn't need to be in 0.12.
> I think that was an amazing feature. Whenever I was asked why I use
> SBT the answer was test-quick. It just makes TDD very sweet.
>
> Probably a reason for why it is removed, but if I could get one
> feature that would be it.
groups.google.com/group/simple-build-tool/browse_thread/thread/5b2bac7eb9bbbb58/358e5dc26640a617
Feedback that I haven't gotten is: what was it about test-quick that was most helpful? Was it how it only reran the failed tests, like test-failed, or was it how it reran tests that were recompiled (and hence, one of their transitive dependencies changed)?
In sbt 0.10+, a test source file (like normal source files) is only recompiled if the API of a direct dependency changes. Is this the better trigger? I think not by default, but perhaps a switch would be useful. To replicate 0.7 behavior, test-quick would have to do extra work beyond that done by 'compile'. (This might be fine, I just don't want to do it if it isn't useful.)
This is what I mean in that thread by, what is the ideal 'test-quick' going forward. I'm happy to implement it; I just would like feedback first.
-Mark
Mark Harrah
ijuma <ism...@juma.me.uk> wrote:
> Hi Mark, sorry for the late reply.
No problem and thanks...
> On Monday, 23 January 2012 23:16:15 UTC, Mark Harrah wrote:
> >
> > Which improvements are you specifically interested in? ... just to make
> > sure we don't disappoint.
> >
> There are 3 things:
>
> 1. Output of JUnit XML by ScalaTest instead of JUnit XML Listener. The
> reason is that the latter doesn't support all of ScalaTest features (like
> pending tests) and that it doesn't report time taken by tests accurately.
> This functionality was implemented for ScalaTest 1.7, but was reverted in
> the last minute due to a few issues mentioned in the thread I linked. Bill
> concluded that SBT should have a notion of a "run" for it to be implemented
> properly.
>
> 2. Better support for aborted suites. ScalaTest currently uses a hack where
> it creates a fake test that fails.
Bill would have to confirm, but I believe both of these will be addressed.
> 3. Better support for controlling parallelism of tests.
This is addressed to the extent of being able to tag a test and then restrict it according to the new support in 0.12 for controlling concurrent execution. Tagging a test is already supported by ScalaTest, but the test interface doesn't support it.
Will this help?
> I was hoping that 1 and 2 would make it to the next release. 3 is becoming
> increasingly important, but I realise that it requires a more
> experimentation to find the best way to deal with that.
Yes, I'd like it in 0.12.0 as well. I think we'll have a milestone soon with what is in trunk now and then work on the improved test interface and fixing #329 for the beta.
-Mark
> Best,
> Ismael
>
> >
>
ijuma
Bill would have to confirm, but I believe both of these will be addressed.
> 3. Better support for controlling parallelism of tests.
This is addressed to the extent of being able to tag a test and then restrict it according to the new support in 0.12 for controlling concurrent execution. Tagging a test is already supported by ScalaTest, but the test interface doesn't support it.
Will this help?
Yes, I'd like it in 0.12.0 as well. I think we'll have a milestone soon with what is in trunk now and then work on the improved test interface and fixing #329 for the beta.
ijuma
On Monday, 6 February 2012 21:05:23 UTC, Mark Harrah wrote:Bill would have to confirm, but I believe both of these will be addressed.
> 3. Better support for controlling parallelism of tests.
Great.