[wildfly-dev] smaller footprints

[Bill Burke]

On 3/4/2014 1:22 PM, David M. Lloyd wrote:
> 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.
>

I'm talking about the maven repo directory structure, not the poms! 
Being able to resolve an artifact given a base URL, artifact name, and 
version is pretty damn powerful.  Trivial, but powerful.

JBoss Modules + Maven Repo = "something better"

>> * 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.
>

I wasn't talking about using a *remote* maven repo to share disk space. 
  I was talking about a local repo.  You would install Wildfly jar 
dependencies into the OS image's local maven directory.  Then, different 
OS VMs could share the same disk space.


>> * 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.
>

I wasn't advocating one approach over another.  I'd like to be able to 
do both.  While we already have a platform that can have "N applications 
in it", we don't have a great way to bundle a "monolithic thing".  The 
ironic thing is that the users I've talked to who want the ability to 
create a "monolithic thing" are talking about applications that are at 
least 100+ meg smaller than the current Wildfly distro. :)

If Wildfly and other non-Wildfly apps used a local maven repo (or remote 
one I guess), you'd have a common cross-environment way of sharing 
dependencies on the same machine.  I'm talking more of using JBoss 
Modules as a way to create an "exeutable" for non-Wildfly applications.

> And I have in the past, and continue to believe that build and run time
> are very distinct.

And I don't think they need to be completely distinct and separate. 
Maven repo for building.  JBoss modules to bridge between the 
"versionless runtime" and the repo, to provide a logical unversioned 
view/grouping of dependencies.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com