I'm definitely not opposed to changing the way zip is downloaded and/or
extracted. It was originally done like this to get something working as
I wasn't sure how much it was going to be used to be honest. Probably
not really a good excuse, but it's the reason :-)
I am just getting to release a new version that does have a start and
shutdown goal so they can be used in integration testing. I do wonder
though in the cases where these goals were requested why not use
Arquillian and the reason I got was basically that they added custom
modules before they run the integration test. This likely could be
achieved with either ARQ or the maven plugin by defining the JBOSS_HOME.
The maven config could get rather messy, but it would work for sure.
As far as the JBoss Modules part, that's up to David and don't quote me,
but I think he rejected something like that before. Again though that's
all up to him.
On 02/25/2013 01:18 PM, Bill Burke wrote:
JBoss AS and jboss-as-maven-plugin just doesn't meet my needs, so
I've
started the process of fixing it. I have some initial code, but I need
to know that my suggestions and pull-requests will be accepted before I
proceed with the rest of the changes I would need to make.
What missing or very hard to do:
* Jetty maven plugin is great because there is no pre-installation
needed. It builds your war, automatically downloads jetty and runs it
in embedded mode, then runs your tests (if you have maven pom configured
right). I'd like to replace this with JBoss AS....But...it is just not
feasible. jboss-as-maven-plugin does download the AS7 ZIP artifact if
jboss isn't running already, but...it unzips the zip into every maven
projects target/ directory. FOR EVERY PROJECT. So, if you have more
than one test, you are unzipping 100M+ PER PROJECT. This is just
unworkable.
* I need the above for my O'Reilly Restful Java book examples.
Currently I use Jetty and I can't replace with jboss-as-maven-plugin. I
refuse to require download/install of jboss and will just stick to jetty
if I must.
* If you are developing on a subsystem integration on AS codebase, as
you build your submodule, you need to either rebuild the distribution,
or copy the library to the built JBoss distribution. Its just a pain.
I'd like to remove this step and streamline integration module development.
* I'd like to have automated AS integration tests in the Resteasy build.
This sucks because of the previous problems. Not only is an unzip of
AS required per maven project, but I need to override resteasy speific
AS modules with the current resteasy build.
* You can't distribute a profile of a complete jboss install without
distributing *EVERY* jar it depends on.
What I'm doing to fix it:
* I've got a pull request for JBoss Modules that allows you to specific
a maven repository artifact instead of a path for a resource-root: i.e.
<resources>
<resource-root group="org.jboss.resteasy"
artifact="resteasy-jaxrs" version="3.0-beta-4"/>
<resource-root group="org.jboss.resteasy"
artifact="resteasy-client" version="3.0-beta-4"/>
</resources>
Looks in the local maven repository for the artifact, if not there,
barfs unless you've pointed a system property to a remote maven
repository. Then it will download the artifact with a nice updated
download-progress message displayed on the console window.
Here's my pull request:
https://github.com/jbossas/jboss-modules/pull/28
* 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.
* Besides the modified distro, I'd like a new maven artifact that is
just a zip of the JBoss AS directory structure and the corresponding
configuration files. No jars.
* I want to rev jboss-as-maven-plugin to take advantage of these new
features and distros. Specifically:
- Allow a src/jboss directory so that users can provide their own config
files that are overlayed on top of the config-only AS distro.
- Make config-only AS distro something you can reference as an artifact
dependency
- provide in-pom support for defining new and override modules.
I hope you can see that not only does this make development easier, but
it also opens the door define JBoss AS profiles that can easily be
exchanged and distributed.
--
James R. Perkins
JBoss by Red Hat