You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2014/04/15 16:19:47 UTC
Intended use of properties in the element
I've been thinking about how to exploit the 3.2.1 feature of
<version>${something}</version>
My idea is that an ordinary developer would end up with 'something'
defined to be a good, old, -SNAPSHOT, while various automated builds
would define it based on git commits.
Is is intended that a POM could declare
<something>44-SNAPSHOT</something>
and then have the command-line override with -Dsomething=SOMETHING-else?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intended use of properties in the element
Posted by Jason van Zyl <ja...@takari.io>.
On Apr 17, 2014, at 10:24 AM, Benson Margulies <bi...@gmail.com> wrote:
> I'd like to arrange a system in which the automated builds stamp out
> releases (in the Maven sense),
In my case there is nothing to stamp out, every build is releasable. I deploy sources and everything else required and have mechanisms to cleanup the repository as our builds are frequent. For releases in the current Maven sense I plan to phase out in all my use cases: no SNAPSHOTs and no release plugin. Things obviously need to be tagged and processed once you decide a particular build is your "release" but we are developing tooling for this.
> but that developers can use the usual
> IDE and command-line builds when just building on their particular
> machine at some particular instant. So I'd like to spare developers
> from 'passing in the version always.'
Our developers don't pass anything in, the system they use does this for them and ultimately I'll make tooling for a generations workflow and people can decide to use it if it works for their case. I definitely don't want developers having to fiddle with properties.
> The device discussed in your
> last paragraph could undoubtedly use some environmental hint to tell
> that it's just a dev's machine and either fill in a very unique
> qualifier or just use a snapshot.
I just use a custom MetadataGenerationFactory to stuff in the right version which is always a release version. The same mechanism to flip SNAPSHOTs to timestamps. This mechanism is not very pretty and at a minimum I will clean this up so that guys like who posted after you don't have to hackup the model reader to achieve what they need.
>
>
> On Tue, Apr 15, 2014 at 12:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>> For the continuous delivery friendly versions I saw an issue in JIRA as well that tried to use snapshots.
>>
>> The version is always a release version, not a snapshot. Snapshots are definitively not CD friendly. In the system I'm working on that currently uses this feature it is always a Perforce changelist which is the version. All artifacts get deployed with this version. This is getting close, but we don't use snapshots or the release plugin which is the way I believe things will evolve in the Maven ecosystem. This is the generations stuff I've mentioned and while it is working in production right now, it's not complete but I'll likely have all the edge cases worked out in a few months.
>>
>> So the theory is with this mechanism that the release version is passed in externally always. I have another method I'm working on which is to have something like x.y.z.qualifier where the magic happens in the maven-aether-provider to do the necessary transformation based on the system you're running in: Git, P4, whatever.
>>
>> What are you trying to do? I can explain more if I know what you're playing with.
>>
>> On Apr 15, 2014, at 10:19 AM, Benson Margulies <bi...@gmail.com> wrote:
>>
>>> I've been thinking about how to exploit the 3.2.1 feature of
>>>
>>> <version>${something}</version>
>>>
>>> My idea is that an ordinary developer would end up with 'something'
>>> defined to be a good, old, -SNAPSHOT, while various automated builds
>>> would define it based on git commits.
>>>
>>> Is is intended that a POM could declare
>>>
>>> <something>44-SNAPSHOT</something>
>>>
>>> and then have the command-line override with -Dsomething=SOMETHING-else?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>> -- Jakob Burckhardt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking.
-- Johann von Goethe
Re: Intended use of properties in the element
Posted by Roger Brechbühl <ro...@gmail.com>.
My solution was to extend the DefaultModelReader where the version is
overridden when a specific system property is set.
There are different possibilities how the version is generated, based on
${project.version} or given from external.
This means, the version in the pom.xml is still a SNAPSHOT version and
developers/eclipse are not affected at all.
To build a non-snapshot release maven is invoked like so: *mvn clean
install -Dversion.override*
This would generate a version like 0.0.1-S-15 where 0.0.1-S is the short
form of 0.0.1-SNAPSHOT and 15 is the ${env.BUILD_NUMBER} which is set by
Jenkins.
Code is here:
https://github.com/rotscher/emerging/blob/master/maven-core-extensions/src/main/java/ch/rotscher/mavenext/VersionOverrideModelReader.java
So far, the only known issue is to take care of the pom which gets
installed/deployed to the local/remote repository (but a solution is
available as well)
Cheers,
Roger
2014-04-17 19:24 GMT+02:00 Benson Margulies <bi...@gmail.com>:
> I'd like to arrange a system in which the automated builds stamp out
> releases (in the Maven sense), but that developers can use the usual
> IDE and command-line builds when just building on their particular
> machine at some particular instant. So I'd like to spare developers
> from 'passing in the version always.' The device discussed in your
> last paragraph could undoubtedly use some environmental hint to tell
> that it's just a dev's machine and either fill in a very unique
> qualifier or just use a snapshot.
>
>
> On Tue, Apr 15, 2014 at 12:09 PM, Jason van Zyl <ja...@takari.io> wrote:
> > For the continuous delivery friendly versions I saw an issue in JIRA as
> well that tried to use snapshots.
> >
> > The version is always a release version, not a snapshot. Snapshots are
> definitively not CD friendly. In the system I'm working on that currently
> uses this feature it is always a Perforce changelist which is the version.
> All artifacts get deployed with this version. This is getting close, but we
> don't use snapshots or the release plugin which is the way I believe things
> will evolve in the Maven ecosystem. This is the generations stuff I've
> mentioned and while it is working in production right now, it's not
> complete but I'll likely have all the edge cases worked out in a few months.
> >
> > So the theory is with this mechanism that the release version is passed
> in externally always. I have another method I'm working on which is to have
> something like x.y.z.qualifier where the magic happens in the
> maven-aether-provider to do the necessary transformation based on the
> system you're running in: Git, P4, whatever.
> >
> > What are you trying to do? I can explain more if I know what you're
> playing with.
> >
> > On Apr 15, 2014, at 10:19 AM, Benson Margulies <bi...@gmail.com>
> wrote:
> >
> >> I've been thinking about how to exploit the 3.2.1 feature of
> >>
> >> <version>${something}</version>
> >>
> >> My idea is that an ordinary developer would end up with 'something'
> >> defined to be a good, old, -SNAPSHOT, while various automated builds
> >> would define it based on git commits.
> >>
> >> Is is intended that a POM could declare
> >>
> >> <something>44-SNAPSHOT</something>
> >>
> >> and then have the command-line override with -Dsomething=SOMETHING-else?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > ---------------------------------------------------------
> >
> > A party which is not afraid of letting culture,
> > business, and welfare go to ruin completely can
> > be omnipotent for a while.
> >
> > -- Jakob Burckhardt
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Intended use of properties in the element
Posted by Benson Margulies <bi...@gmail.com>.
I'd like to arrange a system in which the automated builds stamp out
releases (in the Maven sense), but that developers can use the usual
IDE and command-line builds when just building on their particular
machine at some particular instant. So I'd like to spare developers
from 'passing in the version always.' The device discussed in your
last paragraph could undoubtedly use some environmental hint to tell
that it's just a dev's machine and either fill in a very unique
qualifier or just use a snapshot.
On Tue, Apr 15, 2014 at 12:09 PM, Jason van Zyl <ja...@takari.io> wrote:
> For the continuous delivery friendly versions I saw an issue in JIRA as well that tried to use snapshots.
>
> The version is always a release version, not a snapshot. Snapshots are definitively not CD friendly. In the system I'm working on that currently uses this feature it is always a Perforce changelist which is the version. All artifacts get deployed with this version. This is getting close, but we don't use snapshots or the release plugin which is the way I believe things will evolve in the Maven ecosystem. This is the generations stuff I've mentioned and while it is working in production right now, it's not complete but I'll likely have all the edge cases worked out in a few months.
>
> So the theory is with this mechanism that the release version is passed in externally always. I have another method I'm working on which is to have something like x.y.z.qualifier where the magic happens in the maven-aether-provider to do the necessary transformation based on the system you're running in: Git, P4, whatever.
>
> What are you trying to do? I can explain more if I know what you're playing with.
>
> On Apr 15, 2014, at 10:19 AM, Benson Margulies <bi...@gmail.com> wrote:
>
>> I've been thinking about how to exploit the 3.2.1 feature of
>>
>> <version>${something}</version>
>>
>> My idea is that an ordinary developer would end up with 'something'
>> defined to be a good, old, -SNAPSHOT, while various automated builds
>> would define it based on git commits.
>>
>> Is is intended that a POM could declare
>>
>> <something>44-SNAPSHOT</something>
>>
>> and then have the command-line override with -Dsomething=SOMETHING-else?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
> -- Jakob Burckhardt
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Intended use of properties in the element
Posted by Jason van Zyl <ja...@takari.io>.
For the continuous delivery friendly versions I saw an issue in JIRA as well that tried to use snapshots.
The version is always a release version, not a snapshot. Snapshots are definitively not CD friendly. In the system I'm working on that currently uses this feature it is always a Perforce changelist which is the version. All artifacts get deployed with this version. This is getting close, but we don't use snapshots or the release plugin which is the way I believe things will evolve in the Maven ecosystem. This is the generations stuff I've mentioned and while it is working in production right now, it's not complete but I'll likely have all the edge cases worked out in a few months.
So the theory is with this mechanism that the release version is passed in externally always. I have another method I'm working on which is to have something like x.y.z.qualifier where the magic happens in the maven-aether-provider to do the necessary transformation based on the system you're running in: Git, P4, whatever.
What are you trying to do? I can explain more if I know what you're playing with.
On Apr 15, 2014, at 10:19 AM, Benson Margulies <bi...@gmail.com> wrote:
> I've been thinking about how to exploit the 3.2.1 feature of
>
> <version>${something}</version>
>
> My idea is that an ordinary developer would end up with 'something'
> defined to be a good, old, -SNAPSHOT, while various automated builds
> would define it based on git commits.
>
> Is is intended that a POM could declare
>
> <something>44-SNAPSHOT</something>
>
> and then have the command-line override with -Dsomething=SOMETHING-else?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt