Naming convention for multimoduled projects?
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? Cheers! Magne -- Magne Nordtveit [EMAIL PROTECTED] Systems Engineer Offshore Simulator Centre AS http://www.offsimcentre.no/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming convention for multimoduled projects?
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]
Re: Naming convention for multimoduled projects?
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. Magne -- Magne Nordtveit [EMAIL PROTECTED] Systems Engineer Offshore Simulator Centre AS http://www.offsimcentre.no/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming convention for multimoduled projects?
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.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming convention for multimoduled projects?
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.)
