[...] > I think this sounds nice in theory but losing the information about how an > artifact is produced is not a good idea. for consumers, plugins information is really bloat
> I also don't think having a bunch > of different tools to read one format or another is manageable. we can have multiple tools only is the format is simple: format for consuption will probably be simpler than format for build > I think > that making readers that are more accepting of different versions and > accommodating different elements is another approach. Keeping it all > together forces you to think about the implications of a change. it keeps consumers tied to the tool used by artifact producer to build: not ideal either > > I think general extensibility of the format might be useful but in a general > reader. Right now specific tools can work around this issue by having a > plugin define specifics for a type. While not ideal it works but is more > akin to a general extension mechanism that works with a single type of > accommodating reader. > > I think splitting building vs consumption will open a huge can of worms. for sure, this is a big change but I'm convinced this is worth to try > Now > I'm all for being able to aggressively change the format, but I would > rather have a single document per version of the model. Possibly think > about a future proof version and publish just continue to publish a model > version 4.0.0 along side it indefinitely. I'm not sure how build vs > consumption actually helps us evolve the model. I didn't try to classify our wishes for evolution between consuption and build Evolution on consuption format will always be hard, because there is a full ecosystem for consuption Evolution on build will be easier, since you can simply require someone to use a neer version of your tool if he wants to build some project instead of consuming its pre-built artifacts Regards, Hervé > > -- > > Regards, > > Igor > > > >>> Only with <packaging>pom</packaging> do we actually need things like the > >>> <plugins> section in the deployed pom, because it is a reality that for > >>> noo-pom packaging we just want the transitive dependencies. > >>> > >>> Now there is the <extensions> issue where you might be registering a > >>> different file type that has different rules with respect to the > >>> classpath... but I am unsure if we actually consider those when > >>> evaluating > >>> the dependency tree... and in any case, once we accept that the deployed > >>> pom is not the same as the pom used to build (for non-pom packaging at > >>> least) we can transform that dependency tree using the exact rules that > >>> have to be known at build time thus closing the extensions issue. > >>> > >>> For projects with <packaging>pom</packaging> in fact we are only > >>> deploying > >>> smal files so perhaps we can deploy two pom files... the one that > >>> exposes > >>> the standard dependency stuff and then a second one that is used for > >>> build > >>> inheritance. > >>> > >>> My vision is thus that we deploy between 2 and three pom files for every > >>> project. > >>> > >>> For jar/war/ear/... we deploy: > >>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies) > >>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but > >>> allows > >>> for new scopes) > >>> > >>> For pom we deploy > >>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies) > >>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but > >>> allows > >>> for new scopes) > >>> * the pom itself > >>> > >>> When building a pom, your parent pom must be of a modelVersion <= your > >>> modelVersion. > >> > >> Thanks, > >> > >> Jason > >> > >> ---------------------------------------------------------- > >> Jason van Zyl > >> Founder, Apache Maven > >> http://twitter.com/jvanzyl > >> --------------------------------------------------------- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
