Shale-Parent--pom contains repositories

• Key: SHALE-319
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Matthias Wessendorf
• Reporter: Matthias Wessendorf
• Fix Version/s: 1.0.4

Description

The "parent pom" in Shale has an "abuse" of <repositories/>. It
specifies two repositories inside the <repositories/> xml element. IMO
this should be handled by the user's settings.xml file and not by a
lib.

So, if you are behind a proxy, a corp.-m2-mirrow and a
corp-own-m2-repo, you can't build stuff which uses Shale. (This
envoironment is sorta production like.)

Why can't you build the stuff?
Because maven sees only (to fetch Shale dependencies) these two repos:
-Apache M2 Snapshot
-Java.net

So it tries to download apache2-pom from these... it doesn't look in
other repos.
(currently the apache m2 snapshot repo is down... so it doesn't get
Shale-master too,
which is! available within a regular m2 repo)


Our work around, we changed the shale-parent-pom in our corp. m2 repo
and commented those repositories out. That works.

Comments

[Wendy Smoak]

Related discussion thread: http://www.nabble.com/Bug-in-pom.xml--...-%21-t2496797.html

[Craig McClanahan]

> The "parent pom" in Shale has an "abuse" of <repositories/>. It
> specifies two repositories inside the <repositories/> xml element.
> IMO this should be handled by the user's settings.xml file and not
> by a lib.

I strongly disagree. That's what the <repository> element is there for. If we tell people they have to configure their user settings (to get the right repositories), we have just destroyed the primary reason we switched away from Ant (where you had to customize build.properties files for stuff like this) in the first place.

[snip]
> So, if you are behind a proxy, a corp.-m2-mirrow and a
> corp-own-m2-repo, you can't build stuff which uses Shale. (This
> envoironment is sorta production like.)

Sounds like you should set proxy settings in your user settings file, something which *does* belong there. I can build from behind Sun's firewall with no problems, once I set my proxy servers correctly.

[snip]
> So it tries to download apache2-pom from these...
> it doesn't look in other repos.

Sounds like a bug in Maven to me.

[snip]
> Our work around, we changed the shale-parent-pom in our
> corp. m2 repo and commented those repositories out. That works.

Try this experiment (on a machine outside the firewall):
* Do the same thing
* Erase your local repository
* Do *not* add these repositories to your user settings
  (this reflects the state of the vast majority of the world)
* Try a build
* Watch it fail because it doesn't know where to get the
  dependencies at all.

I'm -1 unless you can demonstrate a technique that (a) works for you, and (b) works in the scenario described above.

>I strongly disagree. That's what the <repository> element is there for. If we tell people they have to configure their user settings (to get the right repositories), we have just >destroyed the primary reason we switched away from Ant (where you had to customize build.properties files for stuff like this) in the first place.

at least if ibiblio is down a user wants to add a mirrow or alternate repo

>Sounds like you should set proxy settings in your user settings file, something which *does* belong there. I can build from behind Sun's firewall with no problems, once I set my proxy servers correctly.

I am not saying that I don't have that stuff setup in my settings, I am able to build, no worries.

>[snip]
> So it tries to download apache2-pom from these...
> it doesn't look in other repos.
>
>Sounds like a bug in Maven to me.

can be that, or we need to remove the <repo/>


[snip]
> Our work around, we changed the shale-parent-pom in our
> corp. m2 repo and commented those repositories out. That works.

>Try this experiment (on a machine outside the firewall):
>* Do the same thing
>* Erase your local repository
>* Do *not* add these repositories to your user settings
  (this reflects the state of the vast majority of the world)
>* Try a build
>* Watch it fail because it doesn't know where to get the
 > dependencies at all.

did everything with a *naked* m2 env. (means no settings at all)

I got this:

Downloading: http://repo1.maven.org/maven2/org/apache/shale/shale-parent/1.0.3/shale-parent-1.0.3.pom
16K downloaded
Downloading: http://people.apache.org/maven-snapshot-repository/org/apache/shale/shale-master/1/shale-master-1.pom
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.shale:shale-parent:pom:1.0.3

Reason: Cannot find parent: org.apache.shale:shale-master for project: org.apache.shale:shale-parent:pom:1.0.3


ok, can be, b/c the people.apache.org is down. BUT! after commented out the repos in -parent, it went through, pretty smooth



So what I did than, *erase* my local_repo again, update shale source, remove the <repo/> from -parent (in source) and run the Shale build.
It went through (and the post shale trinidad build as well)

[Wendy Smoak]

I'm also not in favor of a solution that requires developers to edit settings.xml in order to build Shale, but I don't think that is the case here.

We have releases enabled on apache.snapshots because that is where we have been staging releases. A better idea would be to stage them elsewhere, such as http://people.apache.org/builds/shale/m2-staging-repository, and remove this repository definition from shale-parent.

For the java.net repo, I thought I heard that it would be synced with the central repository. If that is true, then we don't need that one, either.

The build failures seem to be a bug in Maven's dependency resolution mechanism. It should check all of the repositories, and from the log output, it never checks its own central repo. We had a similar report at Struts this morning.

[Matthias Wessendorf]

> I'm also not in favor of a solution that requires developers to edit settings.xml in order to build Shale, but I don't think that is the case here.

right. I didn't have a settings.xml for my latest test case. I only needed to edit the -parent.

> We have releases enabled on apache.snapshots because that is where we have been staging releases. A better idea would be to stage them elsewhere, such as
 > http://people.apache.org/builds/shale/m2-staging-repository, and remove this repository definition from shale-parent.

+1 for the remove :)

> For the java.net repo, I thought I heard that it would be synced with the central repository. If that is true, then we don't need that one, either.

well at least I was able to get sun stuff (like RI) from ibiblio, which was not he case is the past, I think that's the reason why it is still there.

> The build failures seem to be a bug in Maven's dependency resolution mechanism. It should check all of the repositories, and from the log output, it never checks its own
> central repo. We had a similar report at Struts this morning.

yeah, think that's a bug too, but let's remove the (unneeded repos too).

I ping the maven user list about this thread.

-M

[Matthias Wessendorf]

fixed in svn

[Wendy Smoak]

Disabling releases on the snapshot repository means we need to modify our release process to stage them somewhere else.

We still need to:
 * Choose a location (http://people.apache.org/builds/shale/m2-staging-repository)
 * Update the shale-master pom's 'distributionManagement' section
 * Update the release process documentation.

[Wendy Smoak]

I added apache.snapshots back to shale-parent last night, after Torsten had trouble building the framework.

I added it with releases/enabled/false, so it is the same definition that would be inherited from the top-level Apache pom. The issue is that with nothing in your local repo, Maven can't find the snapshot of shale-master in order to inherit the repository definitions. Typical bootstrap problem. :)

Matthias, I'm curious whether this makes the problem you were having re-appear. I think it might have been the 'releases enabled' part that exposed whatever Maven bug you were running into. I hope so, anyway!