Mickael, how about we add a profile that does this:
$ mvn verify -Phelp
[info] Max, if you're trying to override the target platform version
[info] use -DTARGET_PLATFORM_VERSION=x.yz.a.quality-SNAPSHOT, eg.,
[info] mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT
$ mvn verify -Phelp
[info] Fetching a copy of the parent pom from master branch...
[info] Opening parent pom in your default text editor so you can
[info] `egrep -i "target|platform" and figure out the property
[info] you need to override.
I wish Maven had a way to do this - but it doesn't. Don't get me started on how
stupid that is.
Seriously, though, Max, if you can't remember that the
maven/tycho variable for the target platform version is TARGET_PLATFORM_VERSION then
making you memorize a new profile might not be the best solution.
Nick, i'm simply saying using capital letters, fully spelled out and direct contrast
to maven conventions is just weird to me.
And I did not say add a profile I suggest something like mvn -Dtpc.version or
-Dtarget.version similar to 99% of all the other properties in maven pom's.
Now that I check the pom I can see my original tpc.group and tpc.targetKind is in there
but the tpc.version is replaced with this unconventional TARGET_PLATFORM_VERSION.
Why oh why?
In fact, you only need to provide an override if the following two
usecases don't work for you:
a) you want the default minimum:
b) you want the default maximum
mvn verify -Pmaximum
Because, while the idea of having profiles for each and every TP stream is *somewhat*
reasonable, it doesn't solve the usecase where there are multiple Juno SR0 based
target platforms (eg., we have 4.20.5 now and will have 4.20.6 soon - do we have to update
the parent pom every time there's a newer SR0 version created? And what if a user
wants to use the previous one?
-PJunoSR0.previous and -PJunoSR0 ?
-PJunoSR0d and -PJunoSR0e ?
Not suggesting adding those names, just use conventional property names and not introduce
these capital letter based ones which normally means constants and non-changable and
opposite to what maven properties are named.
Besides, the whole point of refactoring the GAVs for the TPs was to
get AWAY from using names like JunoSR0 in favour of 4.20.x.
> Without [removing -SNAPSHOT] we don't have the option of building a component
with a stable parent pom
This is true, but we have some time here since M4/M5 are still under development.
It's not until M7 that the bits are stable enough to be called .CR or .Final, or to
remove the -SNAPSHOT suffix. So... all components, even if they're "done"
this week, should be rebuilding w/ updated TPs all the way through M7 to verify they still
work against the newer Kepler stuff.
which is why I find 4.20.5.Alpha to be perfect valid name to indicate its alpha; but at
least is a fixed content and not a snapshot.
I've bumped https://issues.jboss.org/browse/JBIDE-13408
to Blocker, but I'm
leaving it on Alpha2 for now.
On 01/31/2013 08:43 AM, Max Rydahl Andersen wrote:
>>>> mvn verify -DTARGET_PLATFORM_VERSION=4.20.5.Final-SNAPSHOT #JunoSR0
>>>> mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT #JunoSR1
>>> Would be good to have something easy to remember like
>>> mvn verify -PJunoSR0
>>> mvn verify -PJunoSR1
>> This would add a lot of crap to parent pom for something that we won't use.
So there won't be some profiles for unsupported stuff.
>> -DTARGET_PLATFORM_VERSION is easy to remember as well, and in case you forget it,
feel free to ask.
> I'm sorry but TARGET_PLATFORM_VERSION is not easy to remember nor is it nice to
type. All other user properties in maven is not uppercase and a mile long ;)
>>>> Once the cruft has been cleaned, new TPs will be released & linked
>>>> the usual places , :
>>>> 4.20.6.Final-SNAPSHOT #JunoSR0 (6th respin)
>>>> 4.21.4.Final-SNAPSHOT #JunoSR1 (4th respin)
>>>> 4.30.1.Alpha1-SNAPSHOT #KeplerSR0, 1rst respin
>>> Why are you releasing versions with SNAPSHOT suffix? What is wrong with
>>> just 4.20.6.Final?
>> That's something we are investigating as part of
. But this is not our highest priority yet. If
we remove the "-SNAPSHOT", we'll probably drop the Alpha1/Final qualifier as
> I think this *is* high priority.
> Without it we don't have the option of building a component with a stable parent
pom. If it stays -SNAPSHOT we still have to rebuild the component again and again since
the parent is always moving.
> jbosstools-dev mailing list
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio