2:55 p.m.
If the client is in the same .jar, then it's natural to have a single
project.
For two .jar's, I would go with multiple Maven modules:
1) As stated already, the XML verbosity is roughly the same, complexity
slightly less.
2) With multiple modules, it's much easier to control what happens
during various build phases.
So it could be used to run the client.
qs-foo
qs-foo-ejb
...
...
deploy -> Deploys to server
qs-foo-client
...
...
deploy -> Calls the deployed EJB (e.g. by bound Surefire execution)
3) Most importantly - it's meant to be an example of best practices.
For a tiny project like a quickstart, it doesn't make much sense,
but I believe the best practice for real world is to have EJB and client
split.
If we do it easier to maintain for us, users will likely have to
split anyway.
my2c.
Ondra
On 01/16/2013 06:06 PM, Darran Lofthouse wrote:
On 01/16/2013 04:49 PM, Pete Muir wrote:
> Often people are writing eg. an application client or a java se program that is going
to call into the AS via JNDI, this is what we have to date. If you are thinking of
something else, another structure may be better, indeed!
In this case it is just a Java SE class making the call to an EJB so I
think the single project structure is going to be sufficient.
> On 16 Jan 2013, at 16:47, Darran Lofthouse wrote:
>
>> On 01/16/2013 04:38 PM, Pete Muir wrote:
>>> On 16 Jan 2013, at 16:18, Darran Lofthouse wrote:
>>>
>>>> On 01/16/2013 04:14 PM, Pete Muir wrote:
>>>>> Mostly, we've split the two projects, to keep the maven bit
simple, but there isn't a hard rule here.
>>>> I have to say I don't really see a simplicity gain in having multiple
projects - the only thing possibly a little more complex in a single project is that some
artefacts are now set with a scope of runtime although for a project deploying a jar they
probably don't need a scope setting at all.
>>>>
>>>> For the multi artefact approach we end up with three poms that need to be
maintained together.
>>> Maven is designed to produce one artifact per project, not multiple artifacts
per project. You need to introduce quite a lot of xml to produce multiple artifacts. The
LOC of Maven is definitely higher with three projects, but a lot is identical, so that
doesn't increase the complexity - in fact, most of the xml is the same as what is in
other projects so even simpler.
>>>
>>> BTW the maven guidelines are for one artifact per maven project.
>> For this scenario there is only one artefact which is the jar that is deployed to
the server - the executable client also lives within this artefact.
>>
>> If I was developing an EJB deployment that was going to be called by say a
separate war then I would agree that two projects are needed as a jar and a war need to be
produced.
_______________________________________________
jdf-dev mailing list
jdf-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jdf-dev