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

[Brian Stansberry]

On 2/26/13 1:55 PM, Bill Burke wrote:
>
>
> 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...
>

Huh? I think all of this is really interesting and worth exploring. I've 
got the flu so maybe my responses lack enthusiasm. ;)

You said yourself the "modules/ under profile dir" thing is "a path it 
might or could take." So it doesn't sound like a showstopper to me. It's 
the only thing in this discussion that raises a big red flag for me; my 
other questions/comments are just a standard exchange of information.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat