The ceylon doc for the language module 1.2 release has no links from the generated docs to the source code. What's weird about this is the source code is actually there, there just aren't any links to it.

This problem does not affect the SDK docs.

What used to be gvm is now called sdkman and we really should make Ceylon available there, it's becoming very popular among JVM devs.

http://sdkman.io/vendors.html

• close all M2 issues in ceylon-spec (Stef)
• close all M2 issues in ceylon.language (Tako)
• find new parts of ceylon.language that weren't there in M1 (Tako)
• close all M2 issues in ceylon-module-resolver (Stef)
• close all M2 issues in ceylon-compiler (all of us)
• test the new parts of ceylon.language that weren't there in M1 (all of us)
• make sure these parts are documented (Enrique, Stef)
• update the website docs for M2 features (Tom, Stef)
  • Docs for type mapping (Stef)
  • Docs for interop: calling Java from Ceylon (Stef)
  • Docs for interop: calling Ceylon from Java (Stef)
  • Docs for repositories (Stef)
  • Docs for Maven interop (Stef)
  • Missing reference pages (Tom)
• deal with Google Analytics (Stef)
• Add build.xml samples (Stef)
• package the release (Stef)
• test on OSX, Linux, Windows (Stef/Tako:Windows and Linux)
• update the website for the release
• deal with the annoucements (Stef)
• do the release (Stef)

from /usr/share/ceylon/1.2/doc -> /usr/share/doc/ceylon-1.2.0/

There's got to be a way to generate the OSGi metadata without Eclipse.

• JBoss Modules is currently at 1.4.4.Final and we are using 1.3.3.Final
• JBoss logmanager is currently at 2.0.3.Final and we are using 1.4.0.Final
• JBoss Jandex is currently at 2.0.0.Final and we are using 1.0.3.Final

I think we should update these.

But try to retrieve it from the Ceylon configuration. If it doesn't exist just default to the current value (~/.ceylon/repo)

Needs ceylon/ceylon-compiler#1839

MacPorts needs to be given a port file for Ceylon so that OSX people can use MacPorts instead of HomeBrew.

So they work in JS

To show how to invoke Java code.

Because of a size limitation in the Windows "shell" the build can't process the large number of files it needs to pass to the compiler.

The solution currently chosen to work around this is to use a special class loader that knows how to set up a correct Ceylon environment (libraries + repository). This way we can circumvent having to use shell execution and we can execute the compiler in-process from ant.

Change build IDE task so that -

• it does not copy jars to IDE /lib - after confirming that it is OK to remove them
• copies /repo, minus docs, into IDE/plugin/...ui/defaultRepository

There have no ceylonc and ceylon man pages for Linux ( may be UNIX ). I was create two man pages but there are not completed . How I'm add that man pages to debian package ?

The Java 8 Developer Preview has been released. It would be good if ceylon could be run even if somebody if somebody had updated their Java to try the developer preview

See https://groups.google.com/d/topic/ceylon-dev/L87gYzVHJdg/discussion

The NOTICE file included with the dist need updating for M4, to include the license for all the transitive dependencies needed for the command line tools

Quoting @quintesse

we should have a special "dist" build that just pulls everything to a local folder instead of using sibling projects

Presumably it should clone repos if required (otherwise pull) into subdirectories. This would make it much simpler to know that you had a fully up to date build.

Sure we can speed that up :)

If we add the plugin scripts from ceylon.formatter to the distribution, ceylon format should Just Work™ – the required modules should be downloaded from the Herd on first run.

It should be possible to rm -rf ~/.ceylon/repo then execute a ant siblings package (or similar) and have the build work. Right now it doesn't because:

1. The ceylon-dist/build.xml doesn't specify the dependencies
2. Most of the targets executed in siblings projects (in ceylon-dist/build.xml) use the dist target.

Put together this means we're happily building ceylon-compiler (in ceylon-dist) using a random version of CMR (or whatever dependency) from the last time we happened to run the publish target in CMR, because ceylon-compiler compiles against the published CMR jar.

Before I fix this I want to know whether the distinction between 'publish' and 'dist' really needs to be kept.

This issue is to track the compatibility requirements for Ceylon 1.2.1. This issue assumes that 1.2.1 will be binary compatible with 1.2.0, so the problem is "just" about making the toolset use the 1.2.1 artifacts, rather than complaining about mismatched versions.

The specific requirements are:

1. We need to be able to run a "1.2.0 module" (that is, a module compiled using the 1.2.0 toolset) using a 1.2.1 distribution.
2. We need to gracefully fail to run a 1.2.2 module with a 1.2.1 distribution.

@davidfestal has a requirement to be able to compile a 1.2.0 module using a 1.2.1 compiler. Specifically his requirement seems to relate to the implicit dependency on ceylon.language that gets added to compiled modules.

This should include merging master and branches and rewritiing commit messages to change #NNN into `ceylon/ceylon-xxxx#NNN´.

We now urgently need an Ant build that packages up the:

1. typechecker, compiler, language module, and runtime, along with
2. working cross-platform ceylonc, ceylond, and ceylon shell scripts,
3. some kind of install script for creating a default repo containing the language module, and
4. an examples directory containing a hello world module, with
5. a README with info on how to compile and run the module, and where to go (the website) for documentation.

This is now the main missing piece blocking an M1 release.

So people can use Ceylon from Java Maven projects.

The ceylondoc was generated without the base URL of ceylon.language, so none of the language module types are linked :-(

We really need tests for the samples which get run regularly. Finding errors during release is too late.

I just tried building a distrib and got that:

generate-tooldoc:
     [exec] ceylon doc-tool: Fatal error: Method public void com.redhat.ceylon.compiler.js.
     [exec] CeylonRunJsTool.setNodeExe(java.lang.String) is annotated with @Argument and
     [exec] @Description: Arguments should be documented in the class-level @Description
     [exec] com.redhat.ceylon.common.tool.ModelException: Method public void com.redhat.ceylon.compiler.js.CeylonRunJsTool.setNodeExe(java.lang.String) is annotated with @Argument and @Description: Arguments should be documented in the class-level @Description
     [exec]     at com.redhat.ceylon.common.tool.ToolLoader.buildArgument(ToolLoader.java:377)
     [exec]     at com.redhat.ceylon.common.tool.ToolLoader.addMethod(ToolLoader.java:179)
     [exec]     at com.redhat.ceylon.common.tool.ToolLoader.loadModel(ToolLoader.java:117)
     [exec]     at com.redhat.ceylon.common.tool.ToolLoader.loadToolModel(ToolLoader.java:83)
     [exec]     at com.redhat.ceylon.tools.help.CeylonDocToolTool.loadModels(CeylonDocToolTool.java:162)
     [exec]     at com.redhat.ceylon.tools.help.CeylonDocToolTool.run(CeylonDocToolTool.java:152)
     [exec]     at com.redhat.ceylon.tools.CeylonTool.run(CeylonTool.java:216)
     [exec]     at com.redhat.ceylon.tools.CeylonTool.bootstrap(CeylonTool.java:185)
     [exec]     at com.redhat.ceylon.tools.CeylonTool.main(CeylonTool.java:159)

Looks like a job for @tombentley or @chochos

Turn as much of the JARs we have in the distribution lib folder into proper modules

There's at least one guy on Herd, but I'm sure we have more.

On, or shortly before, 11 April the size of the dist jar grew from ~14M to ~22M and it currently stands at ~25M. We need to find out what caused that and figure out how we can make the download smaller.

I downloaded yesterday, ceylon-0.2, and today tried to run the ceylonc on my WindowsXP system from the command line.

I have the next error message:

C:\ceylon-0.2\bin>ceylonc -help
"Cannot find java.exe at C:\dev\jdk1.7.0_03\jre7 \bin\java.exe, check that your
JAVA_HOME variable is pointing to the right place"

I revised *.bat files in bin directory and in java.bat file in line number 32 I found one unnecessary white space:

28 ::
29 :: get the javahome
30 ::
31 FOR /F "usebackq skip=2 tokens=3*" %%A IN (REG QUERY "%JAVA_CURRENT%" /v JavaHome 2^>nul) DO (
32 set "JAVA_HOME=%%A %%B"
33 )

need: set "JAVA_HOME=%%A%%B"

after this change ceylonc is working successfully.

I install ceylon nightly build on two boxes with different path to the distribution. And I can't build my project on second box if it was create with first box. Because "ceylon.home" property hardcoded into ant project as absolute system path. Also I cant find com.redhat.ceylon.ant-0.5.jar on my system anywhere. But its work with ceylon-ant.jar just fine.

Please, replace following code:

<property name="ceylon.home" value="@[ceylon.home]"/>
<property name="ceylon.ant.lib" value="${ceylon.home}/repo/com/redhat/ceylon/ant/@[ceylon.version.number]/com.redhat.ceylon.ant-@[ceylon.version.number].jar"/>

with this one

<property environment="env"/>
<fail unless="env.CEYLON_HOME" message="Environment variable $CEYLON_HOME isn't set."/>
<property name="ceylon.home" value="${env.CEYLON_HOME}"/>
<property name="ceylon.ant.lib" value="${ceylon.home}/lib/ceylon-ant.jar"/>

We need to update txtmark across all projects.

• Add Ant task to copy info files from ../ceylon-spec/build/$lang/info to ../ceylon-dist/dist/doc/info
• Add commands to install the info file globally to the redhat/ and debian/ scripts (install-info)

As per this mailing list topic: https://groups.google.com/d/topic/ceylon-users/Xgt6aZrLvo4/discussion

Hello,

I'm trying to build the M5 unstable package on Windows 7 64 bits, but the Ant process fails. I first execute ant local get-code, then I do ant local package but the following error is raised:

ceylon.language.java:

BUILD FAILED
E:\Tools\ceylon\ceylon-dist\build.xml:302: The following error occurred while executing this line:
E:\Tools\ceylon\ceylon-dist\projects\ceylon.language\build.xml:181: Failed to find 'ceylon' executable in E:\Tools\ceylon\ceylon-dist\projects\ceylon.language\..\ceylon-dist\dist\bin\ceylon.bat

Total time: 29 seconds

So far we've made up the release process as we've gone along, and @FroMage is good at remembering all the things which need to be done. but one day he might not be available. So we need a simple checklist of all the things which need to be done to do a release.

We should get @gavinking to check the list once @FroMage has written it too.

In Homebrew/legacy-homebrew#24176 it was suggested we change the Java 7 caveat into a Requirement as per Homebrew/legacy-homebrew#24105.

We also should manage man pages.

This is for @gavinking as he has OSX and brew.

Several people complained that building Ceylon is quite complex, what with the myriad of sub-projects we have. We should think about how to address this, as we don't want to scare away contributors.

It seems that GitHub doesn't recommend using Git protocol anymore:

https://help.github.com/articles/which-remote-url-should-i-use

I guess that's because Git protocol is usually blocked by firewalls in corporate environments.

Maybe we should replace "git://" with "https://" in build.xml.

This makes debugging the CLI easier.

edit: this is a dupe of ceylon/ceylon-compiler#1861 - closed this one.

I have a project, in the subdirectory optimizer/ of the git repository https://github.com/lahwran/tree-of-life, that has a module optimizer/source/treeoflife/optimize/, and a couple of jar-imported modules in optimizer/modules/org/uncommons/maths and optimizer/modules/org/uncommons/watchmaker.

treeoflife.optimize depends on watchmaker and java 8, watchmaker depends on maths and java 8, and maths depends on java 8.

After compiling treeoflife.optimize, I wanted to copy it and its dependencies into a new repository, so I attempted to do so with ceylon copy; it said it copied treeoflife, but did not copy any org.uncommons or ceylon core stuff:

$ ceylon copy --out test --with-dependencies treeoflife.optimize/0.0.1
Module treeoflife.optimize/0.0.1 [1/1] Ok
$ find test
test
test/treeoflife
test/treeoflife/optimize
test/treeoflife/optimize/0.0.1
test/treeoflife/optimize/0.0.1/treeoflife.optimize-0.0.1.car
test/treeoflife/optimize/0.0.1/treeoflife.optimize-0.0.1.car.sha1
$

To double-check, I tried getting treeoflife.optimize's dependencies with ceylon info, and that didn't print any dependencies:

$ ceylon info --dependency-depth=all treeoflife.optimize/0.0.1
Name:        treeoflife.optimize
Version:     0.0.1
Artifacts:   Sources
Available:   On local system
Origin:      /Users/lahwran/todo_tracker/todo_tracker/optimizer/modules
$

I unzipped the car and opened up the pom.xml; it definitely refers to watchmaker:

$ unzip -d dumped_car modules/treeoflife/optimize/0.0.1/treeoflife.optimize-0.0.1.car
$ cat dumped_car/META-INF/maven/treeoflife/optimize/pom.xml
<?xml version="1.0" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>treeoflife</groupId>
 <artifactId>optimize</artifactId>
 <version>0.0.1</version>
 <name>treeoflife.optimize</name>
 <dependencies>
  <dependency>
    <groupId>ceylon</groupId>
    <artifactId>collection</artifactId>
    <version>1.1.0</version>
  </dependency>
  <dependency>
    <groupId>ceylon.interop</groupId>
    <artifactId>java</artifactId>
    <version>1.1.0</version>
  </dependency>
  <dependency>
    <groupId>ceylon</groupId>
    <artifactId>time</artifactId>
    <version>1.1.0</version>
  </dependency>
  <dependency>
    <groupId>org.uncommons</groupId>
    <artifactId>watchmaker</artifactId>
    <version>0.7.1</version>
  </dependency>
  <dependency>
    <groupId>org.uncommons</groupId>
    <artifactId>maths</artifactId>
    <version>1.2.1</version>
  </dependency>
 </dependencies>
</project>
$

So I tried getting the imported watchmaker jar's info. that worked:

$ ceylon info --dependency-depth=all org.uncommons.watchmaker/0.7.1
Name:        org.uncommons.watchmaker
Version:     0.7.1
Artifacts:   JVM (legacy), MODULE.PROPERTIES
Available:   On local system
Origin:      /Users/lahwran/todo_tracker/todo_tracker/optimizer/modules
Dependencies (up to depth ∞):
  shared java.base/8
  shared org.uncommons.maths/1.2.1
$

You can view all the files used here in the online git repo.

Why doesn't this work?