Discussion:
[dash-dev] Settings.xml for maven.eclipse.org
David Carver
2011-03-21 17:15:24 UTC
Permalink
Attached is a first cut at a settings.xml file to be used by eclipse.org
projects, using Maven as their build system. This directs all artifact
requests to go to maven.eclipse.org instead of going to the individual
repositories. The goal is that eventually deploy this to the various
build slaves so that all requests for artifacts go to maven.eclipse.org
instead of out to central itself.

At one point, the webmasters wanted finer control of the slaves and
their visibility to the outside world. This settings.xml makes sure
that we use maven.eclipse.org for all requests.

It is a starting point, and I have the WTP XSL currently using this.
If you are an eclipse project using the hudson build servers, you can
add this settings.xml file to your releng project, and then for your
maven configuration add:

-s settings.xml

So for example, the xsl goals setting is setup as:

clean install -s settings.xml

I'm proposing that we eventually bring this in as a hosted file for the
dash git repository, and make it the default for Master, and Slave
machines running hudson, once we have this setup as we would like.

Dave
Alex Blewitt
2011-03-21 17:18:14 UTC
Permalink
Attached is a first cut at a settings.xml file to be used by eclipse.org projects, using Maven as their build system. This directs all artifact requests to go to maven.eclipse.org instead of going to the individual repositories. The goal is that eventually deploy this to the various build slaves so that all requests for artifacts go to maven.eclipse.org instead of out to central itself.
You need to fix the http://central URL, which looks a little short :)

We should figure out short names to use and then hook up the settings.xml to use that instead. We need to figure out what they should be called though - I'm happy to set up the Apache proxy to do the same once we figure out the naming conventions. I don't really want to have /nexus/content/* in any of our settings.xml files to allow us to be flexible in the future.

Otherwise, it looks good - but I'm curious to know whether they're using a pre-defined cache to resolve the plugins :)

Alex
David Carver
2011-03-21 17:33:49 UTC
Permalink
Actually, the url there doesn't matter for now. In fact we can
eliminate that whole section, because the Mirror statement is handling
the redirection.

This is just a start, and I agree we need to continue to tweak this as
we go forward. It should also include the Server information to allow
snapshots to be deployed, as well as nightly, milestone, etc builds and
artifacts to maven.eclipse.org.

Dave
Post by Alex Blewitt
Attached is a first cut at a settings.xml file to be used by eclipse.org projects, using Maven as their build system. This directs all artifact requests to go to maven.eclipse.org instead of going to the individual repositories. The goal is that eventually deploy this to the various build slaves so that all requests for artifacts go to maven.eclipse.org instead of out to central itself.
You need to fix the http://central URL, which looks a little short :)
We should figure out short names to use and then hook up the settings.xml to use that instead. We need to figure out what they should be called though - I'm happy to set up the Apache proxy to do the same once we figure out the naming conventions. I don't really want to have /nexus/content/* in any of our settings.xml files to allow us to be flexible in the future.
Otherwise, it looks good - but I'm curious to know whether they're using a pre-defined cache to resolve the plugins :)
Alex
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
Alex Blewitt
2011-03-21 17:45:42 UTC
Permalink
We should have some comments in this to ensure people know it is a work in progress. Also, I'm convinced we don't want to have central on the build path, just for the pluginDendencies.

Why not yet the .../content/groups/build/ set up specifically for this?

I'm concerned we are rushing ahead and may be appearing to be further ahead than we are. We need to be consistent with the message that this is still a work in progress and that (for example) we need to properly nail down the settings and structure before we tell others to use it.

Alex

Sent from my iPhone 4
Actually, the url there doesn't matter for now. In fact we can eliminate that whole section, because the Mirror statement is handling the redirection.
This is just a start, and I agree we need to continue to tweak this as we go forward. It should also include the Server information to allow snapshots to be deployed, as well as nightly, milestone, etc builds and artifacts to maven.eclipse.org.
Dave
Post by Alex Blewitt
Attached is a first cut at a settings.xml file to be used by eclipse.org projects, using Maven as their build system. This directs all artifact requests to go to maven.eclipse.org instead of going to the individual repositories. The goal is that eventually deploy this to the various build slaves so that all requests for artifacts go to maven.eclipse.org instead of out to central itself.
You need to fix the http://central URL, which looks a little short :)
We should figure out short names to use and then hook up the settings.xml to use that instead. We need to figure out what they should be called though - I'm happy to set up the Apache proxy to do the same once we figure out the naming conventions. I don't really want to have /nexus/content/* in any of our settings.xml files to allow us to be flexible in the future.
Otherwise, it looks good - but I'm curious to know whether they're using a pre-defined cache to resolve the plugins :)
Alex
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
David Carver
2011-03-21 17:59:52 UTC
Permalink
Yes, we need to make sure that we limit the scope of this and use. We
can use the two projects I have setup on the hudson.eclipse.org system
as testing points. The settings.xml file is still experimental at this
stage, and will change as we go forward.

Dave
Post by Alex Blewitt
We should have some comments in this to ensure people know it is a work in progress. Also, I'm convinced we don't want to have central on the build path, just for the pluginDendencies.
Why not yet the .../content/groups/build/ set up specifically for this?
I'm concerned we are rushing ahead and may be appearing to be further ahead than we are. We need to be consistent with the message that this is still a work in progress and that (for example) we need to properly nail down the settings and structure before we tell others to use it.
Alex
Sent from my iPhone 4
Actually, the url there doesn't matter for now. In fact we can eliminate that whole section, because the Mirror statement is handling the redirection.
This is just a start, and I agree we need to continue to tweak this as we go forward. It should also include the Server information to allow snapshots to be deployed, as well as nightly, milestone, etc builds and artifacts to maven.eclipse.org.
Dave
Post by Alex Blewitt
Attached is a first cut at a settings.xml file to be used by eclipse.org projects, using Maven as their build system. This directs all artifact requests to go to maven.eclipse.org instead of going to the individual repositories. The goal is that eventually deploy this to the various build slaves so that all requests for artifacts go to maven.eclipse.org instead of out to central itself.
You need to fix the http://central URL, which looks a little short :)
We should figure out short names to use and then hook up the settings.xml to use that instead. We need to figure out what they should be called though - I'm happy to set up the Apache proxy to do the same once we figure out the naming conventions. I don't really want to have /nexus/content/* in any of our settings.xml files to allow us to be flexible in the future.
Otherwise, it looks good - but I'm curious to know whether they're using a pre-defined cache to resolve the plugins :)
Alex
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
Loading...