| OCL jars from Maven [message #1802899] |
Mon, 18 February 2019 12:31  |
Eclipse User |
|
|
|
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 12:33] by Moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: OCL jars from Maven [message #1826395 is a reply to message #1826386] |
Fri, 24 April 2020 06:43  |
| Eclipse User |
|
|
|
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 07:56] by Moderator |
|
|
|
| Re: OCL jars from Maven [message #1826425 is a reply to message #1826395] |
Fri, 24 April 2020 12:38 |
| Eclipse User |
|
|
|
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 12:59] by Moderator |
|
|
|
|
| Re: OCL jars from Maven [message #1826580 is a reply to message #1826437] |
Mon, 27 April 2020 09:15 |
| Eclipse User |
|
|
|
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 09:24] by Moderator |
|
|
|
|
Home