-
1. Re: Move dependency management back into app server svn stru
adrian.brock Mar 26, 2008 12:01 PM (in response to pgier)"pgier" wrote:
After spending some time updating dependencies in the component-matrix pom while working on the build-thirdparty conversion, it seems that having the component-matrix as a separate project is somewhat error prone.
The main issue is that whenever I make a change in the component matrix I have to make sure that the app server is immediately updated to match, otherwise there are build errors. When the dependency management is part of the app server codebase, this is not an issue because everything gets committed together, and built together.
Why can't the component-matrix be included in the jbossas checkout
using the same svn mechanism as shares docbook across many projects? -
2. Re: Move dependency management back into app server svn stru
pgier Mar 26, 2008 12:10 PM (in response to pgier)You mean using svn:externals?
It could be done that way. That would solve a lot of the issues. The only problem with svn:externals (if I remember correctly) is that you have to specify the entire svn url. Since we use different URLs for anonymous vs non-anonymous, the anonymous checkout might not work with this. -
3. Re: Move dependency management back into app server svn stru
dimitris Mar 26, 2008 2:09 PM (in response to pgier)My view is that the dependencies must be part of the project.
Now, if svn:externals can do the trick, that's maybe an implementation issue.
Depending on an external project to get your dependencies is developer-unfriendly, as you've found out (and weird, too). -
4. Re: Move dependency management back into app server svn stru
dimitris Mar 28, 2008 3:36 PM (in response to pgier)After the last call we had, I'm even more convinced that the component-matrix pom is a bad idea.
So in a purely dictatorship fashion, Paul is going to bring back the dependencies in the AS project. :-) -
5. Re: Move dependency management back into app server svn stru
alrubinger Mar 28, 2008 3:39 PM (in response to pgier)"dimitris@jboss.org" wrote:
After the last call we had, I'm even more convinced that the component-matrix pom is a bad idea.
The POM itself? Or its external location?
S,
ALR -
6. Re: Move dependency management back into app server svn stru
wolfc Mar 28, 2008 6:05 PM (in response to pgier)EJB 3 requires an electronic overview of all components used in JBoss AS 5.0.0.CR1. This is to make sure we build against the correct versions. Since Maven is currently the build system defacto it must be directly consumable by Maven.
How you do this? I don't care.
Where you put this? I don't care.
As long as the above requirements are met before the actual release of JBoss AS 5.0.0.CR1. So I can actually deliver something usable in that AS version. -
7. Re: Move dependency management back into app server svn stru
dimitris Mar 29, 2008 5:48 AM (in response to pgier)"ALRubinger" wrote:
"dimitris@jboss.org" wrote:
After the last call we had, I'm even more convinced that the component-matrix pom is a bad idea.
The POM itself? Or its external location?
Having the AS pom.xml essentially outside the project. -
8. Re: Move dependency management back into app server svn stru
dimitris Mar 29, 2008 6:06 AM (in response to pgier)"wolfc" wrote:
EJB 3 requires an electronic overview of all components used in JBoss AS 5.0.0.CR1. This is to make sure we build against the correct versions. Since Maven is currently the build system defacto it must be directly consumable by Maven.
How you do this? I don't care.
Where you put this? I don't care.
As long as the above requirements are met before the actual release of JBoss AS 5.0.0.CR1. So I can actually deliver something usable in that AS version.
1) Your mission is to deliver a working EJB3 implementation, not screw up the AS build.
2) EJB3 is only pseudo-independent as long as cyclical dependencies exist. It was a mistake to move EJB3 outside AS until this is resolved. -
9. Re: Move dependency management back into app server svn stru
alrubinger Mar 29, 2008 11:26 AM (in response to pgier)"dimitris@jboss.org" wrote:
Having the AS pom.xml essentially outside the project.
That's much different than "the component-matrix pom is a bad idea". :)
----
Though I don't much care where component-matrix lives, we've got conflicting views on the topic of what constitutes a circular dependency."adrian@jboss.org" wrote:
If you depend upon a jbossas sub-project then you are doing it wrong. Circular dependency anyone? :-)
I don't agree with the above statement. The Thread at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132229 explains this more fully. In short, the dependency chain can be "AS Assembly > EJB3 > AS Component" just fine.
However, if Adrian's comment is true, then moving the component-matrix POM under jbossas/trunk means we cannot depend on it, which defeats its purpose in the first place.
----"dimitris@jboss.org" wrote:
1) Your mission is to deliver a working EJB3 implementation, not screw up the AS build.
We've outgrown the current layout of JBossAS. EJB3, webservices, (messaging?), and any future projects need to take advantage of the same libraries/projects that AS does. JBossAS cannot lay claim to exclusive control of these projects.
We need to discuss and come to agreement on the direction in which we're heading by identifying the requisite use cases for both AS and AS Component Consumers.
Let's try to give that some attention this week.
S,
ALR -
10. Re: Move dependency management back into app server svn stru
wolfc Mar 31, 2008 9:12 AM (in response to pgier)I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.
The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk. -
11. Re: Move dependency management back into app server svn stru
adrian.brock Mar 31, 2008 9:35 AM (in response to pgier)"wolfc" wrote:
I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.
The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk.
That's a logical fallacy, in fact probably a few of them. :-)
I only have to do the exercise proposed to see its not true.
After spending some time updating dependencies in the HIBERNATE pom while working on the build-thirdparty conversion, it seems that having ... HIBERNATE as a separate project is somewhat error prone.
The main issue is that whenever I make a change in ... HIBERNATE I have to make sure that the app server is immediately updated to match, otherwise there are build errors.
Which plainly isn't true.
There's a big difference between an external project that is included in JBossAS
as a component and an external project that actually defines what
those components should be. -
12. Re: Move dependency management back into app server svn stru
adrian.brock Mar 31, 2008 9:48 AM (in response to pgier)I really don't see what the disconnect is here or why it is so hard to understand.
There's an integration project called JBossAS that is used to aggregate
other components. One of those components is EJB3 which isn't an integration project
and therefore shouldn't be making assumptions about what JBossAS will actually use.
You only have to go through a few simple use cases to see it doesn't work.
1) Suppose JBossAS wants to integrate the latest version of the TM but EJB3 doesn't
want to do that. Similarly EJB3 wants to use the latest snapshot of security, but
JBossAS doesn't because its not ready.
How do you define a component-matrix that would satisfy both?
2) Suppose JBossAS/Component Matrix is at 5.0.0.CR1 and wants to update
the security project. It can't change the 5.0.0.CR1 release so it has to do
a new release of Component Matrix (5.0.0.CR2). JBossAS trunk then
changes its parent to 5.0.0.CR2. But EJB3 is still on 5.0.0.CR1
Defeating the whole point.
Of course you could use snapshots, but then why have version control at all
if the only way to move things forward is ignore it?
3) Pauls point. You can't synchronously update a component and do the work
the integrate it in one commit. Of course you can play around with local builds
in your local maven repository, but
* that doesn't really test it works with the real build
* there's a gap between the two commits
* two people can't work on it at the same time - how do you create a branch?
4) Longer term EJB3 wants to go its own way anyway so shared dependencies
aren't even the correct solution.
5) The correct way to integrate things is via interfaces NOT implementations.
In my view EJB3 is just being lazy (can't be bothered creating a version
of EJB3 that isn't so brittle to thirdparty implementation details and versions)
and forcing JBossAS to jump through hoops because of that. -
13. Re: Move dependency management back into app server svn stru
alrubinger Mar 31, 2008 3:10 PM (in response to pgier)"adrian@jboss.org" wrote:
4) Longer term EJB3 wants to go its own way anyway so shared dependencies aren't even the correct solution.
Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built to ensure that our compile/runtime dependencies would match."adrian@jboss.org" wrote:
5) The correct way to integrate things is via interfaces NOT implementations.
In my view EJB3 is just being lazy (can't be bothered creating a version
of EJB3 that isn't so brittle to thirdparty implementation details and versions)
and forcing JBossAS to jump through hoops because of that.
You assume that we have access to the SPI/API/interfaces required for us to build.
At the moment, the "integration" project (http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/)
holds SPIs for a whopping 3 projects. Until all of our AS Component dependencies are properly extracted into SPI/Impl, we'll depend on implementations and hence have a cyclic dependency preventing release.
The EJB3 team's efforts towards Mavenization has lead to the discovery of cyclic dependencies in AS. The problems were already there, and the new build tool is bringing them to the surface. For this laziness, you are welcome.
S,
ALR -
14. Re: Move dependency management back into app server svn stru
wolfc Apr 1, 2008 4:37 AM (in response to pgier)"adrian@jboss.org" wrote:
"wolfc" wrote:
I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.
The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk.
That's a logical fallacy, in fact probably a few of them. :-)
So was the theory of Galileo. We're still looking for *our* center of the universe. :-)"adrian@jboss.org" wrote:
I only have to do the exercise proposed to see its not true.After spending some time updating dependencies in the HIBERNATE pom while working on the build-thirdparty conversion, it seems that having ... HIBERNATE as a separate project is somewhat error prone.
The main issue is that whenever I make a change in ... HIBERNATE I have to make sure that the app server is immediately updated to match, otherwise there are build errors.
Which plainly isn't true.
There's a big difference between an external project that is included in JBossAS
as a component and an external project that actually defines what
those components should be.
Yes it's true. If I do a non-backwards compatible change on a snapshot it all breaks apart."adrian@jboss.org" wrote:
You only have to go through a few simple use cases to see it doesn't work.
1) Suppose JBossAS wants to integrate the latest version of the TM but EJB3 doesn't
want to do that. Similarly EJB3 wants to use the latest snapshot of security, but
JBossAS doesn't because its not ready.
How do you define a component-matrix that would satisfy both?
Won't happen because here we actually depend on the JTA API. :-D
Security I agree with you, that is currently a mess because we have no *common* SPI. Still it will always be a common dominator which governs our releases.
The goal of EJB 3 project is to provide both a plugin and a stand-alone which are 100% compatible (with an independent release-cycle!). So I don't want any other versions than those of the latest AS."adrian@jboss.org" wrote:
2) Suppose JBossAS/Component Matrix is at 5.0.0.CR1 and wants to update the security project. It can't change the 5.0.0.CR1 release so it has to do a new release of Component Matrix (5.0.0.CR2). JBossAS trunk then changes its parent to 5.0.0.CR2. But EJB3 is still on 5.0.0.CR1.
That is 100% correct and how I want it to be, because EJB 3 is at that point incompatible with AS 5.0.0.CR2 and must do a refactoring upgrade.
So the AS product, at that point, is not ready for assemblage and waiting for the next EJB 3 release.
I think I've addressed 3."ALRubinger" wrote:
"adrian@jboss.org" wrote:
4) Longer term EJB3 wants to go its own way anyway so shared dependencies aren't even the correct solution.
Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built to ensure that our compile/runtime dependencies would match.
No, we don't. :-)
AS is our primary staging platform and the stand-alone is mostly a facilitator for unit testing."adrian@jboss.org" wrote:
5) The correct way to integrate things is via interfaces NOT implementations.
If you mean public API/SPI then I completely agree with you.
The main problem I see is that AS trunk defines facilitating components which are used by a lot of projects (not just EJB 3) (dare I mention jboss-as-aspects ;-) ). As Andrew says, we're just the messengers.