Has anyone got the Acceleo Maven build to work?
If so what combination of Maven, Tycho, Eclipse, Acceleo, UML2/ecore worked for you?
And as a supplementary question do you still need to adjust the Java classes and config files before running the build (as was required for the old ANT build)?
To be clearer tycho does not like Maven 3.3, Maven 3.3 is the default with Luna. Every version of Eclipse has a different version of the ecore/uml model built in so migrating the Acceleo templates to another version of eclipse requires changes in all "module" definitions and hacking the version inside the UML models, so, its tedious trying to work out which versions are compatible.
I just wondered if someone had a working setup where all the components worked together.
After much trial and error:-
Eclipse Luna
Comes with Eclipse m2e 1.5
ecore uml2 version 5.0.2
Acceleo 3.5.1
Maven 3.0.5
org.eclipse.acceleo:org.eclipse.acceleo.maven:3.5.0-SNAPSHOT
All work together without the usual class not found and missing jars.
However I have yet to build a working pom that actually generates some
template output.
Interestingly the ANT build seems to work fine.
In the end it was just easier to knock up a .bat script to run
the generate and build.
You can have a look at the UML to Java generator of the Eclipse Foundation for the configuration of the pom.xml. For additional information on the use of maven with Acceleo, look at the dedicated page on the wiki.
You do not need to modify any Java class or configuration file now.
Related
I am new to gradle. But I do understand to some extent why developers are encouraged to use gradlew instead of gradle. However what worse could happen if developers use different versions of gradle to build their project? At the end of the day any gradle version makes sure that dependencies of the project is managed properly. For example if a Spring Boot project is dependent of a starter plugin version 2.x, no matter what version of gradle is used, the build tool makes sure that 2.x is available
As far as I'm aware the main point to use a common version of Gradle is plugin compatibility.
Gradle's internal APIs changed quite a lot in the last few versions, so not every plugin works with every Gradle version.
For example: Spring Boot's 2.3.4 reference explicitly states that it's build plugin requires Gradle 6.3 or later (although 5.6 is mentioned to work in a deprecated form)
https://docs.spring.io/spring-boot/docs/2.3.x/reference/htmlsingle/#getting-started-system-requirements
So while you can be sure that the Spring Boot version is used (because you defined it in your buildfile) any older version of Gradle is likely to run into Exceptions when trying to build your project.
Even if you're just using plugins that are provided by Gradle itself there can be compatibility issues. For example the java configuration block was first introduced in Gradle 5 (I think) and therefore would cause a syntax error in earlier versions.
Or simple things like Java versions that older version of Gradle do not support.
The more plugins you use it becomes increasingly unlikely that a lot of Gradle versions will be able to run it. Using the Gradle Wrapper is therefore a simple way that your build works for everyone.
And from the other perspecitve: if you are the one that usually maintains the build you can use all the latest Gradle features using the Wrapper as you can be sure it will not break anything. Getting everyone on the team to update manually before you can use a feature can be a pain
That beeing said, it's really primarly a maintenance issue. Nothing bad can happen if anyone uses their own installed version of gradle, except it might just not work
If everyone on the team uses a similar version nothing might happen at all
As of Java 11 it is necessary to get JAXB from a separate library, not from the JDK. There are plenty of tutorials on the Web showing how to do that, but they all use Maven. The project I need to fix is an Eclipse RCP application. There does not seem to be an easy to make that work with Maven, as Maven essentially takes over most of what Eclipse would do but doesn't have RCP development capabilities.
Sooner or later Maven gets the required libraries. I would like to find another way to get and use whatever libraries are needed, just without using Maven. It should be possible. I just haven't found it.
Thanks.
I did what I wanted by downloading the needed JARs from https://mvnrepository.com/.
I get the below error while executing the default lifecycle 'clean install' from my maven project.
java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
My code uses the flexmojos-maven-plugin. As per the jira thread https://issues.apache.org/jira/browse/MNG-5958 this issue has been resolved, but nowhere could I find how.
As per the solution I would have to update Lifecycle.java. Updating Lifecycle.java would mean updating maven-core.jar.
Will I have to go the extent of updating a standard jar which could impact many other files which are using this jar.
I am using maven 3.3.9 and java 8.
The problem is that the Maven guys changed quite a lot internally again with Maven 3.3.9 so currently you will have to use an older Maven version. I also doubt that I will be able to spare the time to address this in the future as Flexmojos has become more and more a beast to maintain. Therefore I am currently working on a completely new maven plugin which I am developing as part of the Apache flex project. For now I would suggest to use Maven 3.3.3 ... should work nicely with that.
I know, we can convert the project.xml from maven 1.x to pom.xml for maven 2.x, but I have come across a complex project setup that was build using maven 1.x, and I just have maven 2.x currently installed in my machine locally.
There is a option to setup maven 1.x, but that would involve changing the PATH variables, and configurations.
I would like to know, if it is possible to build a maven 1.x project using maven 2.x or not? I just need to test few things.
I tried the maven 1.x commands, but they all failed saying no such goal obviously. So, if there is some tricks, tweaks that can be applied that I am not aware of currently, please let me know.
Unless you convert the project with the one:convert goal, you won't be able to. You have to understand that Maven 1.x and 2.x are extremely different. Either just install 1.x and build the project with it, or convert it, if that is at all possible, as the conversion plugin will not solve everything for you for more complicated projects.
I have a project that uses some Java and some Groovy, and it's all built with Maven. We use the GMaven plugin to compile the Groovy. I've been using Eclipse and have got fed up with the "Plugin execution not covered by lifecycle" message that indicates Eclipse is incapable of doing what my command-line does (I've tried adding the ignore/execute config to fix it, but it never works properly), so I've switched to Spring Tool Suite, which claims to have full Groovy support. How should I set it all up? So far I've had exactly the same experience as with regular Eclipse, but given that SpringSource are responsible for Groovy, I figure there must be a way of doing it.
Have you read this thread?
http://forum.springsource.org/showthread.php?130130-Working-with-Mavenized-Grails-projects-in-GGTS-3-1-0-Updated-for-3-1-0-release/page2
For grails projects, you do not need to use gmaven or the groovy-eclipse-compiler. You must be using the 3.1.0 STS (which is not actually released yet, but you can get this
You also must be using Grails 2.1.1.
You can secretly get a 3.1.0 release build by going to this download page:
http://www.springsource.org/downloads/sts-ggts
Instead of clicking on the links, copy them and substitute 3.1.0 for 3.0.0.