this is a more conceptual question:
I want to create an application which uses the WALA framework, which itself is packaged as a eclipse plugin, built with maven-tycho. When I try to add this as an dependency no transitive dependency gets resolved, because they are covered by the tycho build.
This is the pom of the WALA project I need at least https://github.com/wala/WALA/blob/master/com.ibm.wala.core/pom.xml
Should my application be a OSGI Bundle itself or can I create a regular jar with it without having much trouble? Which approach is more practical?
If I have seen it correctly, wala.core has only two dependencies wala.util and wala.shrike (util has none, shrike depends on util). So you might as well simply include all three dependencies in your project.
On the long haul, however, you might should indeed consider creating an osgi application instead.
Related
I have three Java projects. The first is an application, com.foo:foo-application:1.0.0, and the second is a module used as a dependency to that application, com.foo:foo-framework:1.0.0. The third is a Maven plugin authored by our team, com.foo:foo-plugin:1.0.0.
My intention is that any project, e.g. foo-application, which uses classes available in foo-framework must also validate that it has used those classes correctly, where said validation is enforced by foo-plugin.
Is there a way to enforce this behaviour within foo-framework's POM.xml, whereby any Maven module which declares it as a dependency in its own POM will have foo-plugin executed as part of its build lifecycle?
No (at least no way that I'm aware of).
when you declare a dependency on something, youre declaring a dependency on its output artifacts (and transitively their dependencies as optionally described in that artifact's pom.xml file). There's no place in a pom file to force anything on the build importing it - the build importing it may not even be a maven build.
it appears you may be able to do something similar via other tools though - for example checkstyle supports discovering rules from dependencies on the classpath (not exactly what you want and depends on users of your library running checkstyle configured just right)
I am currently working in a Java project, and we use maven to build the final jar. There are two ways to build the jars as we all know, i.e. one single jar with-dependencies, and a jar without dependencies. In the latter case, we need to add dependent jars to the classpath as well.
In principle both can work, personally I prefer one jar with dependencies, but in the project team members decided to use separate jar without dependencies. So hereby I would like to know which choice is better?
This question has no answer, since it depends on what you need to do.
If you're writing an utility package or component, that could be a dependency of another project, then there's no point in having all the dependencies inside it - it's better to leave dependency resolution to a dependency manager, like Maven.
If you, instead, are writing a full application packaged as a jar, I mean something with a MainClass that can be executed with java -jar myjar, then having the dependencies together will make distribution easier.
Consider that, for instance, if you're writing a webapp, that'll be packaged as a WAR, it normally comes with dependencies.
I am in my project reusing an open source maven-based component that includes a bunch of shaded (e.g, using the maven-shade plugin) direct and transitive dependencies in the component uber-jar. Unfortunately some of those dependencies clash with dependencies that my own project has. Specifically, the component's dependencies transitively include servlet-api 2.x whereas I need 3.x in my project - and they appear to be in the same namespace. The component's top-level dependency that pulls in servlet-api (lucene-demo) is actually not needed for the functionality of the component, so I'd be happy to remove it if possible. My project is built with Gradle.
What is the recommended way of dealing with this type of situation? Is there any way of removing the offending dependencies from the reused uber-jar when I build my own project? Or should I rebuild the reused component myself, excluding the troublesome dependency? If so, can this be done in an automatic manner, such that I don't need to maintain my own fork of the open source component? The component is presently hosted in GitHub and published via Maven Central.
(As you might understand, I'm a bit of a beginner to both Maven and Gradle, so don't worry about dumbing things down).
I'm building an Eclipse plugin using Tycho and am making use of Declarative Services for my OSGi services. Eclipse has a nice Editor for DS files, but it still is a manual process, which means it's slow and error-prone.
In non-Tycho OSGi projects I can use the maven-scr-plugin to generate these annotations. The catch with Tycho is that I can't add a reference to the org.apache.felix.annotations jar since it's
not present in a p2 repository
not a bundle
These annotations are defined with a RetentionPolicy = CLASS, so they don't have to be in a bundle.
I know about dependency on pom-first artifacts, but it's not going to work for me since the annotations jar is not a bundle. Ideally I could just configure Tycho/Eclipse to look for an extra jar just at compile time.
How can I get a compile-time only jar considered by Tycho and Eclipse?
Update: I've tried to use the extraClasspathElements option of the tycho-compiler-plugin. That does allow me to invoke the maven-scr-plugin (see the current pom.xml). However, it seems that the scr plugin can't access the classes, as the build fails with
[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.13.0:scr (generate-scr-descriptor) on project org.apache.sling.ide.eclipse-core: /mnt/md/robert/git/sling-ide-tools/eclipse-core/src/org/apache/sling/ide/eclipse/core/ServerUtil.java : Unable to load compiled class: org.apache.sling.ide.eclipse.core.ServerUtil
You can also see the full build log
Since you are using Tycho/Eclipse, you probably want to use "org.eclipse.equinox.ds" rather than "org.apache.felix.annotations". If I understand correctly, org.eclipse.equinox.ds is a bundle. The Tycho FAQ mentions this as well:
http://wiki.eclipse.org/Tycho/FAQ#How_to_add_a_undeclared_dependency.3F__.28e.g..2C_OSGi_declarative_service.29
EDIT:
http://eclipse.org/tycho/sitedocs/tycho-compiler-plugin/compile-mojo.html#extraClasspathElements
EDIT2: A lot has changed. I'll be updating my answer when time permits. Check the comment threads in the meantime =)
I think the best you can do is to separate your building in two steps.
One for building the felix (scr/bnd) based bundles. the result will be on a local maven repository and all will be already bundles with the manifests and component xmls.
As the annotation is processed only at building time you won't have any problem with the following step.
The second step is to build the tycho based artifacts(bundles,features,rcp,p2,etc) that will consume the bundles in the first build.
I am using the hector & astyanax projects. These projects used to require maven, and now astyanax requires gradle.
I would like to statically link one of these projects to my java project (which is not built using maven/gradle). I am not interested in updating the version of astyanax every time they make a new release. I am not interested in mavenizing/gradelizing my own project.
So, two problems arise: 1. Getting the astyanax jars. 2. Getting the depenedency Jars.
At first, not having time to thoroughly understand maven (get off my lawn!), I copied all of the jar files in my global .maven directory into my project, and linked to them. Problem is, it's a pretty messy solution.
Is there an easier way to get all jars needed to use a gradle/maven library? (While I don't mind using gradle to build astyanax, I don't want to use it to build my own project).
Getting jars for distribution, seems like a very basic use case, am I missing a simple way here?
astyanax is published to maven central as com.netflix.astyanax:astyanax:1.56.42. Any build tool (Grails, Maven, Gradle, Buildr, SBT) that resolves from Maven can make a dependency on Astyanax and have its dependencies transitively downloaded. That fact that it's built with Gradle doesn't change how it's consumed.
From your question, it's unclear how you want to resolve these libraries. If you don't want to use a tool (Grails, Maven, Gradle, Buildr, SBT), then you'll have to manually navigate every dependencies and its dependencies from Maven Central. It's quite uncommon for a modern java project to manually download dependencies anymore, the practicalness given the complex dependencies graph make it prohibitive.