We have a large maven project and not all of the projects specify the same version of various libraries, largely because these libraries haven't changed in some time. This causes problems with debugging because IntelliJ frequently selects the older version when it's the newer that's being used at runtime. Aside from fixing the poms, how can we get IntelliJ to resolve to the sources for the correct version of the library.
There is no way to do it except configuring your project dependencies correctly (to use the same library version in all the modules).
Related
I am interested to see how people are doing release builds for an AEM project:
using the maven release plugin that is in pom.xml OOTB for this archtype
custom process using other maven plugins (build-helper plugin, version plugin)
Pros/cons for each option?
what is the release numbering mechanism that you use?
how is the patching done?
do you use a release branching mechanism?
Thanks
The OOTB maven build configuration from the archetype is good enough and extensively used across all the AEM projects I have been involved in. The versioning can be handled by modifying the version in the pom.xml
I have a .NET Standard class library project. I want the library to be available to the broadest array of consuming applications, so following Microsoft's advice here, I am targeting .NET Standard 1.3 in my project properties.
However, there is also a NuGet package called NetStandard.Library. And somewhere along the line, my project got a reference to this as well. What's more, it's a different version (1.6). I'm confused. Is this okay?
What is the relationship between these?
And somewhere along the line, my project got a reference to this as
well. What's more, it's a different version (1.6). I'm confused. Is
this okay? What is the relationship between these?
I think you should not worry too much about that.
1.6.1 is just the version of NetStandard.Library nuget package and it has nothing to do with the version of the target platform, and they don't interfere with each other.
The NetStandard.Library nuget package just service the related net standard project and provide any libs and apis to develop,build, debug the current project.
Besdies, NetStandard.Library 1.6.1 service net standard 1.x project while NetStandard.Library 2.0.3 services net standard 2.x projects.
So when you finishing developing it and pack your net standard 1.3 lib project as nuget package and then use it in target platform, actually, NetStandard.Library nuget package already finish its job and it is irrelevant in this step.
When you use such net standard project into other target platform projects, you only need to consider that whether the net standard version and the target platform version are within the scope of support as your linked document describes.
--------------Update 1-------------
Actually, sure.1.6.1 version is just only the nuget package version. NetStandard.Library 1.6.1 nuget package defines one or more standard.net version libraries.
And as far as I know, 1.6.1 version supports net standard 1.0~1.6 class library projects and the nuget package services for those net standard version.
And then it will direct the current project to the corresponding target platform projects.
Hope it could help you.
Am new to Scala/SBT but have experience in Java/Maven.
For a new Scala/Spark project, what should be the choice: SBT or Maven?
PS- I intend to use Eclipse or IntellijIdea as IDE.
Thanks
ATT
I have also been looking into this question. Here are some things I have found.
According to the Apache Spark documentation:
Maven is the official build tool recommended for packaging Spark, and is the build of reference. But SBT is supported for day-to-day development since it can provide much faster iterative compilation. More advanced developers may wish to use SBT. http://spark.apache.org/docs/latest/building-spark.html#building-with-sbt
Three reasons I have heard for SBT:
It was built for Scala
It has incremental compilation
.sbt files tend to be more compact
In response though
Maven works just as well
If you are using the JetBrains IntelliJ IDE, which has a free edition, it has its own incremental compilation.
I think I will decide to go with Maven as it integrates better with my build server (continuous deployment).
our software solution contains a Managed C++ library project which can be only compiled if the PC the compilation is running on has a valid installation of VS2008.
Usually I am the only developer working on this project, however my colleagues should be able to compile the solution as a whole with a precompiled version of this library, which is version controlled together with other third-party library dependencies.
So we've decided to add a reference on the DLL into the project which depends on the library, not adding the project itself as a reference. Now my question: is it possible to use the precompiled version when using a specific configuration (i.e. Debug) and to compile the library from scratch when building the project in Release mode, e.g. on a Jenkins server?
Thanks in advance!
I installed a Nuget on top of an application. The Nuget had a dependency to a newer version of a 3rd party dll than the base application, and now the base application cannot run because of this. How to take care of that? Is this a sign that either the Nuget or the base application violates good principles?
Afaiu the base application requires an exact version of the 3rd party dll (and the Nuget requires a later version).
Is the only way to recompile the base application with updated refs - or recompile the Nuget with ref to the older dll version?
A possible workaround could be to install the Nuget withouth automatically installing the newer version of the 3rd party dll, but I don't know how to do that.
It's kludgey, but I would install the older version of the library that the base application requires to the GAC. This isn't ideal, and will have to be accounted for in your installation scenario, but the GAC does allow multiple versions of the same library to be referenced.