-
1. Re: Shared Parent POM for dependencyManagement
rrajesh Mar 13, 2008 11:23 AM (in response to alrubinger)Would moving the common thirdparty dependencies to jboss-parent POM (org.jboss:jboss-parent) solve this?
-
2. Re: Shared Parent POM for dependencyManagement
starksm64 Mar 13, 2008 1:59 PM (in response to alrubinger)org.jboss:jboss-parent is too general for that. A separate parent pom that is imported by jbossas and other projects looking to integrate into it makes more sense.
We still need to get a handle on whether there is an acceptable version range policy (only minor version, custom jboss policy, etc.). I would also suggest that snapshot version cannot be introduced into the common parent. It has to be done in the project. -
3. Re: Shared Parent POM for dependencyManagement
alrubinger Mar 13, 2008 4:41 PM (in response to alrubinger)"scott.stark@jboss.org" wrote:
org.jboss:jboss-parent is too general for that.
Yes, this is what I'm getting at."scott.stark@jboss.org" wrote:
We still need to get a handle on whether there is an acceptable version range policy (only minor version, custom jboss policy, etc.).
Though related, and will affect the values of a shared parent, I don't think this is a requirement to move forward in centralizing the dependencies."scott.stark@jboss.org" wrote:
I would also suggest that snapshot version cannot be introduced into the common parent. It has to be done in the project.
What is the reasoning behind this? If snapshots are done only at the project level, then:
1) AS increments to snapshot of project A
2) EJB3 remains on release 1 of project A
3) AS requires release 2 of project A, updates shared parent
4) EJB3 implicitly gets release 2 now, and has version conflict because it hasn't been seeing snapshot changes all along. Possible compile and runtime problems.
S,
ALR -
4. Re: Shared Parent POM for dependencyManagement
starksm64 Mar 13, 2008 4:53 PM (in response to alrubinger)"ALRubinger" wrote:
What is the reasoning behind this? If snapshots are done only at the project level, then:
1) AS increments to snapshot of project A
2) EJB3 remains on release 1 of project A
3) AS requires release 2 of project A, updates shared parent
4) EJB3 implicitly gets release 2 now, and has version conflict because it hasn't been seeing snapshot changes all along. Possible compile and runtime problems.
Too many projects are affected by an unknown release. A project may not even allow snapshot releases in its build policy. The potential for 4 exists regardless of whether or not snapshots are used. Any update of the shared parent needs coordination and should result in rollback if existing builds fail. Snapshots simply cannot be adequately coordinated in my view. -
5. Re: Shared Parent POM for dependencyManagement
alrubinger Mar 13, 2008 5:10 PM (in response to alrubinger)Hmm, this gets slippery.
"scott.stark@jboss.org" wrote:
The potential for 4 exists regardless of whether or not snapshots are used.
Yes, but the question is - when? If snapshots in the parent are prohibited, projects get switched over to the new dependency's release very late in the game, nearing a milestone. That can hold up the whole works, because of:"scott.stark@jboss.org" wrote:
Any update of the shared parent needs coordination and should result in rollback if existing builds fail.
So now AS requires Dependency Version 2, which breaks EJB3. CR1 is held up because a switch was flipped right before the milestone, and EJB3 needs to resolve the errors before CR1 can ship.
S,
ALR -
6. Re: Shared Parent POM for dependencyManagement
starksm64 Mar 13, 2008 5:18 PM (in response to alrubinger)"ALRubinger" wrote:
So now AS requires Dependency Version 2, which breaks EJB3. CR1 is held up because a switch was flipped right before the milestone, and EJB3 needs to resolve the errors before CR1 can ship.
That coordination should have happened before the shared pom was updated. Each project should have a subtask on the jira issue for updating the parent pom to version 2, and only when those are closed the parent is updated. -
7. Re: Shared Parent POM for dependencyManagement
alrubinger Mar 13, 2008 5:20 PM (in response to alrubinger)Ah, I wasn't taking into account the release cycle of the shared POM.
At the end of this discussion I'd like to see a dependency policy Wiki so we can keep things straight.
S,
ALR -
8. Re: Shared Parent POM for dependencyManagement
starksm64 Mar 13, 2008 5:32 PM (in response to alrubinger)Definitely, and it needs to address version ranges, how version information is locked down as part of the mvn release process, the jboss version resolution policy plugin if we get to needing that, etc.
-
9. Re: Shared Parent POM for dependencyManagement
dimitris Mar 14, 2008 7:15 AM (in response to alrubinger)Let me use a simple example (--> = uses)
AS --> common v2
AS --> EJB v3 --> common v2
If I try to upgrade AS to common v3, wouldn't this be caught by the dependency mechanism when I try to build AS, as long as all the dependencies have been explicitly defined?
What am I missing? -
10. Re: Shared Parent POM for dependencyManagement
pgier Mar 14, 2008 9:42 AM (in response to alrubinger)Yes, normally this would work and the explicit dependency would win. The problem in some of our dependency trees has to do with artifacts that changed their name. So maven doesn't know that these two are really different versions of the same thing.
AS --> ejb3 --> jboss-logging-jdk
AS --> jboss-common-logging-jdk
The transitive one might actually come first in the classpath, because maven builds the tree doing a depth first traversal (This appears to be fixed in 2.0.9 http://jira.codehaus.org/browse/MNG-1412). So jboss-logging-jdk needs to be excluded from the ejb3 dep tree in the AS dependencies. -
11. Re: Shared Parent POM for dependencyManagement
alrubinger Mar 18, 2008 2:04 AM (in response to alrubinger)If there are no objections by midday UTC-5 tomorrow (EOB for EU), I'll start on extracting the AS Versions into a new Component in jbossas/projects, called "component-matrix". This will include:
* Moving the "dependencyManagement" section of the JBossAS Parent into the new component
* Setting the parent of the JBossAS Parent to "component-matrix"
* Removing the "dependencyManagement" section of the EJB3 Build POM
* Setting the parent of the EJB3 Build POM to "component-matrix"
* Resolving conflicts with EJB3 Build to match AS
* Creation of a Dependency Policy Wiki Page
PS - I'm not married to the name "component-matrix", but "build" sounded redundant and non-deterministic. Suggestions?
S,
ALR -
12. Re: Shared Parent POM for dependencyManagement
starksm64 Mar 18, 2008 9:59 AM (in response to alrubinger)Make sure this syncs up with Paul's work on the thirdparty changes, and as requested, these type of change notifications should be forward this to the dev list. I have done the later.
-
13. Re: Shared Parent POM for dependencyManagement
pgier Mar 18, 2008 10:11 AM (in response to alrubinger)"ALRubinger" wrote:
If there are no objections by midday UTC-5 tomorrow (EOB for EU), I'll start on extracting the AS Versions into a new Component in jbossas/projects, called "component-matrix". This will include:
* Moving the "dependencyManagement" section of the JBossAS Parent into the new component
* Setting the parent of the JBossAS Parent to "component-matrix"
* Removing the "dependencyManagement" section of the EJB3 Build POM
* Setting the parent of the EJB3 Build POM to "component-matrix"
* Resolving conflicts with EJB3 Build to match AS
* Creation of a Dependency Policy Wiki Page
PS - I'm not married to the name "component-matrix", but "build" sounded redundant and non-deterministic. Suggestions?
S,
ALR
So the new pom will be the parent of the current jboss-as-parent? You could probably move the pluginManagement section up to the new pom also, since it is just controlling which versions of plugins are used and some basic configuration that could probably be used for EJB also.
Once you're done, just let me know, and I'll update the poms in the thirdparty branch that I'm working on. -
14. Re: Shared Parent POM for dependencyManagement
pgier Mar 18, 2008 10:18 AM (in response to alrubinger)I guess I'm not sure how/if this will solve the circular dependency issues. If the new parent lists dependencies on ejb3 for example, that app server depends on, doesn't that mean that ejb3 would have to be released before the new parent? Since you are technically not supposed to release the parent if it still lists dependencies on a SNAPSHOT version of ejb3.
The same thing would be true for the app server module versions in the new parent pom. Maybe the app server module and ejb3 dependencies should not be listed in the parent? I guess the other option is to release all three at the same time.