-
15. Re: Move dependency management back into app server svn stru
"wolfc" wrote:
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.
Snapshots are worse. I ignored snapshot issues because that's even more broken.
I wanted to give you the benefit of the doubt, I'm talking about sane version control.
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.
Which part are you not getting?
You can't have an independent release cycle
if you have to synch with the AS and vice versa. They may as well be under the
same version control, at least then non-ejb3 contributors would have some
understanding of whats going on.
To use a bad analogy:
You want to have your cake and eat it. But I (as a none-ejb3 contributor)
am just going to stand on it because I don't know it's there. ;-)"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.
So we do 10 candidate releases of component matrix between each AS candidate release
one for each thirdparty update that's needed during the development process.
Please don't say snapshots in your reply.
I think I've addressed 3.
Not unless you advocating an "infinite number" of component-matix releases."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.
See, you just said EJB3 is NOT really independent. In fact it is, because you
have to satisfy at least two different integration decisions. JBossAS and JBoss Embeded.
There's more if JBoss Embedded really wants to support other platforms."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. -
16. Re: Move dependency management back into app server svn stru
This forum software is getting really buggy.
Here's my last comment in a seperate comment."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.
Messengers from whom?
Can you imagine what would happen if everybody took your approach.
How would this mechanism scale to 10 or 20 component projects
all wanting to try to go in lock step with AS dependencies but still claim their own
independent status?
Anyway, I've given up on this argument.
If you want to integrate against implementation details then don't come crying
to me when it all breaks or you find its very difficult to do.
I've worked on that kind of software before, eventually you get to a point where
you can't change anything for fear of knocking over the whole house of cards. -
17. Re: Move dependency management back into app server svn stru
"adrian@jboss.org" wrote:
Anyway, I've given up on this argument.
If you want to integrate against implementation details then don't come crying ...
Well it was nearly my last post. :-)
I should have added don't expect or force others to go down the same brain-dead route. -
18. Re: Move dependency management back into app server svn stru
"adrian@jboss.org" wrote:
If you want to integrate against implementation details then don't come crying to me when it all breaks or you find its very difficult to do.
Again, Adrian, we don't *want* to integrate against internals.
However, for many of the AS Projects we don't have clean separation available to us.
S,
ALR -
19. Re: Move dependency management back into app server svn stru
"ALRubinger" wrote:
"adrian@jboss.org" wrote:
If you want to integrate against implementation details then don't come crying to me when it all breaks or you find its very difficult to do.
Again, Adrian, we don't *want* to integrate against internals.
However, for many of the AS Projects we don't have clean separation available to us.
S,
ALR
I'm ignoring your comment because I've been complaining about this for years.
I created explicit JIRA issues for EJB3 related to the projects I work on, back in 2005.
Admittedly you weren't here then.
The EJB3 team has "quietly" let them bump along from release to release.
Although some issues they eventually got fed up of my badgering.
Complaining that it's not done as you reach the JBoss5 deadline,
is nobody's fault except EJB3's.
Now you know why I said "I'm tired of the argument".
Don't complain about it, fix it. -
20. Re: Move dependency management back into app server svn stru
"adrian@jboss.org" wrote:
I'm ignoring your comment because I've been complaining about this for years.
I created explicit JIRA issues for EJB3 related to the projects I work on, back in 2005.
Admittedly you weren't here then.
Since it is before your time, you probably don't know that EJB3 once
had virtually a complete fork of JCA just because "it was easier".
It's certainly was easier for me, because I refused to have anything to do with
supporting it. :-) -
21. Re: Move dependency management back into app server svn stru
We said we would define the missing integration spis as needed to break any dependency on internals and break the circular dependency between ejb3 and jbossas. This just needs to be done in the coming two weeks.
-
22. Re: Move dependency management back into app server svn stru
So I take it the dependency versions are still coming from jboss-as-component-matrix? However, when I do a build I see thirdparty/jboss/common-core/component-info.xml refer to version 2.2.4.GA while the jboss-as-component-matrix-5.0.0-SNAPSHOT.pom has 2.2.3.GA. I can't figure out what is driving the to the 2.2.4.GA version. This is what is in the build/build-thirdparty.xml, but when I update that to 2.2.5.beta1, the thirdparty contents are stil at 2.2.4.GA.
-
23. Re: Move dependency management back into app server svn stru
Did you look in the new component-matrix module's pom.xml? That has 2.2.4.GA. The module doesn't show up in eclipse as it has no .project or .classpath, but it's there.
I made changes there for local testing and ran the build and the new versions appeared in thirdparty. No idea how. :-) I didn't do any mvn install or mvn deploy after changing the component-matrix/pom.xml; just treated the pom as a new flavor of build-thirdparty.xml -- change it, ran build/build.sh and it worked. -
24. Re: Move dependency management back into app server svn stru
Ah, I see, thanks. I think mvn tries to resolve parent poms locally if it can. I see to different versions in this:
<properties> ... <version.org.jboss.common-core>2.2.3.GA</version.org.jboss.common-core> ... <dependency> <groupId>org.jboss</groupId> <artifactId>jboss-common-core</artifactId> <version>2.2.4.GA</version> </dependency>
I don't see the version.org.jboss.common-core used anywhere though. So the build-thirdparty.xml is not used at all any longer. I thought Paul had updated this, but the build/build.xml createthirdparty target is just calling maven with the thirdparty dir as the basedir. -
25. Re: Move dependency management back into app server svn stru
Why the trunk/component-matrix/pom.xml is picked up is because the trunk/pom.xml is resolved as the thirdparty/pom.xml jboss-as-parent, and its parent is redirected to the component-matrix/pom.xml by this:
<parent> <groupId>org.jboss.jbossas</groupId> <artifactId>jboss-as-component-matrix</artifactId> <version>5.0.0-SNAPSHOT</version> <relativePath>component-matrix</relativePath> </parent>
-
26. Re: Move dependency management back into app server svn stru
Any reason I *shouldn't* check into svn a .project file for component-matrix?
-
27. Re: Move dependency management back into app server svn stru
Silence is golden. A .project file has been added.
-
28. Re: Move dependency management back into app server svn stru
Fyi, Maven 2.0.9 introduced a new "import" scope that allows a pom to import another pom's dependencies, without the second pom being the parent of the first pom. I'm just mentioning it, because it sounds like a feature we might be able to leverage here.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies -
29. Re: Move dependency management back into app server svn stru
Thanks for the info. This could be useful for the integration project or other multi-module projects that are consumed by the app server build.