[wildfly-dev] smaller footprints

[David M. Lloyd]

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