Is it possible to deliver an update which contains only the updated libraries and not the whole package of data. in our application only a few files are updates regularly. The other ones never. With Auto update over the net this would result in a much smaller package...
Is such a setup possible and how?
Thank you.
You can do this by saving your project to a different file (keeing the application ID) and removing the unnecessary files from the distribution tree. When you compile that project, an updates.xml file is created as usual. Use that updates.xml file for auto-updates instead of the updates.xml file from the standalone installer project.
Related
I am using the mybatis-generator in a maven project to generate the Java files for a few tables. At the end of the generation, I would like to generate a few non-java files like properties files and resources. However the default generator allows me to generate only XML and Java files. Is there any way to also get the generator to create sql files, SPI definitions and property files for example?
Looking inside the generator, it seems that the Generated java files and XML files go through some further process(formatting et al). Even if I write a custom plugin, I can generate an XML or an sql file only but not a properties files or an sql file. Even if I did, I cannot get the process to finish because the subsequent steps would fail.
Currently, I am getting over these by creating my own files and writing them thru a custom plugin. However, during the plugin execution, the folder target/generates-sources/mybatis-generator is not created yet. Therefore assuming that location to have already been created is ruled out. On the other hand, if I go ahead and create the folder and its internal META-INF/services folder, I am not sure if this will be overwritten at a later stage. In addition, my plugin does not (by virtue of the way the generator initiates plugins), have access to the project root folder. So that is not an option either.
I neither have access to the ShellCallBack, implying that postponing the file creation to a well defined time-point in the build process is also not possible.
So how do I go about creating the service definitions and the additional resource files?
The last resort is to hard-code the project folder or to pump the project folder through a property. This is coming to my rescue now. But clearly, the generated files are being detected by my git client and I have to clean up these files also despite their being dynamic.
Hints please?
Thanks in advance.
Rahul
The generator currently supports Java, Kotlin, and XML file generation. There is an open feature request to support other file types in plugins. You can follow it here: https://github.com/mybatis/generator/issues/752
Is it possible to create an Eclipse installation package, that contains a bunch of bundles and plugins? If so, how? (Like the ones that are already being offered by Eclipse.org and also from different vendors with their own projects)
The reason I am asking is, that I find it very time-consuming to install a bunch of software into development environment every time I need a clean installation of Eclipse (based on various reasons, corruptions etc.).
So I would like to install all the software I need at once, and save it somewhere else before working with it (as a backup) and if something goes wrong I can install the entire base installation again without being have to handle all the extra software in it.
Thanks!
Eclipse is downloadable as a zip or tar file, so you can dezip it in a folder, add your favorites plugins (their will be store in the eclipse folder in plugins subfolder) and create a new archive with your modified environment (your eclipse folder).
I think It's the simple way to create a backup.
I hope it may help you,
Have a nice day
One option is to use Yoxos, which allows you to create your own package of Eclipse and easily share it (including with yourself).
From Gradle's documentation:
The scripts generated by this task are intended to be committed to
your version control system. This task also generates a small
gradle-wrapper.jar bootstrap JAR file and properties file which should
also be committed to your VCS. The scripts delegates to this JAR.
From: What should NOT be under source control?
I think generated files should not be in the VCS.
When are gradlew and gradle/gradle-wrapper.jar needed?
Why not store a gradle version in the build.gradle file?
Because the whole point of the gradle wrapper is to be able, without having ever installed gradle, and without even knowing how it works, where to download it from, which version, to clone the project from the VCS, to execute the gradlew script it contains, and to build the project without any additional step.
If all you had was a gradle version number in a build.gradle file, you would need a README explaining everyone that gradle version X must be downloaded from URL Y and installed, and you would have to do it every time the version is incremented.
Because the whole point of the Gradle wrapper is to be able, without having ever installed Gradle
Same argument goes for the JDK, do you want to commit that also? Do you also commit all your dependency libraries?
The dependencies should be upgraded continuously as new versions are released to get security and other bug fixes, and because if you get to far behind it can be a very time consuming task to get up to date again.
If the Gradle wrapper is incremented for every new release, and it is committed, the repo will grow very large. The problem is obvious when working with distributed VCS where a clone will download all versions of everything.
and without even knowing how it works
Create a build script that downloads the wrapper and uses it to build. Everyone does not need to know how the script works, they need to agree that the project is build by executing it.
where to download it from, which version
task wrapper(type: Wrapper) {
gradleVersion = 'X.X'
}
for Gradle version >= 5:
wrapper {
gradleVersion = 'X.X'
}
and then
gradle wrapper
to download the correct version.
to clone the project from the VCS, to execute the gradlew script it contains, and to build the project without any additional step.
Solved by the steps above. Downloading the Gradle wrapper is not different from downloading any other dependency. The script could be smart enough to check for any current Gradle wrapper and only download it if there is a new version.
If the developer has never used Gradle before and maybe doesn't know the project is built with Gradle, then it is more obvious to run a build.sh compared to running gradlew build.
If all you had was a gradle version number in a build.gradle file, you would need a README explaining everyone that gradle version X must be downloaded from URL Y an installed,
No, you would not need a README. You could have one, but we are developers and we should automate as much as possible. Creating a script is better.
and you would have to do it every time the version is incremented.
If the developers agree that the correct process is to:
Clone repo
Run build script
Then there upgrading to latest Gradle wrapper is no problem. If the version is incremented since last run, the script could download the new version.
I would like to recommend a simple approach.
In your project's README, document that an installation step is required, namely:
gradle wrapper --gradle-version 3.3
This works with Gradle 2.4 or higher. This creates a wrapper without requiring a dedicated task to be added to "build.gradle".
With this option, ignore (do not check in) these files/folders for version control:
./gradle
gradlew
gradlew.bat
The key benefit is that you don't have to check-in a downloaded file to source control. It costs one extra step on installation. I think it is worth it.
According to Gradle docs, adding gradle-wrapper.jar to VCS is expected as making Gradle Wrapper available to developers is part of the Gradle approach:
To make the Wrapper files available to other developers and execution environments you’ll need to check them into version control. All Wrapper files including the JAR file are very small in size. Adding the JAR file to version control is expected. Some organizations do not allow projects to submit binary files to version control. At the moment there are no alternative options to the approach.
What is the "project"?
Maybe there is a technical definition of this idiom that excludes build scripts. But if we accept this definition, then we must say your "project" is not all the things that you need to versioned!
But if we say "your project" is everything you have done. Then we can say you must include it and only it into VCS.
This is very theoretical and maybe not practical in case of our development works. So we change it to "your project is every file (or folder) you need to editing them directly".
"directly" means "not indirectly" and "indirectly" means by editing another file and then an effect will be reflected into this file.
So we reach the same that OP said (and is said here):
I think Generated files should not be in the VCS.
Yes. Because you haven't created them. So they are not part of "your project" according to the second definition.
What is the result about these files:
build.gradle: Yes. We need to edit it. Our works should be versioned.
Note: There is no difference where you edit it. Whether in your text editor environment or in Project Structure GUI environment. Anyway you doing it directly!
gradle-wrapper.properties: Yes. We need to at least determine Gradle version in this file.
gradle-wrapper.jar and gradlew[.bat]: I haven't created or edited them in any of my development works, till this moment! So the answer is "No". If you have done so, the answer is "Yes" about you at that work (and about the same file you edited).
The important note about the latest case is the user who clones your repo, needs to execute this command on repo's <root-directory> to auto-generate wrapper files:
> gradle wrapper --gradle-version=$v --distribution-type=$distType
$v and $distType are determined from gradle-wrapper.properties:
distributionUrl=https\://services.gradle.org/distributions/gradle-{$v}-{$distType}.zip
See https://gradle.org/install/ for more information.
gradle executable is bin/gradle[.bat] in local distribution. It's not required that local distribution be same as that determined in the repo. After wrapper files created then gradlew[.bat] can download determined Gradle distribution automatically (if not exists locally). Then he/she probably must regenerate wrapper files using new gradle executable (in downloaded distribution) using above instructions.
Note: In the above instructions, supposed the user has at least one Gradle distribution locally (e.g. ~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10). It covers almost all real cases. But what happens if the user hasn't any distribution already?
He/She can download it manually using the URL in .properties file. But if he/she doesn't locate it in the path that the wrapper expected, the wrapper will download it again! The expected path is completely predictable but is out of the subject (see here for the most complex part).
There are also some easier (but dirty) ways. For example, he/she can copy wrapper files (except .properties file) from any other local/remote repository to his/her repository and then run gradlew on his/her repository. It will automatically download the suitable distribution.
Old question, fresh answer. If you don't upgrade gradle often (most of us don't), it's better to commit it to VCS. And the main reason for me is to increase the build speed on the CI server. Nowadays, most of the projects are getting built and installed by CI servers, different server instance every time.
If you don't commit it, CI server will download a jar for every build and it significantly increases a build time. There are other ways to handle this problem, but I find this one the easiest to maintain.
I have some data resources that I would like eclipse to not copy every time it builds. I put them as part of the build path so they get copied, but I don't want that to happen every time as it's time consuming.
Any idea on a better strategy?
I don't even want them to be deleted when clean is invoked. In Visual Studio one can mark a resource file as "copy once" is there such a thing in Eclipse.
Thank You
Having eclipse not copy some file that you have modified even after a clean will be a nightmare: you'll have to remember to copy it manually each time it's modified.
And Eclipse only copies files which have been modified when building incrementally.
If it's so slow, it probably means you have too many such files, and they should perhaps be put in a jar in the build path.
As you ask for a strategy, then ...
Eclipse is not a build tool, it's IDE. So you better not try to setup some build logic based on it. Use eclipse for coding and for performing specific tasks during build use build tools like maven or ant.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.