You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Florin Vancea <fv...@maxiq.ro> on 2003/04/16 15:00:18 UTC
JBoss plugin - jboss:configure
Maybe I'm missing something here, but what's the idea behind creating that
ZIP distributable in jboss:configure ?
Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 16 April 2003 17:07
> To: Maven Developers List
> Subject: Re: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
> First of all, thanks for the elaborate reply.
>
> Now some thoughts (please excuse any clumsiness) :
>
> When running the jboss:package-ear goal, jboss:configure produces the
ZIP
> _before_ and the EAR is put in the deploy subdir only after that, thus
it
> does not make it in the ZIP. Is this the intended behavior?
Nope, it's called a bug!
>
> Furthermore, this is Ant-oriented. I can see how you can maintain the
> globalproject in CVS. I can also see how you can use CVS's "modules"
> feature
> to create "fake" globalprojects while keeping the modules under
> "development" in a single place and promoting reuse.
> What I'm really interested in is how do you plan to map this structure
> through Maven's dependency concept. From what I understood from your
> explanation, the dependencies are locally managed within build.xml
files
> but
> Maven promotes the repository concept.
No issues there (BTW, it is also Maven oriented). It's actually quite
easy (if I understand the question correctly). The development projects
have dependencies on external libraries (like log4j, etc) and other
development projects (like a home made framework, etc). Dependencies are
listed of course in each project's project.xml.
Note that EJB-JAR projects use the tagged properties for correctly
generating the Class-Path in the Manifest.
The environment/applications projects also have dependencies (tagged
with ear.bundle.jar and ear.bundle.ejb). The environment/nodes projects
have zipped dependencies (produced by the environment/applications
projects).
We have a continuous build running on a server that builds all the
projects (every 2 hours) and the deliverables of each project are
deployed on our remote repository. And all our versions are SNAPSHOTs
versions.
>
> Another issue I'm curious about: What's your approach on
container-testing
> _the_modules_? Let's say cactus is used: The test harness for a
particular
> module should be a mini-application in itself, shouldn't it?
Furthermore,
> it's significantly different from the "production" config of the same
> module. How is this handled?
The development/ projects only contain unit tests that do NOT depend on
the environment (using mock objects when needed to isolate the tests).
Integration unit tests and functional unit tests need an environment and
thus are run in the applications/ projects.
>
> Sorry if I ask so many questions; I'm only glad I have the opportunity
to
> discuss some issues that are bothering me and learn something in the
> process.
No problem. Actually that's good practice for my upcoming talk for the
TheServerSide symposium (which will be exactly on this subject of using
Maven/Cactus to build/test complex J2EE projects).
Thanks
-Vincent
>
> Thanks,
> Florin
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pivolis.com>
> To: "'Maven Developers List'" <de...@maven.apache.org>
> Sent: Wednesday, April 16, 2003 5:04 PM
> Subject: Ideas for Packaging applications/full systems (was RE: JBoss
> plugin - jboss:configure)
>
>
> > Florin,
> >
> > This is to support deployments/configuration of jboss applications.
The
> > idea is the following. Imagine a directory structure such as:
> >
> > myglobalproject/
> > development/
> > project-ejb-jar-1/
> > project-ejb-jar-2/
> > project-ejb-war-1/
> > environment/
> > applications/
> > project-application-1/
> > conf/
> > development/
> > integration/
> > demo/
> > pre-production/
> > share/
> > [...]
> > project-application-2/
> > [...]
> > nodes/
> > project-node-1/
> > project-node-2/
> > [...]
> >
> > where:
> >
> > - the projects in myglobalproject/development/ only produces
> > libraries/modules independent of the environment in which they run.
For
> > J2EE applications that's J2EE modules.
> >
> > - the projects in myglobalproject/environment have configurations
> > dependent upon the environment of execution. Examples of
environments
> > are: development platform, automated build platform, integration
> > platform, demo platform, pre-production platform, etc.
> >
> > - the projects in myglobalproject/environment/applications/ are the
> > applications of the myglobalproject project. For J2EE applications
they
> > are EARs. They depends on the projects from
> > myglobalproject/development/. These application projects not only
> > generate an EAR but more importantly they generate a *valid*
packaged
> > application = EAR + container configuration files + application
> > configuration files (those that are not in the EAR). This
application is
> > the zip that jboss:configure generates.
> >
> > - the projects in myglobalproject/environment/nodes/ are packages
list
> > of application that run on a specific node type. Examples of nodes
are:
> > database node, business server node, gui node, simulation node,
admin
> > node, etc. A node is a machine type (there can be several in a
cluster
> > for example). For example, I usually use the following node
directory
> > structure that I package as a zip (but it can be packaged using any
> > installer format):
> >
> > <node name>-<version>/
> > |_ bin/
> > |_ [script to start/stop all applications + other]
> > |_ <application name>/
> > |_ logs/
> > |_ <application name>/
> >
> > where:
> >
> > - <application name>/ contains the result of
> > myglobalproject/environment/applications/ (but unzipped).
> >
> > Note: the logs is in a separate directory so that it can be
symlinked to
> > another physical disk for example and to make it easy to find all
logs.
> >
> > Then you can have a master build.xml which runs all the node builds
(I
> > could have myglobalproject/environment/platform/ projects which
contains
> > all the nodes for a given platform (platform = development, demo,
> > production, etc), but I have not found what these projects would do.
> > Maybe generate automated installation for automated installation of
the
> > different nodes on a given plastform?). I have not been that far
yet...
> > but I am interested in hearing from others! :-)
> >
> > Thus a given platform is made of:
> > - prerequisite software to be installed on the different machines
(app
> > server, database, EAI tools, etc)
> > - the nodes delivered by the myglobalproject/environment/nodes/
> > projects.
> >
> > Is it more clear? I fear I have blurred even further the initial
> > question ;-)).
> >
> > Thanks
> > -Vincent
> >
> > PS: I have implemented this strategy on a previous project using Ant
and
> > it has worked liked a charm. I am not implementing it again on a new
> > project but this time using Maven.
> >
> > > -----Original Message-----
> > > From: Florin Vancea [mailto:fvancea@maxiq.ro]
> > > Sent: 16 April 2003 15:00
> > > To: Maven Developers List
> > > Subject: JBoss plugin - jboss:configure
> > >
> > > Maybe I'm missing something here, but what's the idea behind
creating
> > that
> > > ZIP distributable in jboss:configure ?
> > >
> > >
> > > Florin
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 17 April 2003 11:56
> To: Maven Developers List
> Subject: Re: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
[snip]
> > No cluttering at all! All our projects inherit from a master
project.xml
> > which defines the version as 1.0-SNAPSHOT for the 1.0 production
> > version. Thus there is always a fixed number of jar artifacts in the
> > repo.
>
> Yes! This _is_ a cool thing to do. Never thought about it. May I
"steal"
> the
> tip?
Sure :-)
>
> One more thing: when developing, do you go all the way to the remote
> repository and deploy a new snapshot, or this is the job of the
automated
> build?
It's the goal of the automated build to deploy the artifacts to the
remote repo.
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Florin Vancea <fv...@maxiq.ro>.
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Maven Developers List'" <de...@maven.apache.org>
Sent: Thursday, April 17, 2003 10:43 AM
Subject: RE: Ideas for Packaging applications/full systems (was RE: JBoss
plugin - jboss:configure)
> <snip>
>
> However, as you say, it would be better if a merge was performed. That
> is actually not impossible... On the cactus project we have implemented
> exactly this for merging web.xml files. The same strategy can be used to
> merge ejb-jar.xml and made a jelly task for example which can then be
> used in a new goal of the Maven ejb plugin (ejb:merge-dd).
Now _that_ would be cool. I was contemplating the idea, but I postponed it
because I don't have a real need for it now. However, as you say, it'll
come...
>
> I don't know what <alt-dd> is (I'm offline in the train right now and I
> can't google it... Sorry, no GPRS on me... ;-)).
Less that I am wrong, it's the tag in application.xml that specifies the
override dd file for each module. I presume you overwrite the original when
repackaging, then.
> <snip>
>
> > 3. Is there any way to enforce the consistency of assembly configs
> across
> > platforms? I am thinking about versions, layout and such, between
> > development/auto-build/demo/production. Without that I suspect one can
> > easily end up with functional auto-builds but bad production packs.
>
> Not sure I get it. There are 2 solutions I have experimented:
>
> 1/ Have a share/ directory in applications/<myapp>/conf/ and use Ant
> filters and Ant properties to make the config files generic between
> configurations.
>
> 2/ Create yet another project (we called it Babylon in my previous work
> project) whose goal is to generate config files for a given environment.
> The idea is to save all platform definitions in XML files (machines IP,
> names, app server configs, etc, all is stored in an XML repository).
> Then, we wrapped Babylon with a Maven plugin which could be used like
> this:
>
> maven babylon:generate -Denv.name=demo -Dconfig.file=<config file id>
>
> In term of implementation we were using XSLT and had <config file
> id>.xslt files which were using the global XML definition files to
> generate the required config files.
I like 2/ better...
>
> > 4. Any issues with cluttering the repositories with snapshot-versioned
> > artifacts? At a 2 hour interval you get some.... Do you have a "delete
> > old"
> > policy or the like?
> >
>
> No cluttering at all! All our projects inherit from a master project.xml
> which defines the version as 1.0-SNAPSHOT for the 1.0 production
> version. Thus there is always a fixed number of jar artifacts in the
> repo.
Yes! This _is_ a cool thing to do. Never thought about it. May I "steal" the
tip?
One more thing: when developing, do you go all the way to the remote
repository and deploy a new snapshot, or this is the job of the automated
build?
>
> <snip>
> >
> > So I understand that the EJB's in the development/ modules never get
> > tested
> > (since they need a container) until the integration/functional testing
> > phase?
>
> Not completely true. All business logic gets tested using Mock Objects
> (<plug>check my upcoming book on junit -- not published yet, for how to
> do that</plug>). Also you can easily test using pure junit tests all
> classes not using the J2EE API (there should be quite a few).
>
> However, you are right, we run cactus tests in the application/ project
> (but that gets run every 2 hours).
Then I understand that things like transaction and concurrency get to be
checked only quite late in the process, even if they are testable within a
single module. Isn't it a real pain to whip the whole pack each time you
want to test a change while e.g. debugging transactions?
>
> Not sure if they'll make the session available. The link is
> http://www.theserverside.com/symposium/
>
Then _after_ the event is over, may I ask you for a copy ? Of course, within
any legal constraints.
Thank you,
Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 17 April 2003 07:54
> To: Maven Developers List
> Subject: Re: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pivolis.com>
> To: "'Maven Developers List'" <de...@maven.apache.org>
> Sent: Wednesday, April 16, 2003 8:45 PM
> Subject: RE: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
>
> >
> > <snip>
> >
> > No issues there (BTW, it is also Maven oriented). It's actually
quite
> > easy (if I understand the question correctly). The development
projects
> > have dependencies on external libraries (like log4j, etc) and other
> > development projects (like a home made framework, etc). Dependencies
are
> > listed of course in each project's project.xml.
> >
> > Note that EJB-JAR projects use the tagged properties for correctly
> > generating the Class-Path in the Manifest.
> >
> > The environment/applications projects also have dependencies (tagged
> > with ear.bundle.jar and ear.bundle.ejb). The environment/nodes
projects
> > have zipped dependencies (produced by the environment/applications
> > projects).
> >
> > We have a continuous build running on a server that builds all the
> > projects (every 2 hours) and the deliverables of each project are
> > deployed on our remote repository. And all our versions are
SNAPSHOTs
> > versions.
>
> I see now.
> Some more:
> 1. Do you repackage a new version of ejb-jar.xml when building the
> applications/ projects? Do you use the <alt-dd> instead?
We haven't had a need yet to modify the dd generated by the development/
projects for deployment. However, that will come. Our strategy for now
(which can certainly be improved) is that development/ projects produce
default dd (actually the dd used for the development platform) and that
the applications/ projects are allowed to override them. Now WRT the
overriding part, the simplest implementation is simply by replacing the
dd with a new one locates in applications/<appproject>/conf/<environment
name>/new-ejb-jar.xml (for example).
However, as you say, it would be better if a merge was performed. That
is actually not impossible... On the cactus project we have implemented
exactly this for merging web.xml files. The same strategy can be used to
merge ejb-jar.xml and made a jelly task for example which can then be
used in a new goal of the Maven ejb plugin (ejb:merge-dd).
I don't know what <alt-dd> is (I'm offline in the train right now and I
can't google it... Sorry, no GPRS on me... ;-)).
> 2. Changes in descriptors like ejb-jar.xml from the development/
modules
> are
> propagated by hand or (smi) automatically into the application/
section?
See above.
> 3. Is there any way to enforce the consistency of assembly configs
across
> platforms? I am thinking about versions, layout and such, between
> development/auto-build/demo/production. Without that I suspect one can
> easily end up with functional auto-builds but bad production packs.
Not sure I get it. There are 2 solutions I have experimented:
1/ Have a share/ directory in applications/<myapp>/conf/ and use Ant
filters and Ant properties to make the config files generic between
configurations.
2/ Create yet another project (we called it Babylon in my previous work
project) whose goal is to generate config files for a given environment.
The idea is to save all platform definitions in XML files (machines IP,
names, app server configs, etc, all is stored in an XML repository).
Then, we wrapped Babylon with a Maven plugin which could be used like
this:
maven babylon:generate -Denv.name=demo -Dconfig.file=<config file id>
In term of implementation we were using XSLT and had <config file
id>.xslt files which were using the global XML definition files to
generate the required config files.
> 4. Any issues with cluttering the repositories with snapshot-versioned
> artifacts? At a 2 hour interval you get some.... Do you have a "delete
> old"
> policy or the like?
>
No cluttering at all! All our projects inherit from a master project.xml
which defines the version as 1.0-SNAPSHOT for the 1.0 production
version. Thus there is always a fixed number of jar artifacts in the
repo.
> >
> > >
> > > Another issue I'm curious about: What's your approach on
> > container-testing
> > > _the_modules_? Let's say cactus is used: The test harness for a
> > particular
> > > module should be a mini-application in itself, shouldn't it?
> > Furthermore,
> > > it's significantly different from the "production" config of the
same
> > > module. How is this handled?
> >
> > The development/ projects only contain unit tests that do NOT depend
on
> > the environment (using mock objects when needed to isolate the
tests).
> >
> > Integration unit tests and functional unit tests need an environment
and
> > thus are run in the applications/ projects.
>
> So I understand that the EJB's in the development/ modules never get
> tested
> (since they need a container) until the integration/functional testing
> phase?
Not completely true. All business logic gets tested using Mock Objects
(<plug>check my upcoming book on junit -- not published yet, for how to
do that</plug>). Also you can easily test using pure junit tests all
classes not using the J2EE API (there should be quite a few).
However, you are right, we run cactus tests in the application/ project
(but that gets run every 2 hours).
>
> >
> > >
> > > Sorry if I ask so many questions; I'm only glad I have the
opportunity
> > to
> > > discuss some issues that are bothering me and learn something in
the
> > > process.
> >
> > No problem. Actually that's good practice for my upcoming talk for
the
> > TheServerSide symposium (which will be exactly on this subject of
using
> > Maven/Cactus to build/test complex J2EE projects).
>
> I doubt I'd be able to attend, but I would really like to hear what's
> happening there. Any Web links?
Not sure if they'll make the session available. The link is
http://www.theserverside.com/symposium/
-Vincent
>
> Thanks,
> Florin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Florin Vancea <fv...@maxiq.ro>.
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Maven Developers List'" <de...@maven.apache.org>
Sent: Wednesday, April 16, 2003 8:45 PM
Subject: RE: Ideas for Packaging applications/full systems (was RE: JBoss
plugin - jboss:configure)
>
> <snip>
>
> No issues there (BTW, it is also Maven oriented). It's actually quite
> easy (if I understand the question correctly). The development projects
> have dependencies on external libraries (like log4j, etc) and other
> development projects (like a home made framework, etc). Dependencies are
> listed of course in each project's project.xml.
>
> Note that EJB-JAR projects use the tagged properties for correctly
> generating the Class-Path in the Manifest.
>
> The environment/applications projects also have dependencies (tagged
> with ear.bundle.jar and ear.bundle.ejb). The environment/nodes projects
> have zipped dependencies (produced by the environment/applications
> projects).
>
> We have a continuous build running on a server that builds all the
> projects (every 2 hours) and the deliverables of each project are
> deployed on our remote repository. And all our versions are SNAPSHOTs
> versions.
I see now.
Some more:
1. Do you repackage a new version of ejb-jar.xml when building the
applications/ projects? Do you use the <alt-dd> instead?
2. Changes in descriptors like ejb-jar.xml from the development/ modules are
propagated by hand or (smi) automatically into the application/ section?
3. Is there any way to enforce the consistency of assembly configs across
platforms? I am thinking about versions, layout and such, between
development/auto-build/demo/production. Without that I suspect one can
easily end up with functional auto-builds but bad production packs.
4. Any issues with cluttering the repositories with snapshot-versioned
artifacts? At a 2 hour interval you get some.... Do you have a "delete old"
policy or the like?
>
> >
> > Another issue I'm curious about: What's your approach on
> container-testing
> > _the_modules_? Let's say cactus is used: The test harness for a
> particular
> > module should be a mini-application in itself, shouldn't it?
> Furthermore,
> > it's significantly different from the "production" config of the same
> > module. How is this handled?
>
> The development/ projects only contain unit tests that do NOT depend on
> the environment (using mock objects when needed to isolate the tests).
>
> Integration unit tests and functional unit tests need an environment and
> thus are run in the applications/ projects.
So I understand that the EJB's in the development/ modules never get tested
(since they need a container) until the integration/functional testing
phase?
>
> >
> > Sorry if I ask so many questions; I'm only glad I have the opportunity
> to
> > discuss some issues that are bothering me and learn something in the
> > process.
>
> No problem. Actually that's good practice for my upcoming talk for the
> TheServerSide symposium (which will be exactly on this subject of using
> Maven/Cactus to build/test complex J2EE projects).
I doubt I'd be able to attend, but I would really like to hear what's
happening there. Any Web links?
Thanks,
Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 16 April 2003 17:07
> To: Maven Developers List
> Subject: Re: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
> First of all, thanks for the elaborate reply.
>
> Now some thoughts (please excuse any clumsiness) :
>
> When running the jboss:package-ear goal, jboss:configure produces the
ZIP
> _before_ and the EAR is put in the deploy subdir only after that, thus
it
> does not make it in the ZIP. Is this the intended behavior?
Nope, it's called a bug!
>
> Furthermore, this is Ant-oriented. I can see how you can maintain the
> globalproject in CVS. I can also see how you can use CVS's "modules"
> feature
> to create "fake" globalprojects while keeping the modules under
> "development" in a single place and promoting reuse.
> What I'm really interested in is how do you plan to map this structure
> through Maven's dependency concept. From what I understood from your
> explanation, the dependencies are locally managed within build.xml
files
> but
> Maven promotes the repository concept.
No issues there (BTW, it is also Maven oriented). It's actually quite
easy (if I understand the question correctly). The development projects
have dependencies on external libraries (like log4j, etc) and other
development projects (like a home made framework, etc). Dependencies are
listed of course in each project's project.xml.
Note that EJB-JAR projects use the tagged properties for correctly
generating the Class-Path in the Manifest.
The environment/applications projects also have dependencies (tagged
with ear.bundle.jar and ear.bundle.ejb). The environment/nodes projects
have zipped dependencies (produced by the environment/applications
projects).
We have a continuous build running on a server that builds all the
projects (every 2 hours) and the deliverables of each project are
deployed on our remote repository. And all our versions are SNAPSHOTs
versions.
>
> Another issue I'm curious about: What's your approach on
container-testing
> _the_modules_? Let's say cactus is used: The test harness for a
particular
> module should be a mini-application in itself, shouldn't it?
Furthermore,
> it's significantly different from the "production" config of the same
> module. How is this handled?
The development/ projects only contain unit tests that do NOT depend on
the environment (using mock objects when needed to isolate the tests).
Integration unit tests and functional unit tests need an environment and
thus are run in the applications/ projects.
>
> Sorry if I ask so many questions; I'm only glad I have the opportunity
to
> discuss some issues that are bothering me and learn something in the
> process.
No problem. Actually that's good practice for my upcoming talk for the
TheServerSide symposium (which will be exactly on this subject of using
Maven/Cactus to build/test complex J2EE projects).
Thanks
-Vincent
>
> Thanks,
> Florin
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pivolis.com>
> To: "'Maven Developers List'" <de...@maven.apache.org>
> Sent: Wednesday, April 16, 2003 5:04 PM
> Subject: Ideas for Packaging applications/full systems (was RE: JBoss
> plugin - jboss:configure)
>
>
> > Florin,
> >
> > This is to support deployments/configuration of jboss applications.
The
> > idea is the following. Imagine a directory structure such as:
> >
> > myglobalproject/
> > development/
> > project-ejb-jar-1/
> > project-ejb-jar-2/
> > project-ejb-war-1/
> > environment/
> > applications/
> > project-application-1/
> > conf/
> > development/
> > integration/
> > demo/
> > pre-production/
> > share/
> > [...]
> > project-application-2/
> > [...]
> > nodes/
> > project-node-1/
> > project-node-2/
> > [...]
> >
> > where:
> >
> > - the projects in myglobalproject/development/ only produces
> > libraries/modules independent of the environment in which they run.
For
> > J2EE applications that's J2EE modules.
> >
> > - the projects in myglobalproject/environment have configurations
> > dependent upon the environment of execution. Examples of
environments
> > are: development platform, automated build platform, integration
> > platform, demo platform, pre-production platform, etc.
> >
> > - the projects in myglobalproject/environment/applications/ are the
> > applications of the myglobalproject project. For J2EE applications
they
> > are EARs. They depends on the projects from
> > myglobalproject/development/. These application projects not only
> > generate an EAR but more importantly they generate a *valid*
packaged
> > application = EAR + container configuration files + application
> > configuration files (those that are not in the EAR). This
application is
> > the zip that jboss:configure generates.
> >
> > - the projects in myglobalproject/environment/nodes/ are packages
list
> > of application that run on a specific node type. Examples of nodes
are:
> > database node, business server node, gui node, simulation node,
admin
> > node, etc. A node is a machine type (there can be several in a
cluster
> > for example). For example, I usually use the following node
directory
> > structure that I package as a zip (but it can be packaged using any
> > installer format):
> >
> > <node name>-<version>/
> > |_ bin/
> > |_ [script to start/stop all applications + other]
> > |_ <application name>/
> > |_ logs/
> > |_ <application name>/
> >
> > where:
> >
> > - <application name>/ contains the result of
> > myglobalproject/environment/applications/ (but unzipped).
> >
> > Note: the logs is in a separate directory so that it can be
symlinked to
> > another physical disk for example and to make it easy to find all
logs.
> >
> > Then you can have a master build.xml which runs all the node builds
(I
> > could have myglobalproject/environment/platform/ projects which
contains
> > all the nodes for a given platform (platform = development, demo,
> > production, etc), but I have not found what these projects would do.
> > Maybe generate automated installation for automated installation of
the
> > different nodes on a given plastform?). I have not been that far
yet...
> > but I am interested in hearing from others! :-)
> >
> > Thus a given platform is made of:
> > - prerequisite software to be installed on the different machines
(app
> > server, database, EAI tools, etc)
> > - the nodes delivered by the myglobalproject/environment/nodes/
> > projects.
> >
> > Is it more clear? I fear I have blurred even further the initial
> > question ;-)).
> >
> > Thanks
> > -Vincent
> >
> > PS: I have implemented this strategy on a previous project using Ant
and
> > it has worked liked a charm. I am not implementing it again on a new
> > project but this time using Maven.
> >
> > > -----Original Message-----
> > > From: Florin Vancea [mailto:fvancea@maxiq.ro]
> > > Sent: 16 April 2003 15:00
> > > To: Maven Developers List
> > > Subject: JBoss plugin - jboss:configure
> > >
> > > Maybe I'm missing something here, but what's the idea behind
creating
> > that
> > > ZIP distributable in jboss:configure ?
> > >
> > >
> > > Florin
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: 16 April 2003 23:58
> To: 'Maven Developers List'
> Subject: RE: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
>
>
> > -----Original Message-----
> > From: Florin Vancea [mailto:fvancea@maxiq.ro]
> > Sent: 16 April 2003 17:07
> > To: Maven Developers List
> > Subject: Re: Ideas for Packaging applications/full systems (was RE:
> JBoss
> > plugin - jboss:configure)
> >
> > First of all, thanks for the elaborate reply.
> >
> > Now some thoughts (please excuse any clumsiness) :
> >
> > When running the jboss:package-ear goal, jboss:configure produces
the
> ZIP
> > _before_ and the EAR is put in the deploy subdir only after that,
thus
> it
> > does not make it in the ZIP. Is this the intended behavior?
> >
>
> now fixed in CVS.
I have some problems checking in... will do that tomorrow... sorry.
-Vincent
>
> [snip]
>
> Thanks
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 16 April 2003 17:07
> To: Maven Developers List
> Subject: Re: Ideas for Packaging applications/full systems (was RE:
JBoss
> plugin - jboss:configure)
>
> First of all, thanks for the elaborate reply.
>
> Now some thoughts (please excuse any clumsiness) :
>
> When running the jboss:package-ear goal, jboss:configure produces the
ZIP
> _before_ and the EAR is put in the deploy subdir only after that, thus
it
> does not make it in the ZIP. Is this the intended behavior?
>
now fixed in CVS.
[snip]
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Florin Vancea <fv...@maxiq.ro>.
First of all, thanks for the elaborate reply.
Now some thoughts (please excuse any clumsiness) :
When running the jboss:package-ear goal, jboss:configure produces the ZIP
_before_ and the EAR is put in the deploy subdir only after that, thus it
does not make it in the ZIP. Is this the intended behavior?
Furthermore, this is Ant-oriented. I can see how you can maintain the
globalproject in CVS. I can also see how you can use CVS's "modules" feature
to create "fake" globalprojects while keeping the modules under
"development" in a single place and promoting reuse.
What I'm really interested in is how do you plan to map this structure
through Maven's dependency concept. From what I understood from your
explanation, the dependencies are locally managed within build.xml files but
Maven promotes the repository concept.
Another issue I'm curious about: What's your approach on container-testing
_the_modules_? Let's say cactus is used: The test harness for a particular
module should be a mini-application in itself, shouldn't it? Furthermore,
it's significantly different from the "production" config of the same
module. How is this handled?
Sorry if I ask so many questions; I'm only glad I have the opportunity to
discuss some issues that are bothering me and learn something in the
process.
Thanks,
Florin
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Maven Developers List'" <de...@maven.apache.org>
Sent: Wednesday, April 16, 2003 5:04 PM
Subject: Ideas for Packaging applications/full systems (was RE: JBoss
plugin - jboss:configure)
> Florin,
>
> This is to support deployments/configuration of jboss applications. The
> idea is the following. Imagine a directory structure such as:
>
> myglobalproject/
> development/
> project-ejb-jar-1/
> project-ejb-jar-2/
> project-ejb-war-1/
> environment/
> applications/
> project-application-1/
> conf/
> development/
> integration/
> demo/
> pre-production/
> share/
> [...]
> project-application-2/
> [...]
> nodes/
> project-node-1/
> project-node-2/
> [...]
>
> where:
>
> - the projects in myglobalproject/development/ only produces
> libraries/modules independent of the environment in which they run. For
> J2EE applications that's J2EE modules.
>
> - the projects in myglobalproject/environment have configurations
> dependent upon the environment of execution. Examples of environments
> are: development platform, automated build platform, integration
> platform, demo platform, pre-production platform, etc.
>
> - the projects in myglobalproject/environment/applications/ are the
> applications of the myglobalproject project. For J2EE applications they
> are EARs. They depends on the projects from
> myglobalproject/development/. These application projects not only
> generate an EAR but more importantly they generate a *valid* packaged
> application = EAR + container configuration files + application
> configuration files (those that are not in the EAR). This application is
> the zip that jboss:configure generates.
>
> - the projects in myglobalproject/environment/nodes/ are packages list
> of application that run on a specific node type. Examples of nodes are:
> database node, business server node, gui node, simulation node, admin
> node, etc. A node is a machine type (there can be several in a cluster
> for example). For example, I usually use the following node directory
> structure that I package as a zip (but it can be packaged using any
> installer format):
>
> <node name>-<version>/
> |_ bin/
> |_ [script to start/stop all applications + other]
> |_ <application name>/
> |_ logs/
> |_ <application name>/
>
> where:
>
> - <application name>/ contains the result of
> myglobalproject/environment/applications/ (but unzipped).
>
> Note: the logs is in a separate directory so that it can be symlinked to
> another physical disk for example and to make it easy to find all logs.
>
> Then you can have a master build.xml which runs all the node builds (I
> could have myglobalproject/environment/platform/ projects which contains
> all the nodes for a given platform (platform = development, demo,
> production, etc), but I have not found what these projects would do.
> Maybe generate automated installation for automated installation of the
> different nodes on a given plastform?). I have not been that far yet...
> but I am interested in hearing from others! :-)
>
> Thus a given platform is made of:
> - prerequisite software to be installed on the different machines (app
> server, database, EAI tools, etc)
> - the nodes delivered by the myglobalproject/environment/nodes/
> projects.
>
> Is it more clear? I fear I have blurred even further the initial
> question ;-)).
>
> Thanks
> -Vincent
>
> PS: I have implemented this strategy on a previous project using Ant and
> it has worked liked a charm. I am not implementing it again on a new
> project but this time using Maven.
>
> > -----Original Message-----
> > From: Florin Vancea [mailto:fvancea@maxiq.ro]
> > Sent: 16 April 2003 15:00
> > To: Maven Developers List
> > Subject: JBoss plugin - jboss:configure
> >
> > Maybe I'm missing something here, but what's the idea behind creating
> that
> > ZIP distributable in jboss:configure ?
> >
> >
> > Florin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Ideas for Packaging applications/full systems (was RE: JBoss plugin - jboss:configure)
Posted by Vincent Massol <vm...@pivolis.com>.
Florin,
This is to support deployments/configuration of jboss applications. The
idea is the following. Imagine a directory structure such as:
myglobalproject/
development/
project-ejb-jar-1/
project-ejb-jar-2/
project-ejb-war-1/
environment/
applications/
project-application-1/
conf/
development/
integration/
demo/
pre-production/
share/
[...]
project-application-2/
[...]
nodes/
project-node-1/
project-node-2/
[...]
where:
- the projects in myglobalproject/development/ only produces
libraries/modules independent of the environment in which they run. For
J2EE applications that's J2EE modules.
- the projects in myglobalproject/environment have configurations
dependent upon the environment of execution. Examples of environments
are: development platform, automated build platform, integration
platform, demo platform, pre-production platform, etc.
- the projects in myglobalproject/environment/applications/ are the
applications of the myglobalproject project. For J2EE applications they
are EARs. They depends on the projects from
myglobalproject/development/. These application projects not only
generate an EAR but more importantly they generate a *valid* packaged
application = EAR + container configuration files + application
configuration files (those that are not in the EAR). This application is
the zip that jboss:configure generates.
- the projects in myglobalproject/environment/nodes/ are packages list
of application that run on a specific node type. Examples of nodes are:
database node, business server node, gui node, simulation node, admin
node, etc. A node is a machine type (there can be several in a cluster
for example). For example, I usually use the following node directory
structure that I package as a zip (but it can be packaged using any
installer format):
<node name>-<version>/
|_ bin/
|_ [script to start/stop all applications + other]
|_ <application name>/
|_ logs/
|_ <application name>/
where:
- <application name>/ contains the result of
myglobalproject/environment/applications/ (but unzipped).
Note: the logs is in a separate directory so that it can be symlinked to
another physical disk for example and to make it easy to find all logs.
Then you can have a master build.xml which runs all the node builds (I
could have myglobalproject/environment/platform/ projects which contains
all the nodes for a given platform (platform = development, demo,
production, etc), but I have not found what these projects would do.
Maybe generate automated installation for automated installation of the
different nodes on a given plastform?). I have not been that far yet...
but I am interested in hearing from others! :-)
Thus a given platform is made of:
- prerequisite software to be installed on the different machines (app
server, database, EAI tools, etc)
- the nodes delivered by the myglobalproject/environment/nodes/
projects.
Is it more clear? I fear I have blurred even further the initial
question ;-)).
Thanks
-Vincent
PS: I have implemented this strategy on a previous project using Ant and
it has worked liked a charm. I am not implementing it again on a new
project but this time using Maven.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 16 April 2003 15:00
> To: Maven Developers List
> Subject: JBoss plugin - jboss:configure
>
> Maybe I'm missing something here, but what's the idea behind creating
that
> ZIP distributable in jboss:configure ?
>
>
> Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org