Hi,

ZooKeeper in Maven Central still points to 3.3.1 although versions
3.3.[2-4] and 3.4.0 artifacts are there.
http://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper/maven-metadata.xml

If I'm not mistaken, normally Nexus will update maven-metadata.xml
when you promote close and promote a release but this is the case when
uploading to Maven OSS repo and allowing Maven Central sync. I guess
Apache repository w/ Nexus works the same.

I don't know how ZK artifacts are uploaded to Maven Central (i.e:
manually, central mirroring apache, etc.) but just wanted let the devs
know.

I have very limited knowledge on Maven and nearly none on Ivy2 but if
you need help, I'd like to offer a helping hand.

Cheers,
B

Berk,
 We dont use nexus to upload the maven artifacts. Here's how we do it:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
(take a look at the publishing section).

I am not sure how to fix the maven metadata but if you someone knows
the way, Ill be happy to do that.

thanks
mahadev

On Fri, Dec 9, 2011 at 2:44 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> Hi,
>
> ZooKeeper in Maven Central still points to 3.3.1 although versions
> 3.3.[2-4] and 3.4.0 artifacts are there.
> http://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper/maven-metadata.xml
>
> If I'm not mistaken, normally Nexus will update maven-metadata.xml
> when you promote close and promote a release but this is the case when
> uploading to Maven OSS repo and allowing Maven Central sync. I guess
> Apache repository w/ Nexus works the same.
>
> I don't know how ZK artifacts are uploaded to Maven Central (i.e:
> manually, central mirroring apache, etc.) but just wanted let the devs
> know.
>
> I have very limited knowledge on Maven and nearly none on Ivy2 but if
> you need help, I'd like to offer a helping hand.
>
> Cheers,
> B

On Sat, Dec 10, 2011 at 6:08 PM, Mahadev Konar <[EMAIL PROTECTED]> wrote:
> Berk,
>  We dont use nexus to upload the maven artifacts. Here's how we do it:
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
> (take a look at the publishing section).
>
> I am not sure how to fix the maven metadata but if you someone knows
> the way, Ill be happy to do that.
>

On the URL you sent, scroll down to Maven section.
Seems like since 3.3.2 to today, only steps 1, 2 and 3 were done but
4, 5, 6 were skipped.

I'm attaching the fixed maven-metadata.xml.

Notice it does NOT list 3.4.0 because apparently it's not a stable
release yet. Maven may be the most complex build system in entire
solar system but still needs tremendous hand holding when specifying
dependency version ranges and there's still no clean way to enforce
release-only versions.

Anyway, now anyone declaring version range dependencies like [3.3.0,)
in their POM, they will be able to get 3.3.4. When you 3.4.0 is
considered to be a stable release.

You may ask, what if someone wants to test very latest version (3.4.0
currently) in their project? It won't work with Maven. Suggested
method is to release it as a snapshot to a snapshots only repository
with -SNAPSHOT appended to the version name. Maven will not pull
-SNAPSHOT versions from remote repositories automatically.

Thanks,
B

The mirroring seems broken, here's the source:

http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/zookeeper/zookeeper/maven-metadata.xml

Patrick

On Mon, Dec 12, 2011 at 2:44 AM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 10, 2011 at 6:08 PM, Mahadev Konar <[EMAIL PROTECTED]> wrote:
>> Berk,
>>  We dont use nexus to upload the maven artifacts. Here's how we do it:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
>> (take a look at the publishing section).
>>
>> I am not sure how to fix the maven metadata but if you someone knows
>> the way, Ill be happy to do that.
>>
>
> On the URL you sent, scroll down to Maven section.
> Seems like since 3.3.2 to today, only steps 1, 2 and 3 were done but
> 4, 5, 6 were skipped.
>
> I'm attaching the fixed maven-metadata.xml.
>
> Notice it does NOT list 3.4.0 because apparently it's not a stable
> release yet. Maven may be the most complex build system in entire
> solar system but still needs tremendous hand holding when specifying
> dependency version ranges and there's still no clean way to enforce
> release-only versions.
>
> Anyway, now anyone declaring version range dependencies like [3.3.0,)
> in their POM, they will be able to get 3.3.4. When you 3.4.0 is
> considered to be a stable release.
>
> You may ask, what if someone wants to test very latest version (3.4.0
> currently) in their project? It won't work with Maven. Suggested
> method is to release it as a snapshot to a snapshots only repository
> with -SNAPSHOT appended to the version name. Maven will not pull
> -SNAPSHOT versions from remote repositories automatically.
>
> Thanks,
> B

On Mon, Dec 12, 2011 at 9:03 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> The mirroring seems broken, here's the source:
>
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/zookeeper/zookeeper/maven-metadata.xml

Who do we need to notify to fix that?

I am about to push Asynchronous HBase Client to Central but don't want
to depend on ZK 3.3.1.

BTW, web site shows 3.3.4 as (current) but there is 3.4.0 available.
POM also lists ZK 3.4.0 at the latest. Is it considered production
safe?

No idea - we have no control over third-party mirroring. Sounds like
your best bet would be to set p.a.o as a repo in your pom.

Patrick

On Mon, Dec 12, 2011 at 1:37 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 12, 2011 at 9:03 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> The mirroring seems broken, here's the source:
>>
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/zookeeper/zookeeper/maven-metadata.xml
>
> Who do we need to notify to fix that?
>
> I am about to push Asynchronous HBase Client to Central but don't want
> to depend on ZK 3.3.1.
>
> BTW, web site shows 3.3.4 as (current) but there is 3.4.0 available.
> POM also lists ZK 3.4.0 at the latest. Is it considered production
> safe?

who does control mirroring on repo1.maven.org? Anyone know? Is this
Apache? (you might check wth Apache Infra)

Patrick

On Mon, Dec 12, 2011 at 2:04 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> No idea - we have no control over third-party mirroring. Sounds like
> your best bet would be to set p.a.o as a repo in your pom.
>
> Patrick
>
> On Mon, Dec 12, 2011 at 1:37 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
>> On Mon, Dec 12, 2011 at 9:03 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> The mirroring seems broken, here's the source:
>>>
>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/zookeeper/zookeeper/maven-metadata.xml
>>
>> Who do we need to notify to fix that?
>>
>> I am about to push Asynchronous HBase Client to Central but don't want
>> to depend on ZK 3.3.1.
>>
>> BTW, web site shows 3.3.4 as (current) but there is 3.4.0 available.
>> POM also lists ZK 3.4.0 at the latest. Is it considered production
>> safe?

Resurrecting this problem again after finding out what was wrong and how
the replication broke just the metadata file.

*Background:*
ZooKeeper releases are made manually with Ant copied via scp to old
repository under people.apache.org.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
Although maven-metadata.xml in people.apache.org is correct the one in
Maven Central still points to 3.3.1.

*Why is this happening?*
There are two mirrors defined on Sonatype side. One is from RAO (
repo.apache.org) and the other one is from old people.apache.org repo.
At some point ZK published artifacts to RAO. The lastest one was 3.3.1.
But ZK still uses old people.apache.org repo and publishes new artifacts
there.
Sonatype's Nexus mirrors from both locations and this breaks
maven-metadata.xml.

Here's the JIRA with Apache Infra people and Sonatype's support.
https://issues.sonatype.org/browse/MVNCENTRAL-173

*How to fix*
Brian Fox from Apache Infra suggests to move the project to Nexus and
completely remove the old repository in people.apache.org.

I am offering to help Mavenizing the project and move publishing to RAO.
There is https://issues.apache.org/jira/browse/ZOOKEEPER-1078 from May 2011
and last touched Dec 2011.
...along with https://issues.apache.org/jira/browse/ZOOKEEPER-1402

If the developers are not interested in this one yet, please reach Apache
Infra and make them delete ZK in repo.apache.org.
This is so annoying (reason explained below)

*Why is this important again?*
Sonatype's OSSRH (open source software repository hosting) more or less
became the defacto Maven repository for many open source projects (lately
adopting entire scala-tools.org). If a project has a ZooKeeper dependency,
the latest  version they can get is still 3.3.1. Declaring external
repositories is not allowed in project pom.xml for many reasons.
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

This slows down the adaptation of latest ZooKeeper clients and forces
people to use 3.3.1 from 2010 with a slew of bugs.
Thanks,
B.

On Mon, Dec 12, 2011 at 2:55 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> who does control mirroring on repo1.maven.org? Anyone know? Is this
> Apache? (you might check wth Apache Infra)
>
> Patrick
>
> On Mon, Dec 12, 2011 at 2:04 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> > No idea - we have no control over third-party mirroring. Sounds like
> > your best bet would be to set p.a.o as a repo in your pom.
> >
> > Patrick
> >
> > On Mon, Dec 12, 2011 at 1:37 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> >> On Mon, Dec 12, 2011 at 9:03 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> >>> The mirroring seems broken, here's the source:
> >>>
> >>>
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/zookeeper/zookeeper/maven-metadata.xml
> >>
> >> Who do we need to notify to fix that?
> >>
> >> I am about to push Asynchronous HBase Client to Central but don't want
> >> to depend on ZK 3.3.1.
> >>
> >> BTW, web site shows 3.3.4 as (current) but there is 3.4.0 available.
> >> POM also lists ZK 3.4.0 at the latest. Is it considered production
> >> safe?
>

On Tue, Mar 6, 2012 at 10:24 AM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> Resurrecting this problem again after finding out what was wrong and how
> the replication broke just the metadata file.
>
> *Background:*
> ZooKeeper releases are made manually with Ant copied via scp to old
> repository under people.apache.org.
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
> Although maven-metadata.xml in people.apache.org is correct the one in
> Maven Central still points to 3.3.1.
>
> *Why is this happening?*
> There are two mirrors defined on Sonatype side. One is from RAO (
> repo.apache.org) and the other one is from old people.apache.org repo.
> At some point ZK published artifacts to RAO. The lastest one was 3.3.1.
> But ZK still uses old people.apache.org repo and publishes new artifacts
> there.
> Sonatype's Nexus mirrors from both locations and this breaks
> maven-metadata.xml.
>
> Here's the JIRA with Apache Infra people and Sonatype's support.
> https://issues.sonatype.org/browse/MVNCENTRAL-173
>
> *How to fix*
> Brian Fox from Apache Infra suggests to move the project to Nexus and
> completely remove the old repository in people.apache.org.

Hi Berk, thanks for the in depth writeup, esp for those of us not very
familiar with the underlying issues.  Would love to move to Nexus but
as you mention in the next section ZOOKEEPER-1078 is still pending.
Even when that goes in it would only to to the next version (probably
3.5) and wouldn't effect 3.3 and 3.4 codelines, so we'd still have
this issue regardless. Is it possible to use Nexus w/o using maven? IE
can we drive this from our ant scripts, or at the very least do it by
hand? What's the process look like if doing by hand (I've used nexus
with other projects, but only via maven).

>
> I am offering to help Mavenizing the project and move publishing to RAO.
> There is https://issues.apache.org/jira/browse/ZOOKEEPER-1078 from May 2011
> and last touched Dec 2011.
> ...along with https://issues.apache.org/jira/browse/ZOOKEEPER-1402
>
> If the developers are not interested in this one yet, please reach Apache
> Infra and make them delete ZK in repo.apache.org.
> This is so annoying (reason explained below)

What will be the effect of doing this? (deleting repo.apache.org) I
don't remember setting this up, might someone be depending upon it?

Thanks for the insight and help.

Regards,

Patrick

>
> *Why is this important again?*
> Sonatype's OSSRH (open source software repository hosting) more or less
> became the defacto Maven repository for many open source projects (lately
> adopting entire scala-tools.org). If a project has a ZooKeeper dependency,
> the latest  version they can get is still 3.3.1. Declaring external
> repositories is not allowed in project pom.xml for many reasons.
> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>
> This slows down the adaptation of latest ZooKeeper clients and forces
> people to use 3.3.1 from 2010 with a slew of bugs.
>
>
> Thanks,
> B.
>
> On Mon, Dec 12, 2011 at 2:55 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>
>> who does control mirroring on repo1.maven.org? Anyone know? Is this
>> Apache? (you might check wth Apache Infra)
>>
>> Patrick
>>
>> On Mon, Dec 12, 2011 at 2:04 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> > No idea - we have no control over third-party mirroring. Sounds like
>> > your best bet would be to set p.a.o as a repo in your pom.
>> >
>> > Patrick
>> >
>> > On Mon, Dec 12, 2011 at 1:37 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
>> >> On Mon, Dec 12, 2011 at 9:03 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> >>> The mirroring seems broken, here's the source:
>> >>>
>> >>>
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/zookeeper/zookeeper/maven-metadata.xml
>> >>
>> >> Who do we need to notify to fix that?
>> >>
>> >> I am about to push Asynchronous HBase Client to Central but don't want
>> >> to depend on ZK 3.3.1.
>> >>
>> >> BTW, web site shows 3.3.4 as (current) but there is 3.4.0 available.

On Fri, Mar 9, 2012 at 10:12 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> ...
> Is it possible to use Nexus w/o using maven? IE
> can we drive this from our ant scripts, or at the very least do it by
> hand? What's the process look like if doing by hand (I've used nexus
> with other projects, but only via maven).

It is possible. Here's a step-by-step guide from Sonatype OSSRH documentation.
I don't think Apache repo mandates PGP signing, so you can skip it but
please don't if you can.
http://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7c.DeploySnapshotsandStageReleaseswithAnt

>>
>> If the developers are not interested in this one yet, please reach Apache
>> Infra and make them delete ZK in repo.apache.org.
>> This is so annoying (reason explained below)
>
> What will be the effect of doing this? (deleting repo.apache.org) I
> don't remember setting this up, might someone be depending upon it?

There will be no effect for Maven users because Maven Central
repository is included implicitly in resolution path if you don't
explicitly exclude it.
For people building with SBT, Grails or Apache buildr, there won't be
any changes as well. Maven Central is implicitly included if not
explicitly banned by the user in their build configuration.
For people building with Ivy2 and specifying RAO instead of
people.apache.org, they will need to change their resolver
specification. These users are stuck in 3.3.1 anyway. It's time to change.

So, there are three options now.
- The immediate solution is just to delete all the artifacts in RAO for
now so Maven Central doesn't corrupt metadata.
- More elegant solution is just to copy paste the Ant instructions from
OSSRH documentation and start pushing to RAO from Ant and deleting
people.apache.org repo (which may break Ivy2 users if they don't
declare Maven Central in their build. ...But the odds are high they
also rely on something else hosted in The Central)
- The end game is to Mavenize the build process, publish to RAO and
delete entire people.apache.org repo.

Which ever you choose and proceed, you will make Maven, SBT, Grails
and buildr users happy because they can reach ZK from Maven
Central without defining additional repositories and most importantly
all the projects which are publishing to Maven Central and depending
on ZK can now let their users to move to newer ZK versions instead of
being stuck with 3.3.1.

Thanks,
B.

Just wanted to ping.
Is anyone doing anything about this?

Please at least delete the RAO repo. Current situation cannot be made worse.

Thanks,
B.

On Fri, Mar 9, 2012 at 11:57 AM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> ...
>
> So, there are three options now.
> - The immediate solution is just to delete all the artifacts in RAO for
> now so Maven Central doesn't corrupt metadata.
> - More elegant solution is just to copy paste the Ant instructions from
> OSSRH documentation and start pushing to RAO from Ant and deleting
> people.apache.org repo (which may break Ivy2 users if they don't
> declare Maven Central in their build. ...But the odds are high they
> also rely on something else hosted in The Central)
> - The end game is to Mavenize the build process, publish to RAO and
> delete entire people.apache.org repo.
>
> Which ever you choose and proceed, you will make Maven, SBT, Grails
> and buildr users happy because they can reach ZK from Maven
> Central without defining additional repositories and most importantly
> all the projects which are publishing to Maven Central and depending
> on ZK can now let their users to move to newer ZK versions instead of
> being stuck with 3.3.1.
>
> Thanks,
> B.

On Sat, Mar 17, 2012 at 2:00 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
> Just wanted to ping.
> Is anyone doing anything about this?
>
> Please at least delete the RAO repo. Current situation cannot be made worse.

here's the request with infra:
https://issues.apache.org/jira/browse/INFRA-4550

Patrick

> On Fri, Mar 9, 2012 at 11:57 AM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
>> ...
>>
>> So, there are three options now.
>> - The immediate solution is just to delete all the artifacts in RAO for
>> now so Maven Central doesn't corrupt metadata.
>> - More elegant solution is just to copy paste the Ant instructions from
>> OSSRH documentation and start pushing to RAO from Ant and deleting
>> people.apache.org repo (which may break Ivy2 users if they don't
>> declare Maven Central in their build. ...But the odds are high they
>> also rely on something else hosted in The Central)
>> - The end game is to Mavenize the build process, publish to RAO and
>> delete entire people.apache.org repo.
>>
>> Which ever you choose and proceed, you will make Maven, SBT, Grails
>> and buildr users happy because they can reach ZK from Maven
>> Central without defining additional repositories and most importantly
>> all the projects which are publishing to Maven Central and depending
>> on ZK can now let their users to move to newer ZK versions instead of
>> being stuck with 3.3.1.
>>
>> Thanks,
>> B.

On Sat, Mar 17, 2012 at 10:14 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 17, 2012 at 2:00 PM, Berk D. Demir <[EMAIL PROTECTED]> wrote:
>> Just wanted to ping.
>> Is anyone doing anything about this?
>>
>> Please at least delete the RAO repo. Current situation cannot be made worse.
>
> here's the request with infra:
> https://issues.apache.org/jira/browse/INFRA-4550

Thanks Patrick,

I'm now watching the issue.
Hopefully this can be solved quickly and people can update the ZK
version dependency to 3.4 series in their POMs.