Re: Consumer pom, use a System property or a pom property ?
bq. I would like to use this feature when Maven 3.7.0 is out There's this interesting idea from Stephen to activate it by default, disabling it explicitly by setting the property to false. I did a Twitter poll, and the result after 100 responses was close to 50/50 The more I think about it, the more I start to like the idea. In the past we've always been very careful with activating features, but why in this case? The whole idea here is that it should not break current poms. However, it is possible to remove a couple of elements and these will be added during *build* as if they were always there. The installed/deployed pom in based on this, minus a view build-specific elements. Btw, I discovered that I should take care of the LexicalHandler too, so there will be more commits and tests. Robert ps. thanks for the compliments. I hope it'll move the project forward! On Mon, 07 Oct 2019 07:52:48 +0200, Enrico Olivelli wrote: Hello, Robert sent out a (great) patch than enables experimental support for the consumer pom. This new way of working is enabled by a system property -Dmaven.experimental. I would like to use this feature when Maven 3.7.0 is out, but it won't be possible to use such a feature with a system property, as such system property is to be configured in every build machine in order to be sure that the build is consistent across all of the environments. What about having a simply "property" (in ) in the project ? I will set in on the parent of my hierarchy. I see we cannot a a new xml tag/xml attribute, as it will be a change in the version of the pom. As an alternative we could have a flag in Maven, to be activated by an 'extension' Thoughts Enrico - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Consumer pom...a better name like 'public pom' ?
Hi Enrico, As you might have noticed, I've changed the title of the related Jira issue. IT is now about build/consumer process. Main reason is that there's no consensus about the definitions of these poms yet. The only thing that is very clear is that your local pom can change during install/deploy. When we first talked about this, we only thought about distribution-part. The pom contains information that is only useful during build, but not anymore once installed/deployed. But even for that pom there are a couple of flavors. Hervé started with a wiki-page to describe all elements, and what to do with it.[1] A few element can be removed without discussion: parent.relativePath and modules. Also most of the build-section, but I would like to keep the packaging and plugins with extension. A good example to explain my reason behind this: it should be possible for any artifact to call dependency:unpack. Now it works for most common packaging types, because they are defined as part of Maven Core, but it doesn't belong there. Instead it should ask the plugin for its Unarchiver. Some elements are required when uploading to Central, however in some cases these are exactly the elements you want to remove in commercial products. Also, should all properties be resolved? Should all inherited elements be added? Should all dependencies be explicit(flattened)? Hence, no clear definition of THE consumer pom. Also keep in mind, that we are also thinking of a new attached file that is optimized for dependency resolution[2]. So maybe the distributed pom should stay closer to its current representation, while this new file can be the new definition for consumption. But also this page is still part of discussion. For instance: the more I think about it, the more I would like to see a list instead of a tree, and a recent link[3] supported that idea. When talking about the consumer pom, the current pom also needed to get a name, hence the build pom (as it is right now). However, the improvements I made where never part of the original build-pom, but with the mechanism used for the "consumer-pom" I was able to fix some known limitations we face every day. And with this is should be much easier to attract users, since now they can really experience the changes. But this is also a step towards model 5.0.0[4], because in the end it will still need a (generated) backported version to model 4.0.0, because that is still THE format to use in Maven repositories. So yes, naming is very important, but then we also need to be very clear what is implies. Robert [1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM [2] https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema [3] http://eed3si9n.com/dependency-resolver-semantics [4] https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 On Mon, 07 Oct 2019 07:46:32 +0200, Enrico Olivelli wrote: Hello, Robert sent out a (great) patch to introduce support for the 'consumer' pom, that is (if I understand correctly) a skinny pom that contains only useful information for downstream 'consumers' of the pom (poms that depend on it). This consumer pom feature is required in order to start thinking to new feature of the pom, because it opens the way to publishing a pom with a different 'version' of the original one. I feel that this name is not very clear, at least it is not clear to me. I propose these names: - source pom -> the source file, the pom parsed by Maven from sources - public pom -> the pom that is consumed by dependants, it is usually deployed to remote repositories In alternative to source/public I have imagined other couples: - source/shared - original/result - source/result - source/sharable - source/visible - source/effective . Thoughts ? Enrico - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Consumer pom...a better name like 'public pom' ?
"dependent POM" That is, the POM used by dependents of this project. On Mon, Oct 7, 2019 at 2:04 AM Enrico Olivelli wrote: > > Hello, > Robert sent out a (great) patch to introduce support for the 'consumer' pom, > that is (if I understand correctly) a skinny pom that contains only useful > information for downstream 'consumers' of the pom (poms that depend on it). > > This consumer pom feature is required in order to start thinking to new > feature of the pom, because it opens the way to publishing a pom with a > different 'version' of the original one. > > I feel that this name is not very clear, at least it is not clear to me. > > I propose these names: > - source pom -> the source file, the pom parsed by Maven from sources > - public pom -> the pom that is consumed by dependants, it is usually > deployed to remote repositories > > In alternative to source/public I have imagined other couples: > - source/shared > - original/result > - source/result > - source/sharable > - source/visible > - source/effective > . > > Thoughts ? > > Enrico -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: last review of Reproducible Builds proposal
Hi,
Hervé BOUTEMY wrote:
> based on the feedback I got, I updated the proposal:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
>
> The archives entries timestamp is now configured with
> project.build.outputTimestamp property, in ISO-8601 format
>
>
>
> 2019-10-02T08:04:00Z
>
>
nice work, Hervé.
Two comments:
- We already have maven.build.timestamp [1], so I wonder whether it
should be maven.build.outputTimestap, too. Although one may argue that
this *output* timestamp is a property of the project being built, not
the Maven execution (in particular if the property becomes a POM element
in POM version 5).
- Can we get something analogous to maven.build.timestamp.format? One
could then write the following to be compatible with env.SOURCE_DATE_EPOCH:
${env.SOURCE_DATE_EPOCH}
...
Unfortunately, SimpleDateFormat or its java.time equivalents do not seem
to have a format string for "seconds since the epoch", so we may want to
make "seconds since the epoch" the default for
project.build.outputTimestamp's format and only parse according to
project.build.outputTimestamp.format when that property is indeed set.
WDYT?
Best wishes.
Andreas
signature.asc
Description: OpenPGP digital signature
Re: Consumer pom...a better name like 'public pom' ?
I think the consumer POM (or maybe consumable POM) is a good name, although I also see something in source and shared pom. I don't think effective POM is a name for this POM. There is a name clash with the effective POM from help:effective-pom which shows the result of the combined POM, parent POM's and active profiles. With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Mon, Oct 7, 2019 at 8:04 AM Enrico Olivelli wrote: > Hello, > Robert sent out a (great) patch to introduce support for the 'consumer' > pom, > that is (if I understand correctly) a skinny pom that contains only useful > information for downstream 'consumers' of the pom (poms that depend on it). > > This consumer pom feature is required in order to start thinking to new > feature of the pom, because it opens the way to publishing a pom with a > different 'version' of the original one. > > I feel that this name is not very clear, at least it is not clear to me. > > I propose these names: > - source pom -> the source file, the pom parsed by Maven from sources > - public pom -> the pom that is consumed by dependants, it is usually > deployed to remote repositories > > In alternative to source/public I have imagined other couples: > - source/shared > - original/result > - source/result > - source/sharable > - source/visible > - source/effective > . > > Thoughts ? > > Enrico >
Consumer pom...a better name like 'public pom' ?
Hello, Robert sent out a (great) patch to introduce support for the 'consumer' pom, that is (if I understand correctly) a skinny pom that contains only useful information for downstream 'consumers' of the pom (poms that depend on it). This consumer pom feature is required in order to start thinking to new feature of the pom, because it opens the way to publishing a pom with a different 'version' of the original one. I feel that this name is not very clear, at least it is not clear to me. I propose these names: - source pom -> the source file, the pom parsed by Maven from sources - public pom -> the pom that is consumed by dependants, it is usually deployed to remote repositories In alternative to source/public I have imagined other couples: - source/shared - original/result - source/result - source/sharable - source/visible - source/effective . Thoughts ? Enrico
