This page is no longer maintained — Please continue to the home page at www.scala-lang.org

version detection

16 replies
Stepan Koltsov
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.

Hi, all.

I'd like scalac task to have "minversion" property. Task should fail
if scala version is below specified value.

When program cannot be compiled, I'd like to help developers find
reason faster: because compiler is too old.

I could write a patch.

There is also a need for runtime detection of scala library version. I
know there is a library.property file in the scala-library.jar, that
could be used for that purpose, however:

1. File name library.properties could cause conflict with another
library, which owner wishes to store his library version in the
library.properties file. Scala library library.properties should be
renamed to scala/library.properties.

2. Undocumented anywhere, so not guaranteed to be changed one day. I
don't know where to place description of the file content. There is no
single place of Scala Documentation, like in JDK:
http://download.java.net/jdk7/docs/ . I think this place should be
created. Description of scala/library.properties should live there.

S.

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: version detection
I think both of these suggestions, especially the runtime one, would be very useful.

On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
Hi, all.


I'd like scalac task to have "minversion" property. Task should fail
if scala version is below specified value.

When program cannot be compiled, I'd like to help developers find
reason faster: because compiler is too old.

I could write a patch.


There is also a need for runtime detection of scala library version. I
know there is a library.property file in the scala-library.jar, that
could be used for that purpose, however:

1. File name library.properties could cause conflict with another
library, which owner wishes to store his library version in the
library.properties file. Scala library library.properties should be
renamed to scala/library.properties.

2. Undocumented anywhere, so not guaranteed to be changed one day. I
don't know where to place description of the file content. There is no
single place of Scala Documentation, like in JDK:
http://download.java.net/jdk7/docs/ . I think this place should be
created. Description of scala/library.properties should live there.


S.



--
http://erikengbrecht.blogspot.com/
Alex Boisvert
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection
Same here!   I was about to send the same email to the list.

It would also be great to have this value somewhere in the Scala library,

object Predef {
  ...
  val SCALA_VERSION = "2.7.3"
  ...
}

?

alex


On Sat, Feb 21, 2009 at 3:16 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I think both of these suggestions, especially the runtime one, would be very useful.

On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
Hi, all.


I'd like scalac task to have "minversion" property. Task should fail
if scala version is below specified value.

When program cannot be compiled, I'd like to help developers find
reason faster: because compiler is too old.

I could write a patch.


There is also a need for runtime detection of scala library version. I
know there is a library.property file in the scala-library.jar, that
could be used for that purpose, however:

1. File name library.properties could cause conflict with another
library, which owner wishes to store his library version in the
library.properties file. Scala library library.properties should be
renamed to scala/library.properties.

2. Undocumented anywhere, so not guaranteed to be changed one day. I
don't know where to place description of the file content. There is no
single place of Scala Documentation, like in JDK:
http://download.java.net/jdk7/docs/ . I think this place should be
created. Description of scala/library.properties should live there.


S.



--
http://erikengbrecht.blogspot.com/

loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: version detection
I vote for this feature as well.My proposal would be something in the middle: have the version is some proper property file and then have a lazy val in Predef compute it.

On Sun, Feb 22, 2009 at 5:23 PM, Alex Boisvert <boisvert [at] intalio [dot] com> wrote:
Same here!   I was about to send the same email to the list.

It would also be great to have this value somewhere in the Scala library,

object Predef {
  ...
  val SCALA_VERSION = "2.7.3"
  ...
}

?

alex


On Sat, Feb 21, 2009 at 3:16 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I think both of these suggestions, especially the runtime one, would be very useful.

On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
Hi, all.


I'd like scalac task to have "minversion" property. Task should fail
if scala version is below specified value.

When program cannot be compiled, I'd like to help developers find
reason faster: because compiler is too old.

I could write a patch.


There is also a need for runtime detection of scala library version. I
know there is a library.property file in the scala-library.jar, that
could be used for that purpose, however:

1. File name library.properties could cause conflict with another
library, which owner wishes to store his library version in the
library.properties file. Scala library library.properties should be
renamed to scala/library.properties.

2. Undocumented anywhere, so not guaranteed to be changed one day. I
don't know where to place description of the file content. There is no
single place of Scala Documentation, like in JDK:
http://download.java.net/jdk7/docs/ . I think this place should be
created. Description of scala/library.properties should live there.


S.



--
http://erikengbrecht.blogspot.com/




--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: version detection
I'd rather not make a custom solution, but rather wait for project jigsaw (java 7).
For now, I use maven or OSGi to ensure bundle version compliance.  I recommend we stick to JVM standards until the real modularity Apis are complete.


On Feb 22, 2009, at 10:42 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:

I vote for this feature as well.My proposal would be something in the middle: have the version is some proper property file and then have a lazy val in Predef compute it.

On Sun, Feb 22, 2009 at 5:23 PM, Alex Boisvert <boisvert [at] intalio [dot] com (boisvert [at] intalio [dot] com" rel="nofollow">boisvert [at] intalio [dot] com)> wrote:
Same here!   I was about to send the same email to the list.

It would also be great to have this value somewhere in the Scala library,

object Predef {
  ...
  val SCALA_VERSION = "2.7.3"
  ...
}

?

alex


On Sat, Feb 21, 2009 at 3:16 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com (erik [dot] engbrecht [at] gmail [dot] com" rel="nofollow">erik [dot] engbrecht [at] gmail [dot] com)> wrote:
I think both of these suggestions, especially the runtime one, would be very useful.

On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com (stepan [dot] koltsov [at] gmail [dot] com" rel="nofollow">stepan [dot] koltsov [at] gmail [dot] com)> wrote:
Hi, all.


I'd like scalac task to have "minversion" property. Task should fail
if scala version is below specified value.

When program cannot be compiled, I'd like to help developers find
reason faster: because compiler is too old.

I could write a patch.


There is also a need for runtime detection of scala library version. I
know there is a library.property file in the scala-library.jar, that
could be used for that purpose, however:

1. File name library.properties could cause conflict with another
library, which owner wishes to store his library version in the
library.properties file. Scala library library.properties should be
renamed to scala/library.properties.

2. Undocumented anywhere, so not guaranteed to be changed one day. I
don't know where to place description of the file content. There is no
single place of Scala Documentation, like in JDK:
http://download.java.net/jdk7/docs/ . I think this place should be
created. Description of scala/library.properties should live there.


S.



--
http://erikengbrecht.blogspot.com/




--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: version detection

On Sun, Feb 22, 2009 at 07:23:38AM -0800, Alex Boisvert wrote:
> It would also be great to have this value somewhere in the Scala library,
>
> object Predef {
> ...
> val SCALA_VERSION = "2.7.3"
> ...
> }

I don't disagree with some of the points in this thread, but this is already present, read out of the
library.properties file included in the jar.

scala> scala.util.Properties.versionString
res0: String = version 2.7.3.final

Or for a more numberful experience try trunk:

scala> scala.util.Properties.versionString
res0: String = version 2.8.0.r0-b20090217085811

Alex Boisvert
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection
On Sun, Feb 22, 2009 at 8:24 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Sun, Feb 22, 2009 at 07:23:38AM -0800, Alex Boisvert wrote:
> It would also be great to have this value somewhere in the Scala library,
>
> object Predef {
>   ...
>   val SCALA_VERSION = "2.7.3"
>   ...
> }

I don't disagree with some of the points in this thread, but this is already present, read out of the
library.properties file included in the jar.

scala> scala.util.Properties.versionString
res0: String = version 2.7.3.final

Oh, I didn't know about scala.util.Properties.  This solves it for me.

alex

Stepan Koltsov
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection

The problem with Maven, OSGi, jigsaw, whatever else is that all they
are very hard to understand, configure and launch. Especially for
newcomers, and especially on simple projects, requiring two hours of
coding.

There must always exist simple way to compile and execute application.
It is by using Ant and by invoking java -classpath 'lib/*' . In this
case, anyway, components should be able to perform self-tests.

One note about Maven. Personally, I think that Maven is big bad
useless thing. It works perfectly when you are developing simple
library that depends on two other libraries. But when you have large
complex project, Maven just does not work. Maven adds lots of
restrictions (source tree structure, build process), and requires lots
of efforts to work around them.

One example. While building we execute external process svnversion to
generate version, writing output to properties file, and then packing
properties inside jars, and adding generated version string to the
target jar file name. All this requires 5 minutes of reading Ant
documentation, and about 10 lines in build.xml. I failed to understand
what I have to do with Maven, to achieve this behavior.

There are lots of things that can be required to build complex
project. Better or worse, but all of them are easily solvable with
Ant. Ant build.xml is very simple, and Ant always do exactly what is
written inside build.xml. Writing pom.xml always requires googling and
reading sources to understand Maven magic.

Maven could be used for dependency tracking only, but unfortunately
for Maven, Apache Ivy does dependency tracking much better.

S.

On Sun, Feb 22, 2009 at 18:50, Josh Suereth wrote:
> I'd rather not make a custom solution, but rather wait for project jigsaw
> (java 7).
> For now, I use maven or OSGi to ensure bundle version compliance. I
> recommend we stick to JVM standards until the real modularity Apis are
> complete.
>
>
> On Feb 22, 2009, at 10:42 AM, Christos KK Loverdos
> wrote:
>
> I vote for this feature as well.
> My proposal would be something in the middle: have the version is some
> proper property file and then have a lazy val in Predef compute it.
>
> On Sun, Feb 22, 2009 at 5:23 PM, Alex Boisvert wrote:
>>
>> Same here! I was about to send the same email to the list.
>>
>> It would also be great to have this value somewhere in the Scala library,
>>
>> object Predef {
>> ...
>> val SCALA_VERSION = "2.7.3"
>> ...
>> }
>>
>> ?
>>
>> alex
>>
>>
>> On Sat, Feb 21, 2009 at 3:16 PM, Erik Engbrecht
>> wrote:
>>>
>>> I think both of these suggestions, especially the runtime one, would be
>>> very useful.
>>>
>>> On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov
>>> wrote:
>>>>
>>>> Hi, all.
>>>>
>>>>
>>>> I'd like scalac task to have "minversion" property. Task should fail
>>>> if scala version is below specified value.
>>>>
>>>> When program cannot be compiled, I'd like to help developers find
>>>> reason faster: because compiler is too old.
>>>>
>>>> I could write a patch.
>>>>
>>>>
>>>> There is also a need for runtime detection of scala library version. I
>>>> know there is a library.property file in the scala-library.jar, that
>>>> could be used for that purpose, however:
>>>>
>>>> 1. File name library.properties could cause conflict with another
>>>> library, which owner wishes to store his library version in the
>>>> library.properties file. Scala library library.properties should be
>>>> renamed to scala/library.properties.
>>>>
>>>> 2. Undocumented anywhere, so not guaranteed to be changed one day. I
>>>> don't know where to place description of the file content. There is no
>>>> single place of Scala Documentation, like in JDK:
>>>> http://download.java.net/jdk7/docs/ . I think this place should be
>>>> created. Description of scala/library.properties should live there.
>>>>
>>>>
>>>> S.
>>>
>>>
>>>
>>> --
>>> http://erikengbrecht.blogspot.com/
>>
>
>
>
> --
> __~O
> -\ <, Christos KK Loverdos
> (*)/ (*) http://ckkloverdos.com
>

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: version detection
Hey, I have complaints about maven along with everyone else.  However I disagree with the line " Ant is simple".   Ant is simple because you already understand it.  To me, Maven is simple because I understand it well, and can write my own plugins where it has faults.  Also remember, you can embedd ant "scriptlets" into maven, so the problem you're describing is a 3 second addition to the maven build.  I'd rather not start arguing Ant vs. Maven because It's a pointless debate.  Neither is perfect, and both have strengths.


The main reason things like Maven and OSGi are complicated is because they're *dealing with a deficiency in the Java Platform*.    My argument is that as Sun is attempting to address this deficiency with project jigsaw, we should wait until then before doing anything drastic.   In the meantime, things like Maven (or Ivy for those ant-users) and OSGi have come to the rescue, at the expense of adding more layers of complexity. 

You're right, things should be simpler for new-comers.  I believe some of those layers need to be there, but I look at languages like "Fan" where they are addressing this at the language level.  I'd love to see scala do something similar, but I also think waiting for project jigsaw may be prudent! (or sticking with OSGi, as sun will most likely be forced to have jigsaw be compliant with OSGi).

Even Maven-3 is changing their dependency versioning system to match OSGi.  (I have no clue about Ivy)


-Josh





On Sun, Feb 22, 2009 at 11:35 AM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
The problem with Maven, OSGi, jigsaw, whatever else is that all they
are very hard to understand, configure and launch. Especially for
newcomers, and especially on simple projects, requiring two hours of
coding.

There must always exist simple way to compile and execute application.
It is by using Ant and by invoking java -classpath 'lib/*' . In this
case, anyway, components should be able to perform self-tests.

One note about Maven. Personally, I think that Maven is big bad
useless thing. It works perfectly when you are developing simple
library that depends on two other libraries. But when you have large
complex project, Maven just does not work. Maven adds lots of
restrictions (source tree structure, build process), and requires lots
of efforts to work around them.

One example. While building we execute external process svnversion to
generate version, writing output to properties file, and then packing
properties inside jars, and adding generated version string to the
target jar file name. All this requires 5 minutes of reading Ant
documentation, and about 10 lines in build.xml. I failed to understand
what I have to do with Maven, to achieve this behavior.

There are lots of things that can be required to build complex
project. Better or worse, but all of them are easily solvable with
Ant. Ant build.xml is very simple, and Ant always do exactly what is
written inside build.xml. Writing pom.xml always requires googling and
reading sources to understand Maven magic.

Maven could be used for dependency tracking only, but unfortunately
for Maven, Apache Ivy does dependency tracking much better.

S.

On Sun, Feb 22, 2009 at 18:50, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> I'd rather not make a custom solution, but rather wait for project jigsaw
> (java 7).
> For now, I use maven or OSGi to ensure bundle version compliance.  I
> recommend we stick to JVM standards until the real modularity Apis are
> complete.
>
>
> On Feb 22, 2009, at 10:42 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com>
> wrote:
>
> I vote for this feature as well.
> My proposal would be something in the middle: have the version is some
> proper property file and then have a lazy val in Predef compute it.
>
> On Sun, Feb 22, 2009 at 5:23 PM, Alex Boisvert <boisvert [at] intalio [dot] com> wrote:
>>
>> Same here!   I was about to send the same email to the list.
>>
>> It would also be great to have this value somewhere in the Scala library,
>>
>> object Predef {
>>   ...
>>   val SCALA_VERSION = "2.7.3"
>>   ...
>> }
>>
>> ?
>>
>> alex
>>
>>
>> On Sat, Feb 21, 2009 at 3:16 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com>
>> wrote:
>>>
>>> I think both of these suggestions, especially the runtime one, would be
>>> very useful.
>>>
>>> On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov
>>> <stepan [dot] koltsov [at] gmail [dot] com> wrote:
>>>>
>>>> Hi, all.
>>>>
>>>>
>>>> I'd like scalac task to have "minversion" property. Task should fail
>>>> if scala version is below specified value.
>>>>
>>>> When program cannot be compiled, I'd like to help developers find
>>>> reason faster: because compiler is too old.
>>>>
>>>> I could write a patch.
>>>>
>>>>
>>>> There is also a need for runtime detection of scala library version. I
>>>> know there is a library.property file in the scala-library.jar, that
>>>> could be used for that purpose, however:
>>>>
>>>> 1. File name library.properties could cause conflict with another
>>>> library, which owner wishes to store his library version in the
>>>> library.properties file. Scala library library.properties should be
>>>> renamed to scala/library.properties.
>>>>
>>>> 2. Undocumented anywhere, so not guaranteed to be changed one day. I
>>>> don't know where to place description of the file content. There is no
>>>> single place of Scala Documentation, like in JDK:
>>>> http://download.java.net/jdk7/docs/ . I think this place should be
>>>> created. Description of scala/library.properties should live there.
>>>>
>>>>
>>>> S.
>>>
>>>
>>>
>>> --
>>> http://erikengbrecht.blogspot.com/
>>
>
>
>
> --
>  __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>

Stepan Koltsov
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection

On Sun, Feb 22, 2009 at 19:34, Alex Boisvert wrote:
>> On Sun, Feb 22, 2009 at 07:23:38AM -0800, Alex Boisvert wrote:
>> > It would also be great to have this value somewhere in the Scala
>> > library,
>> >
>> > object Predef {
>> > ...
>> > val SCALA_VERSION = "2.7.3"
>> > ...
>> > }
>>
>> I don't disagree with some of the points in this thread, but this is
>> already present, read out of the
>> library.properties file included in the jar.
>>
>> scala> scala.util.Properties.versionString
>> res0: String = version 2.7.3.final
>
> Oh, I didn't know about scala.util.Properties. This solves it for me.

I didn't know too.

S.

Stepan Koltsov
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection

On Sun, Feb 22, 2009 at 19:51, Josh Suereth wrote:
> Hey, I have complaints about maven along with everyone else. However I
> disagree with the line " Ant is simple". Ant is simple because you already
> understand it.

No. Because build.xml is a script, while pom.xml is a set of options.

S.

Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection

On Sun, Feb 22, 2009 at 5:51 PM, Josh Suereth wrote:

> Even Maven-3 is changing their dependency versioning system to match OSGi.
> (I have no clue about Ivy)
>

Does the standard Package version information not work? (not near a
computer with scala to test :-<)

Ivy has supported configurable versioning schemes for 3 years or more,
so I assume it already does this.

personally speaking I really miss Ivys configuration flexibility with
Maven, its the one thing I truly find lacking. Profiles come close but
they just aren't the same.

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: version detection


On Sun, Feb 22, 2009 at 12:25 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
On Sun, Feb 22, 2009 at 19:51, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> Hey, I have complaints about maven along with everyone else.  However I
> disagree with the line " Ant is simple".   Ant is simple because you already
> understand it.

No. Because build.xml is a script, while pom.xml is a set of options.

S.

You assume a script is easier than a set of options (of which some may be scripts).  I disagree.  I think one reason Ruby on Rails was so popular was "convention over configuration".  Starting a project is easy, just place your source code here, your reasources here, your css/html here, run this command and BOOM!.  I believe maven is the same way.   However, if you already *know* how to script, then yes, ant would be more familiar.   Look at the Simple Build Tool design.  It's fairly simple and easy to get started.  It also chose the convention-over-configuration route. 

Ant is not a script, it's a series of scripts with dependencies, writen in a format better suited for configuration or data marshalling (*not* scripting).  Once again, I believe this has nothing to do with the original point of your question, which was "how should we manage version dependencies in scala".


Anyway, I apologize if my emails sound harsh, I do not intend them to be.  I'm am tired of throwing out the bathwater with the baby when it comes to maven.  Maven dependency management is a good thing for build-time version management.   There is Ivy if you prefer scripting-based build systems like ant/gant.  There's even mercury now if you want to remain closer to the maven world. If you need to manage version during Runtime, there is OSGi.   None of these solutinos is perfect, but I'll say it again: They exist because of deficiency in the Java Platform which is (hopefully) being resolved.
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: version detection


On Sun, Feb 22, 2009 at 1:18 PM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:
On Sun, Feb 22, 2009 at 5:51 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
<snip/>
> Even Maven-3 is changing their dependency versioning system to match OSGi.
> (I have no clue about Ivy)
>

Does the standard Package version information not work? (not near a
computer with scala to test :-<)

Not quite.  OSGi likes to place dates in versions, and so do Maven -SNAPSHOT artifacts.  The issue is what version is "newer" than another.   Maven 2 chose different criteria than OSGi (or perhaps chronologically it may have been the other way around).   OSGi won the argument though, maven 3 (at least the version i have in Tycho) is compatable with OSGi rules. 

Most people probably wouldn't run into this, but it stil exists.
pi song
Joined: 2009-02-20,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection
Just to mention a small thing about Maven.  Basically, once you decide to use Maven, you're not locked-in. Whenever you feel overly uncomfortable with the maven model restrictions, you can fall back by using Maven to generate Ant build file. I have been using Maven for at least 7 months and don't find any problem with it.
Pi Song

On Mon, Feb 23, 2009 at 5:27 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:


On Sun, Feb 22, 2009 at 1:18 PM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:
On Sun, Feb 22, 2009 at 5:51 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
<snip/>
> Even Maven-3 is changing their dependency versioning system to match OSGi.
> (I have no clue about Ivy)
>

Does the standard Package version information not work? (not near a
computer with scala to test :-<)

Not quite.  OSGi likes to place dates in versions, and so do Maven -SNAPSHOT artifacts.  The issue is what version is "newer" than another.   Maven 2 chose different criteria than OSGi (or perhaps chronologically it may have been the other way around).   OSGi won the argument though, maven 3 (at least the version i have in Tycho) is compatable with OSGi rules. 

Most people probably wouldn't run into this, but it stil exists.

loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: version detection
FWIW I recently reached my limits with build/dep-management systems/scripts. We have this commercial project where a part is controlled Maven, another part part is controlled by custom ant scripts (our own from scratch) and another part is controlled by third-party-donot-touch ant scripts that need you to provide their dependencies in a very specific way. Some of the final artifacts are pure jars, others are EJB jars, others are other fancy proprietary J2EE things (weblogic processes, if that matters)
We are talking about a complete build nightmare. I had to sit down and hack, in two man-days, a meta-build tool that can handle the situation in a somewhat developer-friendly and smoother way. 
The whole point to me is openness. People make assumptions that their project will be used in  an environment of same kind projects. Or that you can dissect your build domain in a uniform way. This is simply not true because the world is neither uniform nor perfect. 
Christos

On Sun, Feb 22, 2009 at 6:35 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
The problem with Maven, OSGi, jigsaw, whatever else is that all they
are very hard to understand, configure and launch. Especially for
newcomers, and especially on simple projects, requiring two hours of
coding.

There must always exist simple way to compile and execute application.
It is by using Ant and by invoking java -classpath 'lib/*' . In this
case, anyway, components should be able to perform self-tests.

One note about Maven. Personally, I think that Maven is big bad
useless thing. It works perfectly when you are developing simple
library that depends on two other libraries. But when you have large
complex project, Maven just does not work. Maven adds lots of
restrictions (source tree structure, build process), and requires lots
of efforts to work around them.

One example. While building we execute external process svnversion to
generate version, writing output to properties file, and then packing
properties inside jars, and adding generated version string to the
target jar file name. All this requires 5 minutes of reading Ant
documentation, and about 10 lines in build.xml. I failed to understand
what I have to do with Maven, to achieve this behavior.

There are lots of things that can be required to build complex
project. Better or worse, but all of them are easily solvable with
Ant. Ant build.xml is very simple, and Ant always do exactly what is
written inside build.xml. Writing pom.xml always requires googling and
reading sources to understand Maven magic.

Maven could be used for dependency tracking only, but unfortunately
for Maven, Apache Ivy does dependency tracking much better.

S.

On Sun, Feb 22, 2009 at 18:50, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> I'd rather not make a custom solution, but rather wait for project jigsaw
> (java 7).
> For now, I use maven or OSGi to ensure bundle version compliance.  I
> recommend we stick to JVM standards until the real modularity Apis are
> complete.
>
>
> On Feb 22, 2009, at 10:42 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com>
> wrote:
>
> I vote for this feature as well.
> My proposal would be something in the middle: have the version is some
> proper property file and then have a lazy val in Predef compute it.
>
> On Sun, Feb 22, 2009 at 5:23 PM, Alex Boisvert <boisvert [at] intalio [dot] com> wrote:
>>
>> Same here!   I was about to send the same email to the list.
>>
>> It would also be great to have this value somewhere in the Scala library,
>>
>> object Predef {
>>   ...
>>   val SCALA_VERSION = "2.7.3"
>>   ...
>> }
>>
>> ?
>>
>> alex
>>
>>
>> On Sat, Feb 21, 2009 at 3:16 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com>
>> wrote:
>>>
>>> I think both of these suggestions, especially the runtime one, would be
>>> very useful.
>>>
>>> On Sat, Feb 21, 2009 at 5:49 PM, Stepan Koltsov
>>> <stepan [dot] koltsov [at] gmail [dot] com> wrote:
>>>>
>>>> Hi, all.
>>>>
>>>>
>>>> I'd like scalac task to have "minversion" property. Task should fail
>>>> if scala version is below specified value.
>>>>
>>>> When program cannot be compiled, I'd like to help developers find
>>>> reason faster: because compiler is too old.
>>>>
>>>> I could write a patch.
>>>>
>>>>
>>>> There is also a need for runtime detection of scala library version. I
>>>> know there is a library.property file in the scala-library.jar, that
>>>> could be used for that purpose, however:
>>>>
>>>> 1. File name library.properties could cause conflict with another
>>>> library, which owner wishes to store his library version in the
>>>> library.properties file. Scala library library.properties should be
>>>> renamed to scala/library.properties.
>>>>
>>>> 2. Undocumented anywhere, so not guaranteed to be changed one day. I
>>>> don't know where to place description of the file content. There is no
>>>> single place of Scala Documentation, like in JDK:
>>>> http://download.java.net/jdk7/docs/ . I think this place should be
>>>> created. Description of scala/library.properties should live there.
>>>>
>>>>
>>>> S.
>>>
>>>
>>>
>>> --
>>> http://erikengbrecht.blogspot.com/
>>
>
>
>
> --
>  __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>



--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com
Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: version detection

What I meant was classOf[List[_]].getPackage.

Unfortunately both
println(classOf[List[_]].getPackage.getImplementationVersion) and spec
version both return null, which I assume is an oversight by the Scala
builders (the Manifest is pretty empty). Any version type used should
be fine for these class of functions, isCompatibleWith however depends
on the pure numerical version.

On Sun, Feb 22, 2009 at 7:27 PM, Josh Suereth wrote:
>
>
> On Sun, Feb 22, 2009 at 1:18 PM, Chris Twiner
> wrote:
>>
>> On Sun, Feb 22, 2009 at 5:51 PM, Josh Suereth
>> wrote:
>>
>> > Even Maven-3 is changing their dependency versioning system to match
>> > OSGi.
>> > (I have no clue about Ivy)
>> >
>>
>> Does the standard Package version information not work? (not near a
>> computer with scala to test :-<)
>
> Not quite. OSGi likes to place dates in versions, and so do Maven -SNAPSHOT
> artifacts. The issue is what version is "newer" than another. Maven 2
> chose different criteria than OSGi (or perhaps chronologically it may have
> been the other way around). OSGi won the argument though, maven 3 (at
> least the version i have in Tycho) is compatable with OSGi rules.
>
> Most people probably wouldn't run into this, but it stil exists.
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland