Problem on using this project about adl2-core

[da-baranov]

I've also faced errors trying to warm up the java-libs project. Try the following:

1. Take the latest java-libs project version from git repository, then refresh all the maven dependencies. That'll force loading required version of antlr which you are probably do not have yet.
2. Disable maven test mode (some archetypes do not pass build tests and I don't know why)
3. Rebuild/install java-libs and try build and run your project again

[markopi]

adl2-core libraries have their own dependencies, you need to include those as well.

If go to adl2-core project and run:

    mvn dependency:tree

you will get a list of all dependencies required:

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ adl-parser ---
[INFO] org.openehr.adl2-core:adl-parser:jar:1.2.1-SNAPSHOT
[INFO] +- org.openehr.adl2-core:model-am:jar:1.2.1-SNAPSHOT:compile
[INFO] |  +- org.openehr.adl2-core:model-rm:jar:1.2.1-SNAPSHOT:compile
[INFO] |  \- commons-lang:commons-lang:jar:2.6:compile
[INFO] +- com.google.guava:guava:jar:18.0:compile
[INFO] +- com.google.code.findbugs:jsr305:jar:2.0.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.4.3:test
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.3:test
[INFO] |  \- com.fasterxml.jackson.core:jackson-annotations:jar:2.4.0:test
[INFO] +- org.antlr:antlr4-runtime:jar:4.5.1:compile
[INFO] +- commons-io:commons-io:jar:2.4:compile
[INFO] +- org.testng:testng:jar:6.8.8:test
[INFO] |  +- org.beanshell:bsh:jar:2.0b4:test
[INFO] |  \- com.beust:jcommander:jar:1.27:test
[INFO] \- org.easytesting:fest-assert:jar:1.4:test
[INFO]    \- org.easytesting:fest-util:jar:1.1.6:test

All of these jars (except those that end with :test) must be included in the project.

But manipulating transitive dependencies is quite awkward and error prone, so I suggest you instead create a new maven project and add adl-parser as a dependency.

Then you can use an eclipse plugin such as m2e to update dependencies from maven into eclipse project.

Also, the documentation is out of date: AdlDeserializer no longer takes any parameters.

[avounotr]

Thanks for your answers!

I tried to use what you tell me but I don't understand exactly what you told me, so I download every .jar file and that works fine.
However, the readme says (String adl = ...; // read a .adls file into a string).
I do this:

String adl = "";
try (BufferedReader br = new BufferedReader(new FileReader("adl-test-entry.archetype_desc_missing_purpose.test.adl")))
{
String sCurrentLine;

        while ((sCurrentLine = br.readLine()) != null) {
            System.out.println (sCurrentLine);
            adl += sCurrentLine;
        }

    } catch (IOException e) {
        e.printStackTrace();
    } 

But it does not work good and I have this error: "1:77 mismatched input '[' expecting {, '.', '-', LANGUAGE, CONCEPT, DESCRIPTION, SPECIALISE, DEFINITION, ANNOTATIONS, TERMINOLOGY}"

Can you help me with that?

Thank you!

[markopi]

Adl parser no longer supports adl 1.4. You need to use a file containing adl 2.0. Those have .adls extension.

Also, you have a bug reading in the file contents: you don't separate lines with the newline character. Just use something like:

String adl = new String(Files.readAllBytes(Paths.get("file.adls")), StandardCharsets.UTF_8);

[avounotr]

Thank you!

[ppazos]

We should keek adl 1.4 support at the parser level, since most projects are
working with that version. Selection of parser can be done just by
analyzing the first line of the adl file. I don't think removing 1.4
support is a good strategy.

What do others think?
On Sep 25, 2015 6:46 AM, "markopi64" [email protected] wrote:

Adl parser no longer supports adl 1.4. You need to use a file containing
adl 2.0. Those have .adls extension.

Also, you have a bug reading in the file contents: you don't separate
lines with the newline character. Just use something like:

String adl = new String(Files.readAllBytes(Paths.get("file.adls")), StandardCharsets.UTF_8);

—
Reply to this email directly or view it on GitHub
#8 (comment).

[wolandscat]

You can convert to ADL2 with the ADL Workbench. I think this project is trying to be a 'clean' ADL2 project - ADL 2 is cleaner and more systematic. There is an ADL 1.4 parser in the java-reference project - not sure if it could be integrated at tool level...

[markopi]

Both ADL and AOM had some incompatible changes in version 2.0. Therefore ADL2 requires both a different grammar parser and target AOM than ADL1.4, so it is best to keep one parser targeting a single version.

The scope of adl2-core is ADL2. The previous support for ADL1.4 was doing on-the-fly conversion of ADL1.4 into AOM2, which means that a parsed ADL1.4 could only be serialized into ADL2.
Conversion between versions is better done explicitly by a dedicated tool.

[ppazos]

Not sicusing the target of adl2, but what you said about not supporting adl
1.4

I meant to have 2 parsers, not one targeting two versions. Which parser to
use can be determined by analyzing juat the first line in the adl text.

Image viewer software does this, the first bytes in the file tells the soft
if it is a jpg or png, the the right decoder is executed.
On Sep 28, 2015 4:27 AM, "markopi64" [email protected] wrote:

Both ADL and AOM had some incompatible changes in version 2.0. Therefore
ADL2 requires both a different grammar parser and target AOM than ADL1.4,
so it is best to keep one parser targeting a single version.

The scope of adl2-core is ADL2. The previous support for ADL1.4 was doing
on-the-fly conversion of ADL1.4 into AOM2, which means that a parsed ADL1.4
could only be serialized into ADL2.
Conversion between versions is better done explicitly by a dedicated tool.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[markopi]

ADL 1.4 files have a diferent extension (.adl) than ADL2 (.adls), so choosing the right parser does not require looking at the ADL content. If choosing the parser based on content is still needed, one can write a simple parser just for the header and choose the actual ADL parser based on that.

This project only deals with ADL2 files, like libpng only deals with png files. Parser selection for a particular ADL version can always be done by a higher level project.

[ppazos]

I don't think thatbis correct. I remember old ADLWB generating adls for 1.4.

Ok, got it, so I think the comment about "not longer supporting adl 1.4"
was incorrect, the one that initiated my argument. I mean, if this is for
adl2 only, adl 1.4 support was NOT removed, it was never there.

Sorry for the missunderstanding.
On Sep 29, 2015 5:39 AM, "markopi64" [email protected] wrote:

ADL 1.4 files have a diferent extension (.adl) than ADL2 (.adls), so
choosing the right parser does not require looking at the ADL content. If
choosing the parser based on content is still needed, one can write a
simple parser just for the header and choose the actual ADL parser based on
that.

This project only deals with ADL2 files, like libpng only deals with png
files. Parser selection for a particular ADL version can always be done by
a higher level project.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[borutf]

Pablo, just check the branches. You'll find one called "adl14-compatible" ->
https://github.com/openEHR/adl2-core/tree/adl14-compatible

ADL 1.4 support is right there. Is just not part of the main branch.

We discussed long with Thomas and agreed to have a puristic aproach to ADL2. This makes easier to keep a clean parser, grammar, unit tests, ... instead of a mixed mode with relaxed rules to keep both specs compatible to some degree.

[ppazos]

Perfection, thanks for the info!

On Tue, Sep 29, 2015 at 10:38 AM, borutf [email protected] wrote:

Pablo, just check the branches. You'll find one called "adl14-compatible"
->
https://github.com/openEHR/adl2-core/tree/adl14-compatible

ADL 1.4 support is right there. Is just part of the main branch.

We discussed long with Thomas and agreed to have a puristic aproach to
ADL2. This makes easier to keep a clean parser, grammar, unit tests, ...
instead of a mixed mode with relaxed rules to keep both specs compatible to
some degree.

—
Reply to this email directly or view it on GitHub
#8 (comment).

Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
http://cabolabs.com/
http://www.cabolabs.com
[email protected]