On 3/23/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > 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.
I'm probably missing something, since my M2 knowledge is minimal at the moment (but I'm working on that ;), but what you have above implies compound artifacts. I thought an artifact was a unit (e.g. one jar file), no? In the above, if I declared a dependency like so: <groupId>org.apache</groupId> <artifactId>struts</artifactId> what would I get? My expectation is that I'd get an error. ;-) -- Martin Cooper 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.0tags, > > > >> > > > >>> 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] > >
