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.