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.
On 16 Jan 2013, at 16:07, Sande Gilda wrote:
> I think all of the existing quickstarts that have separate client and server side
artifacts currently split them out with a common parent. But I will defer to Pete on which
is the best approach. :-)
>
> On 01/16/2013 10:10 AM, Darran Lofthouse wrote:
>> Hello all,
>>
>> I have a quick question that I think partly comes down to personal
>> preference so I wanted to get some feedback on other options.
>>
>> When developing a quickstart that contains a deployment and a client to
>> call the deployment is it preferable to contain this within a single
>> maven artefact or split it out with a common parent?
>>
>> As an Eclipse user provided the client is simple my preference is to
>> keep this in a single Maven artefact so when imported into Eclipse it
>> will be a single project. As a command line user I also prefer this as
>> I don't need two terminal tabs or a change of working directory to
>> switch between deploying and running the quickstart.
>>
>> There a some quickstarts that have to be split up to achieve the
>> packaging being demonstrated but I think those have a clear
>> justification for doing so.
>>
>> I understand for IntelliJ users if split with a common parent the sub
>> modules are still represented within the parent module so they don't
>> experience the three project like in Eclipse.
>>
>> So overall just looking for some feedback on which direction is preferable.
>>
>> Thanks for your time.
>>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> jdf-dev mailing list
>> jdf-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>