After an upgrade from 8.2 to 8.23 I'm experiencing violations for missing <p> tags before and after the URL in the license header
/**
* Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version
* 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions
* and limitations under the License.
*/
package bla;
import blu;
public class Bli {
without changing the code.
I'm not sure whether the violation is correct, i.e. whether the rule should be applied to text above package or whether it's a bug.
In case it isn't a bug I'm planning to suggest and option to allow turning of this check more easily.
I'm using checkstyle through Maven 3.6.0 with the maven-checkstyle-plugin 3.1.0.
The easiest approach would be to change /** */ to /* */ in the license header, but I don't want to have to propose and do the change for a tool version upgrade.
If comment has javadoc identtifier, checkstyle apply all rules to it. Violation is valid.
If you do not want to change header format, please use suppression https://checkstyle.org/config_filters.html
Related
I need to use JSON in my Notes project. I've downloaded a library for it here https://openntf.org/main.nsf/project.xsp?r=project/JSON%20LotusScript%20Classes. I get a JSON String from back-end side, do some manipulations with JSON And later I need to parse it back into a String. But unfortunately, I can use either JSONReader or JSONWrapperConverters script. Cannot use both for some really stupid reason. It gives me the following error.
So I am able either to parse a string using JSONReader or cast it back to a string using JSONWrapperConverters. I need to do these 2 things together, obviously.. What is the problem? Why it cannot use 2 libraries at the same time?
The problem was easy to solve as hell. JSONReader's comment
'use the JSONWrapperConverters instead of JSONArray and JSONObject if you need the ability to convert the JSONObject or JSONArray to a JSON string
'Use "ls.snapps.JSONWrapperConverters"
%REM
Copyright 2007, 2008, 2009, 2010 SNAPPS (Strategic Net Applications, Inc.)
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and limitations under the License.
%END REM
So just adding Use "ls.snapps.JSONWrapperConverters" instead of
Use "ls.snapps.JSONArray"
Use "ls.snapps.JSONObject"
Solved the problem.
I am trying to import code and static code check results for APL language (there is no plugin for SonarQube). I have imported all files as txt, created manual rules and manual issue. Installed SQALE plugin and defined measures for my rules, but technical debt is not calculated.
I assume that this is because my rules are not in QualityProfile for my project (I used standart SonarWay C#, Project has C# as language), but I just can not add them there :(
Here is what I get when I try to activate them -
0 rule(s) changed, 50 rule(s) ignored in profile Sonar way - C#
Manual rules can't have technical debt, even if you configure a remediation function for them thanks to the SQALE plugin.
Just for your information, please note that in next version of SonarQube (5.5), the concept of manual rules and manual issues is going to be dropped - see SONAR-7470. The reason is that SonarQube should remain an automated code review tool, and not try to compete with manual code review tools that have a complete different way of working.
Also, as a side note, if you have installed the SQALE plugin (which is a commercial one), you should have purchased a license for it and therefore you get support for this. In this case, you should contact SonarSource support to get help.
We are open-sourcing a java software system that was previously proprietary. We loosely followed semantic versioning, by Tom Preston-Werner, where:
Bugfixes imply a patch update (for example, 1.0.X)
Changes to your Public API that are backwards-compatible imply a minor update (for example 1.X.0)
Changes to your Public API that are backwards-incompatible imply a major update (for example X.0.0)
The task of open-source the system required us to rename packages. We also felt we should consolidate much of the modules that existed previously.
The restructuring tasks do not alter the Public APIs, but does change the dependencies for API users.
Where does restructuring/package renaming fit in to semantic versioning? How is a restructuring like this handled in well-know open source projects?
If client code has to be changed to work with a new version, that's an incompatible API change.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm currently struggling to understand the Ms-RL (Microsoft Reciprocal License).
I read the license four times now, but still I am unsure of the following things:
(Regarding especially 3A and 3E of the license)
If I use the library, without ANY change, do I have to publish the source code of my application?
Is it enough to add the Ms-RL to my own license, mentioning its validity for the used library?
UPDATE:
Do I have to publish my whole application then under the Ms-RL?
A link to the full license text.
And to quote the requested paragraphs:
3(A) Reciprocal Grants- For any file you distribute that contains code from the software (in source code or binary format), you must provide recipients the source code to that file along with a copy of this license, which license will govern that file. You may license other files that are entirely your own work and do not contain code from the software under any terms you choose.
Translation: For each file that uses files under the Ms-RL, you need to provide the source and a copy of the license.
3(E) If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution. If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
Translation: If you distribute any part of code (as source) under the Ms-RL, you can only do this with the Ms-RL. You need to include a copy of the license. If you distribute only compiled or object code, you can do that with any license that is compatible with the Ms-RL.
From Wikipedia:
This Microsoft license allows for distribution of derived code so long
as the modified source files are included and retain the Ms-RL. The
Ms-RL allows those files in the distribution that do not contain code
originally licensed under Ms-RL to be licensed according to the
copyright holder's choosing. This is equivalent to the CDDL, EPL or
LGPL (GPL with a typical "linking exception").
i would say this license is LGPL like.
For any file you distribute that contains code from the software (in
source code or binary format), you must provide recipients the source
code to that file along with a copy of this license, which license
will govern that file.
As long as your source files do not contain code from the software with this license, you don't have to apply the MS-RL to those files. The license is still attached to the "files" containing MS-RL code.
Typically you would license the entire software any way you wish, then add an exception for the files containing MS-RL code.
Disclaimer: I'm not a lawyer and i could be wrong.
I am currently working on automating/improving the release process for packaging my shop's entire product. Currently the product is a combination of:
Java server-side codebase
XML configuration and application files
Shell and batch scripts for administrators
Statically served HTML pages
and some other stuff, but that's most of it
All or most of which have various versioning information contained in them, used for varying purposes. Part of the release packaging process involves doing a lot of finding, grep'ing and sed'ing (in scripts) to update the information. This glue that packages the product seems to have been cobbled together in an organic, just-in-time manner, and is pretty horrible to maintain. For example, some Java methods create Date objects for the time of release, the arguments for which are updated by a textual replacement, without compiler validation... just, urgh.
I'm trying avoid giving examples of actual software used (i.e. CVS, SVN, ant, etc.) because I'd like to avoid the "use xyz's feature to do this" and concentrate more on general practices. I'd like to blame shoddy design for the problem, but if I had to start again, still using varying technologies, I'd be unsure how best to go about handling this, beyond laying down conventions.
My questions is, are there any best practices or hints and tips for maintaining and updating versioning information across different technologies, filetypes, platforms and version control systems?
Create a properties file that contains the version number and have all of the different components reference the properties file
Java files can reference the properties through
XML can use includes?
HTML can use a JavaScript to write the version number from the properties in the HTML
Shell scripts can read in the file
Indeed, to complete Craig Angus's answer, the rule of thumb here should be to not include any meta-informations in your normal delivery files, but to report those meta-data (version number, release date, and so on) into one special file -- included in the release --.
That helps when you use one VCS (Version Control System) tool from the development to homologation to pre-production.
That means whenever you load a workspace (either for developing, or for testing or for preparing a release into production), it is the versionning tool which gives you all the details.
When you prepare a delivery (a set of packaged files), you should ask that VCS tool about every meta-information you want to keep, and write them in a special file itself included into the said set of files.
That delivery should be packaged in an external directory (outside any workspace) and:
copied to a shared directory (or a maven repository) if it is a non-official release (but just a quick packaging for helping the team next door who is waiting for your delivery). That way you can make 10 or 20 delivers a day, it does not matter: they are easily disposable.
imported into the VCS in order to serve as official deliveries, and in order to be deployed easily since all you need is to ask the versionning tool for the right version of the right deliver, and you can begin to deploy it.
Note: I just described a release management process mostly used for many inter-dependant projects. For one small single project, you can skip the import in the VCS tool and store your deliveries elsewhere.
In addition to Craig Angus' ones include the version of tools used.