If we were to have the separation we would need another implementation of an ArtifactDescriptorReader which turns our representation, the POM, into Aether's internal representation for the abbreviated format. I need to check as I'm not sure without looking what happens when you have multiple ArtifactDescriptorReaders. Probably not hard to change it to support multiple if it doesn't already.
On Nov 29, 2013, at 11:31 AM, Robert Scholte <rfscho...@apache.org> wrote: > Correct me if I'm wrong, but IIUC in the end it is Aether which collects all > the dependencies. > Aether is probably only interested in the <dependency>, > <dependencyManagement> and <parent>-tags. > What if we move the responsibility of the consumer-model to Aether as well? > Do we want this? What are the thoughts of the Aether-team? > > Robert > > Op Sun, 24 Nov 2013 22:31:54 +0100 schreef Hervé BOUTEMY > <herve.bout...@free.fr>: > >> Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit : >>> On Nov 24, 2013, at 12:19 AM, Manfred Moser <manf...@mosabuam.com> wrote: >>> >> By separating "consumption" and "production" metadata formats, we'll be >>> >> able to evolve production format more aggressively. For example, it >>> >> would be nice to have Tycho-specific configuration markup inside <build> >>> >> section. This is not currently possible because all poms must be >>> >> compatible with the same model. >>> > >>> > I like the idea of consumptions specifics. It would be great if we could >>> > agree/define some sort of standard on how to declare suitability for >>> > artifacts for certain deployment scenarios .. >>> >>> I don't believe this requires separate documents to support this. >> >> true, this does not require separate documents >> >> but having separate documents helps separating concerns: building a project >> vs >> consuming its artifacts >> >> and descriptor for consuption will be: >> - a lot shorter than descriptor for building: not any plugin, for example >> - build-agnostic >> >> I'm pretty sure that separating descriptors will help us move forward and >> even >> better design things >> >> Regards, >> >> Hervé >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
