after update to tycho 0.14.0, i'm seeing this warning:
[WARNING] Entry: germantechEcfNfe/plugins/org.eclipse.ui.intro.universal_3.2.500.v20110510/themes/slate/graphics/standby/fs_standbyhov.gif longer than 100 characters.
any way to disable this kind of verification?
thank you guys
edit: my build isn't broke or something, but my log is getting full and becomes hard to read the output
Before the 0.14 release there was no way to build product archive files using the .tar.gz format, this is probably the reason you didn't get any error from previous builds.
I have the same problem and by looking at the tycho-p2-director-plugin sources I discovered that it uses the plexus archiver directly instead of delegating to the maven-assembly-plugin.
So by setting the tarLongFileMode property in the maven-assembly-plugin configuration won't remove warnings from your build log.
the warnings are caused by the maven tar archiver. By default, it warns for tar entries with path length > 100 chars. Considering this is an ancient tar format limitation, I changed the default to "gnu" for tycho 0.17.0-SNAPSHOT so you should no longer get these warnings:
https://github.com/eclipse/tycho/commit/5db5cc2b76bdba8526cfc4acb66b3e4674f23f03
Related
As in the subject, we are currently stuck at very (!) old version 2.3.3.1. We must upgrade to the latest (or a least a much more recent) version.
I suspect I'll need a few steps to make such a version leap.
Please give me any pointers you may find useful. This has landed on me, and I've never worked with Artifactory before.
As you suspected, there are several versions you'll have to go through, like 3.9.x.
You can find more info here and here
Following the directions above:
I have taken us to 2.6.7 as a necessary upgrade step, and today I worked on moving to 3.9.2 as a next necessary step.
I have followed the official instructions from https://www.jfrog.com/confluence/display/RTF3X/Upgrading+Artifactory
The "empty" 3.9.2 worked fine of course, so I proceeded with the copy of the filestore and then the import of the System export. The Export had been done as instructed, i.e. with Content excluded, and nothing else excluded.
The import finished but with 99 errors. These were of these three types:
A file missing from the export. In all cases, the export contained a folder with the same name as the file but with a ".artifactory-metadata" appended to its name. So for example instead of
/BACKUP_DISK/ARTIFACTORY/20200402.192450/repositories/jboss-releases-cache/jboss/jboss-j2ee/4.2.0.GA/jboss-j2ee-4.2.0.GA.pom
...in the export there was this folder:
/BACKUP_DISK/ARTIFACTORY/20200402.192450/repositories/jboss-releases-cache/jboss/jboss-j2ee/4.2.0.GA/jboss-j2ee-4.2.0.GA.pom.artifactory-metadata/
...containing two files, artifactory-file.xml and artifactory.stats.xml
Errors about failure to import a file because "MD5 value 'null' is not a valid checksum"
Errors about failure to import file because " Artifact rejected: The repository 'codehaus-cache' is blacked out and cannot serve artifact"
The last disturbing thing is that the new installation in the Home page states that there are half as many artifacts as in the 2.6.7 installation. I wonder if some kind of merging/relabelling has been done, and I should not worry about that.
I'd be grateful for any clues on the above.
I am using php-cs-fixer for code formatting in Netbeans 8.2. When I try to format one file, it shows the error
Files that were not fixed due to errors reported during linting after fixing:
I searched for the fix in many websites, but couldn't get this fixed. Is there any way to fix this? I tried with both php-cs-fixer 1 and php-cs-fixer 2.
The error message means that PHP CS Fixer loaded some files from drive, apply changes on them, and then realised that files are not valid anymore (invalid PHP syntax) after those changes, thus it decided to not save it. That's one of the safety mechanism of PHP CS Fixer to not break your project.
This means that you have found an issue in PHP CS Fixer itself.
Please, verify you are using newest release, maybe the bug was already fixed!
If not, please consider to expose your configuration file (if any) and content of files you got listed at https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/new !
There is also an option to see what happen in progress.
$ ./vendor/bin/php-cs-fixer fix src/ErrorFile.php -vvv
The --verbose option will show the applied rules. When using the txt format it will also display progress notifications.
NOTE: if there is an error like "errors reported during linting after fixing", you can use this to be even more verbose for debugging purpose
-v: verbose
-vv: very verbose
-vvv: debug
I'm working in a project in a very security concious place with no access via proxy to all the online repositories SBT usually requires. We'd like to fetch the dependencies and transitive dependencies we need once.
How can sbt be forced to fetch all the dependencies a project needs once and from there on, only work offline? I have tried doing exactly that from home. I then copied over everything under:
~/.ivy2/cache
~/.ivy2/local
$ACTIVATOR_HOME/repository
but still SBT even when executed with sbt "set offline := true" run goes and tries to fetch everything online ... is a pain. Then finally breaks and complains it doesn't find some dependency.
UPDATE: I noticed another source of troubles but can't yet conclude it is the culprit of the OP broken build issue. I build and get the dependencies for the project from a Linux (Ubuntu box) and then I copy all the files to the corporate Windows 7 Pro environment. I found that many property files under ~/.ivy2/cache refer to the absolute path of the activator repository directory in Ubuntu and this is of course incorrect in the Windows env e.g.
#ivy cached data file for ch.qos.logback#logback-classic;1.1.3
#Fri Mar 10 08:39:37 CET 2017
artifact\:ivy\#ivy.original\#xml\#-1844423371.location=/opt/dev/activator/1.3.12/repository/ch.qos.logback/logback-classic/1.1.3/ivys/ivy.xml
artifact\:ivy\#ivy\#xml\#1016118566.is-local=true
artifact\:ivy\#ivy\#xml\#1016118566.location=/opt/dev/activator/1.3.12/repository/ch.qos.logback/logback-classic/1.1.3/ivys/ivy.xml
artifact\:ivy\#ivy.original\#xml\#-1844423371.is-local=true
artifact\:ivy\#ivy\#xml\#1016118566.exists=true
artifact\:logback-classic\#jar\#jar\#804750561.is-local=true
artifact\:logback-classic\#jar\#jar\#804750561.location=/opt/dev/activator/1.3.12/repository/ch.qos.logback/logback-classic/1.1.3/jars/logback-classic.jar
artifact\:ivy\#ivy.original\#xml\#-1844423371.exists=true
artifact\:logback-classic\#jar\#jar\#804750561.exists=true
So I went and did a find and replace but the build still doesn't work. It doesn't look like a brilliant idea to have thousands of property files hardcoding an absolute path to the activator location. I would rather prefer they use an environment variable for that.
Maybe you could try coursier?
No only it offers
better offline mode - one can safely work with snapshot dependencies if these are in cache (SBT tends to try and fail if it cannot check for updates)
but also is much faster than Ivy due to parallel artifacts downloading. The project is young but promising.
Anyone know if it's possible to build a VS2003 project from the command line without showing any warnings? We've got a heap of VS2003 projects that get built by TSFBuild as part of our platform build and the warnings are just noise in the build log file.
I have looked at the parameters by running devenv.com /help and nothing there seems relevant. VS2010 has a build output verbosity setting but I couldn't find one for VS2003. I am also looking to see if it can be configured through the project file.
Seems like you're building your projects using MSBuild. If so, you can try suppress the warnings by setting the WarningLevel property as suggested here. Or you can choose the console logger to not show the warning and error summary, then output them to seperate files as provided here:
/consoleloggerparameters:parameters
NoSummary: Hides the error and warning summary displayed at the end
of a build.
/fileloggerparameters:
You can use up to ten file loggers by
following the parameter with a digit
identifying the logger. For example,
to generate separate log files for
warnings and errors, use -
/flp1:logfile=errors.txt;errorsonly
/flp2:logfile=warnings.txt;warningsonly
So, I now know what to save from nightly builds. What about when I give something to customers?
For example, I probably want to save debugging information (e.g. PDB).
What else?
We use:
installers
binaries
pdbs
tag of source files
any other source files that might not be in svn - for example config.status
build log
You made me wonder if I'm missing anything important
Compiler and library version information (it may not be part of the build log). Somebody else mentioned the whole binaries.
Linker map file (it can sometimes help the remote debugging of a problem).
Unstripped executable (if on a Unix system you strip it the executable before making it available to clients).
For the SDK releases we do include:
PDB and XML for the libraries (packaged with the latest snapshot of the samples)
Packaged snapshot of sources from SVN (just because we can)
Link to the online documentation (docs are generated from the source automatically)
Trace messages don't necessarily need to be generated by default but the possibility to enable them can be very helpful.
Results and Information generated from ATPs that are run on the build (probably as part of the build process).