Work flow for isolated internal repository

[Guo Du <mr...@duguo.org>]

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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Work flow for isolated internal repository

[Guo Du <mr...@duguo.org>]

>> On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammar<an...@hammar.net>  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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Work flow for isolated internal repository

[Ron Wheeler <rw...@artifact-software.com>]

On 24/01/2011 6:28 PM, Guo Du wrote:
> On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammar<an...@hammar.net>  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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Work flow for isolated internal repository

[Guo Du <mr...@duguo.org>]

On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammar <an...@hammar.net> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Work flow for isolated internal repository

[Anders Hammar <an...@hammar.net>]

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 <mr...@duguo.org> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Work flow for isolated internal repository

[Guo Du <mr...@duguo.org>]

On Mon, Jan 24, 2011 at 2:31 AM, Ron Wheeler
<rw...@artifact-software.com> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Work flow for isolated internal repository

[Ron Wheeler <rw...@artifact-software.com>]

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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org