On 24 May 2011 16:19, John Casey <[email protected]> wrote: > +1 > > Also, generated 4.0.0 POMs should only contain deps and things to support > deps, not build section etc. > > In other words, it's not to be used as a parent...if you can't use the newer > POM syntax, don't use this artifact as a parent.
+1 > > On 5/24/11 11:17 AM, Stephen Connolly wrote: >> >> deploy new poms as poms with classifier >> >> new maven tries to download pom with classifier... fails and falls >> back to pom without >> >> old maven only ever sees pom without classifier >> >> 2011/5/24 Arnaud Héritier<[email protected]>: >>> >>> It doesn't seem so easy for me. >>> If we deploy 4.0.0 only we'll never be able to reuse new POMs in the >>> build >>> process by inheritance for example. >>> Thus always deploying .pom artifacts as 4.0.0 keeps the compatibility but >>> won't allow us to evolve. >>> The problem is how to depend and how to extend (without talking about a >>> future : how to mix..) >>> >>> >>> On Tue, May 24, 2011 at 4:09 PM, John Casey<[email protected]> >>> wrote: >>> >>>> >>>> >>>> On 5/24/11 8:25 AM, Brian Fox wrote: >>>> >>>>> 2011/5/24 Arnaud Héritier<[email protected]>: >>>>> >>>>>> Before talking about a specific change in the model like the addition >>>>>> of >>>>>> mixins (which may be cool but not critical) did we : >>>>>> - studied that we had everything necessary to manage new versions of >>>>>> POMs >>>>>> with something a little bit dynamic inside the core and all that is >>>>>> necessary on repositories side ? >>>>>> - studied if we couldn't start by really simple issues that may >>>>>> already >>>>>> do a >>>>>> very useful 3.1 version like the addition of global exclusions ? >>>>>> >>>>>> >>>>> I didn't read the proposal in detail yet, but my initial concern was >>>>> on pom compat as well. >>>>> >>>> >>>> I think doing some sort of on-the-fly translation into a 4.0.0 POM >>>> purely >>>> to be deployed for backwards compat would be enough here...though we may >>>> want to explore how we could make Maven smart enough to say, "I can't >>>> read >>>> this POM, use a later version" or somesuch... >>>> >>>> >>>> >>>>> >>>>> Arnaud >>>>>> >>>>>> On Tue, May 24, 2011 at 7:30 AM, Brett Porter<[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> I'm working with some projects at the moment that have a high amount >>>>>>> of >>>>>>> repetition in the build section (and in some cases dependencies), but >>>>>>> no >>>>>>> common parent due to different organisational hierarchies. Currently >>>>>>> it's >>>>>>> being solved by using archetypes to create projects consistently, but >>>>>>> it >>>>>>> isn't very satisfying if someone wants to change the archetype later >>>>>>> on. >>>>>>> I've minimised that by limiting what needs to change between projects >>>>>>> based >>>>>>> on the archetype, but it is exactly the situation that calls for >>>>>>> mixins. >>>>>>> >>>>>>> At the same time, this issue was filed today: >>>>>>> http://jira.codehaus.org/browse/MNG-5102, and I was surprised not to >>>>>>> find >>>>>>> a dupe given how often it has come up here. >>>>>>> >>>>>>> Previous discussions I found: >>>>>>> http://s.apache.org/maven-mixin-1 >>>>>>> http://s.apache.org/maven-mixin-2 >>>>>>> http://s.apache.org/maven-mixin-3 >>>>>>> http://s.apache.org/maven-mixin-4 >>>>>>> >>>>>>> I don't see any concrete proposals, other than the notes from Jason >>>>>>> Dillon. >>>>>>> So, I thought I'd start collecting them here. >>>>>>> >>>>>>> I actually prefer the name "template", so I'll use that here, but >>>>>>> happy >>>>>>> to >>>>>>> take other's opinions on that. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Pre-requisites: the ability to make modifications to the POM, >>>>>>> published >>>>>>> to >>>>>>> the repository, without impacting older clients. This needs an issue >>>>>>> of >>>>>>> it's >>>>>>> own, but I don't think it's challenging if we continue to spit out >>>>>>> v4.0.0 to >>>>>>> the repository. >>>>>>> >>>>>>> Some notes on how I think it should work: >>>>>>> - templates should look like a normal POM (perhaps only differing in >>>>>>> root >>>>>>> element, and less strict validation requirements), so that normal >>>>>>> validation >>>>>>> can be applied >>>>>>> - any POM element is valid, other >>>>>>> than<parent>,<groupId>,<artifactId>, >>>>>>> <version>,<templates>,<modules> >>>>>>> - templates need to be sourced from the repository using the normal >>>>>>> mechanism (similarly to the parent POM) >>>>>>> - templates should have an extension "xml" in the repository. It is >>>>>>> attached to the corresponding POM project with packaging >>>>>>> "pom-template". >>>>>>> Multiple templates can be attached using classifiers. The POM of the >>>>>>> template must be separate to the template itself, as some elements >>>>>>> would >>>>>>> otherwise overlap (e.g.<name> of the template vs the templated >>>>>>> name, or >>>>>>> distributionManagement) >>>>>>> - we rely on the later interpolation step to resolve variables - >>>>>>> there >>>>>>> should be no filtering or macro capability on the template >>>>>>> - there should be no additional merge semantics - I think they can be >>>>>>> handled very similarly to external profiles in terms of building >>>>>>> - there should be no conditionals within or around the template >>>>>>> (that's >>>>>>> the >>>>>>> purpose of profiles) >>>>>>> >>>>>>> I think that makes the sequence of project building: >>>>>>> - parents& templates are resolved >>>>>>> - templates are injected, sequentially as declared in the POM. Note >>>>>>> that >>>>>>> this happens before inheritance, so templates in parents are already >>>>>>> applied. >>>>>>> - profiles are selected and injected >>>>>>> - project inheritance is applied >>>>>>> - interpolation is applied >>>>>>> >>>>>>> Templates would be referenced as follows: >>>>>>> >>>>>>> <project> >>>>>>> <parent> >>>>>>> ... >>>>>>> </parent> >>>>>>> <templates> >>>>>>> <template> >>>>>>> <groupId>org.apache.maven.templates</groupId> >>>>>>> <artifactId>maven-release-profile-template</artifactId> >>>>>>> <version>1.0</version> >>>>>>> <classifier>sources-and-javadocs</classifier> (optional >>>>>>> element) >>>>>>> </template> >>>>>>> <template> >>>>>>> <groupId>org.apache.maven.templates</groupId> >>>>>>> <artifactId>maven-team-list</artifactId> >>>>>>> <version>1.0</version> >>>>>>> </template> >>>>>>> </templates> >>>>>>> ... >>>>>>> </project> >>>>>>> >>>>>>> Some alternatives for discussion: >>>>>>> - we could allow profiles to be externalised, and use that instead of >>>>>>> a >>>>>>> new >>>>>>> element. Simplifies building, but I think is less descriptive of >>>>>>> intent >>>>>>> - template as a bare POM - instead of attached >>>>>>> artifacts,<templateSpecs> >>>>>>> could be inlined in the POM, deployed as a single POM and then >>>>>>> imported >>>>>>> into >>>>>>> another project. This seems unnecessarily complicated, though. >>>>>>> - there are other alternatives on how it is packaged in the >>>>>>> repository - >>>>>>> e.g. a ".pomtmpl" extension or similar. If it is XML, I prefer that >>>>>>> extension so it is more readily recognised, and I believe the >>>>>>> group/artifact >>>>>>> IDs will already describe their intent >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>>> Cheers, >>>>>>> Brett >>>>>>> >>>>>>> -- >>>>>>> Brett Porter >>>>>>> [email protected] >>>>>>> http://brettporter.wordpress.com/ >>>>>>> http://au.linkedin.com/in/brettporter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> -- >>>> John Casey >>>> Developer, PMC Member - Apache Maven (http://maven.apache.org) >>>> Blog: http://www.johnofalltrades.name/ >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > -- > John Casey > Developer, PMC Member - Apache Maven (http://maven.apache.org) > Blog: http://www.johnofalltrades.name/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
