We Keep Coding

cloudbuild.yaml for javafx (jdk8u201) with other dependencies

I'm setting up a GitRepo, with different modules of a project. It has some legacy code, some C/C++ for Ardino, and a JavaFX project with some dependencies and Kotlin files in it.
What I actually need is, to build that JavaFx project on pull requests, targeting the develop branch
I already have an empty cloudbuild.yaml in my repository root. What I want is a non-Docker continous integration, so on pull request, I need an artifact build, so the executable can be downloaded for the other project members. GitHub and Google Cloud are connected, only the config is needed.
What is also specific, that I want to build with jdk8u201 (because of the licensing)
The folder structure is something like that:
+- legacy
+- Arduino_codes
+- JavaFX_project
| +- FILES...
+- cloudbuild.yaml
+- .git
If it is possible, that would be great if the builded version would be downloadable, or stored in a specific place in the repository

Try to add :3.5.0-jdk-8 to gcr.io/cloud-builders/mvn if you use maven. Result gcr.io/cloud-builders/mvn:3.5.0-jdk-8
It helped me. More info and cases you can find here.

Using maven to rebuild local sources from other projects in dev environment

We have a microservice architecture where the entire project looks as follows:
+- Utilities
+- Service A REST
+- Service A Backend
+- Service B REST
+- Service B Backend
...
+- Service X REST
+- Service X Backend
Each of these is an independent Maven project that can be independently developed.
It so happens, of course, that some of the projects may have to use classes from another one (e.g. to be able to give back corresponding Exception classes in error messages).
Thus one of the projects may have the following dependencies:
Service A backend
+- dependency 1
+- dependency 2
...
\- Utilities
\- Service B backend
In a standard deployment, we would use a Maven repository and simply add the latest jars as dependencies. The problem is during development: if we make a change in Service B backend, a dependency of Service A backend, we cannot simply do mvn compile Service-A-backend because Service B backend will not be recompiled. Doing this for every single project during development is extremely error-prone.
Eclipse might be able to work around this by having the project on the build path, but we do not want to bind ourselves to an IDE and would like to ideally be able to solve the issue with Maven itself.
Can you use Maven in the above scenario so that you can list Service B backend above as a source dependency where, if we compile or package Service A backend, its local source dependencies also get recompiled if there have been any changes? If not, can you do it with gradle or ant?

You should consider looking at the Maven modules feature. Here is an example of use in a POM file:
<modules>
<module>A</module>
....
</modules>
I personally use in addition to maven modules (for compilation ) git sub-module for pull/push code base on multiple project feature.

can't create entity manager, when add relationships [duplicate]

I'm trying to upgrade to Hibernate 3.5.3-FINAL.
When running my unit tests, I now receive the following exception:
java.lang.NoSuchMethodError: javax.persistence.OneToMany.orphanRemoval()Z
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1837)
My classpath contains the following JAR's:
From the hibernate dist:
antlr-2.7.6.jar
commons-collections-3.1.jar
dom4j-1.6.1.jar
javassist-3.9.0.GA.jar
jta-1.1.jar
slf4j-api-1.5.8.jar
cglib-2.2.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
hibernate3.jar
Other jars:
blazeds-common-3.2.0.3978.jar
blazeds-core-3.2.0.3978.jar
blazeds-opt-3.2.0.3978.jar
blazeds-proxy-3.2.0.3978.jar
blazeds-remoting-3.2.0.3978.jar
commons-lang-2.3.jar
dbunit-2.4.7.jar
ejb3-persistence.jar // Note, I've tried excluding this, but I get different errors
guava-r05.jar
hsqldb-1.8.0.7.jar
junit-4.1.jar
lambdaj-2.0-with-dependencies.jar
log4j-1.2.14.jar
mockito-all-1.8.0.jar
persistence-api-1.0.jar
spring-security-core-2.0.0.jar
spring.jar
sqljdbc.jar
I've researched this, and I find answers that state my webserver must be JPA2 Compliant:
Unfortunately if your app server is
not JPA 2 compliant, you are likely to
be out of luck
This project is a library, not a webserver project. (Although it is eventually deployed to a webserver, I'm simply running unit tests here)
What am I missing?
<indulgent_rant>
As a sidenote, it's very frustrating that every time I upgrade Hibernate, I find myself spending hours researching conflicting jars for MethodNotFoundException or ClassNotFoundException's. There must be a simpler way?
I thought for sure that with the announcement they were merging the modules back to a single core project, that these conflicts would go away?
</indulgent_rant>

As pointed out by Timo, remove persistence-api-1.0.jar.
Just in case, here are the dependencies I'm using:
org.hibernate:hibernate-entitymanager:jar:3.5.3-Final:compile
+- org.hibernate:hibernate-core:jar:3.5.3-Final:compile
| +- antlr:antlr:jar:2.7.6:compile
| +- commons-collections:commons-collections:jar:3.2:compile
| +- dom4j:dom4j:jar:1.6.1:compile
| | \- xml-apis:xml-apis:jar:1.0.b2:compile
| \- javax.transaction:jta:jar:1.1:compile
+- org.hibernate:hibernate-annotations:jar:3.5.3-Final:compile
| \- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
+- cglib:cglib:jar:2.2:compile
| \- asm:asm:jar:3.1:compile
+- javassist:javassist:jar:3.9.0.GA:compile
\- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile
I'm getting them from this single declaration in my pom.xml:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.5.3-Final</version>
</dependency>
This should somehow answer your indulgent rant (if I rephrase: use Maven - or know what you're doing).

Remove these files from project lib location
persistence-api-1.0.jar
ejb3-persistence.jar
add only
javax.persistence-2.0.0.jar
it contains all the required fields and atrributes.
try this it'll work for your problem.
Manish Jaiswal

Try replacing persistence-api-1.0.jar with a JPA 2.0 jar.

Discovered a fix for the issue at least with what I am working with: IBM WebSphere 7 and MyEclipse Blue (Spring), or Bling, ver. 10.6. I created an application that has dependencies on other projects, one of these using Hibernate 3.6.3, requiring JPA 2.0. IBM WS loads JPA 1.0 to support itself ahead of JPA 2.0 and resolves all references to JPA to ver. 1.0. In the case of IBM WS, this causes the error reported above. The only fix I have come across since now includes adding JPA 2.0 as a shared library, then setting the server to load that library ahead of its native classes, similar to the method discussed here:
http://www.mkyong.com/websphere/websphere-7-javaxpersistenceonetomany-orphanremoval-error/
But our server admins will not allow changes to the server-wide classloader policy. So I still needed to find a way to get my project to use JPA 2.0 and not 1.0. I tried a lot of things but finally went for a Hail Mary and it worked.
The fix is to add the JPA 2.0 .jar file to your .war and .ear projects and then edit the Class-Path line in the manifest file in both your .war and .ear projects to point to the .jar files. It seems they must be in both or the approach will not work, so the JPA 2.0 .jar has to be in both the .war and .ear.
In your app (.war project), add hibernate-jpa-2.0-api-1.0.0.Final.jar to the project root. MyEclipse Blue will show it as a file at that location and also listed under "Referenced Libraries" in the Package Explorer view. Then open the manifest file at /WebRoot/META-INF/MANIFEST.MF and make sure the Class-Path line reads:
Class-Path: /hibernate-jpa-2.0-api-1.0.0.Final.jar
In your .ear project, add hibernate-jpa-2.0-api-1.0.0.Final.jar to folder 'lib' at your project root. If there is no 'lib' folder there, create one. Then in /META-INF/MANIFEST.MF, make sure the Class-Path line reads:
Class-Path: /lib/hibernate-jpa-2.0-api-1.0.0.Final.jar
Make sure all files are saved and do a clean build. Then export the .ear and deploy it as usual by the Integrated Solutions Console. But there is another thing you must do before the change will work; it does require changing the class-load policy for the app, but not the server. You are much more likely to get your WAS admin to go for that than changing the classloader policy for the entire server. To make the necessary change, after installing the .ear file, follow the left-hand nav bar click trail "Applications\Application Types\Websphere enterprise applications" and click on the name of your application, then click "Class loading and update detection". Then select "Classes loaded with local class loader first (parent last)" under "Class loader order", then click Apply, then Save. Now back at click trail "Applications\Application Types\Websphere enterprise applications", either start or restart your application. Test out your app and hopefully you will be good to go.
Final note: Evey time you re-deploy your .ear file, you will need to set the classloader option I just discussed. The preference is not retained between deployments.

adding javax.persistence-2.0.0.jar should work fine...

Setting your server's application classloader policy to parent last will resolve this problem so long as you ensure the hibernate-jpa-2.0-api jar file is included in the EAR. If this is possible in your environment it's a much easier solution.
Tested on WebSphere 7.

get maven clean install to work like maven clean + maven install

I have the following project hierarchy:
app
|-module1
| |-pom.xml
|-module2
| |-pom.xml
|-pom.xml
Module1 and module2 both copies files to the same target directory, so im using the app's pom.xml to clear that directory. My problem is, the execution order right now is module1[clean], module1[install], module2[clean], module2[install], app[clean], app[install], so everything module1 and module2 puts into that directory will be deleted.
I would like to get it to execute all clean first, then all install, even when i run mvn clean install. Or if there is another way to execute app[clean] before module1[install] and module2[install], that would work too.
EDIT
I ended up making a separate module (Netbeans POM projekt) for cleaning alone. Not the sollution i was hoping for, but it works for now.

The root of the problem here is that you're trying to make Maven do something that sort-of contradicts Maven's multi-module "conventions", as well as conflicting with Maven's "understanding" of a "target directory". There is a reason why Maven's reactor is operating the way that it does, and it is to preserve the Maven "spirit" (or "convention") of how modules are structured in a multi-module build.
In Maven, the target directory is supposed to belong only to one project: each project has its own target directory. In your scenario, there should really be a different target directory for app, module1 and module2.
I suppose your best bet, in order to both achieve your objective and keep your build process flexible, is to:
Have module1 output its own JAR into its own target directory (module1/target).
Have module2 output its own JAR into its own target directory (module2/target).
Add a plugin to app (the parent module) that will collect whatever it needs from module1/target and module2/target into app/target, and do whatever processing on those artifacts.

How to remove dependency: maven sub-modules creates implicit dependency on parent module

I have a maven project
Parent Project (with the following modules) (package type pom)
API Project (package type jar)
Packaging Project (has a dependency on API Project) (package type custom)
I want to be able to deploy the API project to Nexus repositories so others can leverage that code. The Packaging Project is more of a supporting utility project for a smaller set of deployment use-cases. The Parent Project wraps it all together for me.
When I deploy the API project to the nexus repo, it deploys fine. If i try to make a brand new project that has a depdency on API, it finds the API dependency in nexus but then also wants the Parent project as well. Is there any way to get around publishing the parent project as its really isnt necessary for use of the API lib when used via the nexus repo?
Any tips on how to organize my maven proj to support this?

When you add a <parent> reference to a Maven project what you are doing is saying: "Take all the configuration from that parent and inject it into my model, then override with the following"
Therefore, in order for Maven to build the model of your project, it is necessary for Maven to retrieve the parent itself. In other words, adding a <parent> tag creates an explicit hard dependency between the parent and the child.
The good news is that Inheritance does not have to follow Aggregation. What does that exactly mean?
Aggregation is when you list <modules> in your pom. It tells Maven that the reactor (i.e. the set of projects that Maven builds) should also include the following (sub)projects.
Inheritance is when you set a project's <parent>.
Nowhere does Maven enforce that a project's <parent> has to list its children as <modules> and nowhere does Maven enforce that a projects <modules> must list the project as a <parent>.
Some people will set up their project like so
ROOT/
+- pom.xml
+- parent/
| \- pom.xml
+- api/
| \- pom.xml
\- packaging/
\- pom.xml
where the parent of ROOT, api and packaging is actually a child of ROOT. Or sometimes ROOT will be a standalone project with no parent [In fact this is a pattern I use a lot myself. When I am working on several related project I will throw together an aggregating pom.xml on my local disk and open that with my IDE and that way all the related code is available as one single "project", even though the actual modules may come from different sources]
So in your case the solution would be to remove the <parent> tag from your "API" module.
Now! There is a downside. When you remove the <parent> tag from your "API" module you have removed all the defaults that your parent project is providing, so you will need to copy those defaults that are relevant to the "API" project or else you may find subtle changes in behaviour. For example, you should definately copy over the pinning of plugin versions, and any <dependencyManagement> that is relevant to the "API" dependencies. There are other bits you may have to copy, but you should use the Maven command mvn help:effective-pom before and after removing the <parent> tag as an aid to seeing the effective differences

for my developments I use uber-pom maven plugin which merges information in maven project hierarchy and provides independent pom as result and I publish artifacts in maven central without any extra links to parents