Module version upgrade obscurity

[Alex Aguinore]

Hi!

This question is somewhat related to https://groups.google.com/forum/#!topic/ceylon-users/nZcQ__zAzHs but is more general. Suppose we have common library module org.example.commonModule "1.0.0" and, say, three another library modules depends on it (org.example.libraryA "1.0.0", org.example.libraryB "1.0.0", org.example.libraryC "1.0.0"). Overall, we have 4 projects, each with 3-10 modules, depend on that libraries. We now update commonModule to version 1.0.1 and must manually change every imports in libraries A, B and C, change their versions to 1.0.1 too and change imports of libraries in projects with all that download sources from git, update version, push it back, compile and redeploy. We tried to automatize it someway with grep scripts and teamcity but I don't think it's most straightforward way. Another thought is to forget that imports until we need use new functionality added in 1.0.1 but there may be major bugfixes in updates too.
What can you suggest?

[Gavin King]

> We now updatecommonModule to version 1.0.1 and must manually change every imports in libraries A, B and C, change their versions to 1.0.1 too and change imports of libraries in projects with all that download sources from git, update version, push it back, compile and redeploy.

No no no no, please don't do this! That's crazy!

Please use overrides.xml instead.

> --
> 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 https://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ceylon-users/5c1e036a-4557-4844-98d4-8e4c80ecadbb%40googlegroups.com.
> 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

[Gavin King]

Note that Ceylon module system was originally architected around the
notion of modules and *assemblies*. In fact we never actually
specified or implemented assemblies, and overrides.xml currently fills
the role they were originally meant to take.

For the future, what we've decided to do instead of assemblies is to
essentially make every module a mini-"assembly" and let it override
dependencies of its dependencies. So each module would be able to do
the equivalent of what overrides.xml currently does at the
whole-program (i.e. assembly) level. And these overrides would be
specified in the module descriptor.

We still have to converge on the precise syntax for this, however. The
discussion is here:

https://github.com/ceylon/ceylon/issues/5955

[Alex Aguinore]

So we will have line "import org.example.libraryA "1.0.0"" in module.ceylon and something like

<replace groupId="org.example" artifactId="libraryA" version="1.0.0">
    <with groupId="org.example" artifactId="libraryA" version="1.0.1"/>
</replace>

in overrides.xml, will we?
If so, I have 2 questions:
1. How could I know about overrides.xml and that the import written in module.ceylon is not the import used in program?
2. How can we share overrides.xml between two developers without problems described in question 1? One developer can easy forget about overrides and replace version right in module.ceylon.

[Gavin King]

I believe you can just use a toplevel <set> for this, but check with Stef.

I have never used <replace> and TBH I'm not really sure what it's purpose is.

> https://groups.google.com/d/msgid/ceylon-users/2b980a4d-4451-4573-a046-2bd4ce107968%40googlegroups.com.

[Alex Aguinore]

OK, let it be <set>, but still info in module.ceylon will lies to us about imported version.

[Gavin King]

Well, no, it correctly documents what version of the library the
module was developed and tested and compiled with.

I don't see what the problem here is.

> https://groups.google.com/d/msgid/ceylon-users/6cf12118-0bae-47d8-b4a1-68256207cfba%40googlegroups.com.

[Alex Aguinore]

Can you provide an example, please. I think, we don't understand each other.

[Alex Aguinore]

Hello. We faced similar problem again and I still ask you to provide an example of using overrides.xml file. Please give me a link to real world usage of that feature. Thank you.

[Stephane Epardaud]

There are plenty of examples, but using `set` should work for you. What issue do you have exactly?

On 12 October 2016 at 11:50, Alex Aguinore <agui...@gmail.com> wrote:

Hello. We faced similar problem again and I still ask you to provide an example of using overrides.xml file. Please give me a link to real world usage of that feature. Thank you.

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to ceylon...@googlegroups.com.
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/80060112-64ca-46fd-9e18-11a1a80a3b4b%40googlegroups.com.

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

--

Stéphane Épardaud

[Alex Aguinore]

The issue with module versions synchronous upgrade. I think that using overrides.xml file adds obscurity to project structure and I want to see how it works in real world. What are module.ceylon files, what contains overrides.xml, where to put it and so on.

[Lucono]

Hi Alex,

Here's an example usage of an overrides.xml file in a project:

https://github.com/lucono/ceylon-springboot-demo/blob/master/overrides.xml

In this example, it's being used to override transitive maven dependencies of the module/project as shared, but could have been used to override versions as well like in your use-case.

Thanks.