I have noticed that Mapstruct 1.3 will introduce constructor injection. Is there a Maven repository containing SNAPSHOT releases?
The MapStruct SNAPSHOTs are published at https://oss.sonatype.org/content/repositories/snapshots. You can also use https://jitpack.io/ in case you want to take a specific commit from MapStruct
Related
What is the best practice for managing dependencies within a Simulink Project when the project is worked on across a team and the project has dependencies on different models and libraries?
An parallel example would be when building an application using Gradle and declaring the dependencies of a project including the required version numbers. Grade will resolve and download the versions that are required to build the project.
e.g. the following declares a dependency on version 2.1 of library and version 1.0 upwards of some-library, so that the latest version 1.x (1.0, 1.1, 1.2...) that is available will be downloaded and used.
dependencies {
compile("com.example:library:2.1")
compile("com.example:some-library:1.+")
}
The documentation for Simulink (and also here covering manifests) seems to talk about models within a project having version numbers. It doesn't seem to mention libraries that are imported into the project. Models that are only used within a single project could all be contained in the overall project, but what happens if there are (for example) generic S-Functions defined within a separate project or library (or library defined within a project) that are applicable across multiple projects? This requirement is all with the aim of helping to support an automatic build process triggered by a Continuous Integration server, such as Jenkins.
I'm interested in a workflow that will easily support dependency management and automatic dependency resolution with a Github Flow git branching policy.
I've spent much time on this problem. Finally I didn't find an appropriate solution online, but I'd like to share the workflow we are using now and which fulfills our needs.
In short: We created our own dependency management by using git submodules.
Assumption: In fact, it is more a version management of persistent dependencies rather than offering the possibility to dynamically add new or remove old packages or libraries. This also works, but requires the git submodules to be added to or removed from the main git repository.
Objectives:
Consistent setup for everyone who works on the project.
Traceability of depdendencies.
Continous Integration with less effort.
How we do it (Example):
We have Project A and Project B which shall be used in Project C.
All three projects are under git version control and still under development.
We have set up additional release repositories for Project A and Project B, e.g. located on a network drive.
In Project C we add the release repositories of Project A and Project B as git submodules
We have set up some kind of auto-deployment to push only relevant files into these release repositories. For example if we want to make changes of Project B accessible to Project C, we only create a version tag in Project B's repository and it gets pushed to its release repository.
In Project C we update our git submodules and can checkout a new submodule version (if needed).
Advantages:
Since git stores the checked out version (commit) of git submodules in the main project, we can ensure that everyone works with the same files.
Changing the commit of a submodule is traceable in the main project.
The relation between the main project and the dependencies is always consistent.
Continuous Integration should work "out of the box". We are using GitLab and GitLab Runner and only had to setup our runner to fetch submodules recursively (in case of nested submodules).
I think this approach works as long as the repositories won't get too big, since you do not fetch only the version you need but also the whole version history.
I have a project on Github and I have set a release with a Jar for that project. I want to include this Jar in another project as an SBT dependency. How do I set up the resolvers to look for my jar in the github repo.
You want to release your jar into a repository. One option I would recommend is bintray, see bintray-sbt which is an sbt plugin for publishing to bintray, and details how to setup your second project to fetch the publish artifact.
There is a port of shapeless library to scala-js (https://github.com/alexander-myltsev/shapeless). I need to publish artifact properly with fewer possible dependencies to original shapeless.
Now I forked Miles Sabin's repo, and added changes required to generate scala-js library: add scalajs-sbt-plugin, tune build.scala, add bintray-sbt-plugin.
It is wrong to ask shapeless maintainers to merge my branch because scala-js could broke their build.
On the other hand I'd like to have minimal dependencies to original repo as well. Theoretically and ideally what I'd like is to create, say, shapeless-scalajs sbt-project from scratch. Then reference somehow original shapeless library. And then derive from shapeless-build-scala with required overrides to build it against scala-js and publish to my bintray.
I believe in almighty sbt :) What are my options to solve this task?
I think the easiest way is (no sbt hackery involved):
Fork shapeless
Create Scala.js branch
Change build files as you need. That is, modify the shapelessCore project directly as in your PR. (add scalaJSSettings, your repo coordinates)
Commit
Publish shapeless to your maven central
When a new version of shapeless comes out, just merge shapeless/master with your scala.js branch. If no changes happened to the build file, this will merge just fine.
Re-publish
This will be way easier than an sbt project that depends on an external project (which is doable, but doesn't directly allow you to reuse settings etc.)
We use Gradle to build our projects and to manage our dependencies. We want to reuse our legacy Ivy repository which is filesystem based. Our convention was to have several artifacts per module - one of them being a source artifact.
The normal jars are perfectly managed by the Gradle Eclipse integration. But we are not shown the source artifacts. Are there any conventions for this kind of setting, e.g. name of the source artifacts?
artifactName-sources.jar should work, as should defining a configuration named sources (and assigning sources artifacts to that configuration) in the iyy.xml.
Our company uses Maven. We use the Nexus repository manager in order to store our snapshots and releases.
Currently, we are developing a product based on Eclipse. We use Tycho to do that.
The problem is the following: In our Eclipse-based product we have many features. Our idea is build each feature (or group of features) separately and put them in internal p2 repositories. When one features requires another feature, we point the target platform to necessary internal p2 repository.
Currently, we build application with Tycho. We make our features "deployable", so Tycho produces a P2 site in target. We push that P2 site to our server and then run Eclipse FeaturesAndBundlesPublisher, which merges that recently-built feature with a P2 repository. As a result, we have a internal P2 repository having all the versions of required feature.
We find that this process is too cumbersome. Is there a tool like Nexus, which would be more convenient?
UPD.:There is a discussion on Tycho Users list
With the Unzip Repository Nexus Plugin, you can use Nexus for exchanging binary artifacts between Tycho builds.
Tycho project A publishes its artifacts like a normal Maven project: The project is built with mvn clean deploy, which uploads the project's artifacts into your deploy Maven repository on the Nexus. The only special requirement is that the project builds a p2 repository. The recommended way to do this is an eclipse-repository module, but a "deployable feature" should also work in most cases.
On your Nexus, you only need the following one-time configuration: For the deploy Maven repository (or a "Repository Group" which includes that repository), you need to add a virtual repository of type "Unzip Repository". This virtual repository shows zip artifacts from the deploy repository in unpacked form.
Example: If the p2 repository zip of project A is in the deploy Maven repository at http://nexus.corp/nexus/repositories/build.milestones/corp/example/project-a/project-a-repo/1.0.0/project-a-repo-1.0.0.zip, it will be available in standard p2 repository format in the Unzip Repository at http://nexus.corp/nexus/repositories/build.milestones.unzip/corp/example/project-a/project-a-repo/1.0.0/project-a-repo-1.0.0.zip-unzip/.
Tycho project B can reference the artifacts from project A by adding the latter URL to its target platform, e.g. in a target definition file.
In the above example, project B references a release version of project A. The same approach also works for snapshots because the Unzip Repository has support for "symbolic" versions, like 1.1.0-SNAPSHOT for the last deployed 1.1.0-SNAPSHOT or even just SNAPSHOT for the overall highest version. Using these symbolic versions, Project B can then, for example in its own CI build, reference the CI build results project A by adding the resulting (stable!) p2 repository URLs in its target platform.
Disclaimer: The Unzip Repository Nexus Plugin is part of the Tycho project, of which I'm a committer.
Maybe this is a bit late, but I am currently working on an open source (EPL) repository manager which supports the workflow of deploying to a repository with maven and tycho, and consuming it as P2 repository.
It is also possible to deploy bundles created by maven (not maven tycho) and the P2 metadata will be generated automatically.
The project is called "Package Drone" and hosted on github. There is also a short introduction video.