So I looked a little deeper into this and version 1.2 is already in
Central AND that version doesn't have the repository elements. Also the
plugin I'm using that uses stax-ex transitively is using version 1.2. So I
was wondering why then am I seeing a pom with the repository elements? Well
the Maven 2 java.net repository also happens to have a copy of version 1.2
with the a pom with the repositories. The way I setup our Nexus routing
rules the Java.net repository comes before Maven Central, hence everyone
gets the version of the pom with the repository tags.
Kohsuke, I really appreciate you responding and your feedback. I wouldn't
have found a better solution if you didn't push me to look deeper.
Thanks again,
Brian
On 8/6/09 4:43 PM, "Kohsuke Kawaguchi" <Kohsuke.Kawaguchi_at_Sun.COM> wrote:
> Jackson, Brian R wrote:
>> Thanks Kohsuke,
>> I really respect everything you've done in the Java community. Your
>> contributions are really impressive. But I think you might be wrong here
>> and Brian Fox explains the reason better than I ever could:
>>
>> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms
>> -is-a-bad-idea/
>
> I don't think there's any inconsistency between what he's saying and
> what I was saying. As he notes, if I remove <repository>, it makes it
> that much harder for other people to build the software.
>
>> Also, please realize too that in ~4 years of using Maven, with gigabytes of
>> dependencies, this is the first OSS dependency I've run into that has
>> repositories defined within the released POM.
>>
>> Of course in the end we can agree to disagree.
>
> I guess the solution that makes everyone happy would be to sync up the
> dependencies to central. OTOH, I find this notion very non-internet-like
> that every open-source project has to sync to a central location.
>
> Thus we are between a rock and a hard place, and I'm sorry that you are
> the one who has to suffer, but as I wrote, just removing it would only
> make other set of people suffer.
>
> I suppose in this case if someone is willing to do the work of pushing
> relevant artifacts into central (and thereby eliminating the need of
> <repository>), that would make everyone happy.
>
>
>> All the best,
>> Brian
>>
>>
>> On 8/6/09 12:59 PM, "Kohsuke Kawaguchi" <Kohsuke.Kawaguchi_at_Sun.COM> wrote:
>>
>>>
>>> I'm sorry to hear that, but I hope you see that if we remove
>>> <repository> declaration from the POM, that will break other people's
>>> builds as Maven no longer can find artifacts for them.
>>>
>>> It seems to me that the real culprit is your HTTP proxy. If the proxy
>>> has a policy of prohibiting access to java.net repositories. they should
>>> report appropriate HTTP status code to indicate that, like 401, instead
>>> of just letting it hang.
>>>
>>> I believe another work around is for you to touch up our POM a bit when
>>> you add that to your Nexus.
>>>
>>> Jackson, Brian R wrote:
>>>> We have an internal Nexus repository and all our Maven traffic must go
>>>> through it but recently I added org.jvnet.staxex:stax-ex as a dependency to
>>>> my project and now my builds try to check the java.net repositories
>>>> directly
>>>> and hang because of our internal HTTP proxy.
>>>>
>>>> I�ve solved it by having Maven treat our internal repository as a mirror
>>>> of
>>>> java.net, java.net2 and java.net1. But it would be nice if you released a
>>>> new version with the repository declarations stripped out of the pom.xml.
>>>>
>>>> Thanks,
>>>> ___________________________________________
>>>> Brian R. Jackson
>>>> Staff Software Engineer
>>>> ESPN.com Fantasy Games
>>>> (860) 766-2511
>>>>
>>>>
>>>>
>>>
>>
>> ___________________________________________
>> Brian R. Jackson
>> Staff Software Engineer
>> ESPN.com Fantasy Games
>> (860) 766-2511
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_stax-ex.dev.java.net
>> For additional commands, e-mail: users-help_at_stax-ex.dev.java.net
>>
>> .
>>
>
___________________________________________
Brian R. Jackson
Staff Software Engineer
ESPN.com Fantasy Games
(860) 766-2511