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

[Bill Burke]

On 2/26/2013 1:17 PM, Brian Stansberry wrote:
> 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.

That's why the default would point to the distribution.

> For example, see the
> David Jorm's comments on
> https://community.jboss.org/wiki/SingleInstallationPatching about
> disabling jars.
>

David Jorm's security concern seems pretty bogus to me.  An old jar 
could be accidentally or inadvertently be used in running code?  We're 
talking about modules here. What do OS's do?  OS's definitely support 
multiple versions of a library on the same platform.

> 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?

Its a path it might take or could take.  Its like, hey I want to build a 
IDP, or roll a specific bundle of JBoss AS plus the latest/greatest 
Resteasy, or whatever...I don't have to distribute a 170M download 
anymore....

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

We have this problem already, considering AS7 hasn't had a release in 1 
year projects like Resteasy are forced to distribute a modules zip file 
that overrides the current installation.

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

Patch tool updates module.xml files (via an unzip) and

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

Ok, well, I guess its time for me to move on to something else...It was 
worth a try, unfortunate you all don't see the benefits...

Cheers.

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