+1 (possibly set the deps to 3.0.4 instead, and not 3.0.5)
I don't think we need to branch the parent poms. That will just create
unnecessary complexity. As you pointed out, plugins can continue to use the
Q-1 version of the parent if the want to go with 2.x-compat (and
add/override plugin upgrade
Le 23 févr. 2014 21:20, "Stephen Connolly"
a écrit :
>
> On Sunday, 23 February 2014, Michael Osipov wrote:
>
> > Am 2014-02-23 19:06, schrieb Benson Margulies:
> >
> >> I propose to make releases of our parent stack that are suitable for
> >> components and plugins that are making the leap to Ja
On Feb 23, 2014, at 12:38 PM, Michael Osipov wrote:
>
> Just had a hard time to find this information on the (front) page.
> I think a mere: 2014-02-18 End of Life EoL notes, announce is not enough. I
> would have expected something like this on the front page:
>
> Looking for Maven 2?
> // Ei
I think that Michael might be over-reading my intentions. I am not
trying to start a short-term avalanche of moving components to require
3.0.5. My idea is:
1. We release parents that set up the 3.0.5 dependencies. Call that version Q.
2. Any maintainer who feels inclined to release a 2.2.x-compat
Am 2014-02-23 21:20, schrieb Stephen Connolly:
On Sunday, 23 February 2014, Michael Osipov wrote:
Am 2014-02-23 19:06, schrieb Benson Margulies:
I propose to make releases of our parent stack that are suitable for
components and plugins that are making the leap to Java 1.6 and Maven
3 as the
On Sunday, 23 February 2014, Michael Osipov wrote:
> Am 2014-02-23 19:06, schrieb Benson Margulies:
>
>> I propose to make releases of our parent stack that are suitable for
>> components and plugins that are making the leap to Java 1.6 and Maven
>> 3 as their base requirements.
>>
>> What do peo
Am 2014-02-23 19:06, schrieb Benson Margulies:
I propose to make releases of our parent stack that are suitable for
components and plugins that are making the leap to Java 1.6 and Maven
3 as their base requirements.
What do people think is the right approach in terms of what stays on
trunk and w
Stephen, can I possibly get you to respond to the the questions about branches
(or not) and version numbers for the POM's?
On February 23, 2014 2:00:24 PM EST, Stephen Connolly
wrote:
>Well let's get the maven dep up to at least 3.0.4.
>
>Let's give users an announce that we are moving to only
Well let's get the maven dep up to at least 3.0.4.
Let's give users an announce that we are moving to only checking java 1.5
compat via animal sniffer and that we will be building plugins with 1.6 or
1.7
On Sunday, 23 February 2014, Benson Margulies wrote:
> For this thread, I'd be content to g
For this thread, I'd be content to get a plan for how to manage the
poms to reflect the EOL of 2.x. The actual content of those poms can
argued over by committing an initial proposal.
On Sun, Feb 23, 2014 at 1:50 PM, Benson Margulies wrote:
> I would have expected our first step would be to set
I would have expected our first step would be to set source and target
to 1.6, and move the Maven core dependencies to 3.0.x. I don't see why
the fact that the core was compiled with target=1.5 would have any
impact here.
I'd like to avoid a disorganized process of individual plugins and
component
Keep in mind that maven 3.0-3.1.x are still java 1.5 and we haven't put a
version policy in place.
Personally speaking I'm fine with plugins requiring java 1.6 and maven
3.2.1 as a minimum, but I'd rather see 3.3.x get some legs first and I
suspect we'll have a few 3.2.x releases as we have EOL'd
I propose to make releases of our parent stack that are suitable for
components and plugins that are making the leap to Java 1.6 and Maven
3 as their base requirements.
What do people think is the right approach in terms of what stays on
trunk and what goes on a branch, and whether to do anything
13 matches
Mail list logo
