Following up on this, as I never received any feedback. Can I assume you all trust me to go ahread with this? :)
- Brett Brett Porter wrote: >Hi, > >Ref: http://jira.codehaus.org/browse/MNG-257. > >I'd like to work through any problems that might arise from the >differences between <packaging> and <type>. Below is the background, >problem statement, and design decision to rectify them. Please add any >additional problems you see, or issues with the design. > >Background: >In Maven 2.0, projects are keyed uniquely on only groupId and artifactId >for considering what is a project (version does come into it for >determining different versions of a project). >A packaging is specified on pom.xml to signify how to build that >project, and what type of artifact it produces. > >For a given packaging, it may produce multiple artifacts that share the >same project information - the main example used is an ejb that also >outputs an ejb-client. There are also some goals that will produce >artifacts from a given project - for example, the assembly/distribution >goals, javadoc and sources. > >To be able to depend on only some of those artifacts, <type> on a >dependency may not match packaging - if you declare <type>ejb</type> you >only get the ejb, and if you declare <type>ejb-client</type>, you only >get the ejb-client JAR. The POM can always be located by the >groupId/artifactId/version combination (type is not present in the m2 >repo, and the POM is always under /poms/ if using the old layout). > >This also means that while type is not considered in whether an project >is unique, it is for a dependency - so you can download tld files with >the same name as the JAR they belong to. > >This is pretty sound from general use cases, though there have been a >couple of problems to arise: >- inconsistency could lead to confusion >- guaranteeing snapshots match versions >- does anybody have anything to add? > >** Inconsistency: >I believe this is ok. The naming was different to ensure it is clear >that they can be different, and packaging IS A SUBSET of <type>, >guaranteeing they can be handled consistently. Any value of packaging >should have 1 type that matches exactly, and possibly more types that >are associated with it. Any type has 0..1 matching packaging. > >** Snapshots: >If a JAR is deploy, then a distribution is deployed - either the POM is >republished (so the snapshot is bumped up and the JAR is orphaned), or >it is not and the published dist is orphaned, or reuses the timestamp >which is not technically correct (especially as it may overwrite a >previous distribution). > >Proposed solution: >Firstly, we differentiate types in the following way: >- that specified by packaging >- other types "tied" to the packaging (eg ejb-client and ejb) >- other types only generated by particular optional goals (eg distribution) > >Note that these are not fixed: you might declare a property that forces >"sources" to be tied to "jar" for that project, so you always deploy >sources, but this would not be the default. This could be achieved by >simply binding sources:deploy to the deploy phase. > >- deploying a distribution MUST deploy the JAR - ie, any deployment must >deploy both the POM and the artifact of the packaging (+ anything tied >to it, like an ejb-client). >- deploying an artifact MUST deploy any "tied" artifacts - eg, deploying >an EJB must deploy its client >- deploying an artifact NEED NOT deploy any "untied" artifacts - eg, >deploying a JAR doesn't deploy sources by default - it must be >configured to do so, or the goal added > >This ensures that a POM is always deployed and updated for every >deployment of anything, and that the primary artifact and anything tied >to it is never orphaned. > >It can mean that under the default lifecycle, there will be no snapshots >deployed for a distribution, for example. This simply means you cannot >depend on a distribution where you can a JAR, unless it is tied, which >is reasonable. > >This does not affect released artifacts, as they can be released at >different times and still have the same version. > >*** > >Thanks, >Brett > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
