[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