Ceylon maven plugin

[Julien Viet]

Hi,

for Vert.x needs I started a maven-ceylon-plugin that other may find useful for integrating Ceylon in Maven toolchain : https://github.com/vietj/ceylon-maven-plugin

it is snapshot at the moment but it is deployed in Sonatype snapshot repository for consuming. (so you need to add this repository or build it yourself).

-- 
Julien Viet
www.julienviet.com

[Gavin King]

Good idea, thanks, Julien.

Eventually we should probably include this in our distribution.

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-users...@googlegroups.com.
> To post to this group, send email to ceylon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ceylon-users/etPan.5633e182.7c3dbd3d.3407%40Juliens-MacBook-Pro-2.local.
> For more options, visit https://groups.google.com/d/optout.



--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[Julien Viet]

No need to include it, this plugin should be deployed to Maven Central (at the moment it is in Sonatype snapshot repository) and globally available.

-- 
Julien Viet
www.julienviet.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAP7PoCcE7BmAUA0nxQid4mmM6ZiTKK3yVOb0ejHMtg60wOb17A%40mail.gmail.com.

[Julien Viet]

I’ve done quite some work on the plugin and I believe now it’s quite usable and documented.

It performs three basic tasks (which are sufficient for my needs).

- import maven dependencies in a Ceylon repository

- compile Ceylon source code

- run a Ceylon module

later I might add a test goal but that requires more integration work.

I’ll deploy it to Maven Central in a couple of weeks.

-- 
Julien Viet
www.julienviet.com

[Tako Schotanus]

Nice!

-Tako

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/etPan.5638eb88.3dc240fb.3407%40Juliens-MacBook-Pro-2.local.

[Gavin King]

That sounds great. Thanks for working on this!

But note: if it's not documented anywhere, it may as well not exist....

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-users...@googlegroups.com.
> To post to this group, send email to ceylon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ceylon-users/etPan.5638eb88.3dc240fb.3407%40Juliens-MacBook-Pro-2.local.
>
> For more options, visit https://groups.google.com/d/optout.

[Renato Athaydes]

Hi Julien,

Do you mind if I take some of your code and make a Gradle plugin?

Renato

[John Vasileff]

Renato,

If you’re interested, I have a working but unfinished gradle plugin here:

https://github.com/jvasileff/ceylon-dart/tree/master/buildSrc

It would be great to have others help hack away at it!

I’ve found that requirements for a Ceylon plugin are a bit different that those of Java and other JVM languages, since Ceylon has built in dependency management. So the approach I’ve taken is to consider *module repositories* sort of like class paths, because that is the finest grained level of control available outside of the compiler. Tasks such as “compileCeylon” and "ceylonDoc”  can explicitly specify repositories. But they *also* inherit repositories from tasks they depend on. So, if “ceylonDoc” depends on “compileCeylon”, it *automatically* gets all of the compile tasks’s repositories, plus the compile task’s *output* repository.

I think this is a good approach (it’s worked well so far). But the plugin does need some more work.

John

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/2364d5b5-cfed-4aa5-a3e5-d5e321d0784e%40googlegroups.com.

[Renato Athaydes]

Hi!

I will have a look at what you have in your plugin! Thanks for sharing.

Let me explain to you and others what I am thinking so we can try to find the best way to proceed :)

Ceylon's mechanism to resolve Maven/Ivy/... dependencies is very poor and does not resolve transitive dependencies defined in the pom. So it seems appropriate to me to use Gradle's powerful dependency management as a complement to Ceylon's, so that you can depend on anything in Maven Central, JCenter and so on in your Ceylon project. In my view, that would be a pretty good reason to use Gradle with Ceylon, even considering Ceylon can handle "some" dependencies out-of-the-box.

So most of the work, I guess, would be to let Gradle manage Java dependencies, then before calling "ceylon compile", adding all dependencies resolved by Gradle to the Ceylon local repo. I've implemented something like this in my osgi-run plugin, that's why I think I can implement this easily for Ceylon. Do you think this would work well?

Would your plugin benefit from such approach or it is not compatible (asking this before looking into it myself)?

Renato

Em terça-feira, 3 de novembro de 2015 20:21:21 UTC+1, John Vasileff escreveu:

Renato,

If you’re interested, I have a working but unfinished gradle plugin here:

https://github.com/jvasileff/ceylon-dart/tree/master/buildSrc

It would be great to have others help hack away at it!

I’ve found that requirements for a Ceylon plugin are a bit different that those of Java and other JVM languages, since Ceylon has built in dependency management. So the approach I’ve taken is to consider *module repositories* sort of like class paths, because that is the finest grained level of control available outside of the compiler. Tasks such as “compileCeylon” and "ceylonDoc”  can explicitly specify repositories. But they *also* inherit repositories from tasks they depend on. So, if “ceylonDoc” depends on “compileCeylon”, it *automatically* gets all of the compile tasks’s repositories, plus the compile task’s *output* repository.

I think this is a good approach (it’s worked well so far). But the plugin does need some more work.

John

On Nov 3, 2015, at 1:56 PM, Renato Athaydes <ren...@athaydes.com> wrote:

Hi Julien,

Do you mind if I take some of your code and make a Gradle plugin?

Renato

Em sexta-feira, 30 de outubro de 2015 22:30:48 UTC+1, Julien Viet escreveu:

Hi,

for Vert.x needs I started a maven-ceylon-plugin that other may find useful for integrating Ceylon in Maven toolchain : https://github.com/vietj/ceylon-maven-plugin

it is snapshot at the moment but it is deployed in Sonatype snapshot repository for consuming. (so you need to add this repository or build it yourself).

-- 
Julien Viet
www.julienviet.com

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.

To post to this group, send email to ceylo...@googlegroups.com.

[John Vasileff]

Well, I’d much prefer to see Ceylon’s maven support improved/fixed…

But, to your question, I’ve used gradle to do what you suggest as a “first” step by creating a fat-jar with a bunch of Maven dependencies, then publishing the fat-jar as a Ceylon module. From that point on, everything works as usual - the fat-jar is just imported into Ceylon like any other module.

This approach *is* compatible with my existing plugin code (or any other Ceylon build process), because it’s really just two separate steps.

Of course, the fat-jar approach only works for applications - modularity is lost. In other words, if you use a fat-jar for a library that you want to share, I can’t necessarily use that library if I also need my own fat-jar for my application, perhaps with some common dependencies.

An example where I’ve done this here: https://github.com/jvasileff/csm-petstore/blob/master/build.gradle

John

p.s. I also tried long ago to “fix up” maven modules and package them individually as Ceylon modules, but I *don’t* believe that will ever work and ultimately ends in frustration.

To post to this group, send email to ceylon...@googlegroups.com.

Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/94b2b60c-12d2-4c52-87d5-ab177a8c999a%40googlegroups.com.

[Renato Athaydes]

Just to throw the idea: what if we installed the dependencies downloaded by Gradle in the Ceylon repo as separate modules and auto-generated the Ceylon module file that declares all the dependencies, merging this with the user-provided module file before passing it on to the ceylon compiler (without the user needing to care  about all this, of course)?

[Renato Athaydes]

Another thought: dependency management is pretty difficult to do right, I am not sure Ceylon should invest time to try to do this when tools like Gradle already did all the hard work and support conflict resolution, multiple repo formats and probably solved many other issues along the way (and will continue to improve quickly) related to that... Even Maven still gets it wrong (random dependency resolution being a common source of "works only on my machine" (unless you're really careful with your poms)... so I think that while it's really convenient to have the Ceylon compiler download Ceylon dependencies without any work on my part, for complex projects you'll need a build tool anyway (not only for Java dependency resolution, also for a myriad of issues that build tools solve, but let's not go there).

[Gavin King]

Do you know about overrides.xml?

Sent from my iPhone

On 03 Nov 2015, at 21:35, Renato Athaydes <ren...@athaydes.com> wrote:

Another thought: dependency management is pretty difficult to do right, I am not sure Ceylon should invest time to try to do this when tools like Gradle already did all the hard work and support conflict resolution, multiple repo formats and probably solved many other issues along the way (and will continue to improve quickly) related to that... Even Maven still gets it wrong (random dependency resolution being a common source of "works only on my machine" (unless you're really careful with your poms)... so I think that while it's really convenient to have the Ceylon compiler download Ceylon dependencies without any work on my part, for complex projects you'll need a build tool anyway (not only for Java dependency resolution, also for a myriad of issues that build tools solve, but let's not go there).

--

You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/df085a2a-5c68-4442-a64c-5d67da575d66%40googlegroups.com.

[Renato Athaydes]

No. Please tell me.

[Julien Viet]

I hope Java 9 will clear all this mess and make everybody agree :-)

-- 
Julien Viet
www.julienviet.com

On 3 Nov 2015 at 21:35:06, Renato Athaydes (ren...@athaydes.com) wrote:

Another thought: dependency management is pretty difficult to do right, I am not sure Ceylon should invest time to try to do this when tools like Gradle already did all the hard work and support conflict resolution, multiple repo formats and probably solved many other issues along the way (and will continue to improve quickly) related to that... Even Maven still gets it wrong (random dependency resolution being a common source of "works only on my machine" (unless you're really careful with your poms)... so I think that while it's really convenient to have the Ceylon compiler download Ceylon dependencies without any work on my part, for complex projects you'll need a build tool anyway (not only for Java dependency resolution, also for a myriad of issues that build tools solve, but let's not go there).

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/df085a2a-5c68-4442-a64c-5d67da575d66%40googlegroups.com.

[Renato Athaydes]

I hope Java 9 will clear all this mess and make everybody agree :-)

But then you can already feel disappointed : they dropped versions from the module system and explicitly stated that version resolution should be a concern of build tools. So the mess will probably continue forever in the Java world. All we can do is workaround the root of the problem (or run our code in OSGi - will experiment with taking Ceylon "bundles" and mixing them with some Java bundles to see what happens soon).

Source: http://openjdk.java.net/projects/jigsaw/spec/reqs/02#version-selection

[Stephane Epardaud]

Have you tried compiling and running with --flat-classpath? That's new in 1.2 and in theory should behave exactly like Maven, except for version conflicts.

--

You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/4763bada-0788-4d00-b35c-14b3f531f49c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Stéphane Épardaud

[Gavin King]

It's documented here.

    http://ceylon-lang.org/documentation/1.2/reference/repository/overrides/

But you should definitely also look at the new commandline options that Stef mentioned above.

[Renato Athaydes]

Ok, thanks for the pointers... I will try both options and see what works... but looks to me that the overrides.xml file is primary candidate for auto-generation by Gradle! Does the IDE recognizes it (adding modules declared in the overrides.xml file to the Eclipse build path)?

If not, would that be terribly hard to add?

Regards,

Renato

[David Festal]

Le 4 nov. 2015 19:30, "Renato Athaydes" <ren...@athaydes.com> a écrit :
>
> Ok, thanks for the pointers... I will try both options and see what works... but looks to me that the overrides.xml file is primary candidate for auto-generation by Gradle! Does the IDE recognizes it (adding modules declared in the overrides.xml file to the Eclipse build path)?

Yes, it's fully integrated and taken in account inside the IDE. And I use it heavily to tweak the OSGI dependencies in the Ceylon IDE itself (since it's now both a Plugin project and a real Ceylon project)

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/fce69c9a-2fa2-405b-93b9-4eabe96d55a0%40googlegroups.com.

[Gavin King]

The IDE does support overrides.xml.

Look at Project > Properties > Ceylon Build > Module Repositories.

But I'm not sure if that's exactly what you're asking.

> https://groups.google.com/d/msgid/ceylon-users/fce69c9a-2fa2-405b-93b9-4eabe96d55a0%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Renato Athaydes]

I am trying to get ceylon to use Maven dependencies... it seems to work initially, but I am having trouble getting log4j (just as an example) to work... even using --flat-classpath.

I have this module declaration:

native("jvm")
module com.athaydes.maven "1.0.0" {
    import java.base "8";
    import "org.apache.logging.log4j:log4j-api" "2.4.1";
    import "org.apache.logging.log4j:log4j-core" "2.4.1";
}

Now, when I run this code:

import org.apache.logging.log4j {
    Logger,
    LogManager
}
import java.lang {
    Thread
}

Logger logger = LogManager.getLogger(`class String`);

"Run the module `com.athaydes.maven`."
shared void run() {
    logger.info("Hello Maven!");
    Thread.sleep(1000);
}

I get this error:

ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...

I added the Thread.sleep() to see if that could be because log4j's asynchronous appender didn't have time to flush to output, but that's not the case.

I tried running with the CLI and IDE, tried using "ceylon compile --flat-classpath ...", tried adding a class from the log4j-core jar to "force" it to be in the classpath, and still didn't work.

Any ideas?

Can I "see" what's in the classpath somehow?

Renato

[John Vasileff]

FWIW, your example worked for me when disabling classloader isolation (it still needs a config file, but that is to be expected.)

$ ceylon run --flat-classpath simple

ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.

John

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/5036374f-d372-4244-8e2a-e3eb57946760%40googlegroups.com.

[Renato Athaydes]

Ah! You know, at this time of the night all I saw was some warning... didn't notice it was about the config file when I passed the --flat-classpath option :( and not about the jar not being found!

Thanks for noticing!

I will continue with my experiments now!!

Renato

--
You received this message because you are subscribed to a topic in the Google Groups "ceylon-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ceylon-users/zQvP4MOoh-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ceylon-users...@googlegroups.com.

To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/43E0BFC4-6BAF-4383-92DB-4A71B6FE2B71%40vasileff.com.

[Renato Athaydes]

Where to put the log4j2.xml file? I thought it was in the "resource" folder but that doesn't work...

2015-11-04 21:12 GMT+01:00 John Vasileff <jo...@vasileff.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "ceylon-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ceylon-users/zQvP4MOoh-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ceylon-users...@googlegroups.com.

To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/43E0BFC4-6BAF-4383-92DB-4A71B6FE2B71%40vasileff.com.

[Tako Schotanus]

I don't know where it should be put Renato, but when you said "in the resource folder" I wanted to make sure that you know how that works.

Basically it's the same as a "source" folder, so if you want a resource file for project com.example.foo to be included in the generated .car file you need to put it in the "./resource/com/example/foo" folder.

It will then be included inside the .car file next to the class files (so in a folder "com/example/foo" inside the .car file).

There's a special trick if you want to include resource files in the _root_ of the .car file: you put them in "./resource/com/example/foo/ROOT/"

Not sure if that will help you any.

-Tako

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAPy%2BqKK97kE3gnXwDVWGp%2BqP-M3UVXPSXEOS%2B7Qe91w8yfynbQ%40mail.gmail.com.

[Renato Athaydes]

Yep, that's exactly what I needed!

So, for anyone using log4j, put the log4j file in:

resource/com/yourmodule/ROOT/log4j.xml

Thanks,

Renato

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAOJRyvoG_akJDMRN-4tnj_FFZHX8k2AXOHnydzXBfuxtrvbaAg%40mail.gmail.com.

[Tako Schotanus]

Glad I could be of help! :)

-Tako

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAPy%2BqKKZ0mL6kWYB64L38BQU5dwOkqgBFQYouJgR0o9M%2BHTx9A%40mail.gmail.com.

[Julien Viet]

Hi,

I published a new snapshot of the plugin:

1/ the compiler sources/resources configuration is simplified, no need for nested fileset declaration inside the source/resource tag, i.e

<configuration>

  <sources>

    <source>

      <directory>…</>

    </>

  </>

</>

2/ a new “doc” goal for generating documentation

cheers

-- 
Julien Viet
www.julienviet.com

On 30 Oct 2015 at 22:30:45, Julien Viet (jul...@julienviet.com) wrote:

[Gavin King]

Julien exactly how much of the command-line functionality does this support?

- Does it support compile-js?
- Does it support publishing to remote repos?
- Does it support "ceylon war"?
- Does it support "ceylon copy"?

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-users...@googlegroups.com.
> To post to this group, send email to ceylon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ceylon-users/etPan.564c24ba.109cf92e.2c7%40juliens-mbp-2.

>
> For more options, visit https://groups.google.com/d/optout.



--

[Julien Viet]

At the moment it is driven by the vertx-lang-ceylon needs. I started to write on vertx-lang-ceylon API documentation => the “doc” mojo was done last night for this purpose, etc...

Adding new goals is not hard : for example here is all it takes for the “doc” mojo https://github.com/vietj/ceylon-maven-plugin/blob/master/src/main/java/com/redhat/ceylon/maven/CeylonDocMojo.java

However writing integration tests for each mojo is a bit more tedious

- Does it support compile-js? 

not yet, jgleoj23 wants to contribute this support : https://github.com/vietj/ceylon-maven-plugin/issues/3

- Does it support publishing to remote repos? 

not it does not, but I will need that at some point when I’ll deploy all these modules.

- Does it support "ceylon war"? 

no it does not

- Does it support "ceylon copy"? 

no it does not

there should be also a “test” goal if possible that integrates ceylon.test with proper reporting in JUnit format, so the ceylon tests can be integrated with Jenkins, etc...

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAP7PoCdVTu-LQb6DTg%2B7V_bP5o9rAA8QVc12WLQszbCzVX1m-Q%40mail.gmail.com. 

[Gavin King]

OK, thanks for the info. And yeah the test goal is pretty important I suppose.

Sent from my iPhone

[Julien Viet]

Hi,

I plan to release the plugin soon in Maven Central, this means:

1/ release the Ceylon 1.2.0 jars first

2/ release a version 1.0.0 of the plugin with the actual goals

this plugin is used by vertx-lang-ceylon that will be released soon, hence the motivation.

-- 
Julien Viet
www.julienviet.com

[Gavin King]

Sounds good.

Sent from my iPhone

[Julien Viet]

here we are

http://search.maven.org/#artifactdetails%7Corg.ceylon-lang%7Cceylon-maven-plugin%7C1.2.0-beta1%7Cmaven-plugin

and the project was moved to Ceylon organization.

-- 
Julien Viet
www.julienviet.com

[Alex Aguinore]

Hello. Is there any way to compile and deploy .car file to remote nexus repo using maven?

среда, 18 ноября 2015 г., 15:11:21 UTC+3 пользователь Julien Viet написал:

[Julien Viet]

Hi,

at the moment only Ceylon repositories are supported, basically what the "ceylon tools” provides.

Visit this group at https://groups.google.com/group/ceylon-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/8f62438c-fce3-43c4-bf26-d6636e2ac7f5%40googlegroups.com.

[Alex Aguinore]

Hi, Julien!

How do you think, is it too hard to implement automatic update module.ceylon imports and their versions based on dependency added to pom.xml after mvn build or any other command?

I.e. I have added new dependency to pom.xml, run mvn build or smth and - tada! - that dependency now is added as import in module.ceylon.