2:16 p.m.
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