Re: Work flow for isolated internal repository
>> On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammar wrote: > We do this by building jars that aggregate our 3rd party dependencies once > per release so we know exactly what transitive dependencies are going to be > used by the developers. If you are running maven for some time, I won't surprised if there are thousands of jars already in artifacts/plugins repository. I am interesting to see the flow how you do the "building jars that aggregate our 3rd party dependencies" for those production jars if it's not related to confidential material. Any plugins/tools used to assistant the process? > This gives us simple projects and central control over libraries used. This what I try to achieve. Even central repo is general available and good quality, but no guarantee of bomb free :) Thanks Ron! -Guo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Work flow for isolated internal repository
On 24/01/2011 6:28 PM, Guo Du wrote: On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammar wrote: You could be somewhat aided by the procurement feature of Nexus Pro (the commercial edition of the Nexus repo manager): http://www.sonatype.com/books/nexus-book/reference/procure.html Looked at the link, Procured Development Repository[1] is closest to support the flow. It could works for a very limited number of new dependency to be added before #2. For the use case of a new project setup, lots of dependency could be added and developer may even don't know which library is need as there are transitive dependencies. We do this by building jars that aggregate our 3rd party dependencies once per release so we know exactly what transitive dependencies are going to be used by the developers. This gives us simple projects and central control over libraries used. If procurement could store all the new dependencies to a staging area like a normal release staging repository and reusing existing approval/release functionality, will make the flow more operational. We just put our aggregated libraries in our repo with our webapps, webservices, batch jobs, etc. Also, One thing that you might want to have in mind is two have separate repositories for dependencies and plugins. For Maven to be useful, you will This does not work in Maven 2.x. A very good practice, this is main reason to choose 3.X. We will leave the plugins in a different world and have less restriction :) Thanks all for the thoughts! -Guo [1] http://www.sonatype.com/books/nexus-book/reference/procure.html#procure-sect-dev - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Work flow for isolated internal repository
On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammar wrote: > You could be somewhat aided by the procurement feature of Nexus Pro (the > commercial edition of the Nexus repo manager): > http://www.sonatype.com/books/nexus-book/reference/procure.html Looked at the link, Procured Development Repository[1] is closest to support the flow. It could works for a very limited number of new dependency to be added before #2. For the use case of a new project setup, lots of dependency could be added and developer may even don't know which library is need as there are transitive dependencies. If procurement could store all the new dependencies to a staging area like a normal release staging repository and reusing existing approval/release functionality, will make the flow more operational. > Also, One thing that you might want to have in mind is two have separate > repositories for dependencies and plugins. For Maven to be useful, you will > This does not work in Maven 2.x. A very good practice, this is main reason to choose 3.X. We will leave the plugins in a different world and have less restriction :) Thanks all for the thoughts! -Guo [1] http://www.sonatype.com/books/nexus-book/reference/procure.html#procure-sect-dev - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Work flow for isolated internal repository
On Mon, Jan 24, 2011 at 2:31 AM, Ron Wheeler wrote: > 1. Developer enables the access to internal repository(Nexus or other). Internal repository is isolated from external even with nexus. This is the main point of this work flow. Imaging with transparent proxy to maven central, developer could download 105GB+ artifacts and will result been blocked by central server. > javadoc/sources/license- needs to be done before 2. Why should the developer > waste time using invalid libraries. I want to clarify that in #2, only dependency referenced added to pom, not actual jar files. > 6. Maven/Nexus deploys new dependencies to internal repository It's ok if those new dependencies are in a staging area. Thanks! -Guo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Work flow for isolated internal repository
You could be somewhat aided by the procurement feature of Nexus Pro (the commercial edition of the Nexus repo manager): http://www.sonatype.com/books/nexus-book/reference/procure.html Also, One thing that you might want to have in mind is two have separate repositories for dependencies and plugins. For Maven to be useful, you will need quite a few plugins. These plugins have lots of dependencies which you simply just must allow. If you use Maven 3, plugins and their dependendencies can have separate repos from your projects' dependencies. This does not work in Maven 2.x. /Anders On Mon, Jan 24, 2011 at 00:20, Guo Du wrote: > In a commercial software development environment, production code will > rely on artifacts which may come from public domain such as maven > central repository. For those artifacts from external, would be > validated with some process such as > checksum/javadoc/sources/license/lawyer, once passed those check, then > deployed to internal maven repository to build into product. Internal > repository is isolated from external repository for various reason. > > A typical work flow will be: > 1. Developer enable the access to external repository. > 2. Developer add new dependencies as artifacts/plugins which available > from external repository. > 3. Developer test the new pom setup and it works on local machine > 4. Developer in some how figure out all (hundreds) new dependencies > need added to internal repository > 5. Developer/Administrator/Lawyer valid the new dependencies such as > javadoc/sources/license > 6. Developer/Administrator deploy new dependencies to internal repository > 7. Developer check in projects pom and it will works on continuous > integration server which only have access to internal repository. > > Any question on the work flow? > Is this work flow could be easily supported? (with open > source/commercial repository manager) > > Thanks! > > -Guo > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Work flow for isolated internal repository
1. Developer enables the access to internal repository(Nexus or other). 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Maven and Nexus will automatically load new dependencies that need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license- needs to be done before 2. Why should the developer waste time using invalid libraries. 6. Maven/Nexus deploys new dependencies to internal repository 7. Developer check in projects (pom and sources) and it will work on continuous integration server On 23/01/2011 6:20 PM, Guo Du wrote: In a commercial software development environment, production code will rely on artifacts which may come from public domain such as maven central repository. For those artifacts from external, would be validated with some process such as checksum/javadoc/sources/license/lawyer, once passed those check, then deployed to internal maven repository to build into product. Internal repository is isolated from external repository for various reason. A typical work flow will be: 1. Developer enable the access to external repository. 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Developer in some how figure out all (hundreds) new dependencies need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license 6. Developer/Administrator deploy new dependencies to internal repository 7. Developer check in projects pom and it will works on continuous integration server which only have access to internal repository. Any question on the work flow? Is this work flow could be easily supported? (with open source/commercial repository manager) Thanks! -Guo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Work flow for isolated internal repository
In a commercial software development environment, production code will rely on artifacts which may come from public domain such as maven central repository. For those artifacts from external, would be validated with some process such as checksum/javadoc/sources/license/lawyer, once passed those check, then deployed to internal maven repository to build into product. Internal repository is isolated from external repository for various reason. A typical work flow will be: 1. Developer enable the access to external repository. 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Developer in some how figure out all (hundreds) new dependencies need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license 6. Developer/Administrator deploy new dependencies to internal repository 7. Developer check in projects pom and it will works on continuous integration server which only have access to internal repository. Any question on the work flow? Is this work flow could be easily supported? (with open source/commercial repository manager) Thanks! -Guo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org