[dash-dev] repo.eclipse.org maven instance testing

[Thanh Ha]

Hi Everyone,

I posted this in Bug 394792 [1] but thought I'd post here too.

I think the new Maven instance at Eclipse is about ready to go. I've
been testing so far with the CBI project and released 2 plugins into the
repo so far:

- eclipse-cbi-plugin-1.0.0
- eclipse-jarsigner-plugin-1.0.2

The new instance can be reached at: https://repo.eclipse.org/

We decided on this new URL so that the current maven.eclipse.org won't
be affected while we setup.


At this point I'd like to invite any projects if interested to let me
know and I can add the project to the new instance at
https://repo.eclipse.org so you can try uploading your artifacts to the
new Nexus instance.

The goal is to give each project 2 repos:

- project-releases
- project-snapshots

As well as a group "project" to group the 2 repos. This group will also
be grouped by the top-level group "eclipse".


At the moment there are 4 projects repos defined: cbi, dash, xtend, and
xtext but only committers on CBI can commit to the CBI repos. The
remaining 3 repos are not yet linked to a committer group. I was hoping
a committer on each of the 3 remaining projects can confirm their
interest in using the new repo.eclipse.org and I can link the repo to
the committer group for the project.

Thanks,


Thanh

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=394792

[Matthias Sohn]

Post by Thanh Ha
Hi Everyone,
I posted this in Bug 394792 [1] but thought I'd post here too.
I think the new Maven instance at Eclipse is about ready to go. I've been
testing so far with the CBI project and released 2 plugins into the repo so
- eclipse-cbi-plugin-1.0.0
- eclipse-jarsigner-plugin-1.0.2
The new instance can be reached at: https://repo.eclipse.org/
We decided on this new URL so that the current maven.eclipse.org won't be
affected while we setup.
At this point I'd like to invite any projects if interested to let me know
and I can add the project to the new instance at https://repo.eclipse.orgso you can try uploading your artifacts to the new Nexus instance.
- project-releases
- project-snapshots
As well as a group "project" to group the 2 repos. This group will also be
grouped by the top-level group "eclipse".

This means consumers need to add a repository URL per eclipse project they
want to get artifacts from.
What's the reason for this hard to consume layout ?

Could you add a repository (group) combining the artifacts from all Eclipse
projects, e.g. "releases" and "snapshots".

What's the retention time for snapshot repositories ?

--
Matthias

[Thanh Ha]

Hi Matthias,

My response inline.

Post by Thanh Ha
Hi Everyone,
I posted this in Bug 394792 [1] but thought I'd post here too.
I think the new Maven instance at Eclipse is about ready to go.
I've been testing so far with the CBI project and released 2
- eclipse-cbi-plugin-1.0.0
- eclipse-jarsigner-plugin-1.0.2
The new instance can be reached at: https://repo.eclipse.org/
We decided on this new URL so that the current maven.eclipse.org
<http://maven.eclipse.org> won't be affected while we setup.
At this point I'd like to invite any projects if interested to let
me know and I can add the project to the new instance at
https://repo.eclipse.org so you can try uploading your artifacts
to the new Nexus instance.
- project-releases
- project-snapshots
As well as a group "project" to group the 2 repos. This group will
also be grouped by the top-level group "eclipse".
This means consumers need to add a repository URL per eclipse project
they want to get artifacts from.
What's the reason for this hard to consume layout ?
Could you add a repository (group) combining the artifacts from all
Eclipse projects, e.g. "releases" and "snapshots".

Sorry my explanation may not have been clear enough. This already exists
per the top-level project group "eclipse". Using the URL:

https://repo.eclipse.org/content/groups/eclipse/

This will pull all projects including both releases and snapshots repos.
So you can use it as the single URL to access the entirety of the Nexus
instance.

For those who want finer control, we also provide every project with
their own group that only contains their releases and snapshots repos.

Post by Thanh Ha
What's the retention time for snapshot repositories ?

I'm not sure what you mean by retention time. Can you explain this
setting? Is it the "Not Found Cache TTL"?

Post by Thanh Ha
--
Matthias
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

[Alex Blewitt]

You should also have a group which is 'only releases' and 'only snapshots'. In fact, I'd argue that the main 'eclipse' one only contain releases and have 'eclipse-snapshots' as a separate one, because there's rarely a good reason to mix both releases and snapshots in the same repository.

Alex

Post by Thanh Ha
Hi Matthias,
My response inline.

Post by Thanh Ha
Hi Everyone,
I posted this in Bug 394792 [1] but thought I'd post here too.
- eclipse-cbi-plugin-1.0.0
- eclipse-jarsigner-plugin-1.0.2
The new instance can be reached at: https://repo.eclipse.org/
We decided on this new URL so that the current maven.eclipse.org won't be affected while we setup.
At this point I'd like to invite any projects if interested to let me know and I can add the project to the new instance at https://repo.eclipse.org so you can try uploading your artifacts to the new Nexus instance.
- project-releases
- project-snapshots
As well as a group "project" to group the 2 repos. This group will also be grouped by the top-level group "eclipse".
This means consumers need to add a repository URL per eclipse project they want to get artifacts from.
What's the reason for this hard to consume layout ?
Could you add a repository (group) combining the artifacts from all Eclipse projects, e.g. "releases" and "snapshots".

https://repo.eclipse.org/content/groups/eclipse/
This will pull all projects including both releases and snapshots repos. So you can use it as the single URL to access the entirety of the Nexus instance.
For those who want finer control, we also provide every project with their own group that only contains their releases and snapshots repos.

Post by Thanh Ha
What's the retention time for snapshot repositories ?

I'm not sure what you mean by retention time. Can you explain this setting? Is it the "Not Found Cache TTL"?

Post by Thanh Ha
--
Matthias
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

[Thanh Ha]

Post by Alex Blewitt
You should also have a group which is 'only releases' and 'only
snapshots'. In fact, I'd argue that the main 'eclipse' one only
contain releases and have 'eclipse-snapshots' as a separate one,
because there's rarely a good reason to mix both releases and
snapshots in the same repository.

That makes good sense. I am +1 for this change.

Would it be good to have a mixed one also maybe "eclipse-all" which
aggregates the 2 groups for those who want both?


Thanh

[Matthias Sohn]

Post by Thanh Ha

Post by Alex Blewitt
You should also have a group which is 'only releases' and 'only
snapshots'. In fact, I'd argue that the main 'eclipse' one only contain
releases and have 'eclipse-snapshots' as a separate one, because there's
rarely a good reason to mix both releases and snapshots in the same
repository.
That makes good sense. I am +1 for this change.

+1 to keep release and snapshot repositories strictly separated

Post by Thanh Ha
Would it be good to have a mixed one also maybe "eclipse-all" which
aggregates the 2 groups for those who want both?

I think mixing snapshot and release repositories doesn't make sense

--
Matthias

[Thanh Ha]

Hi Everyone,

repo.eclipse.org has been modified with the suggested changes.

releases only: https://repo.eclipse.org/content/groups/eclipse/
snapshots only: https://repo.eclipse.org/content/groups/eclipse-snapshots/


A scheduled task has also been configured to cleanup snapshots older
than 30-days on a weekly basis.


Thanh

Post by Alex Blewitt
You should also have a group which is 'only releases' and
'only snapshots'. In fact, I'd argue that the main 'eclipse'
one only contain releases and have 'eclipse-snapshots' as a
separate one, because there's rarely a good reason to mix both
releases and snapshots in the same repository.
That makes good sense. I am +1 for this change.
+1 to keep release and snapshot repositories strictly separated
Would it be good to have a mixed one also maybe "eclipse-all"
which aggregates the 2 groups for those who want both?
I think mixing snapshot and release repositories doesn't make sense
--
Matthias
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

[Matthias Sohn]

Post by Thanh Ha
Hi Matthias,
What's the retention time for snapshot repositories ?
I'm not sure what you mean by retention time. Can you explain this
setting? Is it the "Not Found Cache TTL"?

Usually old snapshot builds (e.g. older than 1 month) are purged in order
to limit
disk consumption of the Nexus server.

--
Matthias

[Thanh Ha]

Thanks Matthias,

That helps. I was able to find the setting for this as well. I think 1
month (30 days) is reasonable, I will set it to 30 days unless anyone
has any objections.


Thanh

Post by Thanh Ha
Hi Matthias,

Post by Matthias Sohn
What's the retention time for snapshot repositories ?

I'm not sure what you mean by retention time. Can you explain this
setting? Is it the "Not Found Cache TTL"?
Usually old snapshot builds (e.g. older than 1 month) are purged in
order to limit
disk consumption of the Nexus server.
--
Matthias
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

[Thanh Ha]

Hi Everyone,

Some big changes I need to make today. Using "eclipse" and
"eclipse-snapshots" was not a good idea as aggregate groups of the
entire repo after all. It conflicts with the "Eclipse Project" space so
we need to change this to give "eclipse" back to the "Eclipse Project".

The new proposal is that we will use more generically named groups:

all repo releases: https://repo.eclipse.org/content/groups/releases
all repo snapshots: https://repo.eclipse.org/content/groups/snapshots


The eclipse group will now be given to the "Eclipse Project".

eclipse (group): https://repo.eclipse.org/content/groups/eclipse/
eclipse-releases:
https://repo.eclipse.org/content/repositories/eclipse-releases/
eclipse-snapshots:
https://repo.eclipse.org/content/repositories/eclipse-snapshots/


If you've been using these URLs in your projects you will need to change
them.

Sorry for the inconvenience,


Thanh

[Thanh Ha]

Hi Everyone,

Per discussion in Bug 394792 [1] regarding credential security. We
decided to limit deployment to the Eclipse Hudson instance which means
if you want to deploy you will need to configure a Hudson job. I updated
the wiki page with instructions on how I deployed the CBI maven plugins
using Hudson [2]. If any Hudson experts know of better ways to configure
the job please feel free to leave a suggestion.

[1] http://bugs.eclipse.org/394792
[2]
http://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org

Thanh

[Matthias Sohn]

Post by Thanh Ha
Hi Everyone,
Per discussion in Bug 394792 [1] regarding credential security. We decided
to limit deployment to the Eclipse Hudson instance which means if you want
to deploy you will need to configure a Hudson job. I updated the wiki page
with instructions on how I deployed the CBI maven plugins using Hudson [2].
If any Hudson experts know of better ways to configure the job please feel
free to leave a suggestion.
[1] http://bugs.eclipse.org/394792
[2] http://wiki.eclipse.org/**Services/Nexus#Deploying_**
artifacts_to_repo.eclipse.org<http://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org>

how could we deploy already existing releases ? Could we do that by
deploying
from build.eclipse.org ?

--
Matthias

[Thanh Ha]

Post by Thanh Ha
Hi Everyone,
Per discussion in Bug 394792 [1] regarding credential security. We
decided to limit deployment to the Eclipse Hudson instance which
means if you want to deploy you will need to configure a Hudson
job. I updated the wiki page with instructions on how I deployed
the CBI maven plugins using Hudson [2]. If any Hudson experts know
of better ways to configure the job please feel free to leave a
suggestion.
[1] http://bugs.eclipse.org/394792
[2]
http://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org
how could we deploy already existing releases ? Could we do that by
deploying
from build.eclipse.org <http://build.eclipse.org> ?

No, when I discussed with Webmasters we decided that you need to use
Hudson in order to deploy. If there's a different use case I'll have to
discuss with Webmasters again.

Are the already existing releases Maven repos? If so maybe I can copy
them over if you point me to where they are.


Thanh

[Jesse McConnell]

Why are you adding this restriction to maven usage while binaries built to
be signed by the official Eclipse Foundation key can be built on whatever
virus and compromised machines you wish to be uploaded and signed as
official binaries?

cheers,
jesse

[Jesse McConnell]

For reference to my previous comment, see Denis's comment here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=354756#c26

--
jesse mcconnell

Post by Jesse McConnell
Why are you adding this restriction to maven usage while binaries built to
be signed by the official Eclipse Foundation key can be built on whatever
virus and compromised machines you wish to be uploaded and signed as
official binaries?
cheers,
jesse

[Denis Roy]

I am going with limited knowledge of how Maven works, so please bear
with me.

Our thoughts on limiting publishing to Hudson only is that Hudson
provides us with a mechanism to provide a central set of credentials
that are not exposed to the general public. Just like signins.

If there is a way to allow multiple people to publish artifacts securely
from various locations without having to store committer credentials in
plaintext files, or giving everyone the keys to the entire repo, then I
(and Thanh) are all ears.

Denis

Post by Jesse McConnell
Why are you adding this restriction to maven usage while binaries
built to be signed by the official Eclipse Foundation key can be built
on whatever virus and compromised machines you wish to be uploaded and
signed as official binaries?
cheers,
jesse