12:22 p.m.
On 03/04/2014 08:35 AM, Bill Burke wrote:
Great work Stuart! I'm really happy somebody is taking
initiative on
this because I really think it will help a lot with Wildfly adoption.
Is it ready to use? I'm willing to try it out RIGHT NOW.
I've expressed some of these thoughts months ago when I introduced the
JBoss Modules artifact features, but here was my vision:
* maven repos would become to Wildfly as /lib /usr/local/lib directory
structures are to unix.
I'm not sure how tightly you're gripping to this metaphor, but it can
not be exactly this because the maven dependencies do not semantically
have the right dependency information to function 100% correctly at run
time, which is the point of JBoss Modules and its dependency
infrastructure in the first place.
* The JBoss Module artifact feature would become the preferred way
to
deploy Wildfly/JBoss. This would make it really easy to support
multiple versions as well as different distro's of JBoss/Wildfly on the
same machine and save huge amounts of disk space. If we could get a JVM
that could share JAR instances between processes to save on RAM, the win
would be even bigger! Think of the cloud implications!
Deploy, maybe in certain cases, but I don't think that using Maven repos
is going to be preferred in the data center case or even the cloud case.
In both cases, in any non-trivially sized environment, the systems are
generally going to be either built up by packages long before deployment
time, simply replicated in whole off an image, or built up by high-level
tooling in such a way that it doesn't really pay to "buy in" to the
Maven repository format, which would be more useful perhaps during
development. In many cases, the public Internet isn't even accessible
and a local image is necessary. I think the usefulness of Maven is
heavily, heavily overstated here.
* JBoss Module definitions could eventually be defined in one large
XML
file. We would have maven/ant plugins to help build this large XML file.
This would be a step backwards, especially if we ever want to support
third-party add-ins in a uniform manner.
* This single JBoss Module XML file could be bundled within a
JBoss/Wildfly "executable jar".
* This "executable jar" could be overlayed with external JBoss Module
XML files or directory structures.
* Finally, you could create this "executable jar" for any Java project.
I guess you're looking at it from the perspective of "every Java
application is a monolithic thing" instead of "I have an installation
which has N applications in it", which is more what my world view is.
And I have in the past, and continue to believe that build and run time
are very distinct. At build time, you have a giant, single universe of
artifacts which include versioned dependency information which is used
for build repeatability purposes. At run time, you have one or more
"environments" of selected artifacts which include versionless
dependency information, that are tested together and certified, which
can be (theoretically anyway) updated, installed, and removed
individually without rebuild (only a one-time, centralized retest in the
updates case). This is actually much closer to both the Jigsaw/MR ethos
as well as the way that UNIX-ish /lib works today, and I think is more
in line with what we want to have in the 5+ year time frame (if we
cannot manage it sooner than that).
--
- DML