Are you sure that no other Java SDK exists on your workstation?
Ron
On 24/07/2013 12:44 PM, Dhiman wrote:
Here is code snippet for source and target but this didn't help me
build
plugins
plugin
Hello all,
During my release :perform, maven block on a javadoc instruction and I dont
understand why it block indefinitely
the line where my process block is:
[INFO] [DEBUG] /usr/lib/jvm/jdk1.6.0_37/jre/../bin/javadoc @options
@packages
According to following debug log traces
I'm still struggling - I now think that testng really is in mixed mode and
tries but fails to execute the jUnit test - maybe, because they use a
special runner.
Is there any way to disable the mixed mode for a maven build (entirely)?
How can I pass that property testng.mixed=false to testng
Hello,
In Java 7u25 the following change has been introduced:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/no_redeploy.html
This requires that all the jars included in my webstart application have 2
extra entries in their manifest files.
I build and I sign the jars contained in my
Hi,
In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the
default version for local builds, producing official builds only through
our CI server. This works well but during local builds, Maven will
needlessly look for these versions in external repositories, slowing the
build
Sure. Build in offline mode:
mvn install -o
It may not work everytime, but maven will complain loud enough, if it can't
find an artifact in your local repo.
Andreas
2013/7/25 Kristian Freed kristian.fr...@gmail.com
Hi,
In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the
There are two schools of thought amongst the current members of this
projects PMC.
Without wanting to deliberately tip my hand and reveal where my opinion is,
we would like to solicit the opinions if the community that we serve.
Please give us your thoughts.
The topic is essentially:
Do you
Unfortunately we also have other internal libraries on SNAPSHOT versions
that do need to be retrieved from the repository, so going offline
completely is not an option.
Kristian
On Thu, Jul 25, 2013 at 2:12 PM, Andreas Dolk
andreas.dolk.mo...@googlemail.com wrote:
Sure. Build in offline
That whole section I find pretty bizarre.
- Apache is about (open-source) software.
- Writing code is *good*.
- Forks are *good*
*
*
I'm put in mind of Linus' talk about why git distribution is so important -
that 'if you don't think I'm doing a good job, then you can just take your
code from
There is clearly an underlying issue that prompts this question.
My understanding is that members of the PMC are selected by other
members of the PMC.
There is no democratic will of the people involved.
I am not sure how people get kicked off the PMC.
What are the official grounds for asking
Hi Stephen and everyone,
I largely agree with Nigel, and would add that in general, bureaucratic
rules prohibiting various (often technically and/or socially sound) actions
such as forking are a great way to ensure that skilled people distance
themselves from the organization (i.e., quit the PMC,
Maven has a fair number of conventions that are respected by a lot of its code.
Trying to work against those conventions is likely to cause problems for you.
Maybe if you explain what your goal is, we can suggest a more Maven-like way of
accomplishing the same thing.
On Jul 25, 2013, at 8:58
As a Maven user I think that everybody who is working on a project should
behave the same. Hence, I would say, PMC members should rather certainly
demonstrate how to live the community rules.
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
On Thursday, 25 July 2013, Curtis Rueden wrote:
Hi Stephen and everyone,
I largely agree with Nigel, and would add that in general, bureaucratic
rules prohibiting various (often technically and/or socially sound) actions
such as forking are a great way to ensure that skilled people distance
Are you at least proxying the external Maven repos through your own
repo. That will speed things up.
Ron
On 25/07/2013 9:58 AM, Kristian Freed wrote:
Unfortunately we also have other internal libraries on SNAPSHOT versions
that do need to be retrieved from the repository, so going offline
I think I'm with Ron Wheeler here.
I'd add though: are you a “Project Manager” if you don't contribute to
the project the changes you're doing in a fork? My gut feeling would
be “no”, but that'd be ignoring the amount of contributions to the
project itself (I know who you're talking about, but I
So what's outlined in those paragraphs have counter examples at the ASF. I do
not believe it is a bad thing to have alternative distributions or forks, and
it doesn't matter where they are. What you are saying is that committers are
obliged to share all their work with other committers. Which
The section that was added below has nothing to do with the rest of
the document. It should be reverted, as it is basically nonsense as
Jason has just pointed out.
Maven has lots of other problems. This really doesn't seem like one
anyone should be spending any time or energy on.
Stephen
On
Hi,
For the record, the two pages above were patched.
TL;DR *don't name your maven plugin maven-foo-plugin but foo-maven-plugin.
Legally compulsory, not just a recommendation.*
Cheers
Le 12 juin 2013 14:13, Baptiste MATHUS bmat...@batmat.net a écrit :
2013/6/12 Stephen Connolly
As part of trying to kick this project back to life, we need to grow both
committers and the PMC.
One of the issues with growing either is determining if potential
candidates are the right sort of person.
There is a disagreement in the PMC as to whether dedication to the Maven
project community
Hi Kristian,
In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the
default version for local builds, producing official builds only
through our CI server. This works well but during local builds, Maven
will needlessly look for these versions in external repositories,
slowing
Hi,
I use xxx-LOCAL for this kind of thing, since they are not considered as
snapshots, maven won't try everyday to download a new local version.
Vincent
2013/7/25 Ron Wheeler rwhee...@artifact-software.com
Are you at least proxying the external Maven repos through your own repo.
That will
On Jul 25, 2013, at 12:03 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
As part of trying to kick this project back to life, we need to grow both
committers and the PMC.
You don't need either. You need people who do work. People who do work may
happen to be a committer or
+1
The candidates should be people who contribute in terms of code/patch.
-Original Message-
From: Jason van Zyl [mailto:ja...@tesla.io]
Sent: Thursday, July 25, 2013 9:56 AM
To: Maven Users List
Subject: Re: [DISCUSS] Should the Maven PMC be an example of how we want the
Maven
I would suggest using msysgit with plink and pageant for ssh
authentication, worked like a charmed for me.
On Jul 23, 2013 4:38 PM, Adrien Ruffié adriennolar...@hotmail.fr wrote:
Same thing maven chain parameter like ssh://git:adryen31:mypassword@rd1
/myapp.git
Just stupid parameters I think
The Apache Foundation values Community over Code.
Merit is thus not just a question about writing the best code but helping
and fostering the community around that code.
This in deciding committers we need people who are good enough *both*
socially and technically. This can be a mix, eg one very
All what-ifs. The decisions, as I said, should be made on the typical 6-12
month period of contribution. Everything is encapsulated there: the code done,
how it was introduced, how it was delivered and if there were no issues then
that can be the basis to make a decision. Everything outside the
I also find it quite odd an almost offensive to the open source community
in general to state that a PMC member shall not be allowed to fork too much
around. It's not a marriage, you know ;-).
I tend to agree with Jason: the PMC needs people who *do* stuff, meaning:
* bring the project foward
This community is created around maven, which is a software (code) written in
java.
Lot of people use maven (including me) on a daily basis, because of the value
it provides.
We use it because the code works.
Some of the users, eventually become contributors and committers.
Just like many
+1
On 25/07/2013 11:16 AM, Jason van Zyl wrote:
So what's outlined in those paragraphs have counter examples at the ASF. I do
not believe it is a bad thing to have alternative distributions or forks, and
it doesn't matter where they are. What you are saying is that committers are
obliged to
Well, I guess you found a bug. TestNG should be able to handle JUnit4
tests, and thus the surefire TestNG provider should be able to hand over
the tests in a way that TestNG understands what we want it to do.
Would you be so kind and file a bug at
https://jira.codehaus.org/browse/SUREFIRE? No
I gather that the process is a simple vote by the existing members.
Perhaps this is one of those things that is best left uncodified and
allow each person who has to make the decision to chose their own criteria.
Clearly people like to work with people that they find intelligent,
people
The last thing that you need is a bunch of smart committed people who
talk about doing stuff the Apache way but don't actually write code or
participate in supporting users.
If someone is writing code that works, faster than the rest of the team
can read it, you are in a great position. Get
On Thursday, 25 July 2013, Ron Wheeler wrote:
The last thing that you need is a bunch of smart committed people who talk
about doing stuff the Apache way but don't actually write code or
participate in supporting users.
The key thing is it is not just about writing code.
We need people to
wayne, thanks a lot for your response, it helped to figure out what's going
on.
it's indeed javac that aborts (yes aborts, no error, it just quits).
something with annotations in enum constructors, it's not reported to the
javac mailing list
I hope it's a bug and that it's easy to fix :) Would be great if I could
keep TestNG and use jnario in the same project!
Here is the ticket reference: https://jira.codehaus.org/browse/SUREFIRE-1019
Thanks!
Andreas
2013/7/25 Andreas Gudian andreas.gud...@gmail.com
Well, I guess you found a
wayne, thanks a lot for your response, it helped to figure out what's going
on.
I'm very glad to hear it!
i was wondering if maven could detect that javac does not end successfully,
and then abort and blame the compilation directly instead of building an
I agree this sounds like a
On 26 July 2013 03:25, Andreas Gudian andreas.gud...@gmail.com wrote:
I tend to agree with Jason: the PMC needs people who *do* stuff, meaning:
* bring the project foward (with discussions like this one, or the
JDK5/JDK6 threads).
* keep a close eye on commits.
* keep a very close eye on
Hi,
I think the point is quite simple.
I agree with Jason that work should be the main criteria if not the only
one.
But as Stephen reminds, we should define work in a larger general sense
than just code. Working for the community as worshipped by the ASF can be
pushing code, sure, but also
Perhaps we could reframe the question a little then (as people seem to be
testing hung up on the committed wording)...
Should the PMC encourage people experimenting on new improvements to Maven
to do that work at the ASF? And if so, should they then practice what they
preach, and ensure that any
On 25 July 2013 22:17, Paul Benedict pbened...@apache.org wrote:
Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
On 7/25/13 4:17 PM, Paul Benedict wrote:
Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external
Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external contributions. Isn't that the heart of this
Agreed. I'll tip my hand and give my opinion: PMC members should have an
Apache first mentality. They are gatekeepers and guardians of their
project. Spinning off critical code to other OSS organizations should be
frowned upon -- it splits the development and wider community into smaller
pieces.
Private Sector Usage of Apache code:
Sonatype is the second organization (that I know of) to leverage existing ASF
code to engage Paying Customers
In last 10 years Paul F (dba WS02) leveraged the entire axis project for
Customised SAAS Solutions for HealthCare as well as Financial Services
Maven is open source and anyone can do whatever they want with it.
That is the whole point of the Apache license.
If the code splits off and a new open source product emerges that is
better than Maven, then we all win.
To prevent this, the Maven PMC has to make the right choices about the
On 25/07/2013 5:32 PM, Stephen Connolly wrote:
On 25 July 2013 22:17, Paul Benedict pbened...@apache.org wrote:
Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret
On 25/07/2013 5:05 PM, Stephen Connolly wrote:
Perhaps we could reframe the question a little then (as people seem to be
testing hung up on the committed wording)...
Should the PMC encourage people experimenting on new improvements to Maven
to do that work at the ASF? And if so, should they
48 matches
Mail list logo
