> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: lundi 24 octobre 2005 21:03
> To: Maven Developers List
> Subject: Re: [M2][Proposal] J2EE builds best practices and conventions
>
> Vincent Massol wrote:
> > I've used Maven in the past to do that and it worked very well. I'd like
> to
> > understand better what alternatives you're suggesting?
> >
> > Note for versioning: we have that by storing the config in the SCM.
> >
> > I'm curious to know which tool you're using in the J2EE space for doing
> > "versioning and deployment". I don't know any.
>
> My point was similar to Steve's. Yes, we can provide tools to help, but
> I don't see us coming up with the grand unified theory of configuration
> management. We used to store our configs in SCM and have some simple
> server side tools (that a deployer could use, as developers certainly
> weren't getting up in the middle of the night for releases :)
Sure...
My personal strategy has always been the following:
- automate as much as possible along the course of the project (improve
automation release after release) so that you can automated everything from
code to installation and deployment.
- take into the account the different environments (I usually have 2 or 3:
development, demo or integration and pre-production) in order to generate
distributions as usable as possible.
- for the development and demo/integration environments it's usually the
development team that manages it so no issue.
- for the pre-production environment, I just hand our distribution to the
production team and they do whatever they want with it. They use their own
tools to do deployment, they repackage everything, etc. We do try to work in
harmony so that we invite them into the development team ahead of putting
the application in production so that they tell us their needs and we
implement that in the build to get it as close as what they need.
Now I have seen the case where the production team is interested by the
tools we use for building the system and they have agreed to themselves use
Maven to build the system. What I haven't seen yet is the case where the
production team uses a tool like smartfrog. I'm curious to see what becomes
the contract between the development team and the production team. What do
they take from the development team in that case? Just simple and
non-configured EARs? Do smartfrog config files get committed to the SCM and
extend to the development and demo/integration environments so that only one
solution is used for configuration/deployment?
[snip]
> >>>* support automated functional tests execution
> >>
> >>Cactus, right? :)
> >
> >
> > Nope. Cargo :-)
>
> But cargo isn't doing the actual testing, its just starting and stopping
> the server and setting up the environment. What do you use for the
> testing aspect?
JUnit, TestNG, HttpUnit, Canoo, Abbot, whatever testing framework you want
to use. Cactus can be used too of course. Cargo's strengths is its ability
to perform integration tests that would be complex to do using a black box
strategy.
[snip]
> > The extra jars directories (ejbs/, ears/, etc) are not really required.
> They
> > may be required if you have a big applications with lots of ejbs, wars,
> etc.
> > I'm not recommending a fixed structure with this additional directory
> level.
> > I'm just saying it can exist.
>
> Well, anything can exist, I'm just not sure we'd recommend that layout
> (which is what I thought this was :)
It is... but there are parts for which we can't recommend a structure for as
it's too dependent on the system being built.
Here's an example of the directory structure that I would have used for a
past project:
<project>/
|_ components/
|_ businessServer/ (components for an EAR app)
|_ partners/ (ejb)
|_ clearing/ (ejb)
|_ positions/ (ejb)
|_ referenceData/ (ejb)
|_ [...]
|_ businessServer/ (ear)
|_ client/ (components for a swing app)
|_ partners/ (ejb)
|_ clearing/ (ejb)
|_ positions/ (ejb)
|_ referenceData/ (ejb)
|_ [...]
|_ client/ (jar containing the main() method)
|_ eai/
|_ migration/
|_ [...]
|_ applications/
|_ [...]
|_ system/
As you can see the top level structure is the same as the one proposed but
the nested components/ projects do not follow a specific pattern that we
could propose. BTW I personally prefer naming components with functional
names rather than ejb, jar, ear, etc. But it's hard to do so for a generic
archetype... :-)
> > I'm not sure what this is about?
> >
> > In any case a nested directory structure such as:
> >
> > ear/
> > |_ war/
> > |_ jar1/
> > |_ ejb/
> > |_ jar2/
> >
> > Wouldn't really work, as J2EE modules are created by composition and not
> by
> > inheritance.
> >
> > I don't know if you're referring to this or not.
>
> Yes, this is what I was referring to. I see this as composition with the
> ear as the end result. I understand that the jars might go directly in
> the EAR though and so be at the same level.
>
> I'm not certain of the cirucmstances under which either would be needed,
> and I'm happy to have the ear as a sibling to the others, I just
> remembered the aggregation alternative had been discussed.
Yep. There was a short discussion and we've also discussed it with Jason. It
can probably be done in some special cases but I wouldn't see it as a
general solution. I'll still mention it.
> > Note: I've also tried some other solution. One of them was to have a
> > configuration module in charge of generating the configuration for a
> given
> > server and a given environment. A centralized configuration. It didn't
> work
> > too well. It was too hard to keep it centralized. We didn't use any
> tool. We
> > built our solution based on templates/velocity. I've had better success
> with
> > a distributed configuration approach where each module is in charge of
> > generating its configuration per environment. But I'm interested in
> other
> > people's feedback on this!
>
> Yes, I agree with this approach too. About the only time centralised
> configuration might make sense is if you are talking about application
> configuration via LDAP or a database, for example.
>
> Overall sounds pretty good, I'd probably understand more from seeing it
> in action and fine tuning it by tinkering with it and oing through the
> process of doing deployments, etc.
Thanks for you feedback
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
