What is a 'scoped' repository workspace ?
Does this mean only members in current team will be able to view the repository rather than 'public' where everyone in the prject area can view the repository.
Scoped is what I always recommend when creating a repo workspace:
It allows other member of the project area to access your repo workspace by adding it to their flow targets.
That allows them to accept changesets from your repo workspace even though you haven't delivered them on the Stream.
This is a nice change to the "reserved checkout" issue with ClearCase, when a collaborator is no longer there and the file is blocked.
Here, as long as you have checked in your changes, even if you are not there to deliver them, those changes aren't locked in your computer, but are available for the other members.
This is different from scoped flow target.
And RTC4.0 has introduced Scope read permissions on files and folders.
That being said, a "public" repo workspace has its use (see this thread):
The idea of using a public repository workspace, is to provide an up and running development environment for the team.
I do not want a developer to spend 2-3 hours with the support of somebody else to setup is workspaces, to run a web application with the J2EE artifacts. Currently we are using MAVEN to build are applications and setting up the development environment and we are struggling with it.
To much knowledge required by the developer and way to much money trying to automagically configure the RAD 7.5 workspace with MAVEN and are own scripts.
The idea is to setup pre-configured public repository workspace with all the necessary RAD 7.5 artifacts (server, EAR configuration, web configuration, link between projects and link to MAVEN repository for component that you dont want to load in your workspace.
For our team we may have around 8 public repository workspaces, some with only the front-end projects other with only the back end projects or a mix of both depending on our specific needs.
The developer come in the morning pick the proper public repository workspace for his task and is up and running in 10 minutes. He can see ongoing changes from other, accept changes from his team mate or not. Of Course, from the workspace the changes can be delivered in the stream used for continuous integration.
I think its cool.
Related
I am setting up an ant build system on a project with dependency resolution being managed by ivy. I have it up and running with the file system being used for the local and shared repository currently. My ultimate goal would be that when developers are fixing bugs or creating new functionality, they would only be able to put artifacts into their local repository. When they belive their code is ready to be used by the rest of the team, it would be promoted to the proper branch in SVN and the group in charge of doing official builds would compile and publish the new artifacts.
So I guess my questions are how can you control who can publish to a repository? Does ivy just rely on filesystem permissions?
Also, I would eventually like to make my shared repository available via http. I think I could point apache to the file system repository directories for retrieving artifacts, but how do you setup publishing to an http repository?
I would suggest that you setup a repository manager to manage your project's build artifacts.
The best choices are one of the following:
nexus
artifactory
archiva
Publishing to a Maven repository means that your artifacts can be consumed by projects using other build technologies. All modern build systems support Maven (Including ivy, see the ibiblio resolver).
You could specify three resolvers in your ivy settings file. First would be a chain resolver which include remote and local ivy repositories. Second would be a local resolver for local ivy repository. Third a resolver to remote ivy repository only.
Every developer retrieves artifacts using first chain resolver.
Usual developer publish artifacts using second local resolver.
Your special team could use third remote resolver to publish in remoter ivy repository.
To protect remote repository from usual developers place it on (S)FTP server with write protection by password.
The only problem in this case is how to set versions on artifacts so that artifacts published in remote repository in some cases override locally published in some not.
Our team used such scheme few years ago. But now we use only local ivy repositories and CI server to build and run tests from various branches. We came up to this after switching to git.
for existing ivy repo easy to setup this: rest-ivy
I would like to know weather there is a way/plugin to build a project with maven using a remote pom.xml(http://host:port/pom.xml) with out a pom.xml file in the directory where I run "mvn install".
I need this as I want to effect maven dependencies of multiple clients by making changes to one remote file hosted at (http://host:port/pom.xml).
I am not aware of a way to do this. Generally, if you are doing development with multiple developers, you should be using source control. For example, if you are using subversion, you would just make changes to the pom, commit, and the other developers can update.
Of course using a version control is absolutely necessary...It would quite helpfull to use a Maven Repository Manager to interchange the artifacts with each other simply by deploying the artifacts to a central Repository Manager in your company and furthermore it will increase the build time.
If you are on Windows, you can try mapping the remote location (possibly a network share or an FTP location) to a local drive, and then executing the maven command in your console for the mapped location. It should work.
Else, you can distribute the pom.xml file via an email and ask the users to use it as their project file.
The other option is to use a Version Control System (VCS) such as Mercurial and keeping your pom.xml stored in the repository and make it accessible for the users to checkout. So far, this is the best way to make sure everyone is using the same file.
I know Maven has a central repository that you can upload build artifacts (assemblies) and reference them in your build script so that you get the latest versions.
Is there any similar tool (other than Maven for .Net) that provides a way to centrally store artifacts and reference them in MSBuild scripts?
I'm trying to figure out how to incorporate a library solution we have that is used across all our other solutions (contains common data access, schemas, etc.)
We don't always automatically want it included in our projects as sometimes we need to stay on a particular version for one project until that project is ready to upgrade to the latest.
If I were you, I'd create a build system that allows publishing packaged 'modules' from one end, and importing from the other end.
You create a shared directory at a global place within your organization and this becomes your "central Repository" you're talking of.
Alas, I'm not aware of any public implementation of such an msbuild system.
I have a stable opensource library and was wondering how (and if) I can publish my lib to maven official repositories so people can include it in their pom.xml files and get the dependency downloaded automatically.
The process to get your library in the central repostiory is documented in the Guide to uploading artifacts to the Central Repository. In short, the new process is to get your project hosted by one of the approved Forges that will be synced with central, the Maven folks don't rsync personal repository anymore. In your case, your best bet would be to use the Sonatype Forge (open to any OSS Project). Check the given link (and also this document).
If you want reliable access for everyone out there, you need to stick with central. Due to the tendency of people at dev.java.net to break rules about the immutability of released artifacts, some people don't trust it. Further, it can be Very Slow.
To get your project into central, you need have your code in some public repo that they can sync from.
Central repository
A bit less bureaucratic dev.java.net Maven2 repository - allows completely automatic deployment.
This led on from the question about asking if Apache Maven and IBM Rational ClearCase integrated well. Thought I should write up what I found out - will require various edits, but I shall eventually get round to adding it all I hope.
Environment
ClearCase - Version 7.0.1.2 of ClearCase.
Maven - All of them, from the Maven website.
Hudson - Version 1.307 downloaded straight from the Hudson website
Questions
Does Maven run from a VOB?
I installed all the versions of Maven2 into a VOB 'stacked', i.e. I added Version 2.0 - labelled it, locked the label - then added 2.0.1 on top.
To prevent there being extraneous files, I used the -rnname flag in clearfsimport.
This way, I could simply use a label to specify the version of Maven I wanted access to in my configuration spec, but still keep the same path for the maven executable - /maven/bin/mvn.
Once all the versions were installed, I had no problem running Maven from there via a Dynamic View. Repositories are downloaded from an internal installation of Nexus to the users home directory as normal - and this saves any problems with checking in and out.
A benefit of keeping the tool in source control is that you can set company-wide settings (such as pointing to a internal repository) - then run that single instance of Maven from the VOB on any platform, which retains the settings you originally set!
In Maven projects, I only kept the src directory and the pom.xml in source control, as everything else can be auto-generated afterwards.
Does Hudson work with ClearCase?
I had no problem setting up Hudson to run with ClearCase Dynamic Views. All it took was a symlink from the working directory for Hudson to the root of the view (in this case /view/xxx). The ClearCase plugin successfully ran ct lshistory to find if there had been any changes in the integration branch that developers merge into.
I did write a small script to set-up the initial environment for a job - just the config.xml and dynamic view symlink - so that the correct view was listed in the job and the initial settings were correct. Any enhancements by the users afterwards were then changes to the default template, rather than them setting it up themselves.
In the overall settings of Hudson, I used the $CLEARCASE_VIEW environment variable to set the path to the Maven executable. That way, the version of Maven depended on the version set in the configuration specification - rather than the one they selected within Hudson.
This saves extra administration on both the part of me (the admin) and my users.
What Internal Repository Manager did you use?
I set up Sonatype Nexus to be the Internal Repository Manager - primarily because I read in the Sonatype blog that Hudson was going to get more integrated with Nexus, and we may as well be prepared for new enhancements in the future. I also believed, when I got it set up and tried it, that it was more prepared for a large commercial environment because you could tune the groups within the repository manager to be more flexible - useful for a great number of projects.
I have some Maven repositories outside of ClearCase, for some third-parties libraries referential.
But I have never used Maven with ClearCase since they follow a different logic (Maven needs signed names for files, like myfile-1.2.jar, whereas ClearCase can store only myfile.jar, and record the fact it is version labeled 1.2)
That may have changed with the Maven2 ClearCase plugin reported by romaintaz, but there is still some bugs in this new product, as shown by this thread, when one runs it a second time without unco'ing the pom file. Maven is getting through the checkout fine but is not able to whatever the next step is.
INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".
I am not using this SCM, but there is a Maven2 plugin called SCM that handles Clearcase.
I had a team building with Maven 2 and using Clearcase as the version control system. We used Archiva as the repository for built artifacts so the development team did not need to use the SCM plugin.
However, the continuous integration server was Continuum and that was relying on the SCM information in the POM. We had problems with the Clearcase SCM grabbing snapshot views using out branching strategy. One of my developers had to tweak the Clearcase SCM code to get it to work with our branches. We both moved on before we got round to contributing his fix.