I'm at my wit's end trying to get Java3D working with Maven. The latest version in the Maven core repository is 1.3.1, but there don't seem to be any 64-bit dll files (without installers) that will work with such an early version! It seems that the 1.5.2 dll I donwloaded is incompatible (unsurprisingly).
Does anyone know of a repository that has at least version 1.4.0?
Otherwise, looks like I'm going to have to learn JOGL instead and change all my code.
Rather make a request for enhancement. Maybe we could publish Maven on Maven Central or at least in our development repository. Please check whether you're using Java 3D 1.6, look at that if you don't know how to install it.
Related
My builds broke when I moved to Gradle 5 becasue Gradle v5.2 bundles with Groovy v2.5.4. These projects use the dynamic support build for Groovy.
Invoke dynamic support
groovy-all-2.5.4-indy.jar
This file is not being resolved for either JCenter or MavenCentral. However I did find a copy here:
Sonatyoe repo: https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.4/
groovy-2.5.4-indy.jar
but no groovy-all-2.5.4-indy.jar
I am not sure what can be done for Gradle to 'resolve' this file and actually find it.
Can someone tell me were I should be getting this JAR file from?
I'm using coordinates: "org.codehaus.groovy:groovy-all:2.5.4:indy"
Is that still the correct expression?
Is this a bug or am I just looking in the wrong places (see #1)?
Im ny build.gradle I was using jcenter() and tried changing that to mavenCentral().
Neither option came up with the JAR in question.
A final wrinkle is that we run an instance of Nexus. Is there some way to force Nexus to go outside and look-for this JAR?
This is not entirely conclusive, but it seems that the -indy jar was there in groovy versions prior to 2.5.0 because those versions supported java versions prior to 1.7.
The indy jar was there so that you could optionally enable support for the invokedynamic instruction introduced in java 1.7 while still supporting java versions prior to 1.7 which did not include invokedynamic (groovy docs for indy).
It seems that groovy 2.5 bumped the minimum jdk requirement to, quote:
JDK requirements changes
Groovy 2.5 requires JDK8+ to build and JDK7 is the minimum version of the JRE that we support.
(from http://groovy-lang.org/releasenotes/groovy-2.5.html)
which would make this whole duality of supporting both invokedynamic and without unnecessary.
So my guess would be that they just dumped the indy jar and always include the invokedynamic instruction in the normal groovy jar file set as the required jdk versions will always include it.
I've been looking for the answer to this for a few days and have turned up empty.
I'm devving a Confluence plugin that integrates with a 3rd party app. This 3rd party app has a nice REST API and they even provide a Java SDK (yay!). Except.....the Java SDK has bundled a version of Jersey (1.18) that conflicts with Confluence's forked version of Jersey (1.8-atlassian_15). The SDK was not released as a Maven jar (or at least there's no pom.xml included). There ARE other pom.xml in the jar's META-INF for the dependencies it uses, but the SDK itself is just released as a jar download by the vendor.
So as I've done in the past, I mvn install:install-file the sucker with my own groupId and artifactId, thinking it'd be fine. Intellij recognized the library, everything compiled nicely, and then I tried my test call to the REST API. This is when it threw an error that made it evident that there's a conflict between the versions.
SOOOO. Is there anyway to get around this? Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses? I have a feeling that even after the Jersey dependency is resolved (if that's even possible) there will be other issues....The SDK also bundles the specific version of Jackson, Swagger, etc. with it.
I attempted to decompile the jar and include the decompiled code in my project, but that just had all of issues I'd rather not deal with ever again.
I have reached out the SDK devs to see if they could release a more maven-friendly release, but I'm not hopeful this will be done at all, and even it is, their release cycle is much different than my own requirements (read: I need a solution now). This is my last-ditch effort before rewriting the REST client from scratch.
Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses?
Sure you can. Often-used way to do this is to use Maven shade plugin that transforms an existing jar to a shaded jar, using another package hierarchy and getting rid of the package naming conflict. See also the documentation about relocating packages. I suggest you use that - that's what I've done in cases like this (though I haven't done confluence plugin development, but it should be the same thing as with other platforms).
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.
My setup:
I'm using Grails 2.3.8
I have several private plugins I publish to my local Nexus repository manually via "grails publish-plugin"
I have several Grails applications that use these plugins
Distributed development team
My goal:
Able to deploy new versions of my private plugins and have my Grails apps automatically use those latest versions without having to modify their BuildConfig.groovy files
I know about inline/inplace plugin definitions and that is not what I want
Possible solutions:
As I understand it there might be at least two ways of achieving my goal:
Deploy snapshot versions of my plugins and have my Grails apps use those snapshot versions (e.g., version = "0.1-SNAPSHOT")
Configure my Grails apps's BuildConfig.groovy to use "latest.release" or Maven version ranges. Examples:
compile 'com.mycompany:some-plugin:latest.version'
compile 'com.mycompany:some-plugin:[0.1,)'
The problem:
The two methods above sort of work.
They both result in the latest version of my plugin to be downloaded, at least initially. However, if I publish a new version of the plugin (be it snapshot or release), re-running "grails run-app" on my Grails applications do not attempt to download/install the newer versions which are available.
I feel like the maven-metadata-*.xml files in my M2_HOME local repo are limiting the versions which are known to exist (even though Nexus has newer versions available).
When I define my Nexus repo using mavenRepo(), do I need to pass in some parameters to tell Grails to always check for new versions on the remote repo and not rely on the local repo?
Graeme's suggestion here does not seem to help either: Dependencies and lastest.release
Any help would be great. :-)
Have you configured the updatePolicy for the repository? See
http://grails.org/doc/latest/guide/conf.html#changingDependencies
Section "Aether and SNAPSHOT dependencies". Example:
mavenRepo "http://myrepo", {
updatePolicy "interval:1"
}
I'm using 2.3.7 and seemed to experience a similar problem. Using a SNAPSHOT plugin should be what you want during development. One workaround solution I used was to delete the SNAPSHOT release from Artifactory and then after building a new SNAPSHOT the plugin change was recognized. I am guessing you are using the Maven build which is now the default you could try switching to the ivy build and see if that helps. A JIRA should be created if you are able to recreate this. I believe this is an issue and I do not recall this when working with an older version (2.1.5) and using the ivy build.
I'm not new to maven. but I don't know why my maven use 1.1.1 version of maven-plugin, hornet-maven-plugin. the reason I say about the version is that the repository doesn't have the version. So I think I have to change the version of plugin that the repository has.
the soure code is here( https://github.com/verystrongjoe/hornetq/tree/master/examples/jms/clustered-queue ).
I downloaded that to my local disk. and I imported to my eclipse.
but the result was an error like below.
Failure to find org.hornetq:hornetq-maven-plugin:pom:1.1.1-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public was cached in the local
repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
If you go to the repository http://repository.jboss.org/nexus/content/groups/public , there are 1.1.0 or 1.0.0.
please let me explain about this.. thanks in adavance.
You can see the answer on Line 716 of the super-POM:
<plugin>
<groupId>org.hornetq</groupId>
<artifactId>hornetq-maven-plugin</artifactId>
<version>1.1.1-SNAPSHOT</version>
</plugin>
It sounds like you might not be knowledgeable enough to work on the edge of the github source. Perhaps you should work with one of the recent release tags instead?
You are forking and trying to work with an in-development SNAPSHOT version of HornetQ. That normally requires more work than using released versions. Tip one: consider working only with released versions of HQ.
If not, be aware that:
HornetQ does not release *-SNAPSHOT versions of artifacts to Maven repositories. That is the reason you won't find them at that JBoss Maven repository. BTW, See here for comments with regards to figuring out dependencies of HornetQ examples https://github.com/hornetq/hornetq#recreating-the-examples
See here about the minimal instructions of using the SNAPSHOT version of the hornetq-maven-plugin https://github.com/hornetq/maven-hornetq-plugin/blob/master/README.md
Please notice that the content of each of those links is small. I could have copied their content here but I didn't. My point is: these projects have README files which address your issues, you should always check the README.