Well, I think it would be better to use a 3 levels project like this :
groupdId : org.apache
artifactId : struts
|
---------------- groupdId : org.apache.struts
| artifactId : action
| |
| |--- all the sub projects share the groupId
org.apache.struts.action
|
|
---------------- groupdId : org.apache.struts
artifactId : shale
|
|--- all the sub projects share the groupId
org.apache.struts.shale
Those are best practices recommended by the Maven team.
On 3/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 3/22/06, Nicolas De Loof <[EMAIL PROTECTED]> wrote:
> >
> >
> > Why use "org.apache.struts.action" and not just "org.apache.struts" ?
>
>
> Since I didn't create it, I can't give you a definitive answer, but my
> assumption is that it allows us to have different groups for our different
> "products". So the two groups we would have today would be
> org.apache.struts.action and org.apache.struts.shale. The 'action'
> references the Action framework, and not the 'action' package of the Action
> framework.
>
> AFAIK groupId is expected to gather artifacts from the same development
> > team.
> > For example, "org.apache.maven" groupId is used for all maven artifacts
>
>
> The main difference that I see here is that the maven artifacts within that
> group are intended to work together, while our 'action' and 'shale' will
> very rarely be used together, and are really alternatives.
>
> Using "org.apache.struts.action" means there will also be
> > "org.apache.struts.tiles", "org.apache.struts.taglibs" groupIds with
> > only one artifact per groupId.
>
>
> No, it doesn't. As I described above, the 'action' is not the Java package
> but the framework.
>
> --
> Martin Cooper
>
>
> Wendy Smoak a écrit :
> > > On 3/22/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >> Meaning that the dependency would look like this?
> > >>
> > >> <dependency>
> > >> <groupId>org.apache.struts.action</groupId>
> > >> <artifactId>struts-action</artifactId>
> > >> <version>1.3.0</version>
> > >> </dependency>
> > >>
> > >
> > > Yes.
> > >
> > >
> > >> I don't think the version numbers were changed before the 1.3.0 tags,
> > >>
> > >>> so if you want to deploy the 1.3.0 jars from the distributions, a
> > >>> little revisionist history will be necessary for the version numbers
> > >>> as well as the groupId.
> > >>>
> > >> Not sure I understand this. If I wanted to create a local or remote
> > repo
> > >> that satisfied the above dependency (assuming it's correct), what do I
> > need
> > >> to do?
> > >>
> > >
> > > Edit the pom.xml files from the 1.3.0 tag or distribution to fix the
> > > version and groupId. Depending on whether you want to build from
> > > source or just install an existing jar, either mvn install or mvn
> > > install:install-file with appropriate parameters:
> > > http://maven.apache.org/plugins/maven-install-plugin/
> > >
> > > For deploying to a remote repository (maven-snapshot-repository) I've
> > > just been using 'mvn deploy:deploy-file'. There's an example in the
> > > shale/build/maven2 README file:
> > >
> > http://svn.apache.org/repos/asf/struts/shale/trunk/build/maven2/README.txt
> > >
> > > HTH,
> > > --
> > > Wendy
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> > This message contains information that may be privileged or confidential
> > and is the property of the Capgemini Group. It is intended only for the
> > person to whom it is addressed. If you are not the intended recipient, you
> > are not authorized to read, print, retain, copy, disseminate, distribute,
> > or use this message or any part thereof. If you receive this message in
> > error, please notify the sender immediately and delete all copies of this
> > message.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
--
Alexandre Poitras
Québec, Canada
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
