I doubt this is possible. We used to support building Maven core with Ant,
but IIRC a fairly recent discussion resulted in a decision to stop
supporting that. So you need Maven installed to build Maven core. More info
here:
http://maven.apache.org/guides/development/guide-building-maven.html
/Ande
Out of curiosity, what is your usecase?
--
Regards,
Igor
On Tue, Aug 23, 2016, at 02:25 AM, Björn Höfling wrote:
> I want to build maven without haven _ANY_ maven/plugin binary. How can
> I do that?
>
> I found out that there is a build.xml and it start building a first
> version of Maven. But
I want to build maven without haven _ANY_ maven/plugin binary. How can
I do that?
I found out that there is a build.xml and it start building a first
version of Maven. But then it needs plugins to go further.
I found the plugins source here: https://maven.apache.org/plugins/
But these have only p
On 08/22/2016 10:34 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> i would like to start the release procedure for the
> maven-artifact-transfer shared component..
>
> So we have a chance to continue with outher plugins which rely on
> maven-artifact-transfer...
>
> Any objections?
No objections, jus
On Monday 22 August 2016, Karl Heinz Marbaise wrote:
> Hi Stephen,
> On 23/08/16 01:12, Stephen Connolly wrote:
>
>> On Monday 22 August 2016, Christian Schulte wrote:
>>
>> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
>>>
This is why I said that the v5 pom (which v4.1 is... just under a
when we put "build-pom vs consumer-pom" in place, we don't need to publish
build poms in the repository: the repository is here only to consume already-
built artifacts as dependencies, then with their consumer pom, then without
newer Maven version prerequisites (= what we want: let people consum
Hi Stephen,
On 23/08/16 01:12, Stephen Connolly wrote:
On Monday 22 August 2016, Christian Schulte wrote:
Am 08/22/16 um 09:08 schrieb Stephen Connolly:
This is why I said that the v5 pom (which v4.1 is... just under a
different
name) would have to be deployed separately with a *best effort
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/110
@justinharringa
We are close to cut release version 2.19.2. Only 2 issues are still open
and other critical/blocker issues must be fixed in 2.19.3.
---
If your project is set up for it,
Tested with Java 8, Maven 3.4.0-SNAP, a half dozen projects with
normal usage, nothing exotic.
+1 non-binding
On Mon, Aug 22, 2016 at 4:01 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> We solved 32 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12331760
>
Github user justinharringa commented on the issue:
https://github.com/apache/maven-surefire/pull/110
@Tibor17 I'm also broken on this.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this fea
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/113
@kgyrtkirk Please close the PR. The code was merged with master. Thx for
contributing!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
On Monday 22 August 2016, Christian Schulte wrote:
> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> > This is why I said that the v5 pom (which v4.1 is... just under a
> different
> > name) would have to be deployed separately with a *best effort*
> translation
> > down to the 4.0.0 model deplo
Hi,
i would like to start the release procedure for the
maven-artifact-transfer shared component..
So we have a chance to continue with outher plugins which rely on
maven-artifact-transfer...
Any objections?
Kind regards
Karl Heinz Marbaise
Hi,
We solved 32 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12331760
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/81
@jimma
Please add a test in `maven-surefire-report-plugin/src/test/java/../`
In `maven-surefire-report-plugin/src/test/resources` you can find xml files
used in the tests. I guess you w
Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> This is why I said that the v5 pom (which v4.1 is... just under a different
> name) would have to be deployed separately with a *best effort* translation
> down to the 4.0.0 model deployed at the standard coordinates.
>
> The problem then becomes th
https://github.com/jieryn/maven-3.4.0-testing
On Mon, Aug 22, 2016 at 9:37 AM, jieryn wrote:
> Sure, here is an example project boiled down to the minimum. The
> arquillian module demonstrates the problem, and it is a commonly
> recommended way by RedHat JBoss / Arquillian project to use
> scope=
Sure, here is an example project boiled down to the minimum. The
arquillian module demonstrates the problem, and it is a commonly
recommended way by RedHat JBoss / Arquillian project to use
scope=import for these bom dependency concentrators.
After investigation, I find that several of these boms
This is why I said that the v5 pom (which v4.1 is... just under a different
name) would have to be deployed separately with a *best effort* translation
down to the 4.0.0 model deployed at the standard coordinates.
The problem then becomes that we are deploying now two poms for everything,
a 4.0.0
19 matches
Mail list logo
