I seem to recall that it's already configurable, that someone else has been
here and done this.
On Mon, Jan 11, 2021 at 8:24 AM Dennis Lundberg
wrote:
> Hi all,
>
> When using a CI environments that create a new SemVer-compliant version for
> every build. These could use a qualifier like "-buil
+1 binding
On Tue, Aug 11, 2020 at 1:08 PM Ian Lavallee wrote:
> +1
>
> On Mon, Aug 10, 2020 at 10:20 AM Elliotte Rusty Harold >
> wrote:
>
> > Let's try this one more time. I updated Jira and regenerated the
> > release notes. Nothing else has changed:
> >
> > Hi,
> >
> > We solved 3 issues:
>
upgrade that enables lots of new work in
> > the dependency plugin. Can anyone else give us a +1? Thanks.
> >
> > On Fri, Jul 24, 2020 at 2:43 PM Benson Margulies
> > wrote:
> > >
> > > +1 binding.
> > >
> > >
> > > On Thu,
+1 binding.
On Thu, Jul 23, 2020 at 5:39 PM Eric Lilja wrote:
> On Fri, Jul 24, 2020 at 12:06 AM Sylwester Lachiewicz <
> slachiew...@gmail.com>
> wrote:
>
> > +1
> >
> > in fact, in this release, based on commits, we have also fixed:
> > MSHARED-879 Reproducible builds
> > MSHARED-810 Support
id.apache.org lists bimargulies-google as an ID for me, but I don't see
write access at github.com. Does someone have to do something?
We made a community decision years ago to support slf4j. It's not helpful
to cast aspersions on it. If someone wants to lead an effort to supplant
that with log4j now that it's alive again, or even jul (please, no),
someone can start that process. Until then, using slf4j in an plugin is an
approved
Would it make sense to branch from 2.1 and do a controlled update? What
version of maven core are we willing to require?
On Wed, May 13, 2020 at 1:41 PM Benson Margulies
wrote:
> 2.1 has a terrible bug; it does not compensate for long-ago changes in
> which ArtifactItem.getClassifier() r
; On 13.05.20 01:59, Benson Margulies wrote:
> > What's current best practice for updating the versions of the test
> harness
> > and other bits and bobs?
> >
>
> the problem with Test harness is that it brings more recent versions of
> maven-core with it which is
What's current best practice for updating the versions of the test harness
and other bits and bobs?
I'm helping someone dust this off as a warm up to development in the
plugin. Could folks have a look at the JIRA and see if the feature makes
sense?
Could you send me a pointer to refresh my memory on procedures? It's been a
while ...
On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote:
> Folks,
>
> please do NOT merge via merge button in GitHub:
>
> > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master,
> origin/HEAD)
> > Merge:
I am trying to recall how to debug a Junit test that uses
AbstractMojoTestCase. Simply asking an IDE to debug the test fails with
plexus container errors. I cannot recall if these can be debugged as
ordinary unit tests somehow, or whether we need to set remote debugging
options to the surefire plug
There's a good patch in a PR. It has no test, and the author references
https://github.com/apache/maven-plugins/blame/8762d5746501b894cf766f38111fc514938be280/maven-shade-plugin/src/test/java/org/apache/maven/plugins/shade/filter/MinijarFilterTest.java
containing a commented out test case marked
Is it still non-critical if the user lacks write access to that directory?
On Sat, Feb 25, 2017 at 8:07 AM, Robert Scholte wrote:
> Hi,
>
> found a non-critical issue. It seems like with every Maven build, a new
> lib/ext/jansi-64-1-xxx.13 is generated.
> If this is a temp-file, I'd r
Then don't include it in the distro. Packaging non-standard, possibly
broken, versions in distros is not doing anyone any favors. Users are
better off just downloading for themselves.
On Mon, Feb 13, 2017 at 8:47 AM, Guo Yunhe wrote:
>> Don't. Don't do the same as done here:
>> https://www.rpmfi
How? When I declare a zip dependency on a non-reactor artifact, it is
just zip. Packaging doesn't show up in , or
is this what you are proposing?
On Thu, Feb 9, 2017 at 12:18 PM, Michael Osipov wrote:
> Am 2017-02-09 um 21:10 schrieb Benson Margulies:
>>
>> -1 to zips on th
-1 to zips on the classpath. We need to disentangle the java classpath
from the general concept of 'module X depends on module Y'. I created
quite a lot of code that uses zips as containers to pass files from
one place to another, and would be horribly broken if their transitive
dependencies starte
there is always merge --squash. Makes the master history dead simple
on the theory that no one cares about the dev history of a feature
branch.
On Mon, Jan 16, 2017 at 1:24 AM, Christian Schulte wrote:
> Am 16.01.2017 um 10:21 schrieb Stephen Connolly:
>> or if you want less commands
>>
>> git ch
+1
On Jan 4, 2017 10:03 AM, "Robert Scholte" wrote:
> +1
>
> On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Hi,
>>
>> We have collectively managed to mess up our ability to follow the original
>> release plan for 3.4.0 which was originally su
On Mon, Jan 2, 2017 at 1:38 PM, Hervé BOUTEMY wrote:
> Christian,
>
> Please read Tibor's concerns:
> - big change,
> - near release (with parallel branches for JUnit 5)
> And I'll add: noise, like addition of final, reordering of imports,
> addition/
> suppression of empty lines
>
> Please follo
The normal Apache process here is this: if someone finds a commit
sufficiently objectionable, as per CTR, they
https://www.apache.org/foundation/glossary.html#Veto it. It gets reverted
post haste, no vote is needed.
According to the Apache methodology, a change which has been made or
proposed may
There is no reason to cancel over one missing link. If there are
enough +1 votes, the vote passes. There's no need to view a -1 as a
veto, especially if it's something that can be fixed up later.
On Sun, Nov 6, 2016 at 6:22 PM, Michael Osipov wrote:
> Am 2016-11-07 um 00:13 schrieb Olivier Lamy:
I'm helping out a bit with the bnd-maven-plugin.
They are currently recursing up the chain of parents, looking at the
DOM for , to combine parent and child information.
There's
http://blog.sonatype.com/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/,
but
(a) gosh it looks
This is adapted from a class in the shade plugin
https://github.com/benson-basis/alta/blob/issue-5-include-exclude/src/main/java/com/github/veithen/alta/IncludeExcludeArtifactFilter.java
I think it would live next to:
org.apache.maven.artifact.resolver.filter.IncludesArtifactFilter
pretty happi
On Fri, Aug 5, 2016 at 10:37 AM, Christopher wrote:
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possib
We have this body of code. People in the world use it. Refactoring
this code to break its existing users, just to avoid an awkward name,
strike me as a poor use of time. My suggestion remains that we pick
some inoffensive descriptive string and use it.
I my view, we should not be inventing brand names for miscellaneous
internal pieces of Maven. We have hundreds of such pieces. Why give
nicknames to some?
On Thu, Aug 4, 2016 at 11:40 AM, Manfred Moser wrote:
> I also prefer something like a short name even if its a shortcut like Mars.
> In fact
Greg, the proposal is for the _Default ASF POM_ to be set up so that
_all_ projects would use SHA-512. This is not a question for the Maven
PMC.
On Wed, May 18, 2016 at 1:58 PM, Greg Trasuk wrote:
>
> Hi Christopher:
>
> Thanks for your involvement. Apache Maven is one of many projects at the
>
The tools jar is an old standby, do you need someone to fix a pom to
have the right profile?
On Tue, Jan 26, 2016 at 3:34 PM, Arnaud Héritier wrote:
> No feedback guys ?
>
> On Thu, Jan 21, 2016 at 11:02 PM, Arnaud Héritier
> wrote:
>
>> Build (install -Prun-its) of the PR:
>> Ok with Java 7 an
+1
On Sat, Jan 2, 2016 at 8:42 PM, Michael Osipov wrote:
> Am 2015-12-31 um 21:30 schrieb Michael Osipov:
>>
>> Hi,
>>
>> We solved 5 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12334441
>>
>>
>> There are still a couple of issues left in JIRA:
as, only it doesn't eat my machine and crash as Eclipse + M2E used to
do back before I made the switch. You have a tree of files or packages
on the left, and one or more windows of code on the right, and some
tool at the bottom.
>
> Gary
> On Dec 25, 2015 12:49 PM, "Benson Margul
Eclipse's single classpath makes it fundamentally broken with any maven
project that has test dependences. So some of us bailed to intellij long
ago. m-e-p has one set of incurable issues, and m2e, while much improved,
can still eat all your memory on a moderate project.
We've watched the lack of
to the management of classpaths by the plugins
that, well, manage classpaths. They could have options to change this
behavior in case someone really wants a war file in the classpath for
some reason, but that should not be default behavior. No need, in this
schema, to add a scope.
>
> Robert
On Sun, Dec 13, 2015 at 9:40 AM, Benson Margulies wrote:
> On Dec 13, 2015 3:25 AM, "Stephen Connolly"
> wrote:
>>
>> pom?
>
>
> 1. The feature descriptor is xml
>
> 2. I believe that this still adds transitive dependencies to the dependency
> graph
On Dec 13, 2015 3:25 AM, "Stephen Connolly"
wrote:
> pom?
>
1. The feature descriptor is xml
2. I believe that this still adds transitive dependencies to the dependency
graph.
>
> On Saturday 12 December 2015, Benson Margulies
> wrote:
>
> > Sometime
Sometimes, we want to declare a dependency without changing a classpath.
Project A builds an OSGi bundle and a Karaf feature (classifier
'feature', type 'xml').
Project B wants to consume the feature. it wants to declare the
feature descriptor as a dependency, to (a) ensure reactor order, and
(b)
Paul
>
> On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar wrote:
>
>> That's how Maven core releases were done in the early v3.0.x days.
>> Personally I think it worked very good.
>>
>> /Anders (mobile)
>> On Nov 15, 2015 15:40, "Benson Margulies
Given the number of 'burned' releases recently, I thought people might
be interested in hearing about an alternative approach.
When a Lucene dev has a sudden urge to make a release, he or she set
up a release with a version of x.y.z-RC1. This is a real release. It
goes up for a vote.
If there's s
+1
On Mon, Nov 9, 2015 at 2:44 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> someone else ?
>
> Kind regards
> Karl Heinz Marbaise
> On 11/7/15 2:21 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> Note: This is a Maven 3.0 / JDK 6 release
>>
>> We solved 6 issues:
>>
>> https://issues.apache.org/jira/s
Could some kind soul please remind me of the wiki page where we've got
a procedure for making plugins come up to the maven three base level?
I want to do it to the maven-bundle-plugin over at felix (assuming,
for the moment, that enough dependencies have been released) :-)
I recently taught the Apache Felix Maven Bundle Plugin to produce a
dependency-reduced POM. I copied some source code from the
maven-shade-plugin. When/if I update the bundle plugin to a Maven 3
base, I'd prefer to share rather than to copy.
Do we have a common practice? Is the desired process to
-1. We might want to move to 1.7, but many people are still not in a
position to use 1.8.
On Fri, Nov 6, 2015 at 7:56 AM, Attila-Mihály Balázs wrote:
> Hello,
>
> Given that we're almost in 2015, what do people think about updating the
> default source / target for maven-compiler-plugin to 1.8? (
+1
On Sat, Oct 31, 2015 at 4:48 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> JIRA Reference:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12328931
>
> Changes since the last release:
> http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-22/pom
+1. I had infra set up a staging group for us some time ago to make
this easier; you can stage all of them and test by using the repo URL
for the staging group.
On Sun, Nov 1, 2015 at 8:00 AM, Karl Heinz Marbaise wrote:
> Hi,
>
> +1 for releasing them in one go...
>
>
> On 11/1/15 10:03 AM, Hervé
Sure you can close the PR. Put 'Closes #nn.' in a commit message.
On Oct 28, 2015 4:38 PM, "Stephen Connolly"
wrote:
> I
>
> On Wednesday 28 October 2015, Michael Osipov wrote:
>
> > Am 2015-10-28 um 18:28 schrieb Stephen Connolly:
> >
> >> Thanks for contributions from non-committers go to:
> >
+1
On Tue, Oct 27, 2015 at 4:20 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> i need one more binding VOTE...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> We solved 7 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?pro
ture without
making a giant mess?
>
> --
> Regards,
> Igor
>
> On Tue, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote:
>> On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko
>> wrote:
>> > Did you really mean "the core model has to be mutable"? The rest of your
&g
On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko wrote:
> Did you really mean "the core model has to be mutable"? The rest of your
> message appears to suggest you do not want the model to be mutable, but
> I am not sure.
>
> In any case, I think the core model must not be mutable. If the core
> mo
o-decorated with
dependencyManagement locks.
>
> /Anders (mobile)
> Den 26 okt 2015 15:55 skrev "Benson Margulies" :
>
>> Folks,
>>
>> I would appreciate some assistance in thinking through the
>> implications of the use of version ranges.
>>
>&
Folks,
I would appreciate some assistance in thinking through the
implications of the use of version ranges.
As a thought experiment, consider a loosely-coupled collection of
maven project, maintained with a semver discipline.
Each component has dependencies, and those are written with ordinary
I'm on the case for the checkins. Or ducks.
On Sun, Oct 18, 2015 at 3:45 PM, Michael Osipov wrote:
> Hi,
>
> The vote has passed with the following result:
>
> +1 (binding): Karl Heinz Marbaise, Benson Margulies, Daniel Kulp, Hervé
> Boutemy
>
>
> I will prom
I never suggested that it should hinder the release. I was able to
test it myself, it's my co-worker who couldn't join in. You do have a
+1 from me, I look forward to the announcement.
On Sun, Oct 18, 2015 at 8:18 AM, Michael Osipov wrote:
> Am 2015-10-16 um 15:01 schrieb Ben
Eclipse checks that sort of signature on jar files, as I recall.
On Sun, Oct 18, 2015 at 2:14 AM, Hervé BOUTEMY wrote:
> Hi,
>
> Perhaps the "code signing" feature for jars should be explained, since we
> already have maven-gpg-plugin [1] to sign code, that is used for years with
> great success.
The Apache Maven team is pleased to announce the release of the Apache
Maven Release Component, version 2.5.3
This component automates tagging and preparing releases, and includes
the maven-release-plugin.
http://maven.apache.org/maven-release/
You should specify the version in your project's pl
This vote passes:
+1 binding: bimargulies, khmarbais, herve.boutemy, rfscholte
+1: tibordigana
On Sat, Oct 17, 2015 at 3:45 PM, Robert Scholte wrote:
> +1
>
> Op Wed, 14 Oct 2015 14:05:18 +0200 schreef Benson Margulies
> :
>
>> Hi,
>>
>> We solved 2 issues:
&g
+1 binding. Checked sum, tested the other day by running plugins using it.
On Sat, Oct 17, 2015 at 10:18 AM, Karl Heinz Marbaise wrote:
> Hi,
>
> here we need two more binding VOTE's..
>
> Kind regards
> Karl Heinz Marbaise
> On 10/16/15 11:54 AM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> here i
he regular release, or
>> 2. start Take 3 if we want me to fix something.
>>
>> Honestly making the release Vote of surefire is more painful than
>> maven-shared-* staff.
>>
>> Enjoy the Vote ☺
>>
>>
>> On Fri, Oct 16, 2015 at 7:25 PM, Benson Marg
On Fri, Oct 16, 2015 at 1:23 PM, Andreas Gudian
wrote:
> Benson, is there a full stack trace in the XML test report? I would have
> expected that we shorten out most of the stack traces on the console
> output...
No. That's why I complained.
>
> 2015-10-16 16:35 GMT+02
On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana wrote:
> Can you give me the link?
https://github.com/ops4j/org.ops4j.pax.exam2/commit/c466e58cae6c2275a38bc2712cc76a70f768d769
>
> On Fri, Oct 16, 2015 at 4:27 PM, Benson Margulies [via Maven] <
> ml-node+s40175n5849346...@n5.na
I've committed the fix to the master for pax-exam.
On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies
wrote:
> On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
> wrote:
>> try to debug this stack part of ProbeRunner.
>> What version of pax-exam-spi you use?
>
> 4.6.0
anager.java:239)
> at
> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
> - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>
>
> On Fri, Oct 16,
vate it explicitly when testing staged stuff.
Me too. That's what my co-worker was trying to do.
>
> /Anders (mobile)
> Den 16 okt 2015 15:35 skrev "Benson Margulies" :
>
>> Anders, I added a pluginRepository for the stage to my settings.xml.
>> As far as I
Step 1: here's the backtrace of the InvocationTargetException. It's
caused by an IllegalArgumentException, which I will break on next.
That is in turn, as you supposed, caused by the use of the file:
jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/de
n target/classes/, use surefire-plugin because that's what the
> unit tests do.
>
>
> On Fri, Oct 16, 2015 at 3:04 PM, Benson Margulies
> wrote:
>
>> Um, maybe I voted too soon. Using the new fai
ying to add one?
On Fri, Oct 16, 2015 at 9:19 AM, Anders Hammar wrote:
> It looks like a specific staging repo is accessed (look at the URL in the
> end). As the parent has been released it is no longer available there.
>
> /Anders (mobile)
> Den 16 okt 2015 15:01 skrev "Benson
Um, maybe I voted too soon. Using the new failsafe plugin, I get the
following, and no backtrace, on each of my integration test classes.
Any suggestions, Tibor?
---
Test set: com.basistech.ws.itest.FrontEndIT
---
Maven-plugins 28 is released, of course; what's up? It worked for me,
but not for one of my co-workers.
$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Parent for Text Analytics Maven Project
On Fri, Oct 16, 2015 at 8:20 AM, Tibor Digana wrote:
> https://repository.apache.org/content/repositories/maven-1222
Tested on my current major project. No issues. +1 binding.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apac
On Fri, Oct 16, 2015 at 5:53 AM, Karl Heinz Marbaise wrote:
> http://maven.apache.org/guides/development/guide-testing-releases.html
+1
Ran it on one of my projects, where it promptly exploded due to
checkstyle incompatibilities. So I know it worked.
--
On Wed, Oct 14, 2015 at 6:41 PM, Olivier Lamy wrote:
> did you create a branch with this change?
> At least to help the guys who worked on that...
Since it was a single commit, I didn't think it necessary. I could
either reapply it to trunk or make a branch; to some extent I'm
waiting to hear fr
on,
then let's not call it a policy. Let's call it a working principle.
I'm not trying to coerce anyone; the Apache veto/revert mechanism for
CTR is perfectly sufficient, as per your remark about 'fix it and move
on.' I perceive a presumption of 'leave it to the person who wa
I'd like to open a discussion of a possible policy.
The policy would look something like the following:
___
All of the projects managed by the Maven PMC are maintained in a
releasable condition. If a developer wants to make a change that will
result in an a component being unreleasable for any s
Hi,
We solved 2 issues:
Release Notes - Maven Release Plugin - Version 2.5.3
** Bug
* [MRELEASE-921] - perform goal doesn't support providerImplementation
* [MRELEASE-925] - Old version of plexus utils forced here causes failures
There are still a couple of issues left in JIRA:
https:
+1.
On Tue, Oct 13, 2015 at 4:08 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> I need two more binding VOTEs...
>
> Kind regards
> Karl Heinz Marbaise
> On 10/13/15 7:26 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> here is my +1.
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>> On 10/11/15 10:17 PM,
On Tue, Oct 13, 2015 at 10:29 AM, Jason van Zyl wrote:
>
>> The second is the ease of messing up.
>>
>> The maven-release project is set up as a ticking bomb under this
>> regime. The project uses dependencyManagement to lock to a version; so
>> if any dependency requires a newer version, the resu
onger; the difference
between 'all 12 modules say version=N' and 'the parent has
depManagement that says N' needs to be cast into higher relief.
On Tue, Oct 13, 2015 at 10:14 AM, Benson Margulies
wrote:
> I am perfectly willing to stand corrected; I started this email thread
I am perfectly willing to stand corrected; I started this email thread
to get some insight. I may have misheard Stephen over the noise of the
other runners.
However, I will say that I don't like two aspects of this, and I
wonder if they could be improved.
The first is documentation.
https://mave
I got a lecture on this from Stephen Connolly, who took some time out
from Marathon training to educate me. We're all wrong.
The only way to 'lock down' a version is to use a range: [foo). All
other versions are 'recommended'.
If there are no ranges, then the resolution algorithm decides what
ver
The Apache Maven team is pleased to announce the release of the Apache
Maven Plugins parent POM, version 28.
This POM is the common parent of all of the plugins maintained by the
Apache Maven PMC, and, as such, is of limited use to developers
outside of the Maven project. See the svn history of
ht
;> Hi,
>>
>> +1 ...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 10/11/15 2:56 AM, Benson Margulies wrote:
>>
>>> Hi,
>>>
>>> 2 changes in JIRA. Many other commits.
>>>
>>>
>>> ** Bug
>>&
I am now -1 on commit
1677765 chrisgwarp 1.9.5-SNAPSHOT
from maven-release. Back in May, this made source changes to require
an unreleased, incompatible, SCM version. Now I can't release release
to fix a critical problem. Further, since it involves this level of
API dependency, I think it req
To me, it's a pretty urgent situation when the current version of the
release plugin blows up; what if we end up unable to release the
release plugin? So, absent any objections or further discussion of the
plexus-utils version, I intend start the process for 2.5.3 tomorrow,
since I already made the
level, one must have pluginManagement
> to pick up the correct plexus-util (3.0.15)
Dan, pluginManangement != dependencyManagement.
>
>
> -Dan
>
> On Sun, Oct 11, 2015 at 5:22 PM, Benson Margulies
> wrote:
>
>> On Oct 11, 2015 6:59 PM, "Dan Tran" wrote
same things in the
regular dependency element does.
What do you expect to happen if two dependencies disagree on version?
> If it not so, it is a very serious miss understanding for lots of users
>
> Can someone confirm?
>
> -Dan
>
> On Sun, Oct 11, 2015 at 1:07 PM, Benson Margulie
On Sun, Oct 11, 2015 at 6:54 PM, Karl Heinz Marbaise wrote:
> Hi Benson,
>
> sorry...oversight this..my fault...
I don't know why you are apologizing; the JIRA needed fixing, I fixed it.
>
> (It is too late)..
>
> Kind regards
> Karl Heinz Marbaise
> On 10/12/15
As far as I knew, JIRA would only include resolved issues in a
release. it used to complain if an unresolved issue was tagged with a
release that one was releasing.
The log shows that Robert did this. So I marked it resolved in JIRA.
---
I am confused and away from my computer. I will try to clarify later
On Oct 11, 2015 5:57 PM, "Karl Heinz Marbaise" wrote:
> Hi Benson,
>
> On 10/11/15 11:39 PM, Benson Margulies wrote:
>
>> Hey, I just assume that the JIRAs are correct. What component do you
>>
pa?projectId=12317922&version=12331490
>
> is MSHARED-420 wrongly assigned to maven-dependency-tree 3.0, cause it is
> not part of the release nor it is it ready ?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/10/15 9:04 PM, Benson Margulies wrote:
>>
>> T
pendencies
>
> -D
>
>
>
>
> On Sun, Oct 11, 2015 at 12:07 PM, Tibor Digana
> wrote:
>
>> The problem is that plexus-utils:3.0.10 does not have
>> org/codehaus/plexus/util/xml/
>> pull/EntityReplacementMap
>> It starts since 3.0.13. Maybe 3.0.1
The fully-document JIRA is MRELEASE-925.
On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies wrote:
> This is presumably a core issue, won't someone comment who delves into
> that part of the salt mine?
>
>
> On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran wrote:
>> I encounte
; release plugin.
>>
>>
>> On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies
>> wrote:
>> > This happens trying to release maven-plugins version 28, with 3.2.5
>> > and 3.3.1, even after cleaning my local repo.
>> > That class is not in plexus
ome JIRAs that help get us closer to
releasable plugins, I'll be happy to look at them.
>
> On Sun, Oct 11, 2015 at 1:05 PM, Benson Margulies [via Maven] <
> ml-node+s40175n5848364...@n5.nabble.com> wrote:
>
>> Just writing for myself, I want to explain why I am pushing jus
On Sat, Oct 10, 2015 at 11:31 PM, Robert Scholte
>> wrote:
>>
>>> maven-common-artifact-filters shouldn't be a problem.
>>>
>>> but the API for maven-artifact-transfer isn't stable enough yet, so
>>> please
>>> don't.
>>&
for that rush
> at the moment...
>
>
> On 10/11/15 2:12 AM, Benson Margulies wrote:
>>
>> Hi,
>>
>> We solved 5 issues:
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12331499&styleName=Text&projectId=12317922&a
I guess I swapped two of them in reading the email. I will unwind.
On Oct 11, 2015 1:53 AM, "Tibor Digana" wrote:
> @Benson
> That's good that you take this responsibility but I guess you rush too much
> with this artifact since we still use the old maven-shared-utils:0.7 in it.
> Normally I am t
Hi,
2 changes in JIRA. Many other commits.
** Bug
* [MPOM-88] - yyy-LATEST deployment URL breaks site parent reference menu
* [MPOM-89] - Unbalanced versions of Maven Invoker Plugin
There are no pending issues I can find in JIRA for this pom.
Staging repo:
https://repository.apache.or
I see that the bad version of plexus-utils is called out in the
maven-release parent pom. I patched it in place in my local repo, and
now I can run the release of maven-plugins. I'll write a JIRA for the
release plugin.
On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies wrote:
> This
-utils in the
declaration of the release plugin... but that seems extreme in the
maven-plugins parent pom.
I've seen this sporadically for weeks, but it's always gone away when
switch maven versions until now.
On Sat, Oct 10, 2015 at 8:19 PM, Benson Margulies wrote:
> mvn release:prepa
mvn release:prepare with 3.2.5
➜ maven-plugins mvn release:prepare
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Apache Maven Plugins 28-SNAPSHOT
[INFO]
Hi,
We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12331499&styleName=Text&projectId=12317922&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7C8959a4aa0ef1e581a93c2903df89c21523603417%7Clin
There are still a couple of issues left in JIRA:
https://issues.apache.or
1 - 100 of 1315 matches
Mail list logo
