The paket.dependencies sample file produced when running dotnet new fake currently looks like:
// [ FAKE GROUP ]
group Build
source https://api.nuget.org/v3/index.json
nuget Fake.DotNet.Cli
nuget Fake.IO.FileSystem
nuget Fake.Core.Target
I understand how dependency groups can be used to solve version conflicts, however it seems unnecessary to introduce them until an actual version conflict situation arises.
What is the semantic of the Build group here and why not just have the three dependencies under the Main default group? The same reflection applies to the Test group in the Paket documentation example.
Can one elaborate on reasons for segregating dependencies in groups in the case of no version conflicts? Maybe explaining a bit more the rationale behind the Build and Test groups?
As I have basically introduced that split for FAKE 5:
The reasoning is that one set of the dependencies is used at BUILD-time (ie when running the build script) and one is for your project RUN-time. It is completely valid to have a different set of dependencies for those two.
Consider the following scenario: You use the FSharp.Formatting (FSF, a markdown parser) project in your build process to generate API documentation and in your project to generate websites. Now you want to update the API documentation by updating FSF but you cannot upgrade FSF in your project for compatibility reasons. With the separation between BUILD and RUN-time this is not a problem and you can see them as "different" dependencies in different versions.
I'd like to see that approach similar to how node separates dependencies and dev-dependencies
Regarding the split between RUN and TEST: Personally I'm not a huge fan. I can see how people want to separate their dependencies but paket currently doesn't "really" support that scenario and you can indeed run into issues with that approach. My current suggestion would be to not split between RUN and TEST and manage them in a single group.
To properly split between RUN & TEST paket would need a new feature to reference another group:
group Run
source https://api.nuget.org/v3/index.json
nuget MyDep1
group Test
reference_group Run
source https://api.nuget.org/v3/index.json
nuget MyRunner1
Similar to the external lock-file feature: https://github.com/fsprojects/Paket/pull/3062#issuecomment-367658114
Related
I have two independent .net projects. One is like a project which is baiscalliy to process invoice and another project is something which I am calling as common as I am keeping all sharable/reusable code under that.
Now any project can consume this common-project by adding it via add Existing project option so that source code will not move to consumer project which is Invoice management in my case.
Now if I add common project as reference and run my CI pipeline its failed as its not able to find the path of common project which is obvious as it may be different from my local machine to build server.
Now the solution that I am aware of are below :
Make common as Nuget package and use it under invoice management.
Build common project dll at some centralized file server and give that path in Invoice management
for reference instead of absolute path.
Both solutions are not simple to implement so I am looking for any better quick solution for the situation where project setup is like this and CI build has to execute.
The best would be actually reference via NuGet package. However, there is a third option which I do not recommend. You can use multiple repository pipeline. You will checkout there two repositories. In thi case you have to mimic folder structure wich you will get on AzureDevops. Otherwise build will fail as it will not find the references.
Suppose, I have an opensource project that depends on some library, that must be patched in order to fix some issues. How do I do that? My ideas are:
Have that library sources set up as a module, keep them in my vcs. Pros: simple. Cons: some third party sources in my repo, might slow down build process, hard to find a patched place (though can be fixed in README)
Have a module, like in 1, but keep patched source files only, compile them with orignal library jar in classpath and somehow replace *.class files in library jar on build. Pros: builds faster, easy to find patched places. Cons: hard to configure, that jar hackery is non-obvious (library jar in repository and in my project assembly would be different)
Keep patched *.class files in main/resources, and replace on packaging like in 2). Pros: almost none. Cons: binaries in vcs, hard to recompile a patched class as patch compilation is not automated.
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
This is what I would do (and actually what I do) for both a corporate and an opensource project. Get the sources, put them under version control in a distinct project, patch them, rebuild the patched library (and include this information in the version, something like X.Y.Z-patched), deploy it to a repository (you could use SVN for this, a la Google Code1), declare the repository in your POM and update the dependency to point on your patched version.
With this approach, you can say to your users: check out my code and run mvn install and they will just get the patched version without any extra action. This is IMHO the cleanest way (not error prone, no class path order mess, no increase of the build time, etc).
1 Lots of people are deploying their code to their hosted subversion repository (how-to in this post).
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
I'd agree with this and Pascal's answer. Some additional notes:
you may use dependency:unpack on the original artifact and then combine that with your compiled classes if you don't want to rebuild the whole dependant project
in either case, your pom.xml will need to correctly represent the dependencies of that library
you can still integrate this as part of your project's build to avoid the 'deploy to a repository' step
make sure you honour the constraints of the project's license when doing all this!
Is there an open source project that can serve as a good example on how to use the maven site plugin to generate reports? I would prefer it to
consist of many modules, possibly hierarchically structured
use as many plugins as possible (surefire, jxr, pmd, findbugs, javadoc, checkstyle, you name it)
the reports should be aggregated: if some tests fail you want to have a single page that shows all modules with failing tests, not only a gazillion individual pages to check
include enterprisey stuff (WAR, EAR etc), but this is not so important.
The idea is to have something where you can gather ideas on how it is done and what is possible.
I gave up trying to aggregate reports of a complex multi-modules project with the maven-site-plugin. For this, I use Sonar, it's much more powerful (with features like evolution of metrics over time, aggregation, neat drill down, etc) and just works. Have a look at Nemo, the online demo instance and cry.
For an example see http://www.bartswennenhuis.nl/2013/12/maven-aggregate-reports-for-multi-module-projects/. Findbugs does not support aggregate reports.
I don't think there is such a project, if there is I want to know it as well. In order to find things in maven you have to know what you're looking for(which is not exactly the same with what you want to accomplish).
If its any help I'm building 13 module project with MAVEN, use cobertura maven plugin, surefire, javadoc, etc .. it works as charm, why are you asking this question, you want to determine the capabilities of maven or ?
this is actually a response to your question. please take a look at the Apache Directory project. it contains two big blocks: the directory server and the tooling support (Eclipse based).
you can find the SVN repository of the Apache Directory Studio (this is a complete directory tooling platform intended to be used with any LDAP server) here: http://svn.apache.org/repos/asf/directory/studio/trunk/
take a look at the POM file ( http://svn.apache.org/repos/asf/directory/studio/trunk/pom.xml ) of this multi module project. it consists out of lots of modules, uses most of the plug-ins you're using and it also aggregates some of the reports.this
You can use Violations Maven Plugin to aggregate Findbugs (and many other static code analysis) reports.
It needs to run after the analysis. It will parse their report-files and present them in one unified report. It can, optionally, fail the build depending on number of violations found.
I would like to produce a binary zip distribution of my project that would contain an uber jar and a set of scripts. Right now, I am using two descritors, first one for the uber jar, and the second for the zip that contains the uberjar + extra scripts and documentation. The problem is that both of these get deployed to maven repo, while I don't actually need the uberjar, only the distro. Is there any way to either:
create the distro using one descriptor or
avoid the uberjar being deployed?
Edit: I found this question regarding part 2, but perhaps there is an easier way to do it...
In my opinion, the easiest way is to create the uberjar in one module (set the skip optional parameter in the maven-deploy-plugin configuration to bypass it during deploy) and to create the zip distribution in another module (using a dependency on the previously created assembly as described in Assembling Assemblies via Assembly Dependencies). And that's very close to what you already have which is good news.
I have checked a few testing solution for OSGI including PAX and had a quick look at the abstract TestCase within Spring DM but they both appear to require one to jar up and bundle associated bundles. I was hoping to find something that works without this intermediate step.
Imagine the ability to package up packages on your classpath so that packages x and y made up bundle XY and packages x and z made up bundle XZ. Bundle XZ would not "see" package "y" but could import a service from XY living in package x. Any comments if this is possible or if a equivalent test case / library exists ?
I think that using Tiny Bundles from OPS4J with Pax Exam is what you are looking for.
http://wiki.ops4j.org/display/paxexam/ExamAndTinybundles
If you really want to enforce runtime visibility rules than you probably have to run your tests inside OSGi environment and pay some performance overhead.
However it might be sufficient for you to enforce compile time visibility by separating your classes into distinct compilation units (e.g. separate Maven modules X,Y,Z) with proper dependencies and then running a standard testing framework (e.g. JUnit) without OSGi.