[jbosstools-dev] Parent pom updated! Minimum/default target platform used in master branch (4.1/7.0) now points at Kepler M4 bits, with M5 coming next week; Juno&Kepler TPs will remove unneeded IUs next week
Nick Boldt
nboldt at redhat.com
Thu Jan 31 14:48:17 EST 2013
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
or
$ 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.
:P
--
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.
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:
mvn verify
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 ?
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.
I've bumped https://issues.jboss.org/browse/JBIDE-13408 to Blocker, but
I'm leaving it on Alpha2 for now.
Cheers,
Nick
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 into
>>>> the usual places [1], [2]:
>>>>
>>>> 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 https://issues.jboss.org/browse/JBIDE-13316 . But this is not our highest priority yet. If we remove the "-SNAPSHOT", we'll probably drop the Alpha1/Final qualifier as well.
>
>
> 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.
>
> /max
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
More information about the jbosstools-dev
mailing list