Generally speaking, should one only add the central Maven Repository to a pom.xml + optionally any local Maven Repositories ? In theory (I think?) anybody can set up a repository - is there a 'Maven Repository<->Maven Repository' circle of trust or something ?
How do I know for instance that I'm really downloading (say) the log4j compiled JARs and not some bastardized / evil version ?
Few things you can do to feel comfortable:
Use a local repository manager like Nexus or JFrog, and proxy any repositories that you want to use. There are few benefits to this:
A local manager can keep track of the SHA hashes to make sure that a jar didn't change under your feet.
You can limit the repositories that your developers can access.
Stick with Maven Central when you can - so many people use it that if someone switched out the log4j version with something untrustworthy everyone would know very quickly (because the hashes wouldn't line up). Generally this argument will also hold true for any other repositories that hold popular libraries (eg sourceforge, google code, codehaus, etc)
Things are only likely to get risky if you're using some dude's repo who wrote some library that's not very popular out in the wild. In practice this rarely happens. In those cases, maybe you can just build the code yourself to be sure.
Best practice is not to add any repository into the pom.xml. The best solution is to configure either into the settings.xml or the best solution is to use a repository manager. Furthermore the best thing is to work with maven central if you don't have a repo-manager, but for that you don't need to configure anything, cause Maven Central is the default within Maven itself. Maven Central is control adminstrative by people of Sonatype and it is not that simple to get something into Maven Central. What you can do to secure the transport a little bit more is to turn on the checksum checking which is controled by a configuration in the settings.xml.
Related
I am working with 10.5.4. I would like to use SVN to keep versioning of my site contents so as editors to be able to commit their changes. I have read a lot about mounting the VFS and that stuff, however with that way everyone coulld access and commit others changes
I would appreciate any further information about using versioning not only for module developments but also for site contents
I know, this is probably not exactly what you are looking for, but you may have a look at the OpenCms Maven plugin.
The main focus of this plugin is, to ease the development process of OpenCms projects. But with a good setup and Maven configuration you might use it to put the contents of your production site under version control. If you are interested, you'll find more information on the official website of the plugin.
I am looking to add Groovy support to an existing java project so that I can seemlessly compile mixed Java and Groovy code using invokedynamic so that I can get Java-like execution speed without needing to waste excessive amounts of time with verbose Java syntax
After reading that the gmaven plugin no longer supports compilation -and that the groovy eclipse compiler plugin doesn't yet support invokedynamic, I asked myself, why would I want to continue using Maven if it compiles Groovy code that is needlessly slow?
Consequently, I decided I would try scrapping maven for Gradle so that I could obtain faster code while also porting some python deployment scripts to Gradle tasks so as to only need one codebase.
I have some libraries stored on a simple password protected s3 maven repository (in order to avoid needing enterprise overkill like artifactory). After doing some basic research, I have found that Gradle has no built in support for adding in custom dependency management as determined by this stack overlow question and this support forums post.
I did manage to find a s3 plugin for gradle -but it doesn't deal with management of dependencies.
If the whole point of Gradle is to be more flexible than Maven and if the core purpose of a dependency management/ build system is to effectively manage dependencies from a variety of sources-then lack of support for custom repositories appears to be a fairly significant significant design flaw which makes any issues I have encounted with Maven thus far pale in comparison.
However, it is quite possible that I am missing something, and I have already invested several hours learning Gradle -so I figured I would see if there is some reasonable way to emulate dependency management for these s3 dependencies until Gradle developers fix this critical issue. Otherwise I will have to conclude that I am better off just using Maven and tolerating slower Groovy code until the compiler plugin supports invokedynamic.
Basically I need a solution that does the following:
Downloads dependencies and transitive dependencies to the gradle cache
Doesn't require me to hardcode the path to the gradle cache -so that my build script is platform independent.
Doesn't download the dependencies again if they are already in the cache.
Works with a multi-module project.
However, I cannot find anything in the documentation that would even give me a clue as to where to begin:
Gradle 2.4 has native support for S3 repositories. Both downloading dependencies and publishing artifacts.
To download with IAM credentials (paraphrased from the link above):
repositories {
maven {
url "s3://someS3Bucket/path/to/repo/root"
credentials(AwsCredentials) {
accessKey 'access key'
secretKey 'secret key'
}
}
}
Then specify your dependencies as usual.
You don't need any custom repository support to make this work. Just declare a maven repository with the correct URL. If the repository works when used from Maven, it will also work with Gradle. (Uploading may be a different matter.)
You can use S3 and http
repositories {
mavenCentral()
ivy {
url "https://s3-eu-west-1.amazonaws.com/my-bucket"
layout "pattern", {
artifact "[artifact]-[revision].[ext]"
m2compatible = true
}
}
}
Name the jar in S3 to name-rev.jar (joda-time-3.2.jar) in my-bucket.
Also upload a pom file.
And in S3 give all permission to Download the jar and pom.
I'm new to both of these tools, and I'm also very new to Linux system administration, so I apologize ahead of time for what may seem like a total n00b question.
Basically, I'm starting a whole new project from scratch. Yaaay! Exciting! However, I'm a little lost on how to set up the project. I've installed both git and maven on my dev machine and run through some tutorials. I've also set up git on my server, and have successfully pushed code to it and pulled code from it.
So, first question : Is it even a good idea to use git and maven together? Git seems like the best source control system, and Maven seems like the best build system. Are they known to work well together? Or am I needlessly creating trouble for myself at this early (and precarious) stage of the project? I've used ant enough to know that I don't want to use it, and I'm not really a fan of svn, although I'll use it if I have to.
Second question : Given that these two tools work well together, what's the Best Practices way of setting them up? I know that git is "peer-to-peer", although I suppose nothing is stopping you from setting up a single repository for the git user and having all the devs sync up with that repo when it's time to do a build. Is that the right way to go? How about Maven? Maven seems kinda single-user oriented. Like, everybody sets up Maven on their own machine and has their own Maven repo, right? Or wrong? Would it make sense to create a "Maven user" on my server, and have that user do all my builds from the "main" git repo?
Apologies if I'm totally mistaken on how to use these tools. As I said, I'm pretty new to these things. Any help you have is appreciated.
(also, I'm working on Linux, doing Java dev work in Eclipse, using Spring for the framework, mysql for the data store, and Hibernate as an ORM. Don't know of any of that matters)
Thanks!
Q1: Yes, git will work well with any build systems. Usually your VCS is well abstracted with any modern build system. Ensure that you set up your .gitignore file so that you are not tracking any artifacts from builds.
Q2: The best practice is to have an integration branch to build from. While developing, use topic or feature branches. When ready, merge into the integration branch and push that up to the central repository where maven can build from. Google git-flow for more ideas. You generally want a central build server if you are working on a team to ensure you are building on the same machine. This is not the case if you are working alone or maybe just one developer.
Hope this helps.
Are there security concerns with using Maven? I use Ant today for my main project, but I do use Maven for my "samples" project where I write program spikes. I do like some parts of Maven, but have a concern with downloading my jars through the tool. Is this an unfounded concern? How secure is "http://repo1.maven.org/maven2/"? Is there a more secure way of using the tool?
Thanks.
It's pretty secure and standard. If ever the security of http://repo1.maven.org/maven2/ is compromised, there will have big repercussion in Java devs. I never heard that this site is hacked.
That said, you are not bounded by default repository. You can configure your own repository using Nexus, Artifactory and install safe artifacts manually to them. You may also block remote repositories using Nexus/Artifactory setting. Although, I never needed to do this. But look here, perhaps it's possible.
Please note that you will have to block your local repository to use "repo1", else the local repository will download artifacts from there by default.
Edit 1: added missing link
My question is: How do you guys deploy the same code from whatever [D]VCS you use on multiple machines? Do you have an automated deployment system and if so what's that? Is it built in-house? Are there out there any tools that can do this automatically? I am asking because I am pretty bored updating up to 20 machines every time I make some modifications.
P.S.: Probably this belongs on ServerFault, but I am asking here because I am thinking at writing my own custom-made deployment system.
Roll your own rpm/deb/whatever for your package, set up your own repo, and have your machines pull on a regular basis. Its really not that hard to do and its already built-in to your system, is well tested, and loaded with features. You could use something like Func if you needed to push instead.
Depending on your situation deploying straight from the versioning system might not always be the best idea. You can only so much by just updating files, and mixing deployment and development probably will make the development use of the versioning system less free.
I see two alternatives that might be interesting.
Deploy from your continuous integration server. (add a task that runs after every successful build, copies over files and executes some remote commands, I'm using this to deploy to a testserver and would find it to tricky to upgrade production in such a way)
Deploy using an existing package manager. You can set up your own apt (or equivalent) repository and package the updates using apt. Have your continuous build system build apt packages but let an admin decide if the should be pushed to the update server. I think this is the only safe solution for production machines.
We use Capistrano for deployment & Puppet for maintaining the servers and avoiding the inevitable 'configuration drift' when many developers/engineers tinker with the package lists and configuration files.
Both of these programs are written in Ruby, but we use them for our PHP codebase stored in a git repository.
I use a combination of deb packages with puppet to deploy code and configure a bunch of machines.
In most projects i have been involved with the final stage has always been an scripted rsync deployment to live. so the multiple targets are built into this process.