Re: maven errors on xml security package

[Ron Wheeler]

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  and  but this didn't help me





org.apache.maven.plugins
maven-compiler-plugin
2.4

1.6
1.6



 



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-errors-on-xml-security-package-tp117907p5765081.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any reason ant should compile faster?

[Ron Wheeler]

I suppose that at this time the best that you can do is break out the 
clean bits into small projects and leave the rest as one big compile.


Ron

On 25/07/2013 12:43 AM, Russell Gold wrote:

It builds now because Javac is able to handle this case - as long as it all 
happens in the same compile. For those of us used to older languages that 
compiled one class at a time under the covers, and proceeded in order through 
each source file, it sounds odd, but javac has been doing this since at least 
1.02.

Short answer: I cannot break the graph at present, so it all has to happen in 
one compile - and that's really unfortunate as the coupled classes include half 
of two major subsystems, a third of another, and bits and pieces of a dozen 
more.

It's very frustrating.

On Jul 25, 2013, at 12:34 AM, Ron Wheeler  
wrote:


On 24/07/2013 10:56 PM, Russell Gold wrote:

Exactly. Which I cannot do because these classes are public and our customers 
rely on them. If I break the graph, that means changing a behavior that a 
customer might be using, and that would be a serious problem.

I am pushing to deprecate the entire graph and provide a completely different 
api that won't have these problems, but even if I get that approved, we have to 
support this for several releases.

If there's an alternative, I'm all ears.

On Jul 24, 2013, at 10:38 PM, Barrie Treloar  wrote:


On 25 July 2013 12:06, Russell Gold  wrote:

Or let me rephrase that. In simple terms, I have dependency graphs like this:

A > B > C
^   |
\--- D B-->C-->X
D-->A
or
A-->B-->C-->D-->X
or
A implements X and depends on B-->C-->D
D-->X

Ron


Short answer is:
Break the graph.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
Come read my webnovel, Take a Lemon ,
and listen to the Misfile radio play 
!







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
Come read my webnovel, Take a Lemon ,
and listen to the Misfile radio play 
!








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Changes in how exclusions are applied transitively ?

[Grégory Joseph]

Hey there,

I can't seem to find an accurate trace of this in the release notes,
so I thought I'd just ping the list - Changes in how exclusions are
applied transitively between Maven 2.2.1 and 3.1 ?

Here's a situation: A has dependencies on B and C. Both transitively
depend on D  (through X, which is irrelevant, I think)  but B excludes
it (on its dep declaration of X)

With 2.2.1, D was (wrongly imo) excluded from A (depending on
dependency order, seemingly)

With 3.1, it appears to behave "correctly".

Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now
where I need to work around the bug, currently by removing the
exclusions. That's currently OK, but at some point, those exclusions
will be re-added (in A or in a new project) and we'll face the same
issue again, without any clue as to why.

How have people dealt with this so far ?

Thanks for any hint or pointers !

-greg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven errors on xml security package

[Dhiman]

Here is code snippet for  and  but this didn't help me 





org.apache.maven.plugins
maven-compiler-plugin
2.4

1.6
1.6







--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-errors-on-xml-security-package-tp117907p5765081.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any reason ant should compile faster?

[Russell Gold]

It builds now because Javac is able to handle this case - as long as it all 
happens in the same compile. For those of us used to older languages that 
compiled one class at a time under the covers, and proceeded in order through 
each source file, it sounds odd, but javac has been doing this since at least 
1.02.

Short answer: I cannot break the graph at present, so it all has to happen in 
one compile - and that's really unfortunate as the coupled classes include half 
of two major subsystems, a third of another, and bits and pieces of a dozen 
more.

It's very frustrating.

On Jul 25, 2013, at 12:34 AM, Ron Wheeler  
wrote:

> On 24/07/2013 10:56 PM, Russell Gold wrote:
>> Exactly. Which I cannot do because these classes are public and our 
>> customers rely on them. If I break the graph, that means changing a behavior 
>> that a customer might be using, and that would be a serious problem.
>> 
>> I am pushing to deprecate the entire graph and provide a completely 
>> different api that won't have these problems, but even if I get that 
>> approved, we have to support this for several releases.
>> 
>> If there's an alternative, I'm all ears.
>> 
>> On Jul 24, 2013, at 10:38 PM, Barrie Treloar  wrote:
>> 
>>> On 25 July 2013 12:06, Russell Gold  wrote:
 Or let me rephrase that. In simple terms, I have dependency graphs like 
 this:
 
 A > B > C
 ^   |
 \--- D  I am not sure how you build them now!
> If you can build this now, you can break the graph in the same way and put 
> them in dependent projects.
> 
> How many of these cyclical graphs do you have?
> 
> Once you break the graph you should be able to end up with a set of modules 
> that the customers can continue to use as A,B,C and D even if D no longer 
> depends on A or C no longer depends on D.
> A-->B-->C-->X
> D-->A
> or
> A-->B-->C-->D-->X
> or
> A implements X and depends on B-->C-->D
> D-->X
> 
> Ron
> 
>>> Short answer is:
>>> Break the graph.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>> -
>> Come read my webnovel, Take a Lemon ,
>> and listen to the Misfile radio play 
>> !
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: Any reason ant should compile faster?

[Russell Gold]

Hi Curtis, sadly, it's in the API. I've oversimplified. In general, one of the 
classes in the chain actually has direct API references to hundreds of others. 
It turns out that at least some of the links are through deprecated classes. I 
am hoping that in the next version, we can remove them - and then see if that 
makes things more manageable. I'm not hopeful, though.

- Russ

On Jul 24, 2013, at 11:03 PM, Curtis Rueden  wrote:

> Hi Russell,
> 
> Is the circular dependency in the API itself (i.e., method signatures) or
> merely in usage of the classes in implementation? If only usage, one
> strategy to break compile-time dependencies is the java.lang.reflect API.
> It's not ideal -- your modules will still have a runtime circular
> dependency -- but it will give you a compile-time DAG for easier Maven
> modularization.
> 
> Regards,
> Curtis
> On Jul 24, 2013 9:58 PM, "Russell Gold"  wrote:
> 
>> Exactly. Which I cannot do because these classes are public and our
>> customers rely on them. If I break the graph, that means changing a
>> behavior that a customer might be using, and that would be a serious
>> problem.
>> 
>> I am pushing to deprecate the entire graph and provide a completely
>> different api that won't have these problems, but even if I get that
>> approved, we have to support this for several releases.
>> 
>> If there's an alternative, I'm all ears.
>> 
>> On Jul 24, 2013, at 10:38 PM, Barrie Treloar  wrote:
>> 
>>> On 25 July 2013 12:06, Russell Gold  wrote:
 Or let me rephrase that. In simple terms, I have dependency graphs like
>> this:
 
 A > B > C
 ^   |
 \--- D >> 
>>> Short answer is:
>>> Break the graph.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>> 
>> -
>> Come read my webnovel, Take a Lemon ,
>> and listen to the Misfile radio play <
>> http://www.gold-family.us/audio/misfile.html>!
>> 
>> 
>> 
>> 
>> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: Any reason ant should compile faster?

[Ron Wheeler]

On 24/07/2013 10:56 PM, Russell Gold wrote:

Exactly. Which I cannot do because these classes are public and our customers 
rely on them. If I break the graph, that means changing a behavior that a 
customer might be using, and that would be a serious problem.

I am pushing to deprecate the entire graph and provide a completely different 
api that won't have these problems, but even if I get that approved, we have to 
support this for several releases.

If there's an alternative, I'm all ears.

On Jul 24, 2013, at 10:38 PM, Barrie Treloar  wrote:


On 25 July 2013 12:06, Russell Gold  wrote:

Or let me rephrase that. In simple terms, I have dependency graphs like this:

A > B > C
^   |
\--- D B-->C-->X
D-->A
or
A-->B-->C-->D-->X
or
A implements X and depends on B-->C-->D
D-->X

Ron


Short answer is:
Break the graph.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
Come read my webnovel, Take a Lemon ,
and listen to the Misfile radio play 
!








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any reason ant should compile faster?

[Curtis Rueden]

Hi Russell,

Is the circular dependency in the API itself (i.e., method signatures) or
merely in usage of the classes in implementation? If only usage, one
strategy to break compile-time dependencies is the java.lang.reflect API.
It's not ideal -- your modules will still have a runtime circular
dependency -- but it will give you a compile-time DAG for easier Maven
modularization.

Regards,
Curtis
 On Jul 24, 2013 9:58 PM, "Russell Gold"  wrote:

> Exactly. Which I cannot do because these classes are public and our
> customers rely on them. If I break the graph, that means changing a
> behavior that a customer might be using, and that would be a serious
> problem.
>
> I am pushing to deprecate the entire graph and provide a completely
> different api that won't have these problems, but even if I get that
> approved, we have to support this for several releases.
>
> If there's an alternative, I'm all ears.
>
> On Jul 24, 2013, at 10:38 PM, Barrie Treloar  wrote:
>
> > On 25 July 2013 12:06, Russell Gold  wrote:
> >> Or let me rephrase that. In simple terms, I have dependency graphs like
> this:
> >>
> >> A > B > C
> >> ^   |
> >> \--- D  >>
> >> How do I put these classes into separate modules?
> >
> > Short answer is:
> > Break the graph.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> Come read my webnovel, Take a Lemon ,
> and listen to the Misfile radio play <
> http://www.gold-family.us/audio/misfile.html>!
>
>
>
>
>

Re: Any reason ant should compile faster?

[Russell Gold]

Exactly. Which I cannot do because these classes are public and our customers 
rely on them. If I break the graph, that means changing a behavior that a 
customer might be using, and that would be a serious problem.

I am pushing to deprecate the entire graph and provide a completely different 
api that won't have these problems, but even if I get that approved, we have to 
support this for several releases.

If there's an alternative, I'm all ears.

On Jul 24, 2013, at 10:38 PM, Barrie Treloar  wrote:

> On 25 July 2013 12:06, Russell Gold  wrote:
>> Or let me rephrase that. In simple terms, I have dependency graphs like this:
>> 
>> A > B > C
>> ^   |
>> \--- D > 
>> How do I put these classes into separate modules?
> 
> Short answer is:
> Break the graph.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: Any reason ant should compile faster?

[Barrie Treloar]

On 25 July 2013 12:06, Russell Gold  wrote:
> Or let me rephrase that. In simple terms, I have dependency graphs like this:
>
> A > B > C
> ^   |
>  \--- D 
> How do I put these classes into separate modules?

Short answer is:
Break the graph.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any reason ant should compile faster?

[Russell Gold]

Or let me rephrase that. In simple terms, I have dependency graphs like this:

A > B > C
^   |
 \--- D  
> On Jul 24, 2013, at 8:36 PM, Ron Wheeler  
> wrote:
> 
>> 
>> On 24/07/2013 4:40 PM, Russell Gold wrote:
>>> Oh, you underestimate the coupling of this code. Yes, there are packages, 
>>> but the classes in those packages reference one another willy-nilly. It's 
>>> not a problem with recompiling - it's that there don't appear to be any 
>>> good, sensible subset of classes in this group of 10,000 or so which can be 
>>> compiled on their own. This set of 4000 appears to be the minimum of what's 
>>> left.
>>> 
>>> And worse, it appears that we published the main classes responsible for 
>>> doing the coupling - and our customers use them in their own scripts.
>>> 
>> This does not mean  that they require recompiling  in a single Maven project.
> 
> What am I missing? If I compile the classes I want, I get the others because 
> of compile dependencies. If I compile some of the others instead, I still get 
> them all. How do I not compile them in a single maven project?
> 
> Essentially, there is a backbone of classes, all of which refer to a certain 
> few classes - and those few classes refer to all the rest.
> 
> The comment about customers using them was just an explanation of why we 
> can't just refactor out the dependencies. The public classes are the ones 
> that contain the dependencies.
> 
>> 
>>> The architect responsible for this mess left the company ten years ago, 
>>> shortly after putting it in place over the objections of most of the senior 
>>> staff, and we haven't been able to remove it.
>>> 
>> You could start by breaking the whole mess into packages that live in a 
>> single project.
>> If you  get down to 80-100 Maven projects, you will at least have a start on 
>> a cleanup and a way to reduce the need to compile 4000 classes at once.
> 
> We do use multiple projects. This blob (which is actually what we call it) 
> represents about half the system, and a third of those participate in the 
> tight coupling. Beyond that, we have about 100 separate project that are 
> currently in ant, and are due to convert.
> 
>> 
>> Our biggest application was made up of 90 Maven projects but most major 
>> revisions only required changes to 10-20 Maven projects and we edited, 
>> compiled and tested each project individually even if it depended on other 
>> jars.
>> We had designed it from the start as a layered stack so our initial 
>> packaging into Maven projects made sense but we did many refactoring over 
>> the years as we went through major revisions and changed our views about how 
>> to structure the application.
>> 
>> Maven is designed to support multi-project applications.
>> 
>> Ron
>>> Russ
>>> 
>>> On Jul 24, 2013, at 3:28 PM, Ron Wheeler >> > wrote:
>>> 
 On 24/07/2013 12:35 PM, Russell Gold wrote:
> I wish I could break it up. Among the problems with this code is the 
> extreme bit of coupling. The scripts list 300 files to compile because 
> that's all that we would have wanted, but they pull in other files, which 
> pull in yet others. Trying to compile this fairly small subsystem winds 
> up building about a third of the entire project.
 Pulling in classes does not mean recompiling them.
 Once you have compiled the dependencies and aggregate them into jars, they 
 can be referenced without recompiling them.
 This will speed things up tremendously.
 
 Do you at least have packages to use as a starting point?
 
 Ron
> 
> But I will definitely look at the options and see what I can learn from 
> them; thanks for the suggestions.
> 
> Russ
> 
> On Jul 24, 2013, at 12:31 PM, Wayne Fay  > wrote:
> 
>>> The case I'm wondering about now is one where we have over 10,000
>>> source files in a directory, and compile them bit-by-bit. One step 
>>> specifies
>>> about 300 files, and thanks to javac dependency logic, actually compiles
>>> about 4000 files in ant.
>> Is there any way you can break that into 10 projects with 1k files
>> each, or 20 projects with 500 files each, etc? I have found dramatic
>> improvements in (Java compiling) speed as a result of breaking huge
>> projects like this into a series of much smaller projects with
>> dependencies between the projects etc as needed.
>> 
>> Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
>> but I'm not sure how to explain the 20 sec vs 90 sec results you're
>> experiencing. I'd check versions of everything and flags sent to
>> compilers etc via -X.
>> 
>> Wayne
>> 
>> -
>

Re: Any reason ant should compile faster?

[Russell Gold]

On Jul 24, 2013, at 8:36 PM, Ron Wheeler  wrote:

> 
> On 24/07/2013 4:40 PM, Russell Gold wrote:
>> Oh, you underestimate the coupling of this code. Yes, there are packages, 
>> but the classes in those packages reference one another willy-nilly. It's 
>> not a problem with recompiling - it's that there don't appear to be any 
>> good, sensible subset of classes in this group of 10,000 or so which can be 
>> compiled on their own. This set of 4000 appears to be the minimum of what's 
>> left.
>> 
>> And worse, it appears that we published the main classes responsible for 
>> doing the coupling - and our customers use them in their own scripts.
>> 
> This does not mean  that they require recompiling  in a single Maven project.

What am I missing? If I compile the classes I want, I get the others because of 
compile dependencies. If I compile some of the others instead, I still get them 
all. How do I not compile them in a single maven project?

Essentially, there is a backbone of classes, all of which refer to a certain 
few classes - and those few classes refer to all the rest.

The comment about customers using them was just an explanation of why we can't 
just refactor out the dependencies. The public classes are the ones that 
contain the dependencies.

> 
>> The architect responsible for this mess left the company ten years ago, 
>> shortly after putting it in place over the objections of most of the senior 
>> staff, and we haven't been able to remove it.
>> 
> You could start by breaking the whole mess into packages that live in a 
> single project.
> If you  get down to 80-100 Maven projects, you will at least have a start on 
> a cleanup and a way to reduce the need to compile 4000 classes at once.

We do use multiple projects. This blob (which is actually what we call it) 
represents about half the system, and a third of those participate in the tight 
coupling. Beyond that, we have about 100 separate project that are currently in 
ant, and are due to convert.

> 
> Our biggest application was made up of 90 Maven projects but most major 
> revisions only required changes to 10-20 Maven projects and we edited, 
> compiled and tested each project individually even if it depended on other 
> jars.
> We had designed it from the start as a layered stack so our initial packaging 
> into Maven projects made sense but we did many refactoring over the years as 
> we went through major revisions and changed our views about how to structure 
> the application.
> 
> Maven is designed to support multi-project applications.
> 
> Ron
>> Russ
>> 
>> On Jul 24, 2013, at 3:28 PM, Ron Wheeler > > wrote:
>> 
>>> On 24/07/2013 12:35 PM, Russell Gold wrote:
 I wish I could break it up. Among the problems with this code is the 
 extreme bit of coupling. The scripts list 300 files to compile because 
 that's all that we would have wanted, but they pull in other files, which 
 pull in yet others. Trying to compile this fairly small subsystem winds up 
 building about a third of the entire project.
>>> Pulling in classes does not mean recompiling them.
>>> Once you have compiled the dependencies and aggregate them into jars, they 
>>> can be referenced without recompiling them.
>>> This will speed things up tremendously.
>>> 
>>> Do you at least have packages to use as a starting point?
>>> 
>>> Ron
 
 But I will definitely look at the options and see what I can learn from 
 them; thanks for the suggestions.
 
 Russ
 
 On Jul 24, 2013, at 12:31 PM, Wayne Fay >>> > wrote:
 
>> The case I'm wondering about now is one where we have over 10,000
>> source files in a directory, and compile them bit-by-bit. One step 
>> specifies
>> about 300 files, and thanks to javac dependency logic, actually compiles
>> about 4000 files in ant.
> Is there any way you can break that into 10 projects with 1k files
> each, or 20 projects with 500 files each, etc? I have found dramatic
> improvements in (Java compiling) speed as a result of breaking huge
> projects like this into a series of much smaller projects with
> dependencies between the projects etc as needed.
> 
> Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
> but I'm not sure how to explain the 20 sec vs 90 sec results you're
> experiencing. I'd check versions of everything and flags sent to
> compilers etc via -X.
> 
> Wayne
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
> 
> For additional commands, e-mail: users-h...@maven.apache.org 
> 
> 
 -
 Come read my webnovel, Take a Lemon ,
 and listen to the Misfile radio play 
 

Re: Maven / javac does not compile classes to target folder

[Wayne Fay]

> Any hint what to try next or an idea for a workaround much appreciated
> *sigh*

In the future, sighs are unnecessary.


> The culprit is that the compilation puts nothing into the target folder,
> even though it says it compiles the 217 classes. No error whatsoever. Maybe
> the words "Stale source detected" ring some bells?

Can you please try "mvn -X compile" and then copy/paste the javac line
that Maven shows you to see if this works/compiles fine with javac or
not? If it works with javac with no issues, then we probably have a
Maven issue somewhere. But if javac doesn't like it, then you can't
really expect Maven to do much for you.

You said it works in IntelliJ but this does not necessarily tell me
that it works in plain command-line javac. There are "lots" of things
that IDEs do to "help" people out. Please test that first.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any reason ant should compile faster?

[Ron Wheeler]

On 24/07/2013 4:40 PM, Russell Gold wrote:
Oh, you underestimate the coupling of this code. Yes, there are 
packages, but the classes in those packages reference one another 
willy-nilly. It's not a problem with recompiling - it's that there 
don't appear to be any good, sensible subset of classes in this group 
of 10,000 or so which can be compiled on their own. This set of 4000 
appears to be the minimum of what's left.


And worse, it appears that we published the main classes responsible 
for doing the coupling - and our customers use them in their own scripts.


This does not mean  that they require recompiling  in a single Maven 
project.




The architect responsible for this mess left the company ten years 
ago, shortly after putting it in place over the objections of most of 
the senior staff, and we haven't been able to remove it.


You could start by breaking the whole mess into packages that live in a 
single project.
If you  get down to 80-100 Maven projects, you will at least have a 
start on a cleanup and a way to reduce the need to compile 4000 classes 
at once.


Our biggest application was made up of 90 Maven projects but most major 
revisions only required changes to 10-20 Maven projects and we edited, 
compiled and tested each project individually even if it depended on 
other jars.
We had designed it from the start as a layered stack so our initial 
packaging into Maven projects made sense but we did many refactoring 
over the years as we went through major revisions and changed our views 
about how to structure the application.


Maven is designed to support multi-project applications.

Ron

Russ

On Jul 24, 2013, at 3:28 PM, Ron Wheeler 
> wrote:



On 24/07/2013 12:35 PM, Russell Gold wrote:
I wish I could break it up. Among the problems with this code is the 
extreme bit of coupling. The scripts list 300 files to compile 
because that's all that we would have wanted, but they pull in other 
files, which pull in yet others. Trying to compile this fairly small 
subsystem winds up building about a third of the entire project.

Pulling in classes does not mean recompiling them.
Once you have compiled the dependencies and aggregate them into jars, 
they can be referenced without recompiling them.

This will speed things up tremendously.

Do you at least have packages to use as a starting point?

Ron


But I will definitely look at the options and see what I can learn 
from them; thanks for the suggestions.


Russ

On Jul 24, 2013, at 12:31 PM, Wayne Fay > wrote:



The case I'm wondering about now is one where we have over 10,000
source files in a directory, and compile them bit-by-bit. One step 
specifies
about 300 files, and thanks to javac dependency logic, actually 
compiles

about 4000 files in ant.

Is there any way you can break that into 10 projects with 1k files
each, or 20 projects with 500 files each, etc? I have found dramatic
improvements in (Java compiling) speed as a result of breaking huge
projects like this into a series of much smaller projects with
dependencies between the projects etc as needed.

Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
but I'm not sure how to explain the 20 sec vs 90 sec results you're
experiencing. I'd check versions of everything and flags sent to
compilers etc via -X.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 

For additional commands, e-mail: users-h...@maven.apache.org 




-
Come read my webnovel, Take a Lemon ,
and listen to the Misfile radio play 
!









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com 


skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 

For additional commands, e-mail: users-h...@maven.apache.org 





-
Come read my webnovel,/Take a Lemon/,
and listen to the Misfile radio play 
!








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Maven / javac does not compile classes to target folder

[Gonfi den Tschal]

I have a maven multi-module project where a module ends in SUCCESS, but the
generated jar file is empty, and then the next module fails of course
because of missing classes.

The culprit is that the compilation puts nothing into the target folder,
even though it says it compiles the 217 classes. No error whatsoever. Maybe
the words "Stale source detected" ring some bells?

I've explained the case in detail here:
http://stackoverflow.com/questions/17838714/maven-javac-does-not-compile-classes-to-target-folder

Any hint what to try next or an idea for a workaround much appreciated
*sigh*

Re: maven surefire - selecting providers

[Andreas Dolk]

Hi,

just tried it and yes, only TestNG is started. But it can't execute the
tests. Doesn't find a test method. Maybe because the test actually use a
special runner?

@RunWith(ExampleGroupRunner.class)

@SuppressWarnings("all")

public class JnSpecBPMNProcessSpec {

//...


Unless I can talk the jnario team into supporting TestNG, I think, I still
need a solution to disable the TestNG provider for a certain set of tests
in my project...

Best regards,

Andreas




2013/7/24 Andreas Gudian 

> When both Junit and TestNg tests are found, then the TestNG provider should
> be selected automatically and used in mixed mode.
>
> Did you try not specifying any provider at all?
>
> Am Mittwoch, 24. Juli 2013 schrieb Andreas Dolk :
>
> > But on second thought - TestNG looked at the test but actually didn't
> > execute them. It reported "Tests run: 0, Failures: 0, Errors: 0, Skipped:
> > 0". That should be different in "mixed mode", shouldn't it? If I could
> > activate mixed mode correctly, then I could drop the jUnit provider
> anyway
> > and have TestNG execute all test classes. That would even be a far better
> > solution to my real problem.
> >
> > I need the additional jUnit tests only because I have some test written
> in
> > xtend (where the integration with TestNG is not that good in eclipse
> right
> > now) and because I use jnario, which creates jUnit tests only.
> >
> > So my real problem is running all tests in a maven build. If it is
> possible
> > with TestNG only, even better!
> >
> > Best regards,
> > Andreas
> >
> >
> > 2013/7/24 Andreas Dolk 
> >
> > > Ah sure, sorry:
> > >
> > > jUnit: 4.11
> > > TestNG: 6.8.5
> > >
> > > And thanks for the "mixed mode" hint, I study the reference, maybe I
> find
> > > something in the build files!
> > >
> > > Best regards,
> > > Andreas
> > >
> > >
> > > 2013/7/24 Francesco Mari 
> > >
> > >> I still wasn't able to reproduce your issue.
> > >>
> > >> Looks like TestNG is running in "mixed mode" [1][2]. The last missing
> > >> information is the version of JUnit and TestNG you are using. Can you
> > >> provide this piece of configuration?
> > >>
> > >> [1]: http://testng.org/doc/migrating.html
> > >> [2]: http://testng.org/doc/documentation-main.html#junit
> > >>
> > >>
> > >> 2013/7/24 Andreas Dolk 
> > >>
> > >> > Hi Francesco,
> > >> >
> > >> > I'm using 2.15
> > >> >
> > >> > And here's the result from a test run, that's what happens. The
> tests
> > >> are
> > >> > *only* jUnit tests. I've only replaced path and package names. BTW,
> > the
> > >> > jUnit times are net execution times (unfair!!), testNG reports the
> > total
> > >> > times (fair) ;) The other annoying part is that TestNG picks up far
> > more
> > >> > classes then jUnit...
> > >> >
> > >> > The tests are auto-compiled from jnario specs (jnario.org) which
> > >> shouldn't
> > >> > make a difference - at the end it's classes compiled from java
> source
> > >> > files.
> > >> >
> > >> > Regards,
> > >> > Andreas
> > >> >
> > >> >
> > >> >
> > >> > > mvn -Dtest=JnSpec* test
> > >> >
> > >> > ...
> > >> >
> > >> > [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> > a42-order-be
> > >> > ---
> > >> > [INFO] Surefire report directory: //target/surefire-reports
> > >> > [INFO] Using configured provider
> > >> > org.apache.maven.surefire.junitcore.JUnitCoreProvider
> > >> > [INFO] Using configured provider
> > >> > org.apache.maven.surefire.testng.TestNGProvider
> > >> > [INFO] parallel='none', perCoreThreadCount=true, threadCount=2,
> > >> > useUnlimitedThreads=false
> > >> >
> > >> > ---
> > >> >  T E S T S
> > >> > ---
> > >> >
> > >> > ---
> > >> >  T E S T S
> > >> > ---
> > >> > Running .JnSpecBPMNProcessSpec
> > >> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.199
> > >> sec -
> > >> > in .JnSpecBPMNProcessSpec
> > >> > Running .JnSpecCreateTheResultMessageOfACancellationSpec
> > >> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.485
> > >> sec -
> > >> > in .JnSpecCreateTheResultMessageOfACancellationSpec
> > >> > Running
> > >> .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> > >> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.471
> > >> sec -
> > >> > in
> .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> > >> > Running
> > >> >
> > >>
> >
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> > >> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.975
> > >> sec -
> > >> > in
> > >> >
> > >>
> >
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> > >> > Running
> > >> >
> > >> >
> > >> .JnSpecVerifyingTheCancellation
>



-- 
Andreas Dolk

Zurmainerstraße 33
D-54292 Trier
Phone「+49 651 4362884」
Mobile「+49 177 4970815」
EMail「andreas.dolk

Re: Any reason ant should compile faster?

[Russell Gold]

Oh, you underestimate the coupling of this code. Yes, there are packages, but 
the classes in those packages reference one another willy-nilly. It's not a 
problem with recompiling - it's that there don't appear to be any good, 
sensible subset of classes in this group of 10,000 or so which can be compiled 
on their own. This set of 4000 appears to be the minimum of what's left. 

And worse, it appears that we published the main classes responsible for doing 
the coupling - and our customers use them in their own scripts.

The architect responsible for this mess left the company ten years ago, shortly 
after putting it in place over the objections of most of the senior staff, and 
we haven't been able to remove it.

Russ 

On Jul 24, 2013, at 3:28 PM, Ron Wheeler  wrote:

> On 24/07/2013 12:35 PM, Russell Gold wrote:
>> I wish I could break it up. Among the problems with this code is the extreme 
>> bit of coupling. The scripts list 300 files to compile because that's all 
>> that we would have wanted, but they pull in other files, which pull in yet 
>> others. Trying to compile this fairly small subsystem winds up building 
>> about a third of the entire project.
> Pulling in classes does not mean recompiling them.
> Once you have compiled the dependencies and aggregate them into jars, they 
> can be referenced without recompiling them.
> This will speed things up tremendously.
> 
> Do you at least have packages to use as a starting point?
> 
> Ron
>> 
>> But I will definitely look at the options and see what I can learn from 
>> them; thanks for the suggestions.
>> 
>> Russ
>> 
>> On Jul 24, 2013, at 12:31 PM, Wayne Fay  wrote:
>> 
 The case I'm wondering about now is one where we have over 10,000
 source files in a directory, and compile them bit-by-bit. One step 
 specifies
 about 300 files, and thanks to javac dependency logic, actually compiles
 about 4000 files in ant.
>>> Is there any way you can break that into 10 projects with 1k files
>>> each, or 20 projects with 500 files each, etc? I have found dramatic
>>> improvements in (Java compiling) speed as a result of breaking huge
>>> projects like this into a series of much smaller projects with
>>> dependencies between the projects etc as needed.
>>> 
>>> Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
>>> but I'm not sure how to explain the 20 sec vs 90 sec results you're
>>> experiencing. I'd check versions of everything and flags sent to
>>> compilers etc via -X.
>>> 
>>> Wayne
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>> -
>> Come read my webnovel, Take a Lemon ,
>> and listen to the Misfile radio play 
>> !
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: Any reason ant should compile faster?

[Ron Wheeler]

On 24/07/2013 12:35 PM, Russell Gold wrote:

I wish I could break it up. Among the problems with this code is the extreme 
bit of coupling. The scripts list 300 files to compile because that's all that 
we would have wanted, but they pull in other files, which pull in yet others. 
Trying to compile this fairly small subsystem winds up building about a third 
of the entire project.

Pulling in classes does not mean recompiling them.
Once you have compiled the dependencies and aggregate them into jars, 
they can be referenced without recompiling them.

This will speed things up tremendously.

Do you at least have packages to use as a starting point?

Ron


But I will definitely look at the options and see what I can learn from them; 
thanks for the suggestions.

Russ

On Jul 24, 2013, at 12:31 PM, Wayne Fay  wrote:


The case I'm wondering about now is one where we have over 10,000
source files in a directory, and compile them bit-by-bit. One step specifies
about 300 files, and thanks to javac dependency logic, actually compiles
about 4000 files in ant.

Is there any way you can break that into 10 projects with 1k files
each, or 20 projects with 500 files each, etc? I have found dramatic
improvements in (Java compiling) speed as a result of breaking huge
projects like this into a series of much smaller projects with
dependencies between the projects etc as needed.

Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
but I'm not sure how to explain the 20 sec vs 90 sec results you're
experiencing. I'd check versions of everything and flags sent to
compilers etc via -X.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
Come read my webnovel, Take a Lemon ,
and listen to the Misfile radio play 
!








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Changes in how exclusions are applied transitively ?

[Grégory Joseph]

Hey there,

I can't seem to find an accurate trace of this in the release notes,
so I thought I'd just ping the list - Changes in how exclusions are
applied transitively between Maven 2.2.1 and 3.1 ?

Here's a situation: A has dependencies on B and C. Both transitively
depend on D  (through X, which is irrelevant, I think)  but B excludes
it (on its dep declaration of X)

With 2.2.1, D was (wrongly imo) excluded from A (depending on
dependency order, seemingly)

With 3.1, it appears to behave "correctly".

Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now
where I need to work around the bug, currently by removing the
exclusions. That's currently OK, but at some point, those exclusions
will be re-added (in A or in a new project) and we'll face the same
issue again, without any clue as to why.

How have people dealt with this so far ?

Thanks for any hint or pointers !

-greg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: how to sign up to codehaus?

[Robert Scholte]

Try the mainpage of JIRA[1], which refers to the xircles signup page[2]

Robert

[1] https://jira.codehaus.org/secure/Dashboard.jspa
[2] https://xircles.codehaus.org/signup

Op Wed, 24 Jul 2013 19:07:04 +0200 schreef Baptiste Mathus  
:



Hi,
I'm currently on my phone so cannot check easily, but it should quite  
easy

generally.
You can either create a full-blown account for codehaus.org or just for
JIRA. It might be that JIRA account creation may be temporarily moderated
because of spam spikes.

If your account creation really does not work, there should be some  
people

on this list with enough rights to help you.  Not my case though.

My 2 cents.
Le 24 juil. 2013 17:23, "Gonfi den Tschal"  a
écrit :


i'd like to report a bug for the project

http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel

clicking the green log in link top right brings me to this page
http://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMNG which
says to contact a jira administrator.

(i wish it was as simple as github. and i wish this mailing list was as
simple as google groups.)


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: New to Maven Question

[Ron Wheeler]

This may be too simplistic but can't you just run the build and parse 
the log output?


Ron

On 24/07/2013 1:05 PM, Mark Eggers wrote:

On 7/24/2013 9:53 AM, John Dix wrote:

Hello all,

I am a new user to Maven and was given the task at my work to come up
with a utility in order to output the build order of our products
based on the poms. It made sense to me that I would want to do
basically the same thing that the Reactor does except output the tree
rather than do an actual build so I downloaded the code for Maven and
found the class files ProjectSorter.java and ProjectSorterTest.java
as a beginning point. What I think I need to do here is modify the
reactor code to actually output rather execute a build.

Is there another way to do this very thing? If not, am I on the right
track?

Thanks!

John Dix Programming Sr. SME, Digital Commerce Amdocs Digital
Services Division o: 206-288-0334 m: 425.351.7340

AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS

Did you know...? Amdocs Mobile Payments enables operators to manage
any number of app stores, merchants and aggregators and generate
revenues from digital content and mobile commerce

Follow Amdocs on Facebook,
Twitter,
LinkedIn,
YouTube and
Google+ - and read the
latest on the Amdocs blog network.



This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement, you may
review at http://www.amdocs.com/email_disclaimer.asp



I'm also a new Maven user.

How about:

mvn dependency:tree

http://maven.apache.org/plugins/maven-dependency-plugin/usage.html

. . . . just my two cents.
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: New to Maven Question

[John Dix]

Thanks Curtis. I'll take a look at the validate cmd.

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of 
Curtis Rueden
Sent: Wednesday, July 24, 2013 10:15 AM
To: Maven Users List
Subject: Re: New to Maven Question

Hi John,

> output the build order of our products based on the poms

Is it enough to simply run "mvn validate" and parse the output? That will show 
you the build order of your multi-module reactor.

If you have multiple projects in multiple reactors, you could create a toplevel 
pom.xml joining them all into a single reactor, then run "mvn validate" to get 
the build order. That assumes that all the POMs have matching versions across 
the projects though, of course.

Regards,
Curtis


On Wed, Jul 24, 2013 at 11:53 AM, John Dix  wrote:

> Hello all,
>
> I am a new user to Maven and was given the task at my work to come up
> with a utility in order to output the build order of our products
> based on the poms. It made sense to me that I would want to do
> basically the same thing that the Reactor does except output the tree
> rather than do an actual build so I downloaded the code for Maven and
> found the class files ProjectSorter.java and ProjectSorterTest.java as
> a beginning point. What I think I need to do here is modify the
> reactor code to actually output rather execute a build.
>
> Is there another way to do this very thing? If not, am I on the right
> track?
>
> Thanks!
>
> John Dix
> Programming Sr. SME, Digital Commerce
> Amdocs Digital Services Division
> o: 206-288-0334 m: 425.351.7340
>
> AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS
>
> Did you know...?
> Amdocs Mobile Payments enables operators to manage any number of app
> stores, merchants and aggregators and generate revenues from digital
> content and mobile commerce
>
> Follow Amdocs on Facebook,
> Twitter< http://twitter.com/AmdocsInc>, LinkedIn<
> http://www.linkedin.com/company/amdocs>, YouTube<
> http://www.youtube.com/amdocsinc> and Google+<
> https://plus.google.com/105657940751678445194> - and read the latest
> on the Amdocs blog network.
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may
> review at http://www.amdocs.com/email_disclaimer.asp
>

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: New to Maven Question

[Curtis Rueden]

Hi John,

> output the build order of our products based on the poms

Is it enough to simply run "mvn validate" and parse the output? That will
show you the build order of your multi-module reactor.

If you have multiple projects in multiple reactors, you could create a
toplevel pom.xml joining them all into a single reactor, then run "mvn
validate" to get the build order. That assumes that all the POMs have
matching versions across the projects though, of course.

Regards,
Curtis


On Wed, Jul 24, 2013 at 11:53 AM, John Dix  wrote:

> Hello all,
>
> I am a new user to Maven and was given the task at my work to come up with
> a utility in order to output the build order of our products based on the
> poms. It made sense to me that I would want to do basically the same thing
> that the Reactor does except output the tree rather than do an actual build
> so I downloaded the code for Maven and found the class files
> ProjectSorter.java and ProjectSorterTest.java as a beginning point. What I
> think I need to do here is modify the reactor code to actually output
> rather execute a build.
>
> Is there another way to do this very thing? If not, am I on the right
> track?
>
> Thanks!
>
> John Dix
> Programming Sr. SME, Digital Commerce
> Amdocs Digital Services Division
> o: 206-288-0334 m: 425.351.7340
>
> AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS
>
> Did you know...?
> Amdocs Mobile Payments enables operators to manage any number of app
> stores, merchants and aggregators and generate revenues from digital
> content and mobile commerce
>
> Follow Amdocs on Facebook, Twitter<
> http://twitter.com/AmdocsInc>, LinkedIn<
> http://www.linkedin.com/company/amdocs>, YouTube<
> http://www.youtube.com/amdocsinc> and Google+<
> https://plus.google.com/105657940751678445194> - and read the latest on
> the Amdocs blog network.
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: how to sign up to codehaus?

[Baptiste Mathus]

Hi,
I'm currently on my phone so cannot check easily, but it should quite easy
generally.
You can either create a full-blown account for codehaus.org or just for
JIRA. It might be that JIRA account creation may be temporarily moderated
because of spam spikes.

If your account creation really does not work, there should be some people
on this list with enough rights to help you.  Not my case though.

My 2 cents.
Le 24 juil. 2013 17:23, "Gonfi den Tschal"  a
écrit :

> i'd like to report a bug for the project
>
> http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
>
> clicking the green log in link top right brings me to this page
> http://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMNG which
> says to contact a jira administrator.
>
> (i wish it was as simple as github. and i wish this mailing list was as
> simple as google groups.)
>

Re: New to Maven Question

[Mark Eggers]

On 7/24/2013 9:53 AM, John Dix wrote:

Hello all,

I am a new user to Maven and was given the task at my work to come up
with a utility in order to output the build order of our products
based on the poms. It made sense to me that I would want to do
basically the same thing that the Reactor does except output the tree
rather than do an actual build so I downloaded the code for Maven and
found the class files ProjectSorter.java and ProjectSorterTest.java
as a beginning point. What I think I need to do here is modify the
reactor code to actually output rather execute a build.

Is there another way to do this very thing? If not, am I on the right
track?

Thanks!

John Dix Programming Sr. SME, Digital Commerce Amdocs Digital
Services Division o: 206-288-0334 m: 425.351.7340

AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS

Did you know...? Amdocs Mobile Payments enables operators to manage
any number of app stores, merchants and aggregators and generate
revenues from digital content and mobile commerce

Follow Amdocs on Facebook,
Twitter,
LinkedIn,
YouTube and
Google+ - and read the
latest on the Amdocs blog network.



This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement, you may
review at http://www.amdocs.com/email_disclaimer.asp



I'm also a new Maven user.

How about:

mvn dependency:tree

http://maven.apache.org/plugins/maven-dependency-plugin/usage.html

. . . . just my two cents.
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

New to Maven Question

[John Dix]

Hello all,

I am a new user to Maven and was given the task at my work to come up with a 
utility in order to output the build order of our products based on the poms. 
It made sense to me that I would want to do basically the same thing that the 
Reactor does except output the tree rather than do an actual build so I 
downloaded the code for Maven and found the class files ProjectSorter.java and 
ProjectSorterTest.java as a beginning point. What I think I need to do here is 
modify the reactor code to actually output rather execute a build.

Is there another way to do this very thing? If not, am I on the right track?

Thanks!

John Dix
Programming Sr. SME, Digital Commerce
Amdocs Digital Services Division
o: 206-288-0334 m: 425.351.7340

AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS

Did you know...?
Amdocs Mobile Payments enables operators to manage any number of app stores, 
merchants and aggregators and generate revenues from digital content and mobile 
commerce

Follow Amdocs on Facebook, 
Twitter, 
LinkedIn, 
YouTube and 
Google+ - and read the latest on 
the Amdocs blog network.



This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

Re: Any reason ant should compile faster?

[Russell Gold]

I wish I could break it up. Among the problems with this code is the extreme 
bit of coupling. The scripts list 300 files to compile because that's all that 
we would have wanted, but they pull in other files, which pull in yet others. 
Trying to compile this fairly small subsystem winds up building about a third 
of the entire project.

But I will definitely look at the options and see what I can learn from them; 
thanks for the suggestions.

Russ

On Jul 24, 2013, at 12:31 PM, Wayne Fay  wrote:

>> The case I'm wondering about now is one where we have over 10,000
>> source files in a directory, and compile them bit-by-bit. One step specifies
>> about 300 files, and thanks to javac dependency logic, actually compiles
>> about 4000 files in ant.
> 
> Is there any way you can break that into 10 projects with 1k files
> each, or 20 projects with 500 files each, etc? I have found dramatic
> improvements in (Java compiling) speed as a result of breaking huge
> projects like this into a series of much smaller projects with
> dependencies between the projects etc as needed.
> 
> Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
> but I'm not sure how to explain the 20 sec vs 90 sec results you're
> experiencing. I'd check versions of everything and flags sent to
> compilers etc via -X.
> 
> Wayne
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: maven surefire - selecting providers

[Andreas Gudian]

When both Junit and TestNg tests are found, then the TestNG provider should
be selected automatically and used in mixed mode.

Did you try not specifying any provider at all?

Am Mittwoch, 24. Juli 2013 schrieb Andreas Dolk :

> But on second thought - TestNG looked at the test but actually didn't
> execute them. It reported "Tests run: 0, Failures: 0, Errors: 0, Skipped:
> 0". That should be different in "mixed mode", shouldn't it? If I could
> activate mixed mode correctly, then I could drop the jUnit provider anyway
> and have TestNG execute all test classes. That would even be a far better
> solution to my real problem.
>
> I need the additional jUnit tests only because I have some test written in
> xtend (where the integration with TestNG is not that good in eclipse right
> now) and because I use jnario, which creates jUnit tests only.
>
> So my real problem is running all tests in a maven build. If it is possible
> with TestNG only, even better!
>
> Best regards,
> Andreas
>
>
> 2013/7/24 Andreas Dolk 
>
> > Ah sure, sorry:
> >
> > jUnit: 4.11
> > TestNG: 6.8.5
> >
> > And thanks for the "mixed mode" hint, I study the reference, maybe I find
> > something in the build files!
> >
> > Best regards,
> > Andreas
> >
> >
> > 2013/7/24 Francesco Mari 
> >
> >> I still wasn't able to reproduce your issue.
> >>
> >> Looks like TestNG is running in "mixed mode" [1][2]. The last missing
> >> information is the version of JUnit and TestNG you are using. Can you
> >> provide this piece of configuration?
> >>
> >> [1]: http://testng.org/doc/migrating.html
> >> [2]: http://testng.org/doc/documentation-main.html#junit
> >>
> >>
> >> 2013/7/24 Andreas Dolk 
> >>
> >> > Hi Francesco,
> >> >
> >> > I'm using 2.15
> >> >
> >> > And here's the result from a test run, that's what happens. The tests
> >> are
> >> > *only* jUnit tests. I've only replaced path and package names. BTW,
> the
> >> > jUnit times are net execution times (unfair!!), testNG reports the
> total
> >> > times (fair) ;) The other annoying part is that TestNG picks up far
> more
> >> > classes then jUnit...
> >> >
> >> > The tests are auto-compiled from jnario specs (jnario.org) which
> >> shouldn't
> >> > make a difference - at the end it's classes compiled from java source
> >> > files.
> >> >
> >> > Regards,
> >> > Andreas
> >> >
> >> >
> >> >
> >> > > mvn -Dtest=JnSpec* test
> >> >
> >> > ...
> >> >
> >> > [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> a42-order-be
> >> > ---
> >> > [INFO] Surefire report directory: //target/surefire-reports
> >> > [INFO] Using configured provider
> >> > org.apache.maven.surefire.junitcore.JUnitCoreProvider
> >> > [INFO] Using configured provider
> >> > org.apache.maven.surefire.testng.TestNGProvider
> >> > [INFO] parallel='none', perCoreThreadCount=true, threadCount=2,
> >> > useUnlimitedThreads=false
> >> >
> >> > ---
> >> >  T E S T S
> >> > ---
> >> >
> >> > ---
> >> >  T E S T S
> >> > ---
> >> > Running .JnSpecBPMNProcessSpec
> >> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199
> >> sec -
> >> > in .JnSpecBPMNProcessSpec
> >> > Running .JnSpecCreateTheResultMessageOfACancellationSpec
> >> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485
> >> sec -
> >> > in .JnSpecCreateTheResultMessageOfACancellationSpec
> >> > Running
> >> .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> >> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471
> >> sec -
> >> > in .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> >> > Running
> >> >
> >>
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> >> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975
> >> sec -
> >> > in
> >> >
> >>
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> >> > Running
> >> >
> >> >
> >> .JnSpecVerifyingTheCancellation

Re: Any reason ant should compile faster?

[Wayne Fay]

> The case I'm wondering about now is one where we have over 10,000
> source files in a directory, and compile them bit-by-bit. One step specifies
> about 300 files, and thanks to javac dependency logic, actually compiles
> about 4000 files in ant.

Is there any way you can break that into 10 projects with 1k files
each, or 20 projects with 500 files each, etc? I have found dramatic
improvements in (Java compiling) speed as a result of breaking huge
projects like this into a series of much smaller projects with
dependencies between the projects etc as needed.

Having said that, 20 seconds for 4k files sounds pretty quick! Sorry
but I'm not sure how to explain the 20 sec vs 90 sec results you're
experiencing. I'd check versions of everything and flags sent to
compilers etc via -X.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any reason ant should compile faster?

[Thomas Broyer]

On Wed, Jul 24, 2013 at 4:28 PM, Russell Gold  wrote:
> Hi,
>
> Maybe somebody else has run into this. I'm converting a really messy 
> 200-ant-script build to maven, and some steps seems to run a lot slower, now.
>
> The case I'm wondering about now is one where we have over 10,000 source 
> files in a directory, and compile them bit-by-bit. One step specifies about 
> 300 files, and thanks to javac dependency logic, actually compiles about 4000 
> files in ant.
>
> I have converted this to maven by moving the 4000 files into the maven 
> project src/main/java tree. Maven, of course, tells javac to compile all 4000 
> files.
>
> In ant, this step takes about 20 seconds. In maven, it takes about 90 
> seconds. Any ideas why?

Maybe just because the staleness check used by the
maven-compiler-plugin (or is it plexus-compiler?) now scans the 4000
files whereas your Ant script only scanned 300 files.
The way the compiler is invoked might play a role too, the default
depends on the version of the maven-compiler-plugin (and
plexus-compiler) you're using.

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

how to sign up to codehaus?

[Gonfi den Tschal]

i'd like to report a bug for the project
http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel

clicking the green log in link top right brings me to this page
http://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMNG which
says to contact a jira administrator.

(i wish it was as simple as github. and i wish this mailing list was as
simple as google groups.)

Re: Any reason ant should compile faster?

[Adrien Rivard]

Memory parameters maybe ?


On Wed, Jul 24, 2013 at 4:28 PM, Russell Gold  wrote:

> Hi,
>
> Maybe somebody else has run into this. I'm converting a really messy
> 200-ant-script build to maven, and some steps seems to run a lot slower,
> now.
>
> The case I'm wondering about now is one where we have over 10,000 source
> files in a directory, and compile them bit-by-bit. One step specifies about
> 300 files, and thanks to javac dependency logic, actually compiles about
> 4000 files in ant.
>
> I have converted this to maven by moving the 4000 files into the maven
> project src/main/java tree. Maven, of course, tells javac to compile all
> 4000 files.
>
> In ant, this step takes about 20 seconds. In maven, it takes about 90
> seconds. Any ideas why?
>
> Thanks,
> Russ
> -
> Come read my webnovel, Take a Lemon ,
> and listen to the Misfile radio play <
> http://www.gold-family.us/audio/misfile.html>!
>
>
>
>
>


-- 
Adrien Rivard

Any reason ant should compile faster?

[Russell Gold]

Hi,

Maybe somebody else has run into this. I'm converting a really messy 
200-ant-script build to maven, and some steps seems to run a lot slower, now.

The case I'm wondering about now is one where we have over 10,000 source files 
in a directory, and compile them bit-by-bit. One step specifies about 300 
files, and thanks to javac dependency logic, actually compiles about 4000 files 
in ant.

I have converted this to maven by moving the 4000 files into the maven project 
src/main/java tree. Maven, of course, tells javac to compile all 4000 files.

In ant, this step takes about 20 seconds. In maven, it takes about 90 seconds. 
Any ideas why?

Thanks,
Russ
-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: mvn release:prepare does not update parent version

[Russell Gold]

Hi Markus,

I think we're all a bit confused about what you are trying to do. Can you 
create a very simple project that recreates the problem or describe what you 
are doing in a different way?

Maybe just letting us know the relationship among the modules in your project 
would suffice. Or possibly sending the part of the release log that includes 
the prompts. AFAIK it should only ask you about versions of the modules you are 
releasing, not any external ones.

Thanks,
Russ

On Jul 24, 2013, at 2:09 AM, Markus Karg  wrote:

> Martin,
> 
> I don't know why you're asking this. What has this to do with my actual 
> scenario? I am doing something completely different and my question was not 
> targeting your scenario.
> 
> Thanks
> -Markus
> 
> -Ursprüngliche Nachricht-
> Von: Martin Gainty [mailto:mgai...@hotmail.com] 
> Gesendet: Dienstag, 23. Juli 2013 23:24
> An: users@maven.apache.org
> Betreff: RE: mvn release:prepare does not update parent version
> 
> Markus
> 
> 
> Parent.pom
> |
> v
> -
> | 
>   |
> v 
>   v
> Child1.pom
>   Child2.pom
> release:prepare where  updates/changes Child1.pom Child11.pom 
> Child12.pom
> |
> v
> ---
> | |
> v v
> Child11.pom   Child12.pom
> 
> can you envision a scenario where release plugin should break inheritance and 
> update Parent instead of child  s
> ?
> 
> Martin 
> __ 
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> 
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
> sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
> oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich 
> dem Austausch von Informationen und entfaltet keine rechtliche 
> Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen 
> wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
> destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci 
> est interdite. Ce message sert à l'information seulement et n'aura pas 
> n'importe quel effet légalement obligatoire. Étant donné que les email 
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
> aucune responsabilité pour le contenu fourni.
> 
> 
>> Subject: RE: mvn release:prepare does not update parent version
>> Date: Mon, 22 Jul 2013 22:29:07 +0200
>> From: k...@quipsy.de
>> To: users@maven.apache.org
>> 
>> Thanks for picking up this thread!
>> 
>> I am using: Maven 3.0.4 and maven-release-plugin 2.4.1
>> 
>> -Markus
>> 
>>> Hi, which version of Maven and Maven-Release-Plugin are you using?
>>> 
>>> On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg  wrote:
>>> 
 I'm driving nuts with mvn release:prepare...:
 
 When I do mvn release:prepare, Maven asks whether I want to update
>>> all
 SNAPSHOT version referenced in the POM.
 I say "yes" and confirm all suggested replacement versions
>> unchanged.
 When Maven is done, I check the POM.xml.
 It is correctly rewritten for all references, but not for the parent
 version.
 The parent version still references the *old* SNAPSHOT, while
 obviously it should now name the *next* SNAPSHOT.
 
 Can somebody tell me what I have to do so that mvn release:prepare
 will also make the parent version point tot he *next* SNAPSHOT, as
>> it
 does it correctly with the dependencies and the project's own
>>> version?
 
 Thanks!
 -Markus
 
 
 
>> -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 

Re: maven surefire - selecting providers

[Andreas Dolk]

But on second thought - TestNG looked at the test but actually didn't
execute them. It reported "Tests run: 0, Failures: 0, Errors: 0, Skipped:
0". That should be different in "mixed mode", shouldn't it? If I could
activate mixed mode correctly, then I could drop the jUnit provider anyway
and have TestNG execute all test classes. That would even be a far better
solution to my real problem.

I need the additional jUnit tests only because I have some test written in
xtend (where the integration with TestNG is not that good in eclipse right
now) and because I use jnario, which creates jUnit tests only.

So my real problem is running all tests in a maven build. If it is possible
with TestNG only, even better!

Best regards,
Andreas


2013/7/24 Andreas Dolk 

> Ah sure, sorry:
>
> jUnit: 4.11
> TestNG: 6.8.5
>
> And thanks for the "mixed mode" hint, I study the reference, maybe I find
> something in the build files!
>
> Best regards,
> Andreas
>
>
> 2013/7/24 Francesco Mari 
>
>> I still wasn't able to reproduce your issue.
>>
>> Looks like TestNG is running in "mixed mode" [1][2]. The last missing
>> information is the version of JUnit and TestNG you are using. Can you
>> provide this piece of configuration?
>>
>> [1]: http://testng.org/doc/migrating.html
>> [2]: http://testng.org/doc/documentation-main.html#junit
>>
>>
>> 2013/7/24 Andreas Dolk 
>>
>> > Hi Francesco,
>> >
>> > I'm using 2.15
>> >
>> > And here's the result from a test run, that's what happens. The tests
>> are
>> > *only* jUnit tests. I've only replaced path and package names. BTW, the
>> > jUnit times are net execution times (unfair!!), testNG reports the total
>> > times (fair) ;) The other annoying part is that TestNG picks up far more
>> > classes then jUnit...
>> >
>> > The tests are auto-compiled from jnario specs (jnario.org) which
>> shouldn't
>> > make a difference - at the end it's classes compiled from java source
>> > files.
>> >
>> > Regards,
>> > Andreas
>> >
>> >
>> >
>> > > mvn -Dtest=JnSpec* test
>> >
>> > ...
>> >
>> > [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be
>> > ---
>> > [INFO] Surefire report directory: //target/surefire-reports
>> > [INFO] Using configured provider
>> > org.apache.maven.surefire.junitcore.JUnitCoreProvider
>> > [INFO] Using configured provider
>> > org.apache.maven.surefire.testng.TestNGProvider
>> > [INFO] parallel='none', perCoreThreadCount=true, threadCount=2,
>> > useUnlimitedThreads=false
>> >
>> > ---
>> >  T E S T S
>> > ---
>> >
>> > ---
>> >  T E S T S
>> > ---
>> > Running .JnSpecBPMNProcessSpec
>> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199
>> sec -
>> > in .JnSpecBPMNProcessSpec
>> > Running .JnSpecCreateTheResultMessageOfACancellationSpec
>> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485
>> sec -
>> > in .JnSpecCreateTheResultMessageOfACancellationSpec
>> > Running
>> .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
>> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471
>> sec -
>> > in .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
>> > Running
>> >
>> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
>> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975
>> sec -
>> > in
>> >
>> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
>> > Running
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
>> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262
>> sec -
>> > in
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
>> > Running
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
>> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215
>> sec -
>> > in
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
>> > Running
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
>> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225
>> sec -
>> > in
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
>> > Running
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
>> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
>> sec -
>> > in
>> >
>> >
>> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
>> >
>> > Results :
>> >
>> > Tests run: 14, Failures: 0, Errors: 0, Skipped: 0
>> >
>> >
>> > ---
>> >  T E S T S
>> > ---

Re: maven surefire - selecting providers

[Andreas Dolk]

Ah sure, sorry:

jUnit: 4.11
TestNG: 6.8.5

And thanks for the "mixed mode" hint, I study the reference, maybe I find
something in the build files!

Best regards,
Andreas


2013/7/24 Francesco Mari 

> I still wasn't able to reproduce your issue.
>
> Looks like TestNG is running in "mixed mode" [1][2]. The last missing
> information is the version of JUnit and TestNG you are using. Can you
> provide this piece of configuration?
>
> [1]: http://testng.org/doc/migrating.html
> [2]: http://testng.org/doc/documentation-main.html#junit
>
>
> 2013/7/24 Andreas Dolk 
>
> > Hi Francesco,
> >
> > I'm using 2.15
> >
> > And here's the result from a test run, that's what happens. The tests are
> > *only* jUnit tests. I've only replaced path and package names. BTW, the
> > jUnit times are net execution times (unfair!!), testNG reports the total
> > times (fair) ;) The other annoying part is that TestNG picks up far more
> > classes then jUnit...
> >
> > The tests are auto-compiled from jnario specs (jnario.org) which
> shouldn't
> > make a difference - at the end it's classes compiled from java source
> > files.
> >
> > Regards,
> > Andreas
> >
> >
> >
> > > mvn -Dtest=JnSpec* test
> >
> > ...
> >
> > [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be
> > ---
> > [INFO] Surefire report directory: //target/surefire-reports
> > [INFO] Using configured provider
> > org.apache.maven.surefire.junitcore.JUnitCoreProvider
> > [INFO] Using configured provider
> > org.apache.maven.surefire.testng.TestNGProvider
> > [INFO] parallel='none', perCoreThreadCount=true, threadCount=2,
> > useUnlimitedThreads=false
> >
> > ---
> >  T E S T S
> > ---
> >
> > ---
> >  T E S T S
> > ---
> > Running .JnSpecBPMNProcessSpec
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199
> sec -
> > in .JnSpecBPMNProcessSpec
> > Running .JnSpecCreateTheResultMessageOfACancellationSpec
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485
> sec -
> > in .JnSpecCreateTheResultMessageOfACancellationSpec
> > Running
> .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471
> sec -
> > in .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> > Running
> >
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975
> sec -
> > in
> >
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> > Running
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262
> sec -
> > in
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> > Running
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215
> sec -
> > in
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> > Running
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225
> sec -
> > in
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> > Running
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> sec -
> > in
> >
> >
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> >
> > Results :
> >
> > Tests run: 14, Failures: 0, Errors: 0, Skipped: 0
> >
> >
> > ---
> >  T E S T S
> > ---
> >
> > ---
> >  T E S T S
> > ---
> > Running .JnSpecBPMNProcessSpec$1
> > Configuring TestNG with: TestNG652Configurator
> > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.595
> sec -
> > in .JnSpecBPMNProcessSpec$1
> > Running .JnSpecBPMNProcessSpec
> > Configuring TestNG with: TestNG652Configurator
> > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.693
> sec -
> > in .JnSpecBPMNProcessSpec
> > Running .JnSpecCreateTheResultMessageOfACancellationSpec$1
> > Configuring TestNG with: TestNG652Configurator
> > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.658
> sec -
> > in .JnSpecCreateTheResultMessageOfACancellationSpec$1
> > Running .JnSpecCreateTheResultMessageOfACancellationSpec$2$1
> > Configuring TestNG with: T

Re: maven surefire - selecting providers

[Francesco Mari]

I still wasn't able to reproduce your issue.

Looks like TestNG is running in "mixed mode" [1][2]. The last missing
information is the version of JUnit and TestNG you are using. Can you
provide this piece of configuration?

[1]: http://testng.org/doc/migrating.html
[2]: http://testng.org/doc/documentation-main.html#junit


2013/7/24 Andreas Dolk 

> Hi Francesco,
>
> I'm using 2.15
>
> And here's the result from a test run, that's what happens. The tests are
> *only* jUnit tests. I've only replaced path and package names. BTW, the
> jUnit times are net execution times (unfair!!), testNG reports the total
> times (fair) ;) The other annoying part is that TestNG picks up far more
> classes then jUnit...
>
> The tests are auto-compiled from jnario specs (jnario.org) which shouldn't
> make a difference - at the end it's classes compiled from java source
> files.
>
> Regards,
> Andreas
>
>
>
> > mvn -Dtest=JnSpec* test
>
> ...
>
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be
> ---
> [INFO] Surefire report directory: //target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] Using configured provider
> org.apache.maven.surefire.testng.TestNGProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=2,
> useUnlimitedThreads=false
>
> ---
>  T E S T S
> ---
>
> ---
>  T E S T S
> ---
> Running .JnSpecBPMNProcessSpec
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec -
> in .JnSpecBPMNProcessSpec
> Running .JnSpecCreateTheResultMessageOfACancellationSpec
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485 sec -
> in .JnSpecCreateTheResultMessageOfACancellationSpec
> Running .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471 sec -
> in .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
> Running
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975 sec -
> in
> .JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
> Running
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec -
> in
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> Running
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215 sec -
> in
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> Running
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225 sec -
> in
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
> Running
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec -
> in
>
> .JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
>
> Results :
>
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0
>
>
> ---
>  T E S T S
> ---
>
> ---
>  T E S T S
> ---
> Running .JnSpecBPMNProcessSpec$1
> Configuring TestNG with: TestNG652Configurator
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.595 sec -
> in .JnSpecBPMNProcessSpec$1
> Running .JnSpecBPMNProcessSpec
> Configuring TestNG with: TestNG652Configurator
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.693 sec -
> in .JnSpecBPMNProcessSpec
> Running .JnSpecCreateTheResultMessageOfACancellationSpec$1
> Configuring TestNG with: TestNG652Configurator
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.658 sec -
> in .JnSpecCreateTheResultMessageOfACancellationSpec$1
> Running .JnSpecCreateTheResultMessageOfACancellationSpec$2$1
> Configuring TestNG with: TestNG652Configurator
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.683 sec -
> in .JnSpecCreateTheResultMessageOfACancellationSpec$2$1
> Running .JnSpecCreateTheResultMessageOfACancellationSpec$2
> Configuring TestNG with: TestNG652Configurator
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.621 sec -
> in .JnSpecCreateTheResultMessageOfACancellationSpec$2
> Running .JnSpecCreateTheResultMessageOfACancellationSpec$3
> Configuring TestNG 

Re: Compiler warnings treated as errors

[Aliaksei Lahachou]

And why does it think, that compilation failed? The same source is
successfully compiled by the compiler plugin 2.3.2. It could be also
compiled successfully in another module with 2.5.1 and 3.1. The compiler
source and target are set to 1.5.


On Wed, Jul 24, 2013 at 12:14 PM, Anders Hammar  wrote:

> > The following code seems a bit strange to me. Why does it throw a
> > compilation failure exception when there are warnings?
> >
> > if ( !errors.isEmpty() )
> > {
> > throw new CompilationFailureException( errors );
> > }
> > else
> > {
> > throw new CompilationFailureException( warnings );
> > }
> >
>
> It's due to the wrapping if clause you're not quoting:
>
> if ( failOnError && !compilerResult.isSuccess() )
>
> The compilation has failed as indicated by !compilerResult.isSuccess().
>
> /Anders
>

Re: Compiler warnings treated as errors

[Anders Hammar]

> The following code seems a bit strange to me. Why does it throw a
> compilation failure exception when there are warnings?
>
> if ( !errors.isEmpty() )
> {
> throw new CompilationFailureException( errors );
> }
> else
> {
> throw new CompilationFailureException( warnings );
> }
>

It's due to the wrapping if clause you're not quoting:

if ( failOnError && !compilerResult.isSuccess() )

The compilation has failed as indicated by !compilerResult.isSuccess().

/Anders

Re: maven surefire - selecting providers

[Andreas Dolk]

Hi Francesco,

I'm using 2.15

And here's the result from a test run, that's what happens. The tests are
*only* jUnit tests. I've only replaced path and package names. BTW, the
jUnit times are net execution times (unfair!!), testNG reports the total
times (fair) ;) The other annoying part is that TestNG picks up far more
classes then jUnit...

The tests are auto-compiled from jnario specs (jnario.org) which shouldn't
make a difference - at the end it's classes compiled from java source files.

Regards,
Andreas



> mvn -Dtest=JnSpec* test

...

[INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be ---
[INFO] Surefire report directory: //target/surefire-reports
[INFO] Using configured provider
org.apache.maven.surefire.junitcore.JUnitCoreProvider
[INFO] Using configured provider
org.apache.maven.surefire.testng.TestNGProvider
[INFO] parallel='none', perCoreThreadCount=true, threadCount=2,
useUnlimitedThreads=false

---
 T E S T S
---

---
 T E S T S
---
Running .JnSpecBPMNProcessSpec
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec -
in .JnSpecBPMNProcessSpec
Running .JnSpecCreateTheResultMessageOfACancellationSpec
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485 sec -
in .JnSpecCreateTheResultMessageOfACancellationSpec
Running .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471 sec -
in .JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec
Running
.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975 sec -
in
.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec
Running
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec -
in
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
Running
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215 sec -
in
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
Running
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225 sec -
in
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec
Running
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec -
in
.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec

Results :

Tests run: 14, Failures: 0, Errors: 0, Skipped: 0


---
 T E S T S
---

---
 T E S T S
---
Running .JnSpecBPMNProcessSpec$1
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.595 sec -
in .JnSpecBPMNProcessSpec$1
Running .JnSpecBPMNProcessSpec
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.693 sec -
in .JnSpecBPMNProcessSpec
Running .JnSpecCreateTheResultMessageOfACancellationSpec$1
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.658 sec -
in .JnSpecCreateTheResultMessageOfACancellationSpec$1
Running .JnSpecCreateTheResultMessageOfACancellationSpec$2$1
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.683 sec -
in .JnSpecCreateTheResultMessageOfACancellationSpec$2$1
Running .JnSpecCreateTheResultMessageOfACancellationSpec$2
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.621 sec -
in .JnSpecCreateTheResultMessageOfACancellationSpec$2
Running .JnSpecCreateTheResultMessageOfACancellationSpec$3
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.534 sec -
in .JnSpecCreateTheResultMessageOfACancellationSpec$3
Running .JnSpecCreateTheResultMessageOfACancellationSpec$4$1$1
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.572 sec -
in .JnSpecCreateTheResultMessageOfACancellationSpec$4$1$1
Running .JnSpecCreateTheResultMessageOfACancellationSpec$4$1
Configuring TestNG with: TestNG652Configurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time ela

Re: No class files!!

[Aliaksei Lahachou]

Hi,

you can try only compiling to see if the problem is the compiler, or
another plugin somehow removes the classes:
mvn clean compiler:compile

Regards,
htfv (Aliaksei Lahachou)


On Sun, Jul 21, 2013 at 11:46 PM, Ed Hillmann  wrote:

> From the look of the original output, it did look like it was generating
> classes.  The first thing I would try is to skip the custom configuration
> of the JAR plugin to see if that's doing anything.
>
> If you run the command with "-X", you might get some more information about
> what the plugins are doing.
>
> I haven't done any work on a Mac, is there any file/directory permissions
> that might be causing issues?
>
> Not much help, sorry.
>
>
> On Mon, Jul 22, 2013 at 5:12 AM, Tommy Svensson  wrote:
>
> > I just upgraded from _21 to _25, but no difference! That javac will not
> > produce class files either. It does everything but write class files. If
> I
> > change a source file so that there is an error in it I will get the error
> > when I compile, but when everything is OK and no errors it is quiet, but
> it
> > produces no class files.
> >
> > Have anyone else experienced this problem with JDK 1.7 on a Mac ? If so,
> > what did you do about it ? That is if there is a solution that does not
> > involve reinstalling the whole machine!
> >
> > Regards,
> > Tommy Svensson
> >
> >
> > 21 jul 2013 kl. 20:10 skrev Tommy Svensson :
> >
> > > I found the problem:
> > > 
> > >
> > > Tommys-MacBook-Pro:APSOpenJPAProvider tommy$ echo $cp
> > >
> >
> /Users/tommy/.m2/repository/se/natusoft/osgi/aps/aps-apis/0.9.2/aps-apis-0.9.2.jar:/Users/tommy/.m2/repository/se/natusoft/osgi/aps/aps-tools-lib/0.9.2/aps-tools-lib-0.9.2.jar:/Users/tommy/.m2/repository/org/osgi/org.osgi.core/4.2.0/org.osgi.core-4.2.0.jar:/Users/tommy/.m2/repository/org/osgi/org.osgi.compendium/4.2.0/org.osgi.compendium-4.2.0.jar:/Users/tommy/.m2/repository/org/osgi/org.osgi.enterprise/4.2.0/org.osgi.enterprise-4.2.0.jar:/Users/tommy/.m2/repository/org/apache/openjpa/openjpa-all/2.2.0/openjpa-all-2.2.0.jar:/Users/tommy/.m2/repository/se/natusoft/tools/xob/xob/5.0/xob-5.0.jar
> > >
> > > Tommys-MacBook-Pro:APSOpenJPAProvider tommy$
> > /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/bin/javac
> > -classpath $cp -d target/classes -s target/generated-sources/annotations
> > `find src/main/java -type f`
> > >
> > > Tommys-MacBook-Pro:APSOpenJPAProvider tommy$ ls -l target/classes/
> > > total 0
> > > drwxr-xr-x  3 tommy  staff  102 21 Jul 19:36 META-INF
> > > drwxr-xr-x  4 tommy  staff  136 21 Jul 19:36 lib
> > > 
> > >
> > > Damn you Oracle!
> > >
> > > /Tommy
> > >
> > >
> > > 21 jul 2013 kl. 19:06 skrev Tommy Svensson :
> > >
> > >> Hello,
> > >>
> > >> Can someone please inform me why maven-compiler-plugin is clearly
> > saying that it is compiling 12 classes into my target/classes directory
> but
> > after build there are only resources and no classes there!
> > >>
> > >> Here is the output of a build:
> > >> ___
> > >>
> > >> Tommys-MacBook-Pro:APSOpenJPAProvider tommy$ mvn -version
> > >> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> > >> Maven home: /usr/share/maven
> > >> Java version: 1.7.0_21, vendor: Oracle Corporation
> > >> Java home:
> > /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> > >> Default locale: sv_SE, platform encoding: UTF-8
> > >> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
> > >>
> > >> Tommys-MacBook-Pro:APSOpenJPAProvider tommy$ mvn clean
> > >> [INFO] Scanning for projects...
> > >> [INFO]
> > >> [INFO]
> > 
> > >> [INFO] Building APS OpenJPA Provider 0.9.2
> > >> [INFO]
> > 
> > >> [INFO]
> > >> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> > aps-openjpa-provider ---
> > >> [INFO] Deleting
> >
> /Users/tommy/Development/Projects/OSGi/OSGiApplicationPlatformServices/APS-Data/APSOpenJPAProvider/target
> > >> [INFO]
> > 
> > >> [INFO] BUILD SUCCESS
> > >> [INFO]
> > 
> > >> [INFO] Total time: 0.294s
> > >> [INFO] Finished at: Sun Jul 21 18:43:08 CEST 2013
> > >> [INFO] Final Memory: 6M/131M
> > >> [INFO]
> > 
> > >>
> > >> Tommys-MacBook-Pro:APSOpenJPAProvider tommy$ ls -l
> > >> total 24
> > >> -rw-r--r--  1 tommy  staff  2218 21 Jul 18:37 aps-openjpa-provider.iml
> > >> drwxr-xr-x  8 tommy  staff   272 21 Jul 12:17 docs
> > >> -rw-r--r--  1 tommy  staff  5469 21 Jul 18:37 pom.xml
> > >> drwxr-xr-x  3 tommy  staff   102 21 Jul 12:17 src
> > >>
> > >> Tommys

Compiler warnings treated as errors

[Aliaksei Lahachou]

Hello all,

I think this problem was already discussed here, but I cannot find it. My
problem is that sometimes compiler warnings are treated as errors. For
example:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
(default-compile) on project <...>: Compilation failure: Compilation
failure:
[ERROR] <...>\ImageCaptchaServlet.java:[14,31]
com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and may be
removed in a future release
[ERROR] <...>\ImageCaptchaServlet.java:[15,31]
com.sun.image.codec.jpeg.JPEGImageEncoder is Sun proprietary API and may be
removed in a future release

This is not a problem with m-compiler-p version 2.3.2, but it is a problem
in all newer versions (I tried 2.4, 2.5, 2.5.1, 3.0, 3.1).

This behavior seems to be unstable. The source from the example was
compiled successfully, when they were a part of other Maven module. When I
moved it to another module after refactoring, I could not compile it any
more. Both modules are inherited from the same parent and have the same
m-compiler-p configuration (I also compared effective POMs).

I tried building trunk version of m-compiler-p. There, the
CompilerMojoTestCase.testCompilerFork test fails, and it seems to me for
the same reason:

testCompilerFork(org.apache.maven.plugin.compiler.CompilerMojoTestCase)
Time elapsed: 0.09 sec  <<< ERROR!
org.apache.maven.plugin.compiler.CompilationFailureException: Compilation
failure
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:862)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at
org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerFork(CompilerMojoTestCase.java:160)


The following code seems a bit strange to me. Why does it throw a
compilation failure exception when there are warnings?

if ( !errors.isEmpty() )
{
throw new CompilationFailureException( errors );
}
else
{
throw new CompilationFailureException( warnings );
}

My environment is Windows 7 x64, Oracle JDK 1.6.0_45.

Is this a known problem? Is there a workaround for it? (other than using
version 2.3.2 version of m-compiler-p)

Regards,
htfv (Aliaksei Lahachou)

Re: maven surefire - selecting providers

[Francesco Mari]

I tried to reproduce the problem with the version 2.14.1 of the plugin, but
everything works correctly. Which version of the plugin are you using?


2013/7/24 Andreas Dolk 

> Sure, here we go:
>
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> ${version.maven-surefire-plugin}
> 
> 
> org.apache.maven.surefire
> surefire-junit47
>
> ${version.maven-surefire-plugin}
> 
> 
> org.apache.maven.surefire
> surefire-testng
>
> ${version.maven-surefire-plugin}
> 
> 
> 
> 
> **/*Spec*.java
> **/*Feature.java
> **/*Test.java
> **/*TestCase.java
> 
> 1
> false
> 
> 
>
>
>
> Andreas
>
>
> 2013/7/24 Francesco Mari 
>
> > Can you provide your configuration for the m-surefire-p?
> >
> >
> > 2013/7/24 Andreas Dolk 
> >
> > > Hello all,
> > >
> > > we have maven builds for projects that use both jUnit and testNG tests.
> > So
> > > I configured the maven surefire plugin to use multiple providers (
> > >
> > >
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html
> > > )
> > > and it works pretty well - apart from the problem, that now TestNG
> tries
> > to
> > > run every single jUnit test in the project. It takes about 2 seconds
> for
> > > each test until it finds out that it has nothing to to (only jUnit
> > > annotations on the test class)
> > >
> > > The annoying part is that now some tests that failed with jUnit are
> > marked
> > > ok after TestNG didn't find a problem.
> > >
> > > Is there anyway to configure surefire or the providers so that they
> only
> > > run "their own" tests and ignore the others? A solution where  rename
> the
> > > test to filter by names would be fine for me.
> > >
> > > Best regards,
> > >
> > >
> > > Andreas
> > >
> >
>
>
>
> --
> Andreas Dolk
>
> Zurmainerstraße 33
> D-54292 Trier
> Phone「+49 651 4362884」
> Mobile「+49 177 4970815」
> EMail「andreas.dolk.mo...@googlemail.com」
>

Re: maven surefire - selecting providers

[Andreas Dolk]

Sure, here we go:


org.apache.maven.plugins
maven-surefire-plugin
${version.maven-surefire-plugin}


org.apache.maven.surefire
surefire-junit47

${version.maven-surefire-plugin}


org.apache.maven.surefire
surefire-testng

${version.maven-surefire-plugin}




**/*Spec*.java
**/*Feature.java
**/*Test.java
**/*TestCase.java

1
false





Andreas


2013/7/24 Francesco Mari 

> Can you provide your configuration for the m-surefire-p?
>
>
> 2013/7/24 Andreas Dolk 
>
> > Hello all,
> >
> > we have maven builds for projects that use both jUnit and testNG tests.
> So
> > I configured the maven surefire plugin to use multiple providers (
> >
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html
> > )
> > and it works pretty well - apart from the problem, that now TestNG tries
> to
> > run every single jUnit test in the project. It takes about 2 seconds for
> > each test until it finds out that it has nothing to to (only jUnit
> > annotations on the test class)
> >
> > The annoying part is that now some tests that failed with jUnit are
> marked
> > ok after TestNG didn't find a problem.
> >
> > Is there anyway to configure surefire or the providers so that they only
> > run "their own" tests and ignore the others? A solution where  rename the
> > test to filter by names would be fine for me.
> >
> > Best regards,
> >
> >
> > Andreas
> >
>



-- 
Andreas Dolk

Zurmainerstraße 33
D-54292 Trier
Phone「+49 651 4362884」
Mobile「+49 177 4970815」
EMail「andreas.dolk.mo...@googlemail.com」

Re: maven surefire - selecting providers

[Francesco Mari]

Can you provide your configuration for the m-surefire-p?


2013/7/24 Andreas Dolk 

> Hello all,
>
> we have maven builds for projects that use both jUnit and testNG tests. So
> I configured the maven surefire plugin to use multiple providers (
>
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html
> )
> and it works pretty well - apart from the problem, that now TestNG tries to
> run every single jUnit test in the project. It takes about 2 seconds for
> each test until it finds out that it has nothing to to (only jUnit
> annotations on the test class)
>
> The annoying part is that now some tests that failed with jUnit are marked
> ok after TestNG didn't find a problem.
>
> Is there anyway to configure surefire or the providers so that they only
> run "their own" tests and ignore the others? A solution where  rename the
> test to filter by names would be fine for me.
>
> Best regards,
>
>
> Andreas
>