I would like to know the specs for the maven repository structure.
I know I could use archiva or nexus to create a repository. I am not interested in those information.
I have tried searching apache's maven website and google with the phrase
"maven artifact repository structure specs", and I mostly get the development directory structure expected on the maven client.
I would like someone to explain the structure here or point me to a comprehensive single document (i.e. one that does not explain the directory structure by making me follow a never ending trail of links) that explains for example,
How to create a simple maven repository using a static file system directory, deployed to apache http server.
or how to create a directory structure on googlecode that would appear as a maven repository.
Here is the specification (long overdue for documenting in Maven itself):
https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final
That said, I wouldn't refer to that for creating the repository in the way you've described. The best thing to do is to use mvn deploy:deploy-file with appropriate parameters to upload the files that you want to, as it can write appropriate metadata and structure for you. This can be done to a filesystem location and synced to the location you want to.
Another alternative is to run a repository manager, like Archiva, and upload using the web interface until you are happy, then sync the directory structure to the location that you want to.
Related
I have a repository directory under .m2 that I want to use as a remote repository (-Dmaven.repo.remote=http://remotehostname/repo) to other hosts. I tried just to expose the directory .m2/repository/ under Apache as http://remotehostname/repo, the directory is fully visible via HTTP, but Maven doesn't seem to be reading from the exposed repo. For various reasons, I do not want to add this new remote repo to settings.xml; limit it to -Dmaven.repo.remote
What do I need to do to convert a local repo under .m2 as a remote repo?
Further to #Perception's answer, you can look at Nexus Command Line tool, which can help convert your local repo to nexus repo
I haven't heard of any maven repository manager that can simply mirror your .m2 folder (which is just a local repository). You need to install and configure repository management software ... there are many free, open source ones, I recommend Artifactory or Nexus.
Nexus does fit very closely with your requirements since it uses a file based repository, and the file layout matches with the local repo layout.
I am interested in obtaining all JAR files contained in the public repository http://repo1.maven.org/maven2/
Is there a way to do so apart from writing a POM file containing all items in the Dependency section?
Essentially I want to create a local mirror
You could use something like - http://www.gnu.org/software/wget/ to mirror the entire repository but it is going to be huge.
I would recommend you use a local repository manager like:
http://nexus.sonatype.org/
http://archiva.apache.org
Use a repo manager like Nexus. Trying to mirror everything will get you banned.
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.
I created several web applications that use the same static files (css, js, images).
When I use svn for version control, I use an external repository (svn: externals) to add files to the current project.
For example:
- Project_1
---- Webapp
-------- Static (external to static's repo)
- Project_2
---- Webapp
-------- Static (external to static's repo)
I could easily use it in their web pages by adding a link like /static/ ...
But now our company has moved to perforce.
How can I support the current structure?
We also use maven, I think to pack these files as a jar and use as a dependency, but then my editor (idea) does not see that this dependence are js-scripts and styles.
And i need to repackage and deploy jar file when create minor changes.
How to use maven correctly?
Perforce has support for defining multiple mappings from the depot to your hard drive as part of the client spec. You could, for example, set the following:
Client Name: Sample_Maven
Client Root: c:\inetpub\wwwroot
//depot/Project_1/Webapp/... //Sample_Maven/Project_1/...
//depot/Project_2/Webapp/... //Sample_Maven/Project_2/...
//depot/Shared/static/... //Sample_Maven/static/...
... any other folder mappings you need to bring in and sync ...
Perforce won't handle multiple mapping of the shared static folder situation by itself, you will have to use junctions/symlinks in your file system to get the behavior you want. A word of caution though, make sure only one of the shared static folders is actually managed through Perforce. It can get slightly grumpy if resources get changed out from under it without it knowing about the changes.
Really though, you are probably better off (if you can) - having a single workspace/client spec per project - one for proj1 and one for proj2, each with their own mappings to the shared static folder. If you can structure things appropriately and just use maven to build each "project" things will go more smoothly.
For a Maven based solution, you could use WAR Overlays, sharing common resources across multiple web applications is exactly what overlays are for.
It seems you have a couple of choices, both called overlays:
a) Maven overlays as #Pascal suggests. Then you a struction like #Goyuix suggests to checkout the static content from Perforce.
b) Perforce overlays, which would allow you to have two different workspaces/client specs, one for each project, and in each import the static content into the expected place in the filesystem. This is the closest match to the subversion structure you were using before.
http://maven.apache.org/settings.html As per documentation the user specific settings can be either copied to the .m2 folder or under the maven installation. If a developer changes a machine or gets a new user id, such properties have to be copied manually to these newer machines.
Would it be possible to store user specific setting information in the repository itself (say SVN) and somehow have the mvn scripts load it on startup.
If the content of the settings.xml is not that user specific (e.g. for mirrors), you could store the whole Maven install in SVN with a customized conf/settings.xml and have the developers grab it from SVN to "install" it on a new machine as described in this previous answer.
If the content of the settings.xml is really user specific (e.g. it contains secret things like passwords), then it must be located in ~/.m2 and you will have to somehow make it available at the new location. If a developer logs on another machine, you could use "Roaming user profile". If a developer gets another id, then you'll really have to duplicate it. The technical solution may depend on the level of confidentiality required.
And if you have several developers sharing a userid but still need different settings.xml, then you'll have to pass it to Maven using the -s option. One could imagine storing these custom settings.xml in the project in that case (assuming it doesn't contain sensitive information). For example:
mvn -s settings-user1.xml <goal>
Nope, the whole point of having user settings is to store them outside the maven projects. There's nothing stopping you from creating your own svn repository and storing your configuration files there, though. You could write some shell scripts to bootstrap a new workstation from that repository, but it really depends how often you do this to make it worthwhile.
I would suggest that you setup your own repository such as Archiva, Nexus or Artifactory. Which will get your dependencies/plugins , then you can use mirror to specify explicitly just one repository to be used(the one you setup on your network). So whenever developer changes machine or dependencies are needed for multiple developers the internal mirror can be used as repo, your dependencies/plugins will download in no time to your local repository/ies