> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 1:53 AM
> To: Maven Developers List
> Subject: Re: [M2] filter definition
>
>
> Jason van Zyl wrote:
>
> >>Here's the full URL: http://www.jconfig.org/ConfigurationServer.html
> >>
> >>
> >
> >Cool! I'll take a look and try to integrate it into what I'm making.
> >
> >
> Yeah, I think we are all on the same page now.
>
almost :)
> - Build a single archive
> - swizzle J2EE files that need to be changed for deployment,
> as part of
> the deployment process, not the build process
>
I a not 100% sure if I understand you.
What do you mean by deployment process here? Is it going to be
supported/executed in m2?
In a place where I am working we often follow the following scenario:
There is one person resposible to prepare deployment artifacts.
Some other person is verifing if everything is OK and is transfering those
artifacts to CDs which are later taken to the customer.
Alternativly they are transferd to the customer via ftp/ssh.
Third person is responsible of physical deployment of those artifacts at the
customer site. And this may happen weeks or even months after the artifacts
were prepared (built). It may also happen in the place where there is not a
chance that they will let you use any extra tool (so maven ant and such
tools are excluded).
So as you can see in my case really build process is completly seperated
from deployment process but during the deployment process we are not allowed
to change any artifacts.
As we try to deploy more and more artifacts for each customer to our
artifact repository - it makes it possible to do some cool things
and for example we are exeprimenting with incremental updates and hoping to
soon have a possibility of transfering
to the clients just very small archives which contains the files, which have
changed since the last deployment. This is possible as we know what we have
deployed (historical version are stored in the repoitory) and what we have
to deploy.
So from my experince the communication via artifact repositories (e.g. maven
repositories) and the requirment that build process on output must deploy
ready (or almost ready to use) artifacts to repositoriy(ies) realy is a key
and works quite well. This also requires that each artifact must have unique
name - so the rule one project - one artifact has to be followed. So for
example Vincent's solution:
-----------
project1
|_ src/resources
|_ env1
|_ [files or env1]
|_ envN
|_ [files or envN]
|_ shared
|_ [files shared by all envs]
|_ [...]
And then having the logic to choose the resource files based on a
env.name=env1|envN property.
----------
is not something which we can use as artifacts for different environments
will replace each other in local/remote repository.
I don't think that my scenario is the only valid one it is one and most
likely some other case (simpler or more complex) may require completely
different solutions (e.g. the one described by Jason and Vincent). But I
don't think that there is too many such cases. And I am sure there is a lot
of "private" existing m1 plugins which were never published, which support
those use cases. So it is not like we are exploring new lands - just nothing
was shared and standarized in that domain :).
best regards
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
