I want to check if my project dependencies have any updates.
I've used
versions:dependency-updates-report
But I have some performance problems with it which I was unable to solve. Now I'm trying to use
org.owasp.dependency-check-maven:check
But I could not reproduce their example:
I'm getting similar look but I can't get 4 last columns (Next Version, Next Incremental, Next Minor, Next Major) which is most important for me.
How to reproduce this example?
(full disclosure - I am the founder of meterian)
You may want to consider a commercial product like sourceclear, snyk or meterian.
The meterian client is very easy to use, you can quickly check any maven or gradle project with no changes to the code: get the client, cd into the project folder, run it, see the results.
It's free for open source projects, badges are available for GitHub, and at the moment commercial use is not charged.
Hope this helps.
You will not reproduce the given report with org.owasp.dependency-check-maven because the shown report is created with versions-maven-plugin.
This are two different plugins.
org.owasp.dependency-check-maven is to find vulnerabilities according to the NVD in dependencies whereas versions-maven-plugin is for checking for newer versions, independent of vulnerabilities.
Related
I am developing a Java framework/API to solve a problem at a client. The code/idea is my property (not the client's). I think it might be useful for others, so I would like to publish it as a open source project.
By publishing I mean bringing it out in the open - making it available as a Maven project.
I can think of conforming to Maven structure, proper documentation/example usage available on a web site, and unit tests, maybe some code coverage threshold.
But does it have to be run by some committee? Do I have to present it to somebody? What steps do I need to take to eventually have it available as a Maven dependency?
There's no committee or approval process that I know of. All you have to do is put your code into a public Github repo. This is how open source software works.
Per Kapep's excellent suggestion below, you have to choose a license as well. Apache, Creative Commons, Gnu, MIT - these are a few of your choices. Know what they mean before you decide.
Your problem begins on that day - you'll have to make others aware of it and see if it's adopted by others. If it's good, you'll have the nice problems of dealing with a user base and having others change your code. If not, it'll languish in the repo.
I have recently been charged with building out our "software infrastructure" and so I am putting together a continuous integration server.
After a build completes would it be considered bad form for the CI system to check in some of the artifacts it creates into a tag so that it can be fetched easily later (or if the build breaks you can more easily recreate the problem.)
For the record we use SVN and BuildMaster (free edition) here.
This is more of a best practices question rather than a how-to question. (It is pretty easy to do with BuildMaster)
Seth
If you believe this approach would be beneficial to you, go ahead and do it. As long as you maintain a clear trace of what source code was used to build each artifact, you'll be fine.
You should keep this artifact repository separated from the source code repository.
It is however a little odd to use a source code repository for this - these are typically used for things that will change, something your artifacts most definitely should not.
Source code repositories are also often used in a context where you want to check out "everything", for example the entire trunk. With artifacts you are typically looking for a specific version, and checking out all of the would only be done if exporting them to some other medium.
There are several artifact repositories specialized for this, for example Artifactory or Apache Archiva, but a properly backed up file server will thought-through access settings might be a simple and good-enough solution.
I would say it's a smell to check in binaries as a tag. Your build artifacts should be associated with a particular build version in your build system, and that build should be associated with a particular checkin. You should be able to recreate the exact source code from that information. If what you're looking for is a one-stop-function to open the precise source-code revision that generated the broken build, I'd suggest that you invest some time into building a Powershell module that will do that for you.
Something with a signature like:
OpenBuild -projectName "some project name" -buildNumber "some build number"
I'm trying to build multiple tags of WSO2 Carbon side-by-side for comparison purposes, but I'm concerned I may be missing something about the directory layout and how to do the builds. Please could I have some help?
At present, I've checked out what I think are the relevant tags from:
https://svn.wso2.org/repos/wso2/tags/carbon/3.0.0/
https://svn.wso2.org/repos/wso2/tags/carbon/3.1.0_core/
https://svn.wso2.org/repos/wso2/tags/carbon/3.2.0/
https://svn.wso2.org/repos/wso2/tags/carbon/3.2.2/
https://svn.wso2.org/repos/wso2/tags/carbon/3.2.3/
I've then tried running Maven builds from the top-level directories of each of the checkouts (in various ways, some involving skipping the tests and others not), with varying results (almost all of them unsuccessful in one way or another, whether due to missing artifacts, failing tests or other reasons). I also tried building 3.2.2 and 3.2.3 from the .../carbon/3.2.2/patch-releases/3.2.2 directory and the .../carbon/3.2.3/patch-releases/3.2.3 directories, as per the answer #ThiliniIshaka gave here:
WSO2 sourcecode of identity server (wso2is-3.2.3-src.zip) is always built with errors
This seemed to work (after some fiddling around) for 3.2.2, but some of the tests for 3.2.3 fail and this pulls down the build (I can make it work with the -fn flag to Maven, but that just results in what looks like an incomplete build). Furthermore, the earlier tags don't seem to have a corresponding patch-releases directory, so the same technique won't work for them even if I get it working for 3.2.3.
As an aside, I'm also deeply confused by things such as the 3.2.2 tag containing a 3.2.3 directory under patch-releases, etc.
All of this leads me to think I may be missing the point in some fundamental manner :)
The questions I thus have are:
Am I checking out the right things in the first place?
From which directories and how should I be building each of the tags please?
Do I need the same version of Maven for all of the tags?
Is there any good build documentation for the various different versions explaining some of this please? I've found various technical blogs, but seemingly nothing foolproof and comprehensive (I'm probably looking in the wrong places).
Many thanks.
Answering for the above queries;
Yes, these tags are created for relevant branch and point releases of carbon.
As the previous thread suggests [1] you can build the source, could you please provide us with the issues you get when building the source?
Yes, you need to build above tags with maven2.
Only the trunk [2] (where the normal developments going on) needs maven 3.
Some hints are provided in this blog post.
Start from the root level with mvn install (to skip running tests, build with mvn install -Dmaven.test.skip=true). If you are to build tags related to point releases, build from patch-releases directory.
Hope this helps.
Thanks
I decided to use the following pattern after reading semantic versioning at http://semver.org/. However, I have some unsolved issues in my mind in terms of automaticng and integrating SDLC tools.
Version Pattern:
major.minor.revision.build
Such that;
Major: major changes, should be increamented manually.
Minor: minor changes, should be increamented automatically, whenever a new feature or an enhancement to existing feature is solved in issue tracking system.
Revision: changes not affecting the minor changes, should be increamented automatically, whenever a bug is solved in issue tracking system.
Assume that developers never commit the source unless an issue has been solved in issue tracking system, and the issue tracking system is JIRA in this configuration. This means that there are bugs, improvements, and new features as issue types by default, apart from the tasks.
Furthermore, I am adding a continous integration tool in this configuration, and assume that it is bamboo (by the way, I never used bamboo before, I used Hudson), and I am using Eclipse IDE with mylyn plugin and plus the project is a Maven project (web).
Now, I want to elucidate what I want to do by illustrating following scenario. Analyst (A) opens an issue (I), which is a new feature, related to Maven project (P). As a developer (D), I receive an email about the issue, and I open the task via Mylyn interface in Eclipse. I understand and develop the new feature related to issue (I). Consider, I am a Test Driven Development oriented developer, thus I wrote the Unit, DBUnit, and User-Acceptance (for example using Selenium) tests correspondingly. Finally, I commit the changes to the source control. I think the rest should be cycled automatically but I don't know how can I achieve this? The auto-cycled part is the following:
The Source Control System should have a post-hook script that triggers the Continous integration tool to build the project (P). While building, in the proper phase the test code should be run, and their reports generated. The user-acceptance test should be performed in a dedicated server (For example, jboss, or Tomcat). The order of this acceptance test should be, up the server, run the UA test, then generate the UA test reports and down the server. If all these steps have been successfuly completed, the versioning should be performed. In versioning part, the Maven plugin, or what so ever, should take the number of issues solved from the Issue Tracking System, and increment the related version fragments (minor and revision), at last appends the build number. The fragments of the version may be saved in manifest file in order to show it in User Interface. Last but not the least, the CI tool should deploy it in Test environment. That's all auto-cycled processes I want.
The deployment of the artifact to the production environment should be done automatically or manually?
Let's start with the side question: On the automatic deployment to production, this requires the sign off of "the business" whomever that is. How good do your tests need to be to automatically push to production? Are they good enough that you trust things to just go live? What's your downtime? Is that acceptable? If your tests miss something, can you rollback? Are you monitoring production so you know if you've introduced problems? Generally, the answers to enough of these questions is negative enough that you can't auto-deploy there as the result of a build / autotest event.
As for the tracking, you'll need a few things. You'll need all your assumptions to be true (which I doubt they are, but if you get there that's awesome). You'll also need a build number that can be incremented after build time based on test results. You'll need source changes to be annotated with bug ids. You'll need the build system to parse the source changes and make associations with issues. You'll need an API into the build system so you can get the count of issues associated with the build. Finally you'll need your own bit of scripting to do the query and update the build number accordingly.
That's totally doable, but is it really worth having? What's the value you attach to the numbering scheme?
These questions are for TeamCity users only
1) Is it possible to configure TeamCity to extract build artifact information based on your own your regular expressions? This is exactly what Pulse does here
2) Does TeamCity integrate with any task/bug tracking tool? like JIRA?
3) This question is for people who run static code analyzer only. A tool like PC-Lint/Visual Lint can generate XML reports. Can TeamCity be configured to parse these artifacts and generate a build failure?
4) I'm currently evaluating TeamCity right now...there community forum doesnt seem to be very active. For those who pay for support, how is Jetbrains support? Is it good? Atlassian seems to be much better.
TeamCity allows to get build artifacts with a Ant-based pattern. You can specify multiple patterns and set target directory for each pattern. Read more at http://www.jetbrains.net/confluence/display/TCD4/Build+Artifact
There is an integration which allows to link RF-3432 to the Jira issue. More advanced integration may appear in the next release of TC. Read more at http://www.jetbrains.net/confluence/display/TCD4/Mapping+External+Links+in+Comments
Only with custom plugin. Or your build process can send a specific "echo" message which will change build status and description.
OK, I'm JetBrainer. May be we don't response immediately, but we strive to answer forum questions ASAP. Paid customers also have e-mail support.
Hope this helps,
KIR
Disclaimer: I don't work for JetBrains! But I've worked with Pulse and TeamCity in my current job.
Build Artifacts: Yes, TeamCity will export artifacts that remain after a build. You can add define ant-style wildcard patterns to match files (the default pattern matches any files left in the root build directory). These files can be seen from the project view against each individual build.
You can use special service commands in a build script to immediately export artifacts along the way too, I do this for a code complexity tool that generates xml files, for which I've also defined a custom graph.
Bug Tracking: I don't have experience with this, but KIR pointed out some alternatives.
XML Parsing: You can control this with ant. I included a third-party tool called andariel in my build that can run XPaths across xml documents, then used service messages to export the result (in this case a count of methods exceeding a complexity limit) to be displayed in a custom graph.
I believe you could also publish the artifacts, provide TeamCity with an XSL to render the XML, and create an additional tab in your build results to display it (however I have not done this)
Tech Support: I've found the community forums to be pretty good, most questions I've had answered within a day or two by both civilians and Jetbrains employees, and I was using the free 'Professional' version.
I can only imagine that email support will be just as good if not better!
I am a little confused about this question because my use of TeamCity, TC (and I guess the design principles of TC) is to allow the build script (and not TC) to remain the correspondent of build imperatives.
In other words, if you need TeamCity to do something cool, just add that cool stuff in your build script either using an existing task in your build system or write one yourself.
TeamCity supports NAnt, MSBuild, Ant and am sure, any other build platform you can install on on the buildagents.
The only integration I will want TC or any other CI platform to have is source control integration with my choice of SC. The rest of the integration should be controlled by my build script. That way, I only configure my TC once at the beginning of project for each project and then, don't touch it ever again. In contrast, the build can change per version.
So, the indirect answer to your question is Yes, theoretically, through the build script.
Hope this helps.