dependency-management

In the past, we had our bundles and features on the file system and made them available in Eclipse through a target definition file with a 'Directory' location. In this way, it was easy to use them with the Export wizards in Eclipse. Now I'm trying to build an eclipse-plugin with Tycho which has third party dependencies, e.g. javax.vecmath and org.apache.commons.math . From what I know, the best way to obtain the dependencies in a Tycho build is through a p2 repository. So I'm using one for the Eclipse bundles. But for my third-party bundles, it seems that there is no p2 repository available.

I'm writing a cross-platform library that has platform specific dependencies, one for unix-like platforms, and one for windows. These crates only compile on specific platforms, wherefore I can't just add them all under dependencies normally. In the actual rust code I use cfg attributes, like #[cfg(unix)] to compile certain code for certain platforms, and I want to do something similar in the Cargo.toml, or in a build script, for the dependencies. Currently, I'm using target triplets like these: [target.i686-unknown-linux-gnu.dependencies.crate1] git = repo1 [target.x86-unknown-linux-gnu

I'm writing software that allows one to publish mathematical books as websites. It is based mostly on Python + Flask, but to deal with equations I'm using MathJax. MathJax can be used either client-side or server-side (through MathJax-node ). In the latter case I have to use npm to install MathJax-node in some place accessible to my main Python script, then invoke it from the script. In the former case, I have to provide MathJax.js as an asset, available to client (currently I use Flask's send_from_directory function). My question is: what is the best practice of dealing with such heterogenous

We have a multiwar project and with various people working on the project a lot of times, lots of unused jars are still specified as dependencies, is there any way , to check which jars are not used at all, but nonetheless, are being referred to as a dependency? I hope maven already has support for something like this, considering its such a powerful tool. Run mvn dependency:analyze . It should do the work. 来源： https://stackoverflow.com/questions/8133164/mavenhow-to-check-which-jars-are-not-being-used-at-all

I have a project which has both scala and java code which I am currently managing in eclipse using the scala IDE plugin. At present the directory structure is organized such that some packages have both java and scala code in them. There are scala classes which depend on java classes and there are other java classes which depend on the scala classes. The plugin handles all of this transparently – I believe (but I’m not 100% sure) that the scala compiler compiles both the java and scala code together which is how the cross dependencies are handled. I did find some references to compiling mixed

With the use of transpilers it is already possible to use ES6 modules. One of the easiest ways is using Browserify and Babelify. The problem I'm having is how to handle dependency management. In the old days you'd just have some Bower dependencies. The build would bundle non-CDN to vendor.js and project specific files to foobar.js (or whatever). So then you'd be able to use the resulting code in a different project by simply bower install foobar --save . If both foobar and your new project had a common dependency it would be easily resolved with Bowers flat dependency. Now in come ES6 modules:

With the maven jar plugin I build two jar: bar-1.0.0.jar and bar-1.0.0-client.jar. Actually in my POM I have the following dependency: <dependency> <groupId>de.app.test</groupId> <artifactId>foo</artifactId> <version>1.0.0</version> </dependency> This artifact exist also in two version bar-1.0.0.jar and bar-1.0.0-client.jar I want to make bar-1.0.0-client.jar dependent of foo-1.0.0-client.jar and bar-1.0.0.jar dependent of foo-1.0.0.jar . ================ ->First (wrong) solution: define the scope as provided and use the right foo package when using bar.jar ->Second (long) solution : Add