On Thu, May 22, 2008 at 6:44 AM, simon <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-05-22 at 15:33 +0200, Magne Nordtveit wrote:
>> On Thu, 2008-05-22 at 15:23 +0200, simon wrote:
>> > On Thu, 2008-05-22 at 15:02 +0200, Magne Nordtveit wrote:
>> > > I'm just wondering, how do you name your artifacts in a large
>> > > multimoduled project to avoid having two modules with the same
>> > > artifact-id?
>> > >
>> > > I am thinking in the lines of project-partofgroupid-descriptivename as
>> > > artifact-id. This would make the name of the final jar files (at least
>> > > more) unique and easily identified, but it might give some long
>> > > file-names...
>> > >
>> > > I guess I'm just asking for suggestions here, or a pointer if it exists
>> > > a best-practise on it?
>> >
>> > Why not just set the groupId to something reasonable.
>> >
>> > If your company is acme.com, then the groupId should *start* with
>> > "com.acme", but you can have any arbitrary number of parts after that.
>> >
>> > And presumably your modules have structured java package names so that
>> > the classnames don't collide. So why not model the groupId after the
>> > package in which the code for each module lives?
>> >
>> > com.acme.tractor.engine
>> > com.acme.tractor.chassis
>> > com.acme.steamroller
>> >
>> > IMO, that is nicer than embedding excessive structure into the
>> > artifactId.
>> >
>> > Regards,
>> > Simon
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>> Exactly.
>>
>> But what happens when you have com.acme.tractor:common and
>> com.acme.steamroller:common if you for some reason need to have both
>> common-packages (ok, probably a bad example) as a dependency to another
>> project?
>>
>> When running, wouldn't the classpath be set too
>> "lib/common-1.0.jar:lib/common-1.0.jar"? As far as I know, its only the
>> artifactId that gets put into the actual jar-file.
>>
>> That's what i want to avoid before it happens and while our project is
>> still sub-100 modules.
>
> I don't believe that problem can happen.
>
> When you use maven to compile or run something during development, the
> classpath looks like:
> ${M2REPO}/com/acme/tractor/common/1.0/common-1.0.jar:
> ${M2REPO}/com/acme/steamroller/common/1.0/common-1.0.jar
> so no clash happens.
>
> And when you use the maven-assembly-plugin or maven-shade-plugin or use
> "war" packaging etc to build a "distribution bundle" for shipping, then
> it should detect the filename collision, and build a fully-qualified
> name for the jarfile rather than just using the short name.
>
> When things like the assembly plugin copy files out of local maven
> repository into an assembly directory, there is no requirement for them
> to keep the same filename. When a plugin deliberately discards the
> directory strucuture, it is responsible for avoiding resulting name
> clashes.
>
> Or at least I think that's how it is supposed to work.
Yes, the name collisions will not happen. Maven (or the Maven plugins,
I'm not sure which) is/are smart enough to make the file names unique.
I've been wondering about a naming convention as well, though. Because
the naming collision avoidance behaviour doesn't help with modules.
You still end up with 2 "common" modules (which isn't possible if you
use 1 parent with multiple children in a single directory).
So how do people do that? Do you use multiple layers? Is that not
rather confusing? Or do you resort to repeating part of the group id
in the artifact id (i.e., tractor-common and steamroller-common)? Or
would you create 2 parent projects: 1 for tractor and 1 for
steamroller? (I guess this is very similar to multiple layers of
modules.)
