Evaluating Archive Managers - can Nexus do this

[ChrisY]

Hi, The company I work for are currently performing maven builds using a file-based repository on a shared drive. We would like the libraries to be under some form of configuration management, and are evaluating Nexus, Affinity, and Archiva - selected simply because they are mentioned on the Maven site. The requirements that we have are:

Not Automatically Fetching Libraries
We would like to be able to set up a repository that does not automatically download a new library just because a developer specifies it in a .pom file. We would like an administrator to have to add the file to the repository deliberately. The initial archive would ideally be populated first from our file-based repository, alternatively a build could force an initial fetch then the archive configured not to fetch automatically.

The reason that we want this is so that if a third party changes a library without changing the version number we won't pick up the new version unknowingly. Also we want to ensure that only known libraries and versions are in a build.

Auditing of changes to repository
With information about who does what when. Ideally it would be nice to enable the administrator to add a comment, so they could say why and for which project.

"Normal" archiving of plug-ins
The archive should ideally act as a cache for plug-ins, downloading from the internet when required.

Security model for Administrators
Basically only administrators should be able to add or remove libraries or versions from the repository.

I am looking at Nexus to see how it can achieve the above, I assume that we need to use a hosted repository. Any pointers on what can/can't be done and how it can be achieved would be welcome.

Thanks,
Chris

[Tamás Cservenák]

Hi there,

at first glance, you would achieve your requirements by using
following features of latest Nexus Pro release:

- Not Automatically Fetching libraries: Artifact procurement
http://www.sonatype.com/books/nexus-book/reference/procure.html

- Auditing of changes to repository: not completely equal to your
needs, but Nexus does have RSS feeds, and they do say who did what and
when. You can tie that RSS feed in some 3rd party software to add
comments/annotate those. Not described in the book, but you can see
all available RSS feeds on our instance:
http://repository.sonatype.org/index.html#feed-view-system-changes

- "Normal" archiving of plugins: plain proxying, basic capability of
Nexus. You would end up with a grouped repository, that would contain
this non-procured repo with plugins and the procured repository for
your other dependencies.

- Security model for Administrators: easily done, Nexus security is
really fine-grained (maybe even too fine) :)
http://www.sonatype.com/books/nexus-book/reference/config.html

Just to mention, the 1st requirement "procurement" is available in
Nexus Pro only, while the rest is available in Nexus OSS too.

Hope helps,
~t~

On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:

> Hi, The company I work for are currently performing maven builds using a
> file-based repository on a shared drive. We would like the libraries to be
> under some form of configuration management, and are evaluating Nexus,
> Affinity, and Archiva - selected simply because they are mentioned on the
> Maven site. The requirements that we have are:
>
> Not Automatically Fetching Libraries
> We would like to be able to set up a repository that does not automatically
> download a new library just because a developer specifies it in a .pom file.
> We would like an administrator to have to add the file to the repository
> deliberately. The initial archive would ideally be populated first from our
> file-based repository, alternatively a build could force an initial fetch
> then the archive configured not to fetch automatically.
>
> The reason that we want this is so that if a third party changes a library
> without changing the version number we won't pick up the new version
> unknowingly. Also we want to ensure that only known libraries and versions
> are in a build.
>
> Auditing of changes to repository
> With information about who does what when. Ideally it would be nice to
> enable the administrator to add a comment, so they could say why and for
> which project.
>
> "Normal" archiving of plug-ins
> The archive should ideally act as a cache for plug-ins, downloading from the
> internet when required.
>
> Security model for Administrators
> Basically only administrators should be able to add or remove libraries or
> versions from the repository.
>
> I am looking at Nexus to see how it can achieve the above, I assume that we
> need to use a hosted repository. Any pointers on what can/can't be done and
> how it can be achieved would be welcome.
>
> Thanks,
> Chris
> ________________________________
> View this message in context: Evaluating Archive Managers - can Nexus do
> this
> Sent from the Nexus Maven Repository Manager Users List mailing list archive
> at Nabble.com.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

[ChrisY]

Thank you,
that is very useful. I think that if we choose to go with Nexus the professional edition we would probably need the pro edition.
 Chris

Tamás Cservenák wrote:

Hi there,

at first glance, you would achieve your requirements by using
following features of latest Nexus Pro release:

- Not Automatically Fetching libraries: Artifact procurement
http://www.sonatype.com/books/nexus-book/reference/procure.html

- Auditing of changes to repository: not completely equal to your
needs, but Nexus does have RSS feeds, and they do say who did what and
when. You can tie that RSS feed in some 3rd party software to add
comments/annotate those. Not described in the book, but you can see
all available RSS feeds on our instance:
http://repository.sonatype.org/index.html#feed-view-system-changes

- "Normal" archiving of plugins: plain proxying, basic capability of
Nexus. You would end up with a grouped repository, that would contain
this non-procured repo with plugins and the procured repository for
your other dependencies.

- Security model for Administrators: easily done, Nexus security is
really fine-grained (maybe even too fine) :)
http://www.sonatype.com/books/nexus-book/reference/config.html

Just to mention, the 1st requirement "procurement" is available in
Nexus Pro only, while the rest is available in Nexus OSS too.

Hope helps,
~t~

On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<[e-mail]> wrote:
> Hi, The company I work for are currently performing maven builds using a
> file-based repository on a shared drive. We would like the libraries to be
> under some form of configuration management, and are evaluating Nexus,
> Affinity, and Archiva - selected simply because they are mentioned on the
> Maven site. The requirements that we have are:
>
> Not Automatically Fetching Libraries
> We would like to be able to set up a repository that does not automatically
> download a new library just because a developer specifies it in a .pom file.
> We would like an administrator to have to add the file to the repository
> deliberately. The initial archive would ideally be populated first from our
> file-based repository, alternatively a build could force an initial fetch
> then the archive configured not to fetch automatically.
>
> The reason that we want this is so that if a third party changes a library
> without changing the version number we won't pick up the new version
> unknowingly. Also we want to ensure that only known libraries and versions
> are in a build.
>
> Auditing of changes to repository
> With information about who does what when. Ideally it would be nice to
> enable the administrator to add a comment, so they could say why and for
> which project.
>
> "Normal" archiving of plug-ins
> The archive should ideally act as a cache for plug-ins, downloading from the
> internet when required.
>
> Security model for Administrators
> Basically only administrators should be able to add or remove libraries or
> versions from the repository.
>
> I am looking at Nexus to see how it can achieve the above, I assume that we
> need to use a hosted repository. Any pointers on what can/can't be done and
> how it can be achieved would be welcome.
>
> Thanks,
> Chris
> ________________________________
> View this message in context: Evaluating Archive Managers - can Nexus do
> this
> Sent from the Nexus Maven Repository Manager Users List mailing list archive
> at Nabble.com.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Brian Fox]

You probably also want to look into non-functional requirements like performance, memory consumption and how the files are stored for ease of backup and disaster recovery.

On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:

Thank you,
that is very useful. I think that if we choose to go with Nexus the
professional edition we would probably need the pro edition.
 Chris

Tamás Cservenák wrote:
>
> Hi there,
>
> at first glance, you would achieve your requirements by using
> following features of latest Nexus Pro release:
>
> - Not Automatically Fetching libraries: Artifact procurement
> http://www.sonatype.com/books/nexus-book/reference/procure.html
>
> - Auditing of changes to repository: not completely equal to your
> needs, but Nexus does have RSS feeds, and they do say who did what and
> when. You can tie that RSS feed in some 3rd party software to add
> comments/annotate those. Not described in the book, but you can see
> all available RSS feeds on our instance:
> http://repository.sonatype.org/index.html#feed-view-system-changes
>
> - "Normal" archiving of plugins: plain proxying, basic capability of
> Nexus. You would end up with a grouped repository, that would contain
> this non-procured repo with plugins and the procured repository for
> your other dependencies.
>
> - Security model for Administrators: easily done, Nexus security is
> really fine-grained (maybe even too fine) :)
> http://www.sonatype.com/books/nexus-book/reference/config.html
>
> Just to mention, the 1st requirement "procurement" is available in
> Nexus Pro only, while the rest is available in Nexus OSS too.
>
> Hope helps,
> ~t~
>
> On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>> Hi, The company I work for are currently performing maven builds using a
>> file-based repository on a shared drive. We would like the libraries to
>> be
>> under some form of configuration management, and are evaluating Nexus,
>> Affinity, and Archiva - selected simply because they are mentioned on the
>> Maven site. The requirements that we have are:
>>
>> Not Automatically Fetching Libraries
>> We would like to be able to set up a repository that does not
>> automatically
>> download a new library just because a developer specifies it in a .pom
>> file.
>> We would like an administrator to have to add the file to the repository
>> deliberately. The initial archive would ideally be populated first from
>> our
>> file-based repository, alternatively a build could force an initial fetch
>> then the archive configured not to fetch automatically.
>>
>> The reason that we want this is so that if a third party changes a
>> library
>> without changing the version number we won't pick up the new version
>> unknowingly. Also we want to ensure that only known libraries and
>> versions
>> are in a build.
>>
>> Auditing of changes to repository
>> With information about who does what when. Ideally it would be nice to
>> enable the administrator to add a comment, so they could say why and for
>> which project.
>>
>> "Normal" archiving of plug-ins
>> The archive should ideally act as a cache for plug-ins, downloading from
>> the
>> internet when required.
>>
>> Security model for Administrators
>> Basically only administrators should be able to add or remove libraries
>> or
>> versions from the repository.
>>
>> I am looking at Nexus to see how it can achieve the above, I assume that
>> we
>> need to use a hosted repository. Any pointers on what can/can't be done
>> and
>> how it can be achieved would be welcome.
>>
>> Thanks,
>> Chris
>> ________________________________
>> View this message in context: Evaluating Archive Managers - can Nexus do
>> this
>> Sent from the Nexus Maven Repository Manager Users List mailing list
>> archive
>> at Nabble.com.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-user-unsubscribe@...
> For additional commands, e-mail: nexus-user-help@...
>
>
>

--
View this message in context: http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html

Sent from the Nexus Maven Repository Manager Users List mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

[Fabrice Mercier-3]

You can read this article
http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/

2009/6/26 Brian Fox <brianf@...>

You probably also want to look into non-functional requirements like performance, memory consumption and how the files are stored for ease of backup and disaster recovery.

On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:

Thank you,
that is very useful. I think that if we choose to go with Nexus the
professional edition we would probably need the pro edition.
 Chris

Tamás Cservenák wrote:
>
> Hi there,
>
> at first glance, you would achieve your requirements by using
> following features of latest Nexus Pro release:
>
> - Not Automatically Fetching libraries: Artifact procurement
> http://www.sonatype.com/books/nexus-book/reference/procure.html
>
> - Auditing of changes to repository: not completely equal to your
> needs, but Nexus does have RSS feeds, and they do say who did what and
> when. You can tie that RSS feed in some 3rd party software to add
> comments/annotate those. Not described in the book, but you can see
> all available RSS feeds on our instance:
> http://repository.sonatype.org/index.html#feed-view-system-changes
>
> - "Normal" archiving of plugins: plain proxying, basic capability of
> Nexus. You would end up with a grouped repository, that would contain
> this non-procured repo with plugins and the procured repository for
> your other dependencies.
>
> - Security model for Administrators: easily done, Nexus security is
> really fine-grained (maybe even too fine) :)
> http://www.sonatype.com/books/nexus-book/reference/config.html
>
> Just to mention, the 1st requirement "procurement" is available in
> Nexus Pro only, while the rest is available in Nexus OSS too.
>
> Hope helps,
> ~t~
>
> On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>> Hi, The company I work for are currently performing maven builds using a
>> file-based repository on a shared drive. We would like the libraries to
>> be
>> under some form of configuration management, and are evaluating Nexus,
>> Affinity, and Archiva - selected simply because they are mentioned on the
>> Maven site. The requirements that we have are:
>>
>> Not Automatically Fetching Libraries
>> We would like to be able to set up a repository that does not
>> automatically
>> download a new library just because a developer specifies it in a .pom
>> file.
>> We would like an administrator to have to add the file to the repository
>> deliberately. The initial archive would ideally be populated first from
>> our
>> file-based repository, alternatively a build could force an initial fetch
>> then the archive configured not to fetch automatically.
>>
>> The reason that we want this is so that if a third party changes a
>> library
>> without changing the version number we won't pick up the new version
>> unknowingly. Also we want to ensure that only known libraries and
>> versions
>> are in a build.
>>
>> Auditing of changes to repository
>> With information about who does what when. Ideally it would be nice to
>> enable the administrator to add a comment, so they could say why and for
>> which project.
>>
>> "Normal" archiving of plug-ins
>> The archive should ideally act as a cache for plug-ins, downloading from
>> the
>> internet when required.
>>
>> Security model for Administrators
>> Basically only administrators should be able to add or remove libraries
>> or
>> versions from the repository.
>>
>> I am looking at Nexus to see how it can achieve the above, I assume that
>> we
>> need to use a hosted repository. Any pointers on what can/can't be done
>> and
>> how it can be achieved would be welcome.
>>
>> Thanks,
>> Chris
>> ________________________________
>> View this message in context: Evaluating Archive Managers - can Nexus do
>> this
>> Sent from the Nexus Maven Repository Manager Users List mailing list
>> archive
>> at Nabble.com.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-user-unsubscribe@...
> For additional commands, e-mail: nexus-user-help@...
>
>
>

--
View this message in context: http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html

Sent from the Nexus Maven Repository Manager Users List mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

--
Cordialement / Best regards

Fabrice Mercier

[Anders Hammar]

I would also add extensibility to that list. When you get a
centralized manager for your maven set-up, you want to be able to take
full advantage of that. In that area I'd say Nexus rocks and will most
likely be even better/easier when the plugin architecture is improved
in v1.4.

/Anders

On Fri, Jun 26, 2009 at 03:07, Brian Fox<brianf@...> wrote:

> You probably also want to look into non-functional requirements like
> performance, memory consumption and how the files are stored for ease of
> backup and disaster recovery.
>
> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:
>>
>> Thank you,
>> that is very useful. I think that if we choose to go with Nexus the
>> professional edition we would probably need the pro edition.
>>  Chris
>>
>>
>> Tamás Cservenák wrote:
>> >
>> > Hi there,
>> >
>> > at first glance, you would achieve your requirements by using
>> > following features of latest Nexus Pro release:
>> >
>> > - Not Automatically Fetching libraries: Artifact procurement
>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>> >
>> > - Auditing of changes to repository: not completely equal to your
>> > needs, but Nexus does have RSS feeds, and they do say who did what and
>> > when. You can tie that RSS feed in some 3rd party software to add
>> > comments/annotate those. Not described in the book, but you can see
>> > all available RSS feeds on our instance:
>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>> >
>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>> > Nexus. You would end up with a grouped repository, that would contain
>> > this non-procured repo with plugins and the procured repository for
>> > your other dependencies.
>> >
>> > - Security model for Administrators: easily done, Nexus security is
>> > really fine-grained (maybe even too fine) :)
>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>> >
>> > Just to mention, the 1st requirement "procurement" is available in
>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>> >
>> > Hope helps,
>> > ~t~
>> >
>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>> >> Hi, The company I work for are currently performing maven builds using
>> >> a
>> >> file-based repository on a shared drive. We would like the libraries to
>> >> be
>> >> under some form of configuration management, and are evaluating Nexus,
>> >> Affinity, and Archiva - selected simply because they are mentioned on
>> >> the
>> >> Maven site. The requirements that we have are:
>> >>
>> >> Not Automatically Fetching Libraries
>> >> We would like to be able to set up a repository that does not
>> >> automatically
>> >> download a new library just because a developer specifies it in a .pom
>> >> file.
>> >> We would like an administrator to have to add the file to the
>> >> repository
>> >> deliberately. The initial archive would ideally be populated first from
>> >> our
>> >> file-based repository, alternatively a build could force an initial
>> >> fetch
>> >> then the archive configured not to fetch automatically.
>> >>
>> >> The reason that we want this is so that if a third party changes a
>> >> library
>> >> without changing the version number we won't pick up the new version
>> >> unknowingly. Also we want to ensure that only known libraries and
>> >> versions
>> >> are in a build.
>> >>
>> >> Auditing of changes to repository
>> >> With information about who does what when. Ideally it would be nice to
>> >> enable the administrator to add a comment, so they could say why and
>> >> for
>> >> which project.
>> >>
>> >> "Normal" archiving of plug-ins
>> >> The archive should ideally act as a cache for plug-ins, downloading
>> >> from
>> >> the
>> >> internet when required.
>> >>
>> >> Security model for Administrators
>> >> Basically only administrators should be able to add or remove libraries
>> >> or
>> >> versions from the repository.
>> >>
>> >> I am looking at Nexus to see how it can achieve the above, I assume
>> >> that
>> >> we
>> >> need to use a hosted repository. Any pointers on what can/can't be done
>> >> and
>> >> how it can be achieved would be welcome.
>> >>
>> >> Thanks,
>> >> Chris
>> >> ________________________________
>> >> View this message in context: Evaluating Archive Managers - can Nexus
>> >> do
>> >> this
>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>> >> archive
>> >> at Nabble.com.
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: nexus-user-unsubscribe@...
>> > For additional commands, e-mail: nexus-user-help@...
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>> Sent from the Nexus Maven Repository Manager Users List mailing list
>> archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: nexus-user-unsubscribe@...
>> For additional commands, e-mail: nexus-user-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

[Anders Hammar]

Any chance you could do a brief translation into English? Just the
highlights would be enough.

/Anders

On Fri, Jun 26, 2009 at 09:52, Fabrice
Mercier<fabrice.mercier.pro@...> wrote:

> You can read this article
> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
>
> 2009/6/26 Brian Fox <brianf@...>
>>
>> You probably also want to look into non-functional requirements like
>> performance, memory consumption and how the files are stored for ease of
>> backup and disaster recovery.
>>
>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:
>>>
>>> Thank you,
>>> that is very useful. I think that if we choose to go with Nexus the
>>> professional edition we would probably need the pro edition.
>>>  Chris
>>>
>>>
>>> Tamás Cservenák wrote:
>>> >
>>> > Hi there,
>>> >
>>> > at first glance, you would achieve your requirements by using
>>> > following features of latest Nexus Pro release:
>>> >
>>> > - Not Automatically Fetching libraries: Artifact procurement
>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>>> >
>>> > - Auditing of changes to repository: not completely equal to your
>>> > needs, but Nexus does have RSS feeds, and they do say who did what and
>>> > when. You can tie that RSS feed in some 3rd party software to add
>>> > comments/annotate those. Not described in the book, but you can see
>>> > all available RSS feeds on our instance:
>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>>> >
>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>>> > Nexus. You would end up with a grouped repository, that would contain
>>> > this non-procured repo with plugins and the procured repository for
>>> > your other dependencies.
>>> >
>>> > - Security model for Administrators: easily done, Nexus security is
>>> > really fine-grained (maybe even too fine) :)
>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>>> >
>>> > Just to mention, the 1st requirement "procurement" is available in
>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>>> >
>>> > Hope helps,
>>> > ~t~
>>> >
>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>>> >> Hi, The company I work for are currently performing maven builds using
>>> >> a
>>> >> file-based repository on a shared drive. We would like the libraries
>>> >> to
>>> >> be
>>> >> under some form of configuration management, and are evaluating Nexus,
>>> >> Affinity, and Archiva - selected simply because they are mentioned on
>>> >> the
>>> >> Maven site. The requirements that we have are:
>>> >>
>>> >> Not Automatically Fetching Libraries
>>> >> We would like to be able to set up a repository that does not
>>> >> automatically
>>> >> download a new library just because a developer specifies it in a .pom
>>> >> file.
>>> >> We would like an administrator to have to add the file to the
>>> >> repository
>>> >> deliberately. The initial archive would ideally be populated first
>>> >> from
>>> >> our
>>> >> file-based repository, alternatively a build could force an initial
>>> >> fetch
>>> >> then the archive configured not to fetch automatically.
>>> >>
>>> >> The reason that we want this is so that if a third party changes a
>>> >> library
>>> >> without changing the version number we won't pick up the new version
>>> >> unknowingly. Also we want to ensure that only known libraries and
>>> >> versions
>>> >> are in a build.
>>> >>
>>> >> Auditing of changes to repository
>>> >> With information about who does what when. Ideally it would be nice to
>>> >> enable the administrator to add a comment, so they could say why and
>>> >> for
>>> >> which project.
>>> >>
>>> >> "Normal" archiving of plug-ins
>>> >> The archive should ideally act as a cache for plug-ins, downloading
>>> >> from
>>> >> the
>>> >> internet when required.
>>> >>
>>> >> Security model for Administrators
>>> >> Basically only administrators should be able to add or remove
>>> >> libraries
>>> >> or
>>> >> versions from the repository.
>>> >>
>>> >> I am looking at Nexus to see how it can achieve the above, I assume
>>> >> that
>>> >> we
>>> >> need to use a hosted repository. Any pointers on what can/can't be
>>> >> done
>>> >> and
>>> >> how it can be achieved would be welcome.
>>> >>
>>> >> Thanks,
>>> >> Chris
>>> >> ________________________________
>>> >> View this message in context: Evaluating Archive Managers - can Nexus
>>> >> do
>>> >> this
>>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> >> archive
>>> >> at Nabble.com.
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> > For additional commands, e-mail: nexus-user-help@...
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>>> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> For additional commands, e-mail: nexus-user-help@...
>>>
>>
>
>
>
> --
> Cordialement / Best regards
>
> Fabrice Mercier
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

[Fabrice Mercier-3]

You have google traduction for that :-)

2009/6/26 Anders Hammar <anders@...>

Any chance you could do a brief translation into English? Just the
highlights would be enough.

/Anders

On Fri, Jun 26, 2009 at 09:52, Fabrice
Mercier<[e-mail]> wrote:
> You can read this article
> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
>
> 2009/6/26 Brian Fox <brianf@...>
>>
>> You probably also want to look into non-functional requirements like
>> performance, memory consumption and how the files are stored for ease of
>> backup and disaster recovery.
>>
>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:
>>>
>>> Thank you,
>>> that is very useful. I think that if we choose to go with Nexus the
>>> professional edition we would probably need the pro edition.
>>>  Chris
>>>
>>>
>>> Tamás Cservenák wrote:
>>> >
>>> > Hi there,
>>> >
>>> > at first glance, you would achieve your requirements by using
>>> > following features of latest Nexus Pro release:
>>> >
>>> > - Not Automatically Fetching libraries: Artifact procurement
>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>>> >
>>> > - Auditing of changes to repository: not completely equal to your
>>> > needs, but Nexus does have RSS feeds, and they do say who did what and
>>> > when. You can tie that RSS feed in some 3rd party software to add
>>> > comments/annotate those. Not described in the book, but you can see
>>> > all available RSS feeds on our instance:
>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>>> >
>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>>> > Nexus. You would end up with a grouped repository, that would contain
>>> > this non-procured repo with plugins and the procured repository for
>>> > your other dependencies.
>>> >
>>> > - Security model for Administrators: easily done, Nexus security is
>>> > really fine-grained (maybe even too fine) :)
>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>>> >
>>> > Just to mention, the 1st requirement "procurement" is available in
>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>>> >
>>> > Hope helps,
>>> > ~t~
>>> >
>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>>> >> Hi, The company I work for are currently performing maven builds using
>>> >> a
>>> >> file-based repository on a shared drive. We would like the libraries
>>> >> to
>>> >> be
>>> >> under some form of configuration management, and are evaluating Nexus,
>>> >> Affinity, and Archiva - selected simply because they are mentioned on
>>> >> the
>>> >> Maven site. The requirements that we have are:
>>> >>
>>> >> Not Automatically Fetching Libraries
>>> >> We would like to be able to set up a repository that does not
>>> >> automatically
>>> >> download a new library just because a developer specifies it in a .pom
>>> >> file.
>>> >> We would like an administrator to have to add the file to the
>>> >> repository
>>> >> deliberately. The initial archive would ideally be populated first
>>> >> from
>>> >> our
>>> >> file-based repository, alternatively a build could force an initial
>>> >> fetch
>>> >> then the archive configured not to fetch automatically.
>>> >>
>>> >> The reason that we want this is so that if a third party changes a
>>> >> library
>>> >> without changing the version number we won't pick up the new version
>>> >> unknowingly. Also we want to ensure that only known libraries and
>>> >> versions
>>> >> are in a build.
>>> >>
>>> >> Auditing of changes to repository
>>> >> With information about who does what when. Ideally it would be nice to
>>> >> enable the administrator to add a comment, so they could say why and
>>> >> for
>>> >> which project.
>>> >>
>>> >> "Normal" archiving of plug-ins
>>> >> The archive should ideally act as a cache for plug-ins, downloading
>>> >> from
>>> >> the
>>> >> internet when required.
>>> >>
>>> >> Security model for Administrators
>>> >> Basically only administrators should be able to add or remove
>>> >> libraries
>>> >> or
>>> >> versions from the repository.
>>> >>
>>> >> I am looking at Nexus to see how it can achieve the above, I assume
>>> >> that
>>> >> we
>>> >> need to use a hosted repository. Any pointers on what can/can't be
>>> >> done
>>> >> and
>>> >> how it can be achieved would be welcome.
>>> >>
>>> >> Thanks,
>>> >> Chris
>>> >> ________________________________
>>> >> View this message in context: Evaluating Archive Managers - can Nexus
>>> >> do
>>> >> this
>>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> >> archive
>>> >> at Nabble.com.
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> > For additional commands, e-mail: nexus-user-help@...
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>>> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> For additional commands, e-mail: nexus-user-help@...
>>>
>>
>
>
>
> --
> Cordialement / Best regards
>
> Fabrice Mercier
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

--
Cordialement / Best regards

Fabrice Mercier

[Baptiste MATHUS]

Hi Anders,

• "Le nombre de descripteurs de fichiers ouverts par le produit" : file descriptor count open by Nexus.
• La consommation mémoire : memory consumption
• Les problèmes de snapshots non trouvés : the "snapshot not found" problem
• Due to some maven or nexus bugs (see references)
• Les cookies rejetés : Rejected cookies.
• Some problems were encountered with rewriting rules. Maven complains when it deploys that cookies are rejected. No harm, but it just gets noisy in the logs.
  
• La cerise sur le gâteau : something like "last but not least"
• Something like "In the end, all those resources saves on the server and the better quality of nexus for artifact upload (whatever its size) provides the integration server a real better stability/regularity. As you can see below in those graphics created using Bamboo, there's a clear reduction when nexus was put in use. You can notice an exceptional regularity with build times, and more importantly a big reduction of those".
• Conclusion : Use nexus ! (this is even more interesting it because Arnaud reminds us that he's one of the member of the archiva team).

Cheers.

2009/6/26 Anders Hammar <anders@...>

Any chance you could do a brief translation into English? Just the
highlights would be enough.

/Anders

On Fri, Jun 26, 2009 at 09:52, Fabrice
Mercier<[e-mail]> wrote:
> You can read this article
> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
>
> 2009/6/26 Brian Fox <brianf@...>
>>
>> You probably also want to look into non-functional requirements like
>> performance, memory consumption and how the files are stored for ease of
>> backup and disaster recovery.
>>
>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:
>>>
>>> Thank you,
>>> that is very useful. I think that if we choose to go with Nexus the
>>> professional edition we would probably need the pro edition.
>>>  Chris
>>>
>>>
>>> Tamás Cservenák wrote:
>>> >
>>> > Hi there,
>>> >
>>> > at first glance, you would achieve your requirements by using
>>> > following features of latest Nexus Pro release:
>>> >
>>> > - Not Automatically Fetching libraries: Artifact procurement
>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>>> >
>>> > - Auditing of changes to repository: not completely equal to your
>>> > needs, but Nexus does have RSS feeds, and they do say who did what and
>>> > when. You can tie that RSS feed in some 3rd party software to add
>>> > comments/annotate those. Not described in the book, but you can see
>>> > all available RSS feeds on our instance:
>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>>> >
>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>>> > Nexus. You would end up with a grouped repository, that would contain
>>> > this non-procured repo with plugins and the procured repository for
>>> > your other dependencies.
>>> >
>>> > - Security model for Administrators: easily done, Nexus security is
>>> > really fine-grained (maybe even too fine) :)
>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>>> >
>>> > Just to mention, the 1st requirement "procurement" is available in
>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>>> >
>>> > Hope helps,
>>> > ~t~
>>> >
>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>>> >> Hi, The company I work for are currently performing maven builds using
>>> >> a
>>> >> file-based repository on a shared drive. We would like the libraries
>>> >> to
>>> >> be
>>> >> under some form of configuration management, and are evaluating Nexus,
>>> >> Affinity, and Archiva - selected simply because they are mentioned on
>>> >> the
>>> >> Maven site. The requirements that we have are:
>>> >>
>>> >> Not Automatically Fetching Libraries
>>> >> We would like to be able to set up a repository that does not
>>> >> automatically
>>> >> download a new library just because a developer specifies it in a .pom
>>> >> file.
>>> >> We would like an administrator to have to add the file to the
>>> >> repository
>>> >> deliberately. The initial archive would ideally be populated first
>>> >> from
>>> >> our
>>> >> file-based repository, alternatively a build could force an initial
>>> >> fetch
>>> >> then the archive configured not to fetch automatically.
>>> >>
>>> >> The reason that we want this is so that if a third party changes a
>>> >> library
>>> >> without changing the version number we won't pick up the new version
>>> >> unknowingly. Also we want to ensure that only known libraries and
>>> >> versions
>>> >> are in a build.
>>> >>
>>> >> Auditing of changes to repository
>>> >> With information about who does what when. Ideally it would be nice to
>>> >> enable the administrator to add a comment, so they could say why and
>>> >> for
>>> >> which project.
>>> >>
>>> >> "Normal" archiving of plug-ins
>>> >> The archive should ideally act as a cache for plug-ins, downloading
>>> >> from
>>> >> the
>>> >> internet when required.
>>> >>
>>> >> Security model for Administrators
>>> >> Basically only administrators should be able to add or remove
>>> >> libraries
>>> >> or
>>> >> versions from the repository.
>>> >>
>>> >> I am looking at Nexus to see how it can achieve the above, I assume
>>> >> that
>>> >> we
>>> >> need to use a hosted repository. Any pointers on what can/can't be
>>> >> done
>>> >> and
>>> >> how it can be achieved would be welcome.
>>> >>
>>> >> Thanks,
>>> >> Chris
>>> >> ________________________________
>>> >> View this message in context: Evaluating Archive Managers - can Nexus
>>> >> do
>>> >> this
>>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> >> archive
>>> >> at Nabble.com.
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> > For additional commands, e-mail: nexus-user-help@...
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>>> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> For additional commands, e-mail: nexus-user-help@...
>>>
>>
>
>
>
> --
> Cordialement / Best regards
>
> Fabrice Mercier
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Brian Fox]

The google translations are quite readable, here they are


The first and second installments are here:
http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fblog.aheritier.net%2Fdapache-archiva-a-sonatype-nexus-introduction%2F&sl=fr&tl=en&history_state0=
http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fblog.aheritier.net%2Fdapache-archiva-a-sonatype-nexus-la-migration%2F&sl=fr&tl=en&history_state0==

http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fblog.aheritier.net%2Fdapache-archiva-a-sonatype-nexus-le-bilan%2F&sl=fr&tl=en&history_state0=

On Fri, Jun 26, 2009 at 3:59 AM, Anders Hammar <anders@...> wrote:

Any chance you could do a brief translation into English? Just the
highlights would be enough.

/Anders

On Fri, Jun 26, 2009 at 09:52, Fabrice
Mercier<[e-mail]> wrote:
> You can read this article
> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
>
> 2009/6/26 Brian Fox <brianf@...>
>>
>> You probably also want to look into non-functional requirements like
>> performance, memory consumption and how the files are stored for ease of
>> backup and disaster recovery.
>>
>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:
>>>
>>> Thank you,
>>> that is very useful. I think that if we choose to go with Nexus the
>>> professional edition we would probably need the pro edition.
>>>  Chris
>>>
>>>
>>> Tamás Cservenák wrote:
>>> >
>>> > Hi there,
>>> >
>>> > at first glance, you would achieve your requirements by using
>>> > following features of latest Nexus Pro release:
>>> >
>>> > - Not Automatically Fetching libraries: Artifact procurement
>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>>> >
>>> > - Auditing of changes to repository: not completely equal to your
>>> > needs, but Nexus does have RSS feeds, and they do say who did what and
>>> > when. You can tie that RSS feed in some 3rd party software to add
>>> > comments/annotate those. Not described in the book, but you can see
>>> > all available RSS feeds on our instance:
>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>>> >
>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>>> > Nexus. You would end up with a grouped repository, that would contain
>>> > this non-procured repo with plugins and the procured repository for
>>> > your other dependencies.
>>> >
>>> > - Security model for Administrators: easily done, Nexus security is
>>> > really fine-grained (maybe even too fine) :)
>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>>> >
>>> > Just to mention, the 1st requirement "procurement" is available in
>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>>> >
>>> > Hope helps,
>>> > ~t~
>>> >
>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>>> >> Hi, The company I work for are currently performing maven builds using
>>> >> a
>>> >> file-based repository on a shared drive. We would like the libraries
>>> >> to
>>> >> be
>>> >> under some form of configuration management, and are evaluating Nexus,
>>> >> Affinity, and Archiva - selected simply because they are mentioned on
>>> >> the
>>> >> Maven site. The requirements that we have are:
>>> >>
>>> >> Not Automatically Fetching Libraries
>>> >> We would like to be able to set up a repository that does not
>>> >> automatically
>>> >> download a new library just because a developer specifies it in a .pom
>>> >> file.
>>> >> We would like an administrator to have to add the file to the
>>> >> repository
>>> >> deliberately. The initial archive would ideally be populated first
>>> >> from
>>> >> our
>>> >> file-based repository, alternatively a build could force an initial
>>> >> fetch
>>> >> then the archive configured not to fetch automatically.
>>> >>
>>> >> The reason that we want this is so that if a third party changes a
>>> >> library
>>> >> without changing the version number we won't pick up the new version
>>> >> unknowingly. Also we want to ensure that only known libraries and
>>> >> versions
>>> >> are in a build.
>>> >>
>>> >> Auditing of changes to repository
>>> >> With information about who does what when. Ideally it would be nice to
>>> >> enable the administrator to add a comment, so they could say why and
>>> >> for
>>> >> which project.
>>> >>
>>> >> "Normal" archiving of plug-ins
>>> >> The archive should ideally act as a cache for plug-ins, downloading
>>> >> from
>>> >> the
>>> >> internet when required.
>>> >>
>>> >> Security model for Administrators
>>> >> Basically only administrators should be able to add or remove
>>> >> libraries
>>> >> or
>>> >> versions from the repository.
>>> >>
>>> >> I am looking at Nexus to see how it can achieve the above, I assume
>>> >> that
>>> >> we
>>> >> need to use a hosted repository. Any pointers on what can/can't be
>>> >> done
>>> >> and
>>> >> how it can be achieved would be welcome.
>>> >>
>>> >> Thanks,
>>> >> Chris
>>> >> ________________________________
>>> >> View this message in context: Evaluating Archive Managers - can Nexus
>>> >> do
>>> >> this
>>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> >> archive
>>> >> at Nabble.com.
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> > For additional commands, e-mail: nexus-user-help@...
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>>> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>> For additional commands, e-mail: nexus-user-help@...
>>>
>>
>
>
>
> --
> Cordialement / Best regards
>
> Fabrice Mercier
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

[Baptiste MATHUS]

Hi Anders (wrote this in the morning, but it seems like it didn't get through),

    * "Le nombre de descripteurs de fichiers ouverts par le produit" : file descriptor count open by Nexus.
    * La consommation mémoire : memory consumption
    * Les problèmes de snapshots non trouvés : the "snapshot not found" problem
          o Due to some maven or nexus bugs (see references)
    * Les cookies rejetés : Rejected cookies.
          o Some problems were encountered with rewriting rules. Maven complains when it deploys that cookies are rejected. No harm, but it just gets noisy in the logs.
    * La cerise sur le gâteau : something like "last but not least"
          o Something like "In the end, all those resources saves on the server and the better quality of nexus for artifact upload (whatever its size) provides the integration server a real better stability/regularity. As you can see below in those graphics created using Bamboo, there's a clear reduction when nexus was put in use. You can notice an exceptional regularity with build times, and more importantly a big reduction of those".
    * Conclusion : Use nexus ! (this is even more interesting it because Arnaud reminds us that he's one of the member of the archiva team).

Cheers.

Anders Hammar wrote:

Any chance you could do a brief translation into English? Just the
highlights would be enough.

/Anders

On Fri, Jun 26, 2009 at 09:52, Fabrice
Mercier<[e-mail]> wrote:
> You can read this article
> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
>
> 2009/6/26 Brian Fox <[e-mail]>
>>
>> You probably also want to look into non-functional requirements like
>> performance, memory consumption and how the files are stored for ease of
>> backup and disaster recovery.
>>
>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <[e-mail]> wrote:
>>>
>>> Thank you,
>>> that is very useful. I think that if we choose to go with Nexus the
>>> professional edition we would probably need the pro edition.
>>>  Chris
>>>
>>>
>>> Tamás Cservenák wrote:
>>> >
>>> > Hi there,
>>> >
>>> > at first glance, you would achieve your requirements by using
>>> > following features of latest Nexus Pro release:
>>> >
>>> > - Not Automatically Fetching libraries: Artifact procurement
>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>>> >
>>> > - Auditing of changes to repository: not completely equal to your
>>> > needs, but Nexus does have RSS feeds, and they do say who did what and
>>> > when. You can tie that RSS feed in some 3rd party software to add
>>> > comments/annotate those. Not described in the book, but you can see
>>> > all available RSS feeds on our instance:
>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>>> >
>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>>> > Nexus. You would end up with a grouped repository, that would contain
>>> > this non-procured repo with plugins and the procured repository for
>>> > your other dependencies.
>>> >
>>> > - Security model for Administrators: easily done, Nexus security is
>>> > really fine-grained (maybe even too fine) :)
>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>>> >
>>> > Just to mention, the 1st requirement "procurement" is available in
>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>>> >
>>> > Hope helps,
>>> > ~t~
>>> >
>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<[e-mail]> wrote:
>>> >> Hi, The company I work for are currently performing maven builds using
>>> >> a
>>> >> file-based repository on a shared drive. We would like the libraries
>>> >> to
>>> >> be
>>> >> under some form of configuration management, and are evaluating Nexus,
>>> >> Affinity, and Archiva - selected simply because they are mentioned on
>>> >> the
>>> >> Maven site. The requirements that we have are:
>>> >>
>>> >> Not Automatically Fetching Libraries
>>> >> We would like to be able to set up a repository that does not
>>> >> automatically
>>> >> download a new library just because a developer specifies it in a .pom
>>> >> file.
>>> >> We would like an administrator to have to add the file to the
>>> >> repository
>>> >> deliberately. The initial archive would ideally be populated first
>>> >> from
>>> >> our
>>> >> file-based repository, alternatively a build could force an initial
>>> >> fetch
>>> >> then the archive configured not to fetch automatically.
>>> >>
>>> >> The reason that we want this is so that if a third party changes a
>>> >> library
>>> >> without changing the version number we won't pick up the new version
>>> >> unknowingly. Also we want to ensure that only known libraries and
>>> >> versions
>>> >> are in a build.
>>> >>
>>> >> Auditing of changes to repository
>>> >> With information about who does what when. Ideally it would be nice to
>>> >> enable the administrator to add a comment, so they could say why and
>>> >> for
>>> >> which project.
>>> >>
>>> >> "Normal" archiving of plug-ins
>>> >> The archive should ideally act as a cache for plug-ins, downloading
>>> >> from
>>> >> the
>>> >> internet when required.
>>> >>
>>> >> Security model for Administrators
>>> >> Basically only administrators should be able to add or remove
>>> >> libraries
>>> >> or
>>> >> versions from the repository.
>>> >>
>>> >> I am looking at Nexus to see how it can achieve the above, I assume
>>> >> that
>>> >> we
>>> >> need to use a hosted repository. Any pointers on what can/can't be
>>> >> done
>>> >> and
>>> >> how it can be achieved would be welcome.
>>> >>
>>> >> Thanks,
>>> >> Chris
>>> >> ________________________________
>>> >> View this message in context: Evaluating Archive Managers - can Nexus
>>> >> do
>>> >> this
>>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> >> archive
>>> >> at Nabble.com.
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [e-mail]
>>> > For additional commands, e-mail: [e-mail]
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>>> Sent from the Nexus Maven Repository Manager Users List mailing list
>>> archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [e-mail]
>>> For additional commands, e-mail: [e-mail]
>>>
>>
>
>
>
> --
> Cordialement / Best regards
>
> Fabrice Mercier
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Fabrice Mercier-3]

it is so funny for me, as a french, to see traduction
La cerise sur le gâteau : something like "last but not least"

:-)

2009/6/26 Baptiste MATHUS <ml@...>

Hi Anders (wrote this in the morning, but it seems like it didn't get
through),

   * "Le nombre de descripteurs de fichiers ouverts par le produit" : file
descriptor count open by Nexus.
   * La consommation mémoire : memory consumption
   * Les problèmes de snapshots non trouvés : the "snapshot not found"
problem
         o Due to some maven or nexus bugs (see references)
   * Les cookies rejetés : Rejected cookies.
         o Some problems were encountered with rewriting rules. Maven
complains when it deploys that cookies are rejected. No harm, but it just
gets noisy in the logs.
   * La cerise sur le gâteau : something like "last but not least"
         o Something like "In the end, all those resources saves on the
server and the better quality of nexus for artifact upload (whatever its
size) provides the integration server a real better stability/regularity. As
you can see below in those graphics created using Bamboo, there's a clear
reduction when nexus was put in use. You can notice an exceptional
regularity with build times, and more importantly a big reduction of those".
   * Conclusion : Use nexus ! (this is even more interesting it because
Arnaud reminds us that he's one of the member of the archiva team).

Cheers.

Anders Hammar wrote:
>
> Any chance you could do a brief translation into English? Just the
> highlights would be enough.
>
> /Anders
>
> On Fri, Jun 26, 2009 at 09:52, Fabrice
> Mercier<[e-mail]> wrote:
>> You can read this article
>> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
>>
>> 2009/6/26 Brian Fox <brianf@...>
>>>
>>> You probably also want to look into non-functional requirements like
>>> performance, memory consumption and how the files are stored for ease of
>>> backup and disaster recovery.
>>>
>>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <czbrooking@...> wrote:
>>>>
>>>> Thank you,
>>>> that is very useful. I think that if we choose to go with Nexus the
>>>> professional edition we would probably need the pro edition.
>>>>  Chris
>>>>
>>>>
>>>> Tamás Cservenák wrote:
>>>> >
>>>> > Hi there,
>>>> >
>>>> > at first glance, you would achieve your requirements by using
>>>> > following features of latest Nexus Pro release:
>>>> >
>>>> > - Not Automatically Fetching libraries: Artifact procurement
>>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
>>>> >
>>>> > - Auditing of changes to repository: not completely equal to your
>>>> > needs, but Nexus does have RSS feeds, and they do say who did what
>>>> and
>>>> > when. You can tie that RSS feed in some 3rd party software to add
>>>> > comments/annotate those. Not described in the book, but you can see
>>>> > all available RSS feeds on our instance:
>>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
>>>> >
>>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
>>>> > Nexus. You would end up with a grouped repository, that would contain
>>>> > this non-procured repo with plugins and the procured repository for
>>>> > your other dependencies.
>>>> >
>>>> > - Security model for Administrators: easily done, Nexus security is
>>>> > really fine-grained (maybe even too fine) :)
>>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
>>>> >
>>>> > Just to mention, the 1st requirement "procurement" is available in
>>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
>>>> >
>>>> > Hope helps,
>>>> > ~t~
>>>> >
>>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<czbrooking@...> wrote:
>>>> >> Hi, The company I work for are currently performing maven builds
>>>> using
>>>> >> a
>>>> >> file-based repository on a shared drive. We would like the libraries
>>>> >> to
>>>> >> be
>>>> >> under some form of configuration management, and are evaluating
>>>> Nexus,
>>>> >> Affinity, and Archiva - selected simply because they are mentioned
>>>> on
>>>> >> the
>>>> >> Maven site. The requirements that we have are:
>>>> >>
>>>> >> Not Automatically Fetching Libraries
>>>> >> We would like to be able to set up a repository that does not
>>>> >> automatically
>>>> >> download a new library just because a developer specifies it in a
>>>> .pom
>>>> >> file.
>>>> >> We would like an administrator to have to add the file to the
>>>> >> repository
>>>> >> deliberately. The initial archive would ideally be populated first
>>>> >> from
>>>> >> our
>>>> >> file-based repository, alternatively a build could force an initial
>>>> >> fetch
>>>> >> then the archive configured not to fetch automatically.
>>>> >>
>>>> >> The reason that we want this is so that if a third party changes a
>>>> >> library
>>>> >> without changing the version number we won't pick up the new version
>>>> >> unknowingly. Also we want to ensure that only known libraries and
>>>> >> versions
>>>> >> are in a build.
>>>> >>
>>>> >> Auditing of changes to repository
>>>> >> With information about who does what when. Ideally it would be nice
>>>> to
>>>> >> enable the administrator to add a comment, so they could say why and
>>>> >> for
>>>> >> which project.
>>>> >>
>>>> >> "Normal" archiving of plug-ins
>>>> >> The archive should ideally act as a cache for plug-ins, downloading
>>>> >> from
>>>> >> the
>>>> >> internet when required.
>>>> >>
>>>> >> Security model for Administrators
>>>> >> Basically only administrators should be able to add or remove
>>>> >> libraries
>>>> >> or
>>>> >> versions from the repository.
>>>> >>
>>>> >> I am looking at Nexus to see how it can achieve the above, I assume
>>>> >> that
>>>> >> we
>>>> >> need to use a hosted repository. Any pointers on what can/can't be
>>>> >> done
>>>> >> and
>>>> >> how it can be achieved would be welcome.
>>>> >>
>>>> >> Thanks,
>>>> >> Chris
>>>> >> ________________________________
>>>> >> View this message in context: Evaluating Archive Managers - can
>>>> Nexus
>>>> >> do
>>>> >> this
>>>> >> Sent from the Nexus Maven Repository Manager Users List mailing list
>>>> >> archive
>>>> >> at Nabble.com.
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>>> > For additional commands, e-mail: nexus-user-help@...
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
>>>> Sent from the Nexus Maven Repository Manager Users List mailing list
>>>> archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: nexus-user-unsubscribe@...
>>>> For additional commands, e-mail: nexus-user-help@...
>>>>
>>>
>>
>>
>>
>> --
>> Cordialement / Best regards
>>
>> Fabrice Mercier
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-user-unsubscribe@...
> For additional commands, e-mail: nexus-user-help@...
>
>
>

--
View this message in context: http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24220861.html

Sent from the Nexus Maven Repository Manager Users List mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

--
Cordialement / Best regards

Fabrice Mercier

[Baptiste MATHUS]

:-).


Well, for non-french users, litteral translation is "cherry on the cake", but I wasn't sure this idiom exists in english. Does it?

Cheers (and not "cherries" ;-)).

Fabrice Mercier-3 wrote:

it is so funny for me, as a french, to see traduction
La cerise sur le gâteau : something like "last but not least"

:-)


2009/6/26 Baptiste MATHUS <[e-mail]>

>
> Hi Anders (wrote this in the morning, but it seems like it didn't get
> through),
>
>    * "Le nombre de descripteurs de fichiers ouverts par le produit" : file
> descriptor count open by Nexus.
>    * La consommation mémoire : memory consumption
>    * Les problèmes de snapshots non trouvés : the "snapshot not found"
> problem
>          o Due to some maven or nexus bugs (see references)
>    * Les cookies rejetés : Rejected cookies.
>          o Some problems were encountered with rewriting rules. Maven
> complains when it deploys that cookies are rejected. No harm, but it just
> gets noisy in the logs.
>    * La cerise sur le gâteau : something like "last but not least"
>          o Something like "In the end, all those resources saves on the
> server and the better quality of nexus for artifact upload (whatever its
> size) provides the integration server a real better stability/regularity.
> As
> you can see below in those graphics created using Bamboo, there's a clear
> reduction when nexus was put in use. You can notice an exceptional
> regularity with build times, and more importantly a big reduction of
> those".
>    * Conclusion : Use nexus ! (this is even more interesting it because
> Arnaud reminds us that he's one of the member of the archiva team).
>
> Cheers.
>
>
> Anders Hammar wrote:
> >
> > Any chance you could do a brief translation into English? Just the
> > highlights would be enough.
> >
> > /Anders
> >
> > On Fri, Jun 26, 2009 at 09:52, Fabrice
> > Mercier<[e-mail]> wrote:
> >> You can read this article
> >> http://blog.aheritier.net/dapache-archiva-a-sonatype-nexus-le-bilan/
> >>
> >> 2009/6/26 Brian Fox <[e-mail]>
> >>>
> >>> You probably also want to look into non-functional requirements like
> >>> performance, memory consumption and how the files are stored for ease
> of
> >>> backup and disaster recovery.
> >>>
> >>> On Tue, Jun 23, 2009 at 10:21 AM, ChrisY <[e-mail]> wrote:
> >>>>
> >>>> Thank you,
> >>>> that is very useful. I think that if we choose to go with Nexus the
> >>>> professional edition we would probably need the pro edition.
> >>>>  Chris
> >>>>
> >>>>
> >>>> Tamás Cservenák wrote:
> >>>> >
> >>>> > Hi there,
> >>>> >
> >>>> > at first glance, you would achieve your requirements by using
> >>>> > following features of latest Nexus Pro release:
> >>>> >
> >>>> > - Not Automatically Fetching libraries: Artifact procurement
> >>>> > http://www.sonatype.com/books/nexus-book/reference/procure.html
> >>>> >
> >>>> > - Auditing of changes to repository: not completely equal to your
> >>>> > needs, but Nexus does have RSS feeds, and they do say who did what
> >>>> and
> >>>> > when. You can tie that RSS feed in some 3rd party software to add
> >>>> > comments/annotate those. Not described in the book, but you can see
> >>>> > all available RSS feeds on our instance:
> >>>> > http://repository.sonatype.org/index.html#feed-view-system-changes
> >>>> >
> >>>> > - "Normal" archiving of plugins: plain proxying, basic capability of
> >>>> > Nexus. You would end up with a grouped repository, that would
> contain
> >>>> > this non-procured repo with plugins and the procured repository for
> >>>> > your other dependencies.
> >>>> >
> >>>> > - Security model for Administrators: easily done, Nexus security is
> >>>> > really fine-grained (maybe even too fine) :)
> >>>> > http://www.sonatype.com/books/nexus-book/reference/config.html
> >>>> >
> >>>> > Just to mention, the 1st requirement "procurement" is available in
> >>>> > Nexus Pro only, while the rest is available in Nexus OSS too.
> >>>> >
> >>>> > Hope helps,
> >>>> > ~t~
> >>>> >
> >>>> > On Tue, Jun 23, 2009 at 2:56 PM, ChrisY<[e-mail]>
> wrote:
> >>>> >> Hi, The company I work for are currently performing maven builds
> >>>> using
> >>>> >> a
> >>>> >> file-based repository on a shared drive. We would like the
> libraries
> >>>> >> to
> >>>> >> be
> >>>> >> under some form of configuration management, and are evaluating
> >>>> Nexus,
> >>>> >> Affinity, and Archiva - selected simply because they are mentioned
> >>>> on
> >>>> >> the
> >>>> >> Maven site. The requirements that we have are:
> >>>> >>
> >>>> >> Not Automatically Fetching Libraries
> >>>> >> We would like to be able to set up a repository that does not
> >>>> >> automatically
> >>>> >> download a new library just because a developer specifies it in a
> >>>> .pom
> >>>> >> file.
> >>>> >> We would like an administrator to have to add the file to the
> >>>> >> repository
> >>>> >> deliberately. The initial archive would ideally be populated first
> >>>> >> from
> >>>> >> our
> >>>> >> file-based repository, alternatively a build could force an initial
> >>>> >> fetch
> >>>> >> then the archive configured not to fetch automatically.
> >>>> >>
> >>>> >> The reason that we want this is so that if a third party changes a
> >>>> >> library
> >>>> >> without changing the version number we won't pick up the new
> version
> >>>> >> unknowingly. Also we want to ensure that only known libraries and
> >>>> >> versions
> >>>> >> are in a build.
> >>>> >>
> >>>> >> Auditing of changes to repository
> >>>> >> With information about who does what when. Ideally it would be nice
> >>>> to
> >>>> >> enable the administrator to add a comment, so they could say why
> and
> >>>> >> for
> >>>> >> which project.
> >>>> >>
> >>>> >> "Normal" archiving of plug-ins
> >>>> >> The archive should ideally act as a cache for plug-ins, downloading
> >>>> >> from
> >>>> >> the
> >>>> >> internet when required.
> >>>> >>
> >>>> >> Security model for Administrators
> >>>> >> Basically only administrators should be able to add or remove
> >>>> >> libraries
> >>>> >> or
> >>>> >> versions from the repository.
> >>>> >>
> >>>> >> I am looking at Nexus to see how it can achieve the above, I assume
> >>>> >> that
> >>>> >> we
> >>>> >> need to use a hosted repository. Any pointers on what can/can't be
> >>>> >> done
> >>>> >> and
> >>>> >> how it can be achieved would be welcome.
> >>>> >>
> >>>> >> Thanks,
> >>>> >> Chris
> >>>> >> ________________________________
> >>>> >> View this message in context: Evaluating Archive Managers - can
> >>>> Nexus
> >>>> >> do
> >>>> >> this
> >>>> >> Sent from the Nexus Maven Repository Manager Users List mailing
> list
> >>>> >> archive
> >>>> >> at Nabble.com.
> >>>> >>
> >>>> >
> >>>> >
> ---------------------------------------------------------------------
> >>>> > To unsubscribe, e-mail: [e-mail]
> >>>> > For additional commands, e-mail: [e-mail]
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24166933.html
> >>>> Sent from the Nexus Maven Repository Manager Users List mailing list
> >>>> archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [e-mail]
> >>>> For additional commands, e-mail: [e-mail]
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement / Best regards
> >>
> >> Fabrice Mercier
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [e-mail]
> > For additional commands, e-mail: [e-mail]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Evaluating-Archive-Managers---can-Nexus-do-this-tp24165474p24220861.html
> Sent from the Nexus Maven Repository Manager Users List mailing list
> archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>


--
Cordialement / Best regards

Fabrice Mercier

[Nord, James-2]

> Well, for non-french users, litteral translation is "cherry
> on the cake", but I wasn't sure this idiom exists in english. Does it?

We English prefer icing on our cakes :-)

/James

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@... and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...

[Brian Fox]

But we do have "and the cherry on top..." or "the icing on the cake" 

On Fri, Jun 26, 2009 at 12:55 PM, Nord, James <JNord@...> wrote:

> Well, for non-french users, litteral translation is "cherry
> on the cake", but I wasn't sure this idiom exists in english. Does it?

We English prefer icing on our cakes :-)

/James

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@... and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-user-unsubscribe@...
For additional commands, e-mail: nexus-user-help@...