[jboss-as7-dev] cant get rid of jetty maven plugin - so lets mavenize JBoss Modules

[Brian Stansberry]

On 2/25/13 7:32 PM, Bill Burke wrote:
>
>
> On 2/25/2013 8:07 PM, Brian Stansberry wrote:
>>> * I'd like to change the JBoss AS distribution to use this new
>>> jboss-modules maven artifact feature.  This requires modifying
>>> module.xml creation as well as creating and distributing a local maven
>>> repository with the jars needed.
>>>
>>
>> This is a pretty big change for our distribution model, particularly for
>> doing things like shipping patches. Sounds interesting as an alternative
>> form of distribution though. It might work fine as the only form of
>> distribution, although I think we'd need to pretty thoroughly vet it
>> before making that move.
>>
>
> I agree its an idea that needs to be vetted.  But here's what a distro
> would look like:
>
> bin/
> standalone/
> modules/
> jboss-maven-repository/
>
> The interesting thing is that you can have a distro without the
> repository.  Patching would change to adding a new jar to the maven
> repository instead of the modules directory.
>

Yep. If the maven repo is "owned" by the AS installation, it seems 
pretty straightforward. If the repo is not owned (e.g. it's the user's 
standard local maven repo) then it's a problem. For example, see the 
David Jorm's comments on 
https://community.jboss.org/wiki/SingleInstallationPatching about 
disabling jars.

There's no law though that says we have to support patching no matter 
how a user configures their installation.

>
> Furthermore, since the modules/ directory wouldn't have any jars you
> move it under the profile's directory:
>
> bin/
> standalone/
>             modules/
> web-profile/
>             modules/
> soa-profile/
>             modules/
> data-profile/
>             modules/
>

Is this a core part of what you're going for, or just a further path it 
might take? This concerns me more than the rest. We don't have 
"standalone", "web-profile", "soa-profile" etc. If these are 
user-defined structures, then patching them becomes a royal pain. The 
patch tool has no clue how the patch relates to the user's installation. 
If they are structures defined by us, we'd need one for every 
permutation we offer, and that will be a very large set.

Also, it doesn't map well to domain mode, where a domain configuration 
covers multiple profiles.

> I said this in a previous email, but it doesn't make much sense to me
> why build-time, run-time, and the OS all have their own special way of
> distributing and managing java binaries.
>
>
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat