for trace-ability,  i add this to top level pom

     <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>this-has-scm-info-for-tagging-and-tracability-purpose</id>
            <phase>prepare-package</phase>
            <goals>
              <goal>create-metadata</goal>
            </goals>
            <inherited>false</inherited> <!-- only one is needed -->
            <configuration>
              <timestampPropertyName>date</timestampPropertyName>
              <timestampFormat>YYYY.MM.dd</timestampFormat>
              <attach>true</attach>
              <properties>
                <scm>${project.scm.developerConnection}</scm>
              </properties>
            </configuration>
          </execution>
        </executions>
      </plugin>

On Thu, May 4, 2017 at 10:53 AM, Eric Benzacar <e...@benzacar.ca> wrote:

> I've read through Karl's blog (http://blog.soebes.de/blog/
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
> understand the approach, there is still one critical issue that bothers
> me.  I think this actually reopens an old thread that circulated on this
> list a few months ago, but it related to the Idempotence of a pom file.
>
> From my perspective/view a pom file should be idempotent.  That is every
> single build of a given NON-SNAPSHOT pom file should finish with the same
> build.  But by moving a release number or version number outside of the
> pom, it eliminates this need.  Furthermore, from a traceability
> perspective, my source control can no longer show me precisely version was
> being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but
> none the less, the value can be overridden at build time with a completely
> different value.  Consequently, I can still not be 100% confident that a
> pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm
> thinking that something like the version-plugin being able to manipulate a
> revision property that can then be committed as part of the pom would be
> the best of both approaches.  In that way, my developers can fix the
> version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > How about everybody read their mail?
> > (see below)
> >
> > On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:
> >
> > > Hi Dan, Karl & everyone,
> > >
> > > > See Karl's Blog
> > >
> > > Link, please?
> > >
> > […]
> >
> > > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > > >
> > > > > >> Hi
> > > > > >>
> > > > > >> I have been experimenting with suggestion from Karl [1] with
> small
> > > > multi
> > > > > >> module maven project.
> >
> > […]
> >
> > > > > >> [1]
> > > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > > >> t-a-version-in-it/
> > >
> >
>

Reply via email to