Rémy Maucherat wrote:
I base my opinion on this after looking at what Maven is doing when
downloading dependencies, and how it apparently needs specific
configuration to consider downloading the right thing.
Well, we've been specifying "suggestions" to the dependency resolution
mechanism. This gives Maven free reign to resolve based on a "nearest
wins" model in the tree. After we stabilize with specific versions, we
should be *constraining* into compatible version ranges using the
bracket syntax. Anything that doesn't fit will fail the build.
> We've outgrown the monolithic AS layout, and need to be
adopting a
> componentized structure where each project pushes forth frequent releases
> for integration.
If this could stop, it would be nice. It has been going on for months :(
So we keep everything together under repos/jbossas/trunk? This presents
that:
* No IDE can handle such a huge codebase
* Every project must be tagged and released together
...which means that EJB3, as a defining example, would not be able to
push time-boxed releases to the community without waiting on the rest of
AS stabilizing and going through QA.
For the past 3 days, AS has been so unstable that it's been nearly
impossible to develop. Back when the EJB3 Plugin was compatible with
Beta4, our project did not have to worry about being stalled because of
regression introduced into AS. It's a matter of numbers; too many hands
in one codebase, and one commit is sure to bring down the whole house
eventually.
No. Maven stores JARs in two places, I have found (its own, and
thirdparty). This causes management problems that did not exist
before. Also, errors in poms yield non existent error messages
(stacktrace with "invalid POM" without mention on what or where the
error was).
Another point eased by restricting to releases, not snapshots, pushed
upstream to consumers of your project. :)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com