[dash-dev] maven.eclipse.org

Discussion:

Thanh Ha

2013-01-31 13:20:07 UTC

Hi Everyone,

Per Bug 394792 I'm looking at moving maven.eclipse.org to become a
managed service at Eclipse. I plan on tackling this issue soon and was
wondering if taking this server down would affect any projects?

Some things we'd like to do is update the Nexus server version as well
as restart the service from a fresh configuration, essentially start over.

Thanks,

Thanh

Jesse McConnell

2013-01-31 13:32:42 UTC

Permalink

Post by Thanh Ha
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org to become a
managed service at Eclipse. I plan on tackling this issue soon and was
wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server version as well as
restart the service from a fresh configuration, essentially start over.
Thanks,
Thanh
______________________________**_________________
dash-dev mailing list
https://dev.eclipse.org/**mailman/listinfo/dash-dev<https://dev.eclipse.org/mailman/listinfo/dash-dev>

Martin Taal

2013-01-31 13:37:19 UTC

Permalink

I agree with Jesse...

Maybe it is best to take maven.eclipse.org down, but don't do anything else unless someone takes responsibility and
there is funding to do so.

I currently publish EMF Texo/Teneo and EMF jars through sonatypeto get them on maven.central. It works fine, but I find
it strange that eclipse projects have to use a 3rd party to get their code on maven central. I would expect
eclipse.orgto provide a service similar to sonatype...

Just my 2 cents...

gr. Martin

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: ***@springsite.com - ***@elver.org
Web: www.springsite.com - www.elver.org

I really don't understand the point of resetting it if there is not a clear understanding of what roll it will serve
within the organization moving forward and a recommended path for how projects will interact with it.
If it is only going to be a proxy for maven central, then that is fine and you should go for it, but if you're
planning on having projects actually deploy to it and/or build out the story for syncing to maven central then all of
that should be ironed out ahead of time and wired up accordingly.
Maven repositories are meant to be durable and exist forever, unlike orbit repositories that are transitory and exist
for small windows of time. If you screw something up with Orbit then no biggy, it will eventually just disappear and
problem solved. With a maven repository once it is released it is locked away for time eternal, which is why I am
such a strong proponent of having staging repositories so upon release you can give things a pre-flight check before
releasing it and locking it down.
Once you set this up and take ownership of it you are making a contract with anyone that uses it that you will support
the stuff in there from that point on. None of this disappearing repository stuff where you check out an old tag and
some repository you built against is now missing and perhaps replaced with a different version of some dependency.
cheers,
jesse
--
jesse mcconnell
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org <http://maven.eclipse.org> to become a managed service at
Eclipse. I plan on tackling this issue soon and was wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server version as well as restart the service from a fresh
configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

Jesse McConnell

2013-01-31 13:59:38 UTC

Permalink

Martin,

And you would not want to use something @ eclipse that didn't have the
staging functionality that exists on oss.sonatype.org correct?

cheers,
jesse

--
jesse mcconnell

Post by Martin Taal
I agree with Jesse...
Maybe it is best to take maven.eclipse.org down, but don't do anything
else unless someone takes responsibility and there is funding to do so.
I currently publish EMF Texo/Teneo and EMF jars through sonatype to get
them on maven.central. It works fine, but I find it strange that eclipse
projects have to use a 3rd party to get their code on maven central. I
would expect eclipse.org to provide a service similar to sonatype...
Just my 2 cents...
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Web: www.springsite.com - www.elver.org
I really don't understand the point of resetting it if there is not a
clear understanding of what roll it will serve within the organization
moving forward and a recommended path for how projects will interact with
it.
If it is only going to be a proxy for maven central, then that is fine
and you should go for it, but if you're planning on having projects
actually deploy to it and/or build out the story for syncing to maven
central then all of that should be ironed out ahead of time and wired up
accordingly.
Maven repositories are meant to be durable and exist forever, unlike
orbit repositories that are transitory and exist for small windows of time.
If you screw something up with Orbit then no biggy, it will eventually
just disappear and problem solved. With a maven repository once it is
released it is locked away for time eternal, which is why I am such a
strong proponent of having staging repositories so upon release you can
give things a pre-flight check before releasing it and locking it down.
Once you set this up and take ownership of it you are making a contract
with anyone that uses it that you will support the stuff in there from that
point on. None of this disappearing repository stuff where you check out
an old tag and some repository you built against is now missing and perhaps
replaced with a different version of some dependency.
cheers,
jesse
--
jesse mcconnell

Post by Thanh Ha
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org to become a
managed service at Eclipse. I plan on tackling this issue soon and was
wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server version as well as
restart the service from a fresh configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

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

Martin Taal

2013-01-31 14:20:15 UTC

Permalink

As a replacement of sonatype, I would need 2 things:
- a place to publish nightly/weekly builds
- an entry in maven central (with a 2 step procedure, that's fine)

I don't need the sonatype ui, so publishing/releasing through maven commandline would be fine with me.

I think eclipse could offer a location for nightly builds (to be consumed by maven) and entry point into maven central.
Eclipse.org does not need to offer an eternal durable maven repo. I would just use maven central for that.

gr. Martin

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: ***@springsite.com - ***@elver.org
Web: www.springsite.com - www.elver.org

Post by Jesse McConnell
Martin,
oss.sonatype.org <http://oss.sonatype.org> correct?
cheers,
jesse
--
jesse mcconnell
I agree with Jesse...
Maybe it is best to take maven.eclipse.org down, but don't do anything else unless someone takes responsibility
and there is funding to do so.
I currently publish EMF Texo/Teneo and EMF jars through sonatypeto get them on maven.central. It works fine, but I
find it strange that eclipse projects have to use a 3rd party to get their code on maven central. I would expect
eclipse.org <http://eclipse.org>to provide a service similar to sonatype...
Just my 2 cents...
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell:+31 (0)6 288 48 943 <tel:%2B31%20%280%296%20288%2048%20943>
Tel:+31 (0)84 420 2397 <tel:%2B31%20%280%2984%20420%202397>
Fax:+31 (0)84 225 9307 <tel:%2B31%20%280%2984%20225%209307>
Web:www.springsite.com <http://www.springsite.com> -www.elver.org <http://www.elver.org>

I really don't understand the point of resetting it if there is not a clear understanding of what roll it will
serve within the organization moving forward and a recommended path for how projects will interact with it.
If it is only going to be a proxy for maven central, then that is fine and you should go for it, but if you're
planning on having projects actually deploy to it and/or build out the story for syncing to maven central then
all of that should be ironed out ahead of time and wired up accordingly.
Maven repositories are meant to be durable and exist forever, unlike orbit repositories that are transitory and
exist for small windows of time. If you screw something up with Orbit then no biggy, it will eventually just
disappear and problem solved. With a maven repository once it is released it is locked away for time eternal,
which is why I am such a strong proponent of having staging repositories so upon release you can give things a
pre-flight check before releasing it and locking it down.
Once you set this up and take ownership of it you are making a contract with anyone that uses it that you will
support the stuff in there from that point on. None of this disappearing repository stuff where you check out an
old tag and some repository you built against is now missing and perhaps replaced with a different version of
some dependency.
cheers,
jesse
--
jesse mcconnell
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org <http://maven.eclipse.org> to become a managed service
at Eclipse. I plan on tackling this issue soon and was wondering if taking this server down would affect any
projects?
Some things we'd like to do is update the Nexus server version as well as restart the service from a fresh
configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
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

Thanh Ha

2013-01-31 15:16:48 UTC

Permalink

I had a look at oss.sonatype.org's nexus instance and from what I gather
it provides each project with 4 repository services.

project-snapshots (hosted)
project-releases (hosted)
project-with-staging (group)
project repositories (group)

I think if we setup maven.eclipse.org with a similar model we can
achieve the releases with the "project-releases" service and
nightly/weekly builds with the "project-snapshots" service.

I'm new to Nexus so it's not clear to me what the difference between the
2 groups are I hope someone who's used oss.sonatype.org might be able to
explain. If I had to guess "project repositories" is a group containing
the releases repo and project-with-staging contains both snapshots and
releases? I'm guessing these groups are alternative URLs to the hosted
repos?

As for an entry into maven central I think initially we won't be able to
provide this service as the focus will be on getting projects using
maven.eclipse.org but it's something we can look as the service ramps up.

Thanh

Post by Martin Taal
- a place to publish nightly/weekly builds
- an entry in maven central (with a 2 step procedure, that's fine)
I don't need the sonatype ui, so publishing/releasing through maven
commandline would be fine with me.
I think eclipse could offer a location for nightly builds (to be
consumed by maven) and entry point into maven central. Eclipse.org
does not need to offer an eternal durable maven repo. I would just use
maven central for that.
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Web:www.springsite.com -www.elver.org

Post by Jesse McConnell
Martin,
the staging functionality that exists on oss.sonatype.org
<http://oss.sonatype.org> correct?
cheers,
jesse
--
jesse mcconnell
I agree with Jesse...
Maybe it is best to take maven.eclipse.org down, but don't do
anything else unless someone takes responsibility and there is
funding to do so.
I currently publish EMF Texo/Teneo and EMF jars through
sonatypeto get them on maven.central. It works fine, but I find
it strange that eclipse projects have to use a 3rd party to get
their code on maven central. I would expect eclipse.org
<http://eclipse.org>to provide a service similar to sonatype...
Just my 2 cents...
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell:+31 (0)6 288 48 943 <tel:%2B31%20%280%296%20288%2048%20943>
Tel:+31 (0)84 420 2397 <tel:%2B31%20%280%2984%20420%202397>
Fax:+31 (0)84 225 9307 <tel:%2B31%20%280%2984%20225%209307>
Web:www.springsite.com <http://www.springsite.com> -www.elver.org <http://www.elver.org>

Post by Jesse McConnell
I really don't understand the point of resetting it if there is
not a clear understanding of what roll it will serve within the
organization moving forward and a recommended path for how
projects will interact with it.
If it is only going to be a proxy for maven central, then that
is fine and you should go for it, but if you're planning on
having projects actually deploy to it and/or build out the story
for syncing to maven central then all of that should be ironed
out ahead of time and wired up accordingly.
Maven repositories are meant to be durable and exist forever,
unlike orbit repositories that are transitory and exist for
small windows of time. If you screw something up with Orbit
then no biggy, it will eventually just disappear and problem
solved. With a maven repository once it is released it is
locked away for time eternal, which is why I am such a strong
proponent of having staging repositories so upon release you can
give things a pre-flight check before releasing it and locking it down.
Once you set this up and take ownership of it you are making a
contract with anyone that uses it that you will support the
stuff in there from that point on. None of this disappearing
repository stuff where you check out an old tag and some
repository you built against is now missing and perhaps replaced
with a different version of some dependency.
cheers,
jesse
--
jesse mcconnell
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org
<http://maven.eclipse.org> to become a managed service at
Eclipse. I plan on tackling this issue soon and was
wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server
version as well as restart the service from a fresh
configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
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

David Carver

2013-01-31 15:48:49 UTC

Permalink

Just remember Staging Repository support is only available in Nexus if
you get the Nexus Pro version, which Sonatype has offered to you guys in
the past at no charge, but was turned down.

If hosting a Nexus Pro instance still goes against eclipse foundation
software usage guidelines, then the only alternative I see is doing a
partnership with oss.sonatype.org. If you want more control over the
repos and tieing everything into your Eclipse security infrastructure
then you need to hose a Nexus Pro instance.

I'll let you guys figure out the best way forward.

Remember also there are some qualitity assurance items that need to
happen as well to get items into Maven Central. Currently
oss.sonatype.org provides all those checks ahead of time.

Dave

Post by Thanh Ha
I had a look at oss.sonatype.org's nexus instance and from what I
gather it provides each project with 4 repository services.
project-snapshots (hosted)
project-releases (hosted)
project-with-staging (group)
project repositories (group)
I think if we setup maven.eclipse.org with a similar model we can
achieve the releases with the "project-releases" service and
nightly/weekly builds with the "project-snapshots" service.
I'm new to Nexus so it's not clear to me what the difference between
the 2 groups are I hope someone who's used oss.sonatype.org might be
able to explain. If I had to guess "project repositories" is a group
containing the releases repo and project-with-staging contains both
snapshots and releases? I'm guessing these groups are alternative URLs
to the hosted repos?
As for an entry into maven central I think initially we won't be able
to provide this service as the focus will be on getting projects using
maven.eclipse.org but it's something we can look as the service ramps up.
Thanh

Post by Martin Taal
- a place to publish nightly/weekly builds
- an entry in maven central (with a 2 step procedure, that's fine)
I don't need the sonatype ui, so publishing/releasing through maven
commandline would be fine with me.
I think eclipse could offer a location for nightly builds (to be
consumed by maven) and entry point into maven central. Eclipse.org
does not need to offer an eternal durable maven repo. I would just
use maven central for that.
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Web:www.springsite.com -www.elver.org

Post by Jesse McConnell
I really don't understand the point of resetting it if there is
not a clear understanding of what roll it will serve within the
organization moving forward and a recommended path for how
projects will interact with it.
If it is only going to be a proxy for maven central, then that
is fine and you should go for it, but if you're planning on
having projects actually deploy to it and/or build out the
story for syncing to maven central then all of that should be
ironed out ahead of time and wired up accordingly.
Maven repositories are meant to be durable and exist forever,
unlike orbit repositories that are transitory and exist for
small windows of time. If you screw something up with Orbit
then no biggy, it will eventually just disappear and problem
solved. With a maven repository once it is released it is
locked away for time eternal, which is why I am such a strong
proponent of having staging repositories so upon release you
can give things a pre-flight check before releasing it and
locking it down.
Once you set this up and take ownership of it you are making a
contract with anyone that uses it that you will support the
stuff in there from that point on. None of this disappearing
repository stuff where you check out an old tag and some
repository you built against is now missing and perhaps
replaced with a different version of some dependency.
cheers,
jesse
--
jesse mcconnell
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org
<http://maven.eclipse.org> to become a managed service at
Eclipse. I plan on tackling this issue soon and was
wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server
version as well as restart the service from a fresh
configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
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

Jason van Zyl

2013-01-31 15:59:43 UTC

Permalink

Thanh,

We will never accept artifacts from a Nexus instance that is not running the staging suite. The staging suite is the facility that validates there is a valid POM, javadocs, sources, PGP signatures and also ensures that a release doesn't get corrupted. We have spent an enormous amount of time and energy helping Apache, Codehaus, JBoss and Java.net get Nexus Pro instances in place so that the synchronization of their artifacts to Central are as good as if they came in through the OSS Nexus instance we host for the community.

So if you're a project that wants to get your artifacts into Maven Central than just use the facilities that Sonatype provides because Eclipse can't run a Nexus Pro instance and we will not make any exceptions for Eclipse even if you re-implemented the whole suite because we've already solved the problem and we're not validating another tool chain.

We open sourced all the p2 related tools so those can be extended and used for many of your purposes, but for Maven artifacts the choices are use Nexus Pro instance and sync to Central, or have projects directly work with us to get the artifacts into Central. In the case of Eclipse I believe the second option is the only real choice at Eclipse.

I had a look at oss.sonatype.org's nexus instance and from what I gather it provides each project with 4 repository services.
project-snapshots (hosted)
project-releases (hosted)
project-with-staging (group)
project repositories (group)
I think if we setup maven.eclipse.org with a similar model we can achieve the releases with the "project-releases" service and nightly/weekly builds with the "project-snapshots" service.
I'm new to Nexus so it's not clear to me what the difference between the 2 groups are I hope someone who's used oss.sonatype.org might be able to explain. If I had to guess "project repositories" is a group containing the releases repo and project-with-staging contains both snapshots and releases? I'm guessing these groups are alternative URLs to the hosted repos?
As for an entry into maven central I think initially we won't be able to provide this service as the focus will be on getting projects using maven.eclipse.org but it's something we can look as the service ramps up.
Thanh

Post by Martin Taal
- a place to publish nightly/weekly builds
- an entry in maven central (with a 2 step procedure, that's fine)
I don't need the sonatype ui, so publishing/releasing through maven commandline would be fine with me.
I think eclipse could offer a location for nightly builds (to be consumed by maven) and entry point into maven central. Eclipse.org does not need to offer an eternal durable maven repo. I would just use maven central for that.
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Web: www.springsite.com - www.elver.org

Post by Jesse McConnell
Martin,
cheers,
jesse
--
jesse mcconnell
I agree with Jesse...
Maybe it is best to take maven.eclipse.org down, but don't do anything else unless someone takes responsibility and there is funding to do so.
I currently publish EMF Texo/Teneo and EMF jars through sonatype to get them on maven.central. It works fine, but I find it strange that eclipse projects have to use a 3rd party to get their code on maven central. I would expect eclipse.org to provide a service similar to sonatype...
Just my 2 cents...
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Web: www.springsite.com - www.elver.org

I really don't understand the point of resetting it if there is not a clear understanding of what roll it will serve within the organization moving forward and a recommended path for how projects will interact with it.
If it is only going to be a proxy for maven central, then that is fine and you should go for it, but if you're planning on having projects actually deploy to it and/or build out the story for syncing to maven central then all of that should be ironed out ahead of time and wired up accordingly.
Maven repositories are meant to be durable and exist forever, unlike orbit repositories that are transitory and exist for small windows of time. If you screw something up with Orbit then no biggy, it will eventually just disappear and problem solved. With a maven repository once it is released it is locked away for time eternal, which is why I am such a strong proponent of having staging repositories so upon release you can give things a pre-flight check before releasing it and locking it down.
Once you set this up and take ownership of it you are making a contract with anyone that uses it that you will support the stuff in there from that point on. None of this disappearing repository stuff where you check out an old tag and some repository you built against is now missing and perhaps replaced with a different version of some dependency.
cheers,
jesse
--
jesse mcconnell
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org to become a managed service at Eclipse. I plan on tackling this issue soon and was wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server version as well as restart the service from a fresh configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

I never make the mistake of arguing with people for whose opinions I have no respect.

-- Edward Gibbon

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Thanh Ha

2013-01-31 16:12:43 UTC

Permalink

Thanks Jason,

This clears up some questions I had regarding staging and Maven Central.

Thanh

Post by Jason van Zyl
Thanh,
We will never accept artifacts from a Nexus instance that is not
running the staging suite. The staging suite is the facility that
validates there is a valid POM, javadocs, sources, PGP signatures and
also ensures that a release doesn't get corrupted. We have spent an
enormous amount of time and energy helping Apache, Codehaus, JBoss and
Java.net <http://Java.net> get Nexus Pro instances in place so that
the synchronization of their artifacts to Central are as good as if
they came in through the OSS Nexus instance we host for the community.
So if you're a project that wants to get your artifacts into Maven
Central than just use the facilities that Sonatype provides because
Eclipse can't run a Nexus Pro instance and we will not make any
exceptions for Eclipse even if you re-implemented the whole suite
because we've already solved the problem and we're not validating
another tool chain.
We open sourced all the p2 related tools so those can be extended and
used for many of your purposes, but for Maven artifacts the choices
are use Nexus Pro instance and sync to Central, or have projects
directly work with us to get the artifacts into Central. In the case
of Eclipse I believe the second option is the only real choice at Eclipse.

I had a look at oss.sonatype.org <http://oss.sonatype.org>'s nexus
instance and from what I gather it provides each project with 4
repository services.
project-snapshots (hosted)
project-releases (hosted)
project-with-staging (group)
project repositories (group)
I think if we setup maven.eclipse.org <http://maven.eclipse.org> with
a similar model we can achieve the releases with the
"project-releases" service and nightly/weekly builds with the
"project-snapshots" service.
I'm new to Nexus so it's not clear to me what the difference between
the 2 groups are I hope someone who's used oss.sonatype.org
<http://oss.sonatype.org> might be able to explain. If I had to guess
"project repositories" is a group containing the releases repo and
project-with-staging contains both snapshots and releases? I'm
guessing these groups are alternative URLs to the hosted repos?
As for an entry into maven central I think initially we won't be able
to provide this service as the focus will be on getting projects
using maven.eclipse.org <http://maven.eclipse.org> but it's something
we can look as the service ramps up.
Thanh

Post by Martin Taal
- a place to publish nightly/weekly builds
- an entry in maven central (with a 2 step procedure, that's fine)
I don't need the sonatype ui, so publishing/releasing through maven
commandline would be fine with me.
I think eclipse could offer a location for nightly builds (to be
consumed by maven) and entry point into maven central. Eclipse.org
<http://Eclipse.org> does not need to offer an eternal durable maven
repo. I would just use maven central for that.
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org <http://Elver.org>
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Web:www.springsite.com -www.elver.org

Post by Jesse McConnell
Martin,
the staging functionality that exists on oss.sonatype.org
<http://oss.sonatype.org/> correct?
cheers,
jesse
--
jesse mcconnell
I agree with Jesse...
Maybe it is best to take maven.eclipse.org down, but don't do
anything else unless someone takes responsibility and there is
funding to do so.
I currently publish EMF Texo/Teneo and EMF jars through
sonatypeto get them on maven.central. It works fine, but I find
it strange that eclipse projects have to use a 3rd party to get
their code on maven central. I would expect eclipse.org
<http://eclipse.org/>to provide a service similar to sonatype...
Just my 2 cents...
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org <http://Elver.org>
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell:+31 (0)6 288 48 943 <tel:%2B31%20%280%296%20288%2048%20943>
Tel:+31 (0)84 420 2397 <tel:%2B31%20%280%2984%20420%202397>
Fax:+31 (0)84 225 9307 <tel:%2B31%20%280%2984%20225%209307>
Web:www.springsite.com <http://www.springsite.com/> -www.elver.org <http://www.elver.org/>

Post by Jesse McConnell
I really don't understand the point of resetting it if there
is not a clear understanding of what roll it will serve within
the organization moving forward and a recommended path for how
projects will interact with it.
If it is only going to be a proxy for maven central, then that
is fine and you should go for it, but if you're planning on
having projects actually deploy to it and/or build out the
story for syncing to maven central then all of that should be
ironed out ahead of time and wired up accordingly.
Maven repositories are meant to be durable and exist forever,
unlike orbit repositories that are transitory and exist for
small windows of time. If you screw something up with Orbit
then no biggy, it will eventually just disappear and problem
solved. With a maven repository once it is released it is
locked away for time eternal, which is why I am such a strong
proponent of having staging repositories so upon release you
can give things a pre-flight check before releasing it and
locking it down.
Once you set this up and take ownership of it you are making a
contract with anyone that uses it that you will support the
stuff in there from that point on. None of this disappearing
repository stuff where you check out an old tag and some
repository you built against is now missing and perhaps
replaced with a different version of some dependency.
cheers,
jesse
--
jesse mcconnell
On Thu, Jan 31, 2013 at 7:20 AM, Thanh Ha
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org
<http://maven.eclipse.org/> to become a managed service at
Eclipse. I plan on tackling this issue soon and was
wondering if taking this server down would affect any projects?
Some things we'd like to do is update the Nexus server
version as well as restart the service from a fresh
configuration, essentially start over.
Thanks,
Thanh
_______________________________________________
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

Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I have no respect.
-- Edward Gibbon
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

Andrew Ross

2013-01-31 14:30:09 UTC

Permalink

Jesse, All

Agreeing with you, and building upon what you've said:

In our work on CBI & LTS, it became clear that not only would a well
managed service in this case be very useful, but also satisfy very
important use cases for LTS.

LTS' success helps subsidize efforts like CBI & this work with Nexus.
Naturally we're mindful of value to LTS members but there are benefits
to the broader community too.

LTS absolutely needs dependable/durable repositories for the very long
term. Each LTS member (Premium & Steering Committee level) has the right
to a company specific forge. So getting it right with Nexus also helps
us with flow control of content from community, into LTS central, to
each company specific forge in LTS, and back the other way sometimes.
Doing this by hand would be an unmanageable nightmare approximately like
trying to do N simultaneous releases at the same time where N is
reasonably large.

It's probably clear, we're glad to hash this out in the open to factor
the wisdom from experts in the community and give us the highest chance
for a strong success.

Andrew

Post by Jesse McConnell
I really don't understand the point of resetting it if there is not a
clear understanding of what roll it will serve within the organization
moving forward and a recommended path for how projects will interact
with it.
If it is only going to be a proxy for maven central, then that is fine
and you should go for it, but if you're planning on having projects
actually deploy to it and/or build out the story for syncing to maven
central then all of that should be ironed out ahead of time and wired
up accordingly.
Maven repositories are meant to be durable and exist forever, unlike
orbit repositories that are transitory and exist for small windows of
time. If you screw something up with Orbit then no biggy, it will
eventually just disappear and problem solved. With a maven repository
once it is released it is locked away for time eternal, which is why I
am such a strong proponent of having staging repositories so upon
release you can give things a pre-flight check before releasing it and
locking it down.
Once you set this up and take ownership of it you are making a
contract with anyone that uses it that you will support the stuff in
there from that point on. None of this disappearing repository stuff
where you check out an old tag and some repository you built against
is now missing and perhaps replaced with a different version of some
dependency.
cheers,
jesse
--
jesse mcconnell
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org
<http://maven.eclipse.org> to become a managed service at Eclipse.
I plan on tackling this issue soon and was wondering if taking
this server down would affect any projects?
Some things we'd like to do is update the Nexus server version as
well as restart the service from a fresh configuration,
essentially start over.
Thanks,
Thanh

Matthias Sohn

2013-01-31 16:41:33 UTC

Permalink

Jesse McConnell

2013-01-31 16:44:49 UTC

Permalink

oh that is true, we use that plugin for our p2 repositories for jetty as
well so please leave that around for the time being

--
jesse mcconnell

Post by Matthias Sohn

the EGit project is downloading the eclipse-signing-maven-plugin from
maven.eclipse.org. So if you take down this system
signing of our builds on Hudson would fail, this could be solved if you
can serve this plugin from a different place.
--
Matthias
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

Thanh Ha

2013-01-31 16:56:59 UTC

Permalink

Thanks, this is good feedback to know. I'm thinking maybe the best
option at the moment is to create a new server elsewhere thus leaving
maven.eclipse.org alone for now. Once the new server is ready to go we
can make the switch later.

Thanh

Post by Jesse McConnell
oh that is true, we use that plugin for our p2 repositories for jetty
as well so please leave that around for the time being
--
jesse mcconnell
On Thu, Jan 31, 2013 at 10:41 AM, Matthias Sohn
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org
<http://maven.eclipse.org> to become a managed service at
Eclipse. I plan on tackling this issue soon and was wondering
if taking this server down would affect any projects?
the EGit project is downloading the eclipse-signing-maven-plugin
from maven.eclipse.org <http://maven.eclipse.org/>. So if you take
down this system
signing of our builds on Hudson would fail, this could be solved
if you can serve this plugin from a different place.
--
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

Andrew Ross

2013-01-31 18:43:34 UTC

Permalink

Post by Thanh Ha
Hi Everyone,
Per Bug 394792 I'm looking at moving maven.eclipse.org
<http://maven.eclipse.org> to become a managed service at Eclipse.
I plan on tackling this issue soon and was wondering if taking
this server down would affect any projects?
the EGit project is downloading the eclipse-signing-maven-plugin from
maven.eclipse.org <http://maven.eclipse.org/>. So if you take down
this system
signing of our builds on Hudson would fail, this could be solved if
you can serve this plugin from a different place.
--
Matthias

Thanks Matthias, "CBI stuff" is first on the list. We'll get it served
from the new instance and swap some of the builds using it to test.

Speaking of EGit, I'm wondering... is there any value in EGit pulling
JGit from Nexus rather than ../JGit?

Andrew

Matthias Sohn

2013-01-31 20:35:58 UTC

Permalink

Post by Matthias Sohn

the EGit project is downloading the eclipse-signing-maven-plugin from
maven.eclipse.org. So if you take down this system
signing of our builds on Hudson would fail, this could be solved if you
can serve this plugin from a different place.
--
Matthias
Thanks Matthias, "CBI stuff" is first on the list. We'll get it served
from the new instance and swap some of the builds using it to test.
Speaking of EGit, I'm wondering... is there any value in EGit pulling JGit
from Nexus rather than ../JGit?

I think this could help to integrate a couple of system calls we
implemented using JNI [1-3]
which could help to speedup JGit by making some low level file system calls
accessible from
Java. So far we didn't integrate that due to the unsolved problem how to
integrate the results of
these native makes into JGit's maven build. Nexus could be used to store
results of the native
makes and the JGit Tycho-based packaging build could consume them from
there.

Until Tycho and Maven builds can be mixed in the same reactor JGit will
still need 2 runs of Maven:
- first Maven build to create the libraries exposed as Maven artifacts
(containing OSGi manifests) since most
JGit consumers are non-OSGi, releases of these are published via Sonatype
OSS to Maven central
- packaging build using Tycho to create the JGit features and p2 repository
- the Tycho based EGit build then consumes JGit via its p2 repository.
Using the Nexus unzip plugin [4]
my Tycho colleagues have implemented the JGit p2 repository could be
published in Nexus so that the
EGit Hudson build wouldn't need to reference the JGit p2 repository on
Hudson any longer.

[1] https://git.eclipse.org/r/#/c/1815/ "Provide native lstat() via JNI"
[2] https://git.eclipse.org/r/#/c/2126/ "Provide native readdir() via JNI"
[3] https://git.eclipse.org/r/#/c/2125/ "Provide native symlink() via JNI"
[4] http://wiki.eclipse.org/Tycho/Nexus_Unzip_Plugin

--
Matthias