| OCL jars from Maven [message #1802899] |
Mon, 18 February 2019 17:31  |
 Edouard R. Batot
Messages: 100
Registered: March 2015 |
Senior Member |
|
|
Hi folks,
I am trying to rebuild an old project and look for OCL, UML etc. jars for Maven.
I am looking, for example, to
- org.eclipse.ocl.uml 5.2.0
- org.eclipse.uml2.uml 3.1.1
- org.eclipse.core.runtime 3.1.0
Any idea where I can find these ?
Thank you,
Edouard
[edit]
What I find on Maven repository are close version (4.1 instead of 3.1 for example, and I would try to fix it, but unfortunately, even these close version show problem to download from Maven "the dependency does not exist" they say)
[Updated on: Mon, 18 February 2019 17:33] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: OCL jars from Maven [message #1826310 is a reply to message #1826190] |
Thu, 23 April 2020 10:49  |
Andrzej Wąsowski
Messages: 21
Registered: November 2019 |
Junior Member |
|
|
Ed,
I think I like the old fashioned way. I am pursuing this suggestion (thanks). I got all the plugin jars and dropped them into my gradle project. Then I asked gradle to include all of them (in desperation, I will optimize the necessary dependencies while things work). Now I tried to ways of setting up the standalone setup. With the following results.
1) If I only do
org.eclipse.ocl.pivot.utilities.PivotStandaloneSetup.doSetup()
This makes my build go through but any attempt to load an ecore instance of an OCL-annotated model gets me an error of the following kind:
+ test-00:An exception occurred while delegating evaluation of the 'C1' constraint on 'mdsebook.fsm.impl.ModelI
mpl@6b60858c{../mdsebook.fsm/test-files/test-00.xmi#/}': java.lang.NoClassDefFoundError: Could not initialize class org.
eclipse.ocl.pivot.library.oclany.OclAnyNotEqualOperation
This looks like the delegate is still not initialized?
2) So I added also the following to the above:
org.eclipse.ocl.xtext.completeocl.CompleteOCLStandaloneSetup.doSetup()
But this I am unable to compile, with the following error:
Class org.eclipse.xtext.ISetup not found
(the above message is from a Scala compiler, but the java compiler message for the same invocation is similar: 'error: can not access ISetup'). Strangely enough this error is reported a few lines below the above change. I do not really understand what is going on. I couldn't find the org.eclipse.xtext.ISetup class in any of the jar files from the OCL distribution.
3) I also tried to follow the instructions at: https://help.eclipse.org/2020-03/index.jsp?topic=%2Forg.eclipse.ocl.doc%2Fhelp%2FPivotStandalone.html
But these seem to fail compiling already on the very first line of the setup:
object OCL is not a member of package org.eclipse.ocl.pivot
Since I already took all the plugin jars I do not know where to search for the missing files.
Probably I did not get all the jars. I will keep searching, but any help in any of the three directions above would be highly appreciated. Thanks!
[Updated on: Thu, 23 April 2020 11:17] Report message to a moderator |
|
|
|
|
| Re: OCL jars from Maven [message #1826377 is a reply to message #1826364] |
Fri, 24 April 2020 07:29 |
German Vega
Messages: 104
Registered: December 2015
Location: Grenoble, France |
Senior Member |
|
|
HI Andrezj,
A couple of years ago I did exactly the same painstaking exercise you are now doing. Adding a jar at a time until I got a good classpath.
The java.lang.NoClassDefFoundError exception is because one of the superclasses of OclAnyNotEqualOperation can not be found.
The minimal list of dependencies for OCL 6.3 that I got was (I use OCL+UML so may be in your case the list might be shorter) :
-a---- 04/12/2019 16:46 151989 antlr-runtime-3.2.jar
-a---- 04/12/2019 16:46 2172168 guava-15.0.jar
-a---- 04/12/2019 16:46 710492 guice-3.0.jar
-a---- 04/12/2019 16:46 2497 javax.inject-1.jar
-a---- 04/12/2019 16:46 481535 log4j-1.2.16.jar
-a---- 04/12/2019 16:46 206568 org.antlr.runtime-3.2.0-v201101311130.jar
-a---- 04/12/2019 16:46 415047 org.apache.log4j-1.2.15-v201012070815.jar
-a---- 04/12/2019 16:46 357670 org.eclipse.emf.common-2.12.0.jar
-a---- 04/12/2019 16:46 1190945 org.eclipse.emf.ecore-2.12.0.jar
-a---- 04/12/2019 16:46 230424 org.eclipse.emf.ecore.xmi-2.12.0.jar
-a---- 04/12/2019 16:46 278989 org.eclipse.emf.edit-2.12.0.jar
-a---- 04/12/2019 16:46 40680 org.eclipse.emf.mapping.ecore2xml-2.9.0-v20150806-0404.jar
-a---- 04/12/2019 16:46 121509 org.eclipse.equinox.common-3.9.0.jar
-a---- 04/12/2019 16:46 109196 org.eclipse.equinox.supplement-1.7.0.jar
-a---- 04/12/2019 16:46 34381 org.eclipse.ocl.common-1.4.200-v20160613-1518.jar
-a---- 04/12/2019 16:46 3120018 org.eclipse.ocl.pivot-1.3.0-v20170522-1753.jar
-a---- 04/12/2019 16:46 241562 org.eclipse.ocl.pivot.uml-1.3.0-v20170613-1432.jar
-a---- 04/12/2019 16:46 549893 org.eclipse.ocl.xtext.base-1.3.0-v20170522-1753.jar
-a---- 04/12/2019 16:46 365309 org.eclipse.ocl.xtext.completeocl-1.3.0-v20170522-1753.jar
-a---- 04/12/2019 16:46 659401 org.eclipse.ocl.xtext.essentialocl-1.3.0-v20170522-1753.jar
-a---- 04/12/2019 16:46 90236 org.eclipse.uml2.common-2.1.0-v20170530-1052.jar
-a---- 04/12/2019 16:46 18761 org.eclipse.uml2.types-2.0.0-v20170530-1052.jar
-a---- 04/12/2019 16:46 3456603 org.eclipse.uml2.uml-5.2.4-v20170530-1052.jar
-a---- 04/12/2019 16:46 136186 org.eclipse.uml2.uml.profile.standard-1.0.100-v20170530-1052.jar
-a---- 04/12/2019 16:46 262863 org.eclipse.uml2.uml.resources-5.2.0-v20170530-1052.jar
-a---- 04/12/2019 16:46 2615136 org.eclipse.xtext-2.10.0.jar
-a---- 04/12/2019 16:46 284321 org.eclipse.xtext.util-2.10.1-SNAPSHOT.jar
-a---- 04/12/2019 16:48 2398 THIRD-PARTY-LICENSES
I think you should find the corresponding jars for the version of OCL that you are using.
At the end I automatized everything with maven by mirroring the p2 updatesites and producing a local maven repository and then using standard maven dependencies (and painstakingly adding a dependency at a time with the good version) .
After that I moved to use maven tycho , so I never maintained that old stuff, but it still works and I can build my old projects, if you are interested I can explain you what I did
Regards
[Updated on: Fri, 24 April 2020 08:04] Report message to a moderator |
|
|
|
|
|
| Re: OCL jars from Maven [message #1826395 is a reply to message #1826386] |
Fri, 24 April 2020 10:43 |
Andrzej Wąsowski
Messages: 21
Registered: November 2019 |
Junior Member |
|
|
Thanks guys. I got it to work. I think I will not optimize the classpath for now but just commit the entire release of MDT-OCL. This way it should be easier for me to upgrade in the future (even if this sounds excessive).
For the record this is what I did (for folks attempting to use OCL in a gradle build AD 2020). I have the following dependency setup in build.gradle:
dependencies {
// stuff needed mostly for EMF
compile "org.eclipse.emf:org.eclipse.emf.ecore:$emfVersion"
compile "org.eclipse.emf:org.eclipse.emf.ecore.xmi:$emfVersion"
compile "org.eclipse.emf:org.eclipse.emf.edit:$emfVersion"
compile "org.eclipse.emf:org.eclipse.emf.common:$emfVersion"
// Stuff needed for OCL
compile fileTree (include: ['*.jar'], dir: '../lib')
compile "org.eclipse.xtext:org.eclipse.xtext:${xtextVersion}"
}
$emfVersion and $xtextVersion is set up globally in my project. I downloaded the MDT-OCL distribution from https://www.eclipse.org/modeling/mdt/downloads/?project=ocl , following Ed's advice, unzipped it, and dropped all plugin jars into 'lib/'. The lib in dependencies above is prefixed with '../' because my build is a multi-project build so I have to pull jars from level above. In a single project build you should not need this. This was actually quite hard to debug, as gradle (at least at the current version) reports no error if jars cannot be found at the specified location. Not even if you depend on concrete file names. Presently I work with jars from MDT-OCL 6.9.0.
I created the constraints using the OCLInEcore editor in Eclipse. I don't actually use Eclipse for my daily work, but this editor is convenient, as it directly embeds the constraints in an ecore file. I used Pivot OCL variant (at least this is the meta-model referenced from my Ecore files after the operation).
In Scala, I initialized the OCL setup with
org.eclipse.ocl.xtext.essentialocl.EssentialOCLStandaloneSetup.doSetup
In Java you need to add parentheses and semicolons. The OCL documentation at https://help.eclipse.org/2020-03/index.jsp?topic=%2Forg.eclipse.ocl.doc%2Fhelp%2FPivotStandalone.html seems to be outdated. Several steps do not seem to work anymore (classes have apparently been moved around). But with a bit of tweaking I arrived at the above. This allowed me to use Ecore validation API, as follows:
val diagnostic = Diagnostician.INSTANCE.validate (eObject)
After the OCL annotations have been added to the meta-model, this also checks OCL constraints, and seems to behave as expected. That is constraints fail when I expect them to fail. I hope others may find this info useful.
The project will be available here: https://bitbucket.org/dsldesign/dsldesign if folks wanna see how to use OCL from gradle. But it will take me some time to push. I still need to sort out a few issues, and decides how to organize the example. If I remember, I will update the link in this post, after I have done that.
Thank you both for helping.
[Updated on: Sat, 25 April 2020 11:56] Report message to a moderator |
|
|
|
| Re: OCL jars from Maven [message #1826425 is a reply to message #1826395] |
Fri, 24 April 2020 16:38 |
German Vega
Messages: 104
Registered: December 2015
Location: Grenoble, France |
Senior Member |
|
|
Hello,
To complement Andrzej work with gradle I have just produced a working, self-contained version of my previous attempts for automating maven building of standalone OCL programs.
DISCLAIMER: the easiest, well supported, way to use maven for eclipse projects is to use eclipse tycho. These instructions are for people who cannot (or don't want to) use tycho, and need a more "plain" maven solution.
Attached you will find two maven projects :
1) eclispe.maven.repository
This projects mirrors the official updatesites of OCL (6.11), Xtext(2.21) and EMF(2.21) into a local maven repository. I have not mirrored everything, only runtime artifacts (no UI, editors or generators) and some required transitive dependencies.
Mirroring is performed using CBI aggregator, as I said before it mirrors officially released jars (with hash validated during download). The specification of the updatesites used and the features mirrored is defined in file src/main/resources/maven.repository.aggregator
To perform the mirroring just build the project (mvn clean install). This will download the artifacts from the update sites (may take some time, specially these days of lockdown) and produces a big zip file (in the "target" directory).
If you extract the zip you will get a maven repository with all the artifacts as well as metadata (pom.xml) for each artifact ( including transitive dependencies declarations).
You can use this repository to build your projects using maven or gradle, instead of relying on some untrusted version that happens to exist in maven central.
The pom of this file also defines a BOM (Bill of Materials) that you can import from your maven project (see importing dependencies) to avoid handcoding version numbers; The BOM is defined in the <dependencyManagement> of the pom of this project.
2) completeocl.standalone.test
This is a test project that shows how to build an stand-alone OCL project using maven (and the repository mirrored by the previous step)
The code of the project is a ecore metamodel (located in directory src/main/resources/model) with constraints defined using oclinecore. Other than the emf generated classes, there is a single main Launcher class that creates two models (one that satisfies the constraints and one that fails) and validates them.
To test the project just build it (mvn clean install) this will generate a zip file (in the "target" directory). If you unzip it you will get a single jar (with the code of the metamodel and the Launcher) and a "libs" directory with the required dependencies jars. To run it, just "java - jar <name of the jar>"
The pom.xml of this project illustrates the following points:
- the first time that the project is built (in the pre-clean phase) it takes the zip produced by the built of the project eclispe.maven.repository and extract it in the "repository" directory
- It defines a local maven <repository> that points to the "repository" directory
- it imports the BOM defined in the eclispe.maven.repository
- it has a minimal (handcrafted) list of <dependencies> required to compile and run the code
- it automatically copies the (transitive) dependencies to the "libs" directory
- it automatically adds the MANISFEST.MF required to run the generated jar directly (specifically it adds a classpath entry thar points to the jars in the "libs" directory)
- it zips everything to get a self-contained releasable artifact
I suppose that a similar setup can be achieved in Gradle (but I am not sufficiently proficient with Gradle to do it myself)
Hope this helps other people that come to this thread in the future.
Regards
G. Vega
[Updated on: Fri, 24 April 2020 16:59] Report message to a moderator |
|
|
|
|
| Re: OCL jars from Maven [message #1826580 is a reply to message #1826437] |
Mon, 27 April 2020 13:15 |
German Vega
Messages: 104
Registered: December 2015
Location: Grenoble, France |
Senior Member |
|
|
Hi Ed,
Sorry I skipped your question
Quote:
Maven users seem to like Maven and dislike having to look beyond Maven Central.
Tycho seems to provide all sorts of extensions to Maven to facilitate Eclipse Plugin Development.
Eclipse publishes P2 repos not maven tepos.
Is there a relatively minimal maven snippet that uses Tycho and perhaps its target definition to load Eclipse P2 repos so that Maven can use them? If so, it should be a relatively simple cut and paste of the snippet to exploit P2 repos in Maven. Maybe the snippet could be streamlined by a variant Tycho mojo.
I am not completely sure to understand you question, but I suppose that you want a maven snippet to automate the transformation of a p2 udatesite into a maven repository.
That's exactly what the eclispe.maven.repository project in my contribution does. You can take a look at it and extract the relevant parts. The important thing is that you need to write a CBI aggregator file to specify what you want to mirror and where to find the dependencies. This information is somehow redundant with the tycho target platforms, in my projects I maintained both synchronized by hand. And you may end-up needing different versions of this file for different kind of publishing (release, nightly, etc)
That said, however, my utility is a fast and dirty solution that doesn't consider many details, and it is far from usable in a production project. My only goal when I wrote that utility was to be able to have a maven repository of eclipse artifacts that I can use to locally resolve dependencies of standard maven projects without using tycho. The produced repository was never meant to be published.
If you refer to the process to release eclipse platform to maven central my script corresponds to a very simplified version of step 1 ("Run the aggregator"), all the other steps are missing.
The important missing considerations are :
1) Consistent naming : ids of eclipse artifacts must be consistently translated to maven groupId and artifactId. For OCL this seems straightforward as all the artifacts seems to have a common prefix.
2) Consistent versioning : you have to find equivalence between the eclipse version numbering and the maven versionning schema . For major.minor.increment this seems straightforward, the problem usually comes with qualifiers. Some eclipse release qualifiers (like RC1 or M1) do not compare properly when used with the maven algorithm, so they need to be renamed. You also have to find an equivalence to maven SNAPSHOT versions, perhaps nightly builds?
3) Dependencies to third-party libraries. Many eclipse projects depends on libraries coming from the orbit p2 repositories. However these libraries also exist in the maven central with different naming conventions. In the generated pom metadata it is better to translate these dependencies to refer to the projects in the maven central.
All of these 3 steps can be automated using the CBI aggegator (that both my maven script and the platform releng shell script ultimately rely on), so you can take a look at the platform aggregator for inspiration.
4) Streamlining the repository. Many eclipse artifacts (features for example) do not have any interest in maven, so you can remove them from the repository.
5) Adding metadata to POM. The pom generated by CBI aggregator only include the dependency information. You may want to add more metadata : licenses, contributors, SCM repository, issue management url, etc. Apparently platform releng have a tool to automate that.
6) Sources and javadocs. If you generate sources and javadocs for your artifacts, it would be nice to attach them to their respective maven artifacts. This is more or less easy depending if you have the same granularity for code and documentation. Maven needs a single source or javadoc per artifact. If you have several binary eclipse plugins and a single javadoc or source feature the correspondence is not that easy.
7) Signing the artifacts
8) Publishing to the OSSRH nexus
All in all, given all these devilish details, producing a maven repository for an eclipse project, that did not have that in mind from the beginning, is really a pain.
I am not a contributor of any eclipse project, so I am not familiar with the eclipse releng infrastructure, and how these general considerations are declined (for instance, how signing keys are handled?). Perhaps you can get a better advice from people with maven experience in other eclipse projects. The people from xtext seems to have a nicely working maven releng infrastructure.
Regards,
G. Vega
[Updated on: Mon, 27 April 2020 13:24] Report message to a moderator |
|
|
|
|
] 
Search
Help
Register
Login
Home
