Re: svn commit: r511210 - in /maven/plugins/trunk/maven-antrun-plugin: ./ src/it/test6/ src/main/java/org/apache/maven/plugin/antrun/ src/main/java/org/apache/maven/plugin/antrun/components/ src/main/

[Jason van Zyl]

On 23 Feb 07, at 11:52 PM 23 Feb 07, [EMAIL PROTECTED] wrote:


Author: brett
Date: Fri Feb 23 20:52:20 2007
New Revision: 511210

URL: http://svn.apache.org/viewvc?view=rev&rev=511210
Log:
roll back r462640, these tests are failing



Fine provided it's not just a snapshot deployment missing. And really  
it boils down to the continuum output being useless because I can't  
easily see it amongst a mass of crap it spits out.

D


Added:
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/AntPropertyHelper.java
  - copied unchanged from r462640, maven/plugins/trunk/maven- 
antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/ 
AntPropertyHelper.java
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/components/
  - copied from r462640, maven/plugins/trunk/maven-antrun- 
plugin/src/main/java/org/apache/maven/plugin/antrun/components/
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/components/AntTargetConverter.java
  - copied unchanged from r462640, maven/plugins/trunk/maven- 
antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/ 
components/AntTargetConverter.java

maven/plugins/trunk/maven-antrun-plugin/src/main/resources/
  - copied from r462640, maven/plugins/trunk/maven-antrun- 
plugin/src/main/resources/
maven/plugins/trunk/maven-antrun-plugin/src/main/resources/META- 
INF/
  - copied from r462640, maven/plugins/trunk/maven-antrun- 
plugin/src/main/resources/META-INF/
maven/plugins/trunk/maven-antrun-plugin/src/main/resources/META- 
INF/plexus/
  - copied from r462640, maven/plugins/trunk/maven-antrun- 
plugin/src/main/resources/META-INF/plexus/
maven/plugins/trunk/maven-antrun-plugin/src/main/resources/META- 
INF/plexus/components.xml
  - copied unchanged from r462640, maven/plugins/trunk/maven- 
antrun-plugin/src/main/resources/META-INF/plexus/components.xml

Modified:
maven/plugins/trunk/maven-antrun-plugin/pom.xml
maven/plugins/trunk/maven-antrun-plugin/src/it/test6/build.xml
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/AbstractAntMojo.java
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/AntRunMojo.java
maven/plugins/trunk/maven-antrun-plugin/src/test/java/org/ 
apache/maven/plugin/antrun/AntRunMojoTest.java


Modified: maven/plugins/trunk/maven-antrun-plugin/pom.xml
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-antrun- 
plugin/pom.xml?view=diff&rev=511210&r1=511209&r2=511210
== 


--- maven/plugins/trunk/maven-antrun-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-antrun-plugin/pom.xml Fri Feb 23  
20:52:20 2007

@@ -15,7 +15,9 @@
   ~ limitations under the License.

 -->
-xsi:schemaLocation='http://maven.apache.org/POM/4.0.0 http:// 
maven.apache.org/maven-v4_0_0.xsd' xmlns='http://maven.apache.org/ 
POM/4.0.0'>

+http://maven.apache.org/POM/4.0.0";
+  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http:// 
maven.apache.org/maven-v4_0_0.xsd">

   
 maven-plugins
 org.apache.maven.plugins
@@ -36,11 +38,6 @@
   
   
 
-  org.apache.maven.shared
-  maven-ant
-  1.0-SNAPSHOT
-
-
   org.apache.maven
   maven-plugin-api
   2.0.1
@@ -105,5 +102,3 @@
 
   
 
-
-

Modified: maven/plugins/trunk/maven-antrun-plugin/src/it/test6/ 
build.xml
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-antrun- 
plugin/src/it/test6/build.xml?view=diff&rev=511210&r1=511209&r2=511210
== 

--- maven/plugins/trunk/maven-antrun-plugin/src/it/test6/build.xml  
(original)
+++ maven/plugins/trunk/maven-antrun-plugin/src/it/test6/build.xml  
Fri Feb 23 20:52:20 2007

@@ -2,9 +2,9 @@
 

 
-
+
 

-
+
 
 
 

Modified: maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/AbstractAntMojo.java
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-antrun- 
plugin/src/main/java/org/apache/maven/plugin/antrun/ 
AbstractAntMojo.java?view=diff&rev=511210&r1=511209&r2=511210
== 

--- maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/AbstractAntMojo.java (original)
+++ maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/ 
apache/maven/plugin/antrun/AbstractAntMojo.java Fri Feb 23 20:52:20  
2007

@@ -16,13 +16,26 @@
  * limitations under the License.
  */

+import java.io.File;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Iterator;
+import java.util.List;
+
+import org.apache.maven.artifact.Artifact;
+import  
org.apache.maven.artifact.Depend

continuum instance down

[Brett Porter]

I've taken this down to upgrade the database after the jpox update so  
we can run continuum trunk. Should be back up and running tomorrow.


- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: what to do about chronically failing plugins?

[Brett Porter]

antrun: rolled back r462641 (jvanzyl) - passes again.

eclipse: just the one failure (though still exceptionally slow - 5  
minutes) - EclipsePluginMasterProjectTest. It only fails when clean,  
so it could be a simple fix. Anyone familiar able to take a look?


repository: was fixed a little while back


On 24/01/2007, at 5:00 PM, Brett Porter wrote:

antrun, eclipse and repository are all failing both on my machine,  
and on CI. Is this the case for everyone else too?


I got no responses on any of these last time I asked, so the next  
steps I'll take are to create a branch of the current code, and  
then start rolling trunk back until they work on each, and let  
whoever made the changes figure out how to get them back in again.


I'm also getting failures locally on the dependency plugin, but not  
in CI. Anyone else seeing this? Maybe it depends on local  
repository state?


- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Integration Testing

[Brett Porter]

On 04/01/2007, at 4:32 PM, Brett Porter wrote:


Jason - any further thoughts on this?


Ping... No is a valid answer :)

I'd like to get your summary put somewhere individuals can pick  
things off to work on - probably a jira project for shared. WDYT?


I'm overcommitted for working on things right now, but I know a  
couple of people are confused about the IT testing, and we've got all  
those chronically broken plugins. Volunteers?



On 18/12/2006, at 4:35 PM, Brett Porter wrote:



On 12/12/2006, at 5:08 AM, Jason van Zyl wrote:

So, in response to John's email: I think we need to settle on  
what we're going to use and stop writing new tools. We have  
several invokers, several verifiers, several IT plugins, and the  
plugin harness. It is simply out of control. We have different  
methods being used in different plugins, nothing is standard and  
it's going to kill us. The most prevalent tool, as defective as  
it might be is what is being used in the ITs themselves. Stephane  
managed to use this successfully in some of his plugins. Then  
after that we have an array of usages. What should happen before  
we start writing more stuff is to figure out something we can use  
now, and how to merge what we have together instead of writing  
more tools.


Agreed. I think that's what John was getting at too, but by doing  
it clean rather than rewriting something that was in use  
somewhere. So the work left to do, in either case, is apply it  
consistently and get rid of the stuff we aren't going to use.


To me, it looks like:
- the plugin-testing-harness needs to go. They should be  
integration tests that use a proper pom, or use pure mocks rather  
than the stubs that tend to just have a bunch of impossible-to-get- 
under-real-condition values.
- John's test tools have the most complete invocation options, and  
tools for managing repositories that we can reuse, so I'd opt for  
that in that area
- the verifier is well utilised, so if that is merged with the  
code from the verifier plugin then we can lose the invocation  
stuff and repository management stuff and merge it all together


Can we have a wiki page with this work list? Or, can we check in  
the omni outliner files + an export for the non-mac users to review?


[snip points I agree with]


- [+] The ITs should be in a project of their own so that we can
  reuse them across versions of Maven. We could actually run
  new versions of integration tests against old versions of
  Maven. Solution: the ITs are now in a separate build  
and it

  is possible to run them


How should this play out in plugins? I would be in favour of  
separate projects for these.


Two things that are must haves for me:
- integration tests / anything that forks a Maven instance must  
*not* be part of the normal test build for a plugin. They take way  
too long, and lead to use of maven.test.skip :(
- as far as integration testing in general, I think we recommend a  
separate project, but enable them to be part of the same project  
for simplicity of development (this is more specific to things  
like web applications where it is probably beneficial).



- [ ] We should be able to easily integrate the IT into a larger
  run where we can use forked or embedded execution.


Not sure what you mean here. What is an IT that *doesn't* use  
forked or embedded execution?



- [ ] automate the testing of ITs submitted by users


what does this mean? I think, like a patch, a submitted IT still  
needs to be reviewed, and incorporated into the main test suite  
(with corresponding fix-for version so it only runs when it is  
expected to work). Otherwise, long term, we'll have lots of  
duplicated or poorly conceived ITs. I've seen test cases submitted  
that are quite useful at demonstrating something, but contain half  
of the user's proect which is not good for our long term scalability.


- [ ] Each IT should have its own repository if it needs  
resources
  from repository. We can't mess with a users repository  
when

  testing.
- [ ] We need to have a file system based remote repository for
  testing


Agreed. Isn't that what John's tool already does?

- [ ] We need to standardize on integration testing in  
general. We

  have people going all over the place and it's a disaster.
- [ ] We have too many IT plugins (3)
- [ ] We have too many invokers (5)
- [ ] We have too many verifiers (3)


Let's specifically get these mapped out and a path forward so that  
everyone can push towards it, rather than relying on you to do the  
work.



- [ ] The ITs should run nicely from an IDE. Solution: this does
  work but requires that you run mvn clean
  resources:testResources first as the IDE doesn't know  
how to

  set that up. Needs to be fully fixed. But it is much nicer
  running this stuff in your IDE.


Agree with th

Re: Need someone to review my patch for JXR

[Brett Porter]

It all looks pretty much right to me - I'd say go for it.

- Brett

On 24/02/2007, at 8:52 AM, Dennis Lundberg wrote:

I have posted a proposed patch to add include/exclude functionality  
to JXR here:

  http://jira.codehaus.org/browse/JXR-17

This is the last remaining issue scheduled for the 1.1 release.

As this is my first venture into JXR I would appreciate if someone  
could review this patch. If it is considered good I can apply it  
myself.


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: surefire 2.3 SUREFIRE-122 vs. SUREFIRE-256

[Brett Porter]

I didn't review any of the issues other than at a high level to  
schedule them. 2.3 will be released if the vote passes and 2.4 will  
be started straight away and all the issues evaluated.


I've commented on the issue that the tests still need to be applied -  
thanks for pointing it out.


- Brett

On 24/02/2007, at 6:37 AM, berndq wrote:


Hi,

SUREFIRE-256 has basically the same patch as SUREFIRE-122.
Furthermore SUREFIRE-256 has tests plus the patch.

Just wondering why -122 was applied and closed and -256
deferred to 2.4.

best regards
Bernd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extension to install custom proxy muck in Maven?

[Jason Dillon]

Yes Maven 2.0.x does allow you to configure a mirror for a repo, but  
that is *not* what I am looking for.


Also, there is no corporate proxy, if I has the luxury of such a  
proxy for my users then this would not be an issue.  The problem is  
that my users are all of the folks who build Apache Geronimo... and I  
can't force them all to setup a proxy pointing at some server for all  
artifacts.


What I need is a way to install/configure a tiny proxy which can  
follow some simple rules (aka something like DSMP) and have it run  
automatically *inside* of the Maven JVM w/o the user having to worry  
about it at all (ie. they still run `mvn install` and it works just  
the same).


--jason


On Feb 23, 2007, at 2:01 PM, Joakim Erdfelt wrote:


Actually, I believe the current maven 2.0.5 supports setting up a
 entry like this 


  corporate.proxy
  *
  http://my.corporate.proxy/maven/


(typed from memory, parsing errors potential in effect)

This would in effect send all requests to your corporate proxy.

- Joakim

Jason Dillon wrote:

(seems I keep sending these to [EMAIL PROTECTED] instead of [EMAIL PROTECTED])

Is it possible to install a Maven extension which can configure
Maven's proxy handling?

I'm wondering if with little work, that it might be possible to  
create
some kinda of plugin to Maven, which would embed a simply proxy  
server
(kinda like DSMP) directly into Maven, and then configure Maven to  
use

that server as a proxy.

I really need a way to control what repos our projects use, and since
we use artifacts which list other repos, there is no easy way (that I
know of) to limit this behavior except for configuring a proxy and
putting the controls in the proxy process.

The problem with this technique is that it...

a) requires users' to configure maven to use the proxy

b) requires users to start a proxy process and/or point at a remote
server, in which case you need a remote server and bandwidth to
effectively use.

Both of these end up becoming blockers to actually making this a
reality.  But, Maven is a Plexus application, and its easy enough to
write a Plexus component which implements this proxy, so why not have
the one Maven process boot up the proxy, and then configure Maven to
use that proxy?  This seems to me the best way, short of major  
changes

to Maven, to get real concrete control over how Maven uses remote
repositories.

For the case at hand, what I really want is to, no matter what repos
are configured (by the project or by dependencies of the project),
only grab artifacts from one repository... and to help
populate/maintain that repository, flip a switch on the proxy
component to all it to pass-through to all configure urls for  
artifacts.


There are a few other use cases I can think of... I'd like to install
a listener into the proxy component which will simply catalog all
artifact requests and at the end of a build simply dump a list of all
artifacts which were used.  Another, is that for some automated
builds, I need to keep the "cache" of artifacts separate from the set
of artifacts which are actually used by a project.  This isn't'  
really

possible now, but with a proxy layer, I can easily separate cached
artifacts from artifacts used in a project.

 * * *

Anyways... I really think that having this extra proxy component in
the Maven process would be a massive help to solve some of the more
complicated repository issues which we (Geronimo) are facing with
using Maven.  I think that if I could get a proxy component into the
Maven bootstrap, and provide some ability for the project to  
configure

it, that it would really help improve the quality of our builds with
Maven.

I also don't think its that difficult to implement... the major issue
is... how does one install such a bootstrap component into Maven?  Is
it possible?  Or does one need to provide a separate assembly with
extra libs and extra components.xml or something along those lines?

--jason


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Poll: release continuum alpha

[Robert Dale]

On 2/23/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:


Question:  Should we take all the work that has been done on continuum
in the last year+ and get it pushed out as an Alpha1 or a Milestone1
or some suitable equivalent?

[+1/0/-1]


I was wondering what happened to release early, release often..

+1

--
Robert Dale

Re: Poll: release continuum alpha

[Hilco Wijbenga]

Yes, please release an alpha version.

Re: Poll: release continuum alpha

[Trygve Laugstøl]

Jesse McConnell wrote:

I was talking to trygve a bit on irc and it dovetailed nicely with
some plans I had talked about late last year in regard to
continuum...I am just about a month late is all.  We thought we ought
to take a poll on here about continuum and see what folks thought.
This is not a vote, its just a poll and perhaps a discussion starter
on short to mid term plans with continuum.  I just know it bothers me
a bit everytime someone pops on IRC and asks questions about continuum
1.0.3...which is quite aged atm with so many of the bugs on it
resolved on the trunk.




Question:  Should we take all the work that has been done on continuum
in the last year+ and get it pushed out as an Alpha1 or a Milestone1
or some suitable equivalent?


Yes, definitely. I feel bad every time I talk to someone using Continuum 
knowing that a whole bunch of annoying bugs are fixes and very useful 
features have been added.


A milestone should focus on showing the fancy new features and bugs 
fixed. Stuff like security, upgrading existing databases etc are all 
secondary. This will give the community the ability to check in on the 
latest development and make sure that the developers don't stray too far 
away from what the users actually need.



[+1/0/-1]


I though you said that this wasn't a vote? ;)

Thanks a whole lot for listening to me and taking the time to do this 
Jesse. I am very interested in getting 1.1 (or 1.0.4 if it has to be) 
out the door and can hopefully do some work for you guys.


--
Trygve

Is a Changeset without files allowed?

[Dennis Lundberg]

I'm trying to figure out
  http://jira.codehaus.org/browse/MCHANGELOG-54

The reporter is getting an NPE based on the fact that the ChangeSet 
returns null from getFiles(). I'm curious to know whether it is valid to 
have a ChangeSet without files, i.e. where getFiles() returns null. I 
feel as if the SCM provider should at least return an empty List from 
getFiles() if it contains no files.


The provider in this case is Synergy. Is this a bug in the Synergy 
provider? Or should the changes-plugin be altered to handle the case 
that getFiles() might return null?


--
Dennis Lundberg

Re: [VOTE] Release maven-changelog-plugin 2.0 (take 2)

[Dennis Lundberg]

Pinging all PMC members...

Dennis Lundberg skrev:

Hi,

I'd like to release the maven-changelog-plugin. A vote for this has 
already taken place before, but I'm adhering to the new release process 
with staged artifacts here. So I encourage you to cast your vote once more.


A lot of issues have been resolved for 2.0 as can be seen in JIRA:

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11211&fixfor=12471 



There are still 2 open issues, but I don't think they should hold back a
release:

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11211&fixfor=-1 



Revision: 508620

The staged artifacts are available here:

http://people.apache.org/~dennisl/staging-repository/org/apache/maven/plugins/maven-changelog-plugin/2.0/ 




The vote will be open for 72 hours.


Here is my +1




--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extension to install custom proxy muck in Maven?

[Joakim Erdfelt]

Actually, I believe the current maven 2.0.5 supports setting up a
 entry like this 


  corporate.proxy
  *
  http://my.corporate.proxy/maven/


(typed from memory, parsing errors potential in effect)

This would in effect send all requests to your corporate proxy.

- Joakim

Jason Dillon wrote:
> (seems I keep sending these to [EMAIL PROTECTED] instead of [EMAIL PROTECTED])
>
> Is it possible to install a Maven extension which can configure
> Maven's proxy handling?
>
> I'm wondering if with little work, that it might be possible to create
> some kinda of plugin to Maven, which would embed a simply proxy server
> (kinda like DSMP) directly into Maven, and then configure Maven to use
> that server as a proxy.
>
> I really need a way to control what repos our projects use, and since
> we use artifacts which list other repos, there is no easy way (that I
> know of) to limit this behavior except for configuring a proxy and
> putting the controls in the proxy process.
>
> The problem with this technique is that it...
>
> a) requires users' to configure maven to use the proxy
>
> b) requires users to start a proxy process and/or point at a remote
> server, in which case you need a remote server and bandwidth to
> effectively use.
>
> Both of these end up becoming blockers to actually making this a
> reality.  But, Maven is a Plexus application, and its easy enough to
> write a Plexus component which implements this proxy, so why not have
> the one Maven process boot up the proxy, and then configure Maven to
> use that proxy?  This seems to me the best way, short of major changes
> to Maven, to get real concrete control over how Maven uses remote
> repositories.
>
> For the case at hand, what I really want is to, no matter what repos
> are configured (by the project or by dependencies of the project),
> only grab artifacts from one repository... and to help
> populate/maintain that repository, flip a switch on the proxy
> component to all it to pass-through to all configure urls for artifacts.
>
> There are a few other use cases I can think of... I'd like to install
> a listener into the proxy component which will simply catalog all
> artifact requests and at the end of a build simply dump a list of all
> artifacts which were used.  Another, is that for some automated
> builds, I need to keep the "cache" of artifacts separate from the set
> of artifacts which are actually used by a project.  This isn't' really
> possible now, but with a proxy layer, I can easily separate cached
> artifacts from artifacts used in a project.
>
>  * * *
>
> Anyways... I really think that having this extra proxy component in
> the Maven process would be a massive help to solve some of the more
> complicated repository issues which we (Geronimo) are facing with
> using Maven.  I think that if I could get a proxy component into the
> Maven bootstrap, and provide some ability for the project to configure
> it, that it would really help improve the quality of our builds with
> Maven.
>
> I also don't think its that difficult to implement... the major issue
> is... how does one install such a bootstrap component into Maven?  Is
> it possible?  Or does one need to provide a separate assembly with
> extra libs and extra components.xml or something along those lines?
>
> --jason
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote-result] injecting attributes into the Site mojo failing?

[Elliot Metsger]

Aha.  This problem may be related to :
http://www.nabble.com/forum/ViewPost.jtp?post=2337561&framed=y&skin=177

Elliot Metsger wrote:
> 
> I'm attempting to inject attributes into the site plugin like so in my
> pom:
> 
> 
> bar
> 
> 
>   bar
> 
> site.vm
> 
> 
> 
> Supposedly I'm allowed to do this according to the online documentation,
> and according to the annotation on the attributes field of the
> AbstractSiteRender class.
> 
> However, when running 'mvn -X site', the attributes do not show up:
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:site' -->
> [DEBUG]   (f) generateReports = true
> [DEBUG]   (f) generatedSiteDirectory =
> /Users/esm/workspace/pluto11trunk/pluto-site/target/generated-site
> [DEBUG]   (f) inputEncoding = ISO-8859-1
> [DEBUG]   (f) localRepository = [local] ->
> file:///Users/esm/.m2/repository
> [DEBUG]   (f) outputDirectory =
> /Users/esm/workspace/pluto11trunk/pluto-site/target/site
> [DEBUG]   (f) outputEncoding = ISO-8859-1
> [DEBUG]   (f) project = [EMAIL PROTECTED]
> [DEBUG]   (f) reactorProjects =
> [EMAIL PROTECTED]
> [DEBUG]   (f) reports =
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED]
> [DEBUG]   (f) repositories = [[apache.snapshots] ->
> http://people.apache.org/repo/m2-snapshot-repository, [central] ->
> http://repo1.maven.org/maven2]
> [DEBUG]   (f) siteDirectory =
> /Users/esm/workspace/pluto11trunk/pluto-site/src/site
> [DEBUG]   (f) template = site.vm
> [DEBUG]   (f) templateDirectory =
> /Users/esm/workspace/pluto11trunk/pluto-site/src/site
> [DEBUG]   (f) xdocDirectory =
> /Users/esm/workspace/pluto11trunk/pluto-site/xdocs
> [DEBUG] -- end configuration --
> 
> I've added debugging to the AbstractSiteRenderingMojo, and indeed the
> attributes Map is null, despite it being configured in the POM.  
> 
> I've discovered that if I change
> /**
>  * @parameter expression="${attributes}"
>  */
> protected Map attributes;
> 
> to (take away expression="${attributes}"):
> 
> /**
>  * @parameter
>  */
> protected Map attributes;
> 
> and re-install the site plugin, my / element is
> used.
> 
> Any ideas?  
> 
> Thanks,
> Elliot
> 

-- 
View this message in context: 
http://www.nabble.com/injecting-attributes-into-the-Site-mojo-failing--tf3276726s177.html#a9127535
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Need someone to review my patch for JXR

[Dennis Lundberg]

I have posted a proposed patch to add include/exclude functionality to 
JXR here:

  http://jira.codehaus.org/browse/JXR-17

This is the last remaining issue scheduled for the 1.1 release.

As this is my first venture into JXR I would appreciate if someone could 
review this patch. If it is considered good I can apply it myself.


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Extension to install custom proxy muck in Maven?

[Jason Dillon]

(seems I keep sending these to [EMAIL PROTECTED] instead of [EMAIL PROTECTED])

Is it possible to install a Maven extension which can configure  
Maven's proxy handling?


I'm wondering if with little work, that it might be possible to  
create some kinda of plugin to Maven, which would embed a simply  
proxy server (kinda like DSMP) directly into Maven, and then  
configure Maven to use that server as a proxy.


I really need a way to control what repos our projects use, and since  
we use artifacts which list other repos, there is no easy way (that I  
know of) to limit this behavior except for configuring a proxy and  
putting the controls in the proxy process.


The problem with this technique is that it...

a) requires users' to configure maven to use the proxy

b) requires users to start a proxy process and/or point at a remote  
server, in which case you need a remote server and bandwidth to  
effectively use.


Both of these end up becoming blockers to actually making this a  
reality.  But, Maven is a Plexus application, and its easy enough to  
write a Plexus component which implements this proxy, so why not have  
the one Maven process boot up the proxy, and then configure Maven to  
use that proxy?  This seems to me the best way, short of major  
changes to Maven, to get real concrete control over how Maven uses  
remote repositories.


For the case at hand, what I really want is to, no matter what repos  
are configured (by the project or by dependencies of the project),  
only grab artifacts from one repository... and to help populate/ 
maintain that repository, flip a switch on the proxy component to all  
it to pass-through to all configure urls for artifacts.


There are a few other use cases I can think of... I'd like to install  
a listener into the proxy component which will simply catalog all  
artifact requests and at the end of a build simply dump a list of all  
artifacts which were used.  Another, is that for some automated  
builds, I need to keep the "cache" of artifacts separate from the set  
of artifacts which are actually used by a project.  This isn't'  
really possible now, but with a proxy layer, I can easily separate  
cached artifacts from artifacts used in a project.


 * * *

Anyways... I really think that having this extra proxy component in  
the Maven process would be a massive help to solve some of the more  
complicated repository issues which we (Geronimo) are facing with  
using Maven.  I think that if I could get a proxy component into the  
Maven bootstrap, and provide some ability for the project to  
configure it, that it would really help improve the quality of our  
builds with Maven.


I also don't think its that difficult to implement... the major issue  
is... how does one install such a bootstrap component into Maven?  Is  
it possible?  Or does one need to provide a separate assembly with  
extra libs and extra components.xml or something along those lines?


--jason


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Poll: release continuum alpha

[Vivek_Nakeesan]

Sounds good and can't waiting for the milestone build with fixes

~nakees





   
   
   
 "Jesse McConnell"  To 
  cc 
   
   Subject 
 23/02/2007 04:35  Poll: release continuum alpha   
 PM
   
   
 Please respond to 
 [EMAIL PROTECTED] 
   en.apache.org   
   
   




I was talking to trygve a bit on irc and it dovetailed nicely with
some plans I had talked about late last year in regard to
continuum...I am just about a month late is all.  We thought we ought
to take a poll on here about continuum and see what folks thought.
This is not a vote, its just a poll and perhaps a discussion starter
on short to mid term plans with continuum.  I just know it bothers me
a bit everytime someone pops on IRC and asks questions about continuum
1.0.3...which is quite aged atm with so many of the bugs on it
resolved on the trunk.




Question:  Should we take all the work that has been done on continuum
in the last year+ and get it pushed out as an Alpha1 or a Milestone1
or some suitable equivalent?

[+1/0/-1]


jesse



--
jesse mcconnell
[EMAIL PROTECTED]

Re: Poll: release continuum alpha

[Stephane Nicoll]

I've a SNAPSHOT of early february and it runs OK (except  minor issues
with the "remember me" feature - I'll open an issue for that later).

I guess having an alpha out is a good thing, especially to make sure
that a 1.0.3 instance can be upgraded to 1.1

Cheers,
Stéphane

On 2/23/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:

I was talking to trygve a bit on irc and it dovetailed nicely with
some plans I had talked about late last year in regard to
continuum...I am just about a month late is all.  We thought we ought
to take a poll on here about continuum and see what folks thought.
This is not a vote, its just a poll and perhaps a discussion starter
on short to mid term plans with continuum.  I just know it bothers me
a bit everytime someone pops on IRC and asks questions about continuum
1.0.3...which is quite aged atm with so many of the bugs on it
resolved on the trunk.




Question:  Should we take all the work that has been done on continuum
in the last year+ and get it pushed out as an Alpha1 or a Milestone1
or some suitable equivalent?

[+1/0/-1]


jesse



--
jesse mcconnell
[EMAIL PROTECTED]

Poll: release continuum alpha

[Jesse McConnell]

I was talking to trygve a bit on irc and it dovetailed nicely with
some plans I had talked about late last year in regard to
continuum...I am just about a month late is all.  We thought we ought
to take a poll on here about continuum and see what folks thought.
This is not a vote, its just a poll and perhaps a discussion starter
on short to mid term plans with continuum.  I just know it bothers me
a bit everytime someone pops on IRC and asks questions about continuum
1.0.3...which is quite aged atm with so many of the bugs on it
resolved on the trunk.




Question:  Should we take all the work that has been done on continuum
in the last year+ and get it pushed out as an Alpha1 or a Milestone1
or some suitable equivalent?

[+1/0/-1]


jesse



--
jesse mcconnell
[EMAIL PROTECTED]

surefire 2.3 SUREFIRE-122 vs. SUREFIRE-256

[berndq]

Hi,

SUREFIRE-256 has basically the same patch as SUREFIRE-122.
Furthermore SUREFIRE-256 has tests plus the patch.

Just wondering why -122 was applied and closed and -256
deferred to 2.4.

best regards
Bernd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Questions on remote resources plugin

[Brett Porter]

That's what it was. It changed from NOTICE.txt to NOTICE in alpha-2,  
so I had the wrong name. Working now - thanks.


On 24/02/2007, at 3:38 AM, Daniel Kulp wrote:



Brett,

On Friday 23 February 2007 10:38, Daniel Kulp wrote:

On Friday 23 February 2007 03:14, Brett Porter wrote:
I've worked around it for now, but I wanted to understand a  
couple of

things:
- is there a way to append a custom notice? surefire-api contains
code from springframework (not a dependency), and I couldn't get
anything to append the right text
- what does appended-resources do? I thought it was the above,  
but it

didn't seem to work for me


Hmm...   that IS what's it's supposed to do.  I'll take a look.   The
file in the appended-resources has to EXACTLY match the target  
name of

the remote-resource.


I just verified that this does work, but for a moment, I thought it  
wasn't

working and got confused.  Maybe you did too.   :-)

The name is VERY important.   The name of the resource
is "META-INF/NOTICE".   Thus, the text you want appended would be in:

${basedir}/src/main/appended-resources/META-INF/NOTICE

I had originally just put it in:
${basedir}/src/main/appended-resources/NOTICE
and it wasn't working.

Can you verify that the full name of the appended stuff is correct and
re-try?


Thanks!
Dan




- alpha-2 seems to include notices for all of the dependencies. I
don't believe this to be correct - it should only be needed if they
are actually included in the distribution, which for a jar they are
not. Should this be made a flag?


Depends on which lawyers you're talking to.  :-(   Some want a  
complete
description of everything that's needed to use the jar as well.
I'm of
the opinion that more is better.  apache-jar-resource-bundle:1.1  
changes

the wording to "This product includes/uses software" to allow the
"not included, but does use it" case.

This is not a part of the remote-resources, but of the
apache-jar-resource-bundle.   alpha-2 of RR didn't provide access  
to the
dependencies at all, but the apache-jar-resource-bundle:1.0  
pretended it
did.   With apache-jar-resource-bundle:1.1, the velocity templates  
have

been updated to allow some flags to be passed in.   One flag is the
noProjects.  You can add:

 true

to the config and it will turn those off.

apache-jar-resource-bundle:1.1 ALSO adds preProjectText and
postProjectText properties where you can provide extra text to be put
before/after the project list.

apache-jar-resource-bundle:1.1.1-SNAPSHOT adds a "projectName"  
property

that can be used to specify the project name used (instead
of "project.name" from the pom).   That's more for the large
multi-module projects.   Example:  "Apache Geronimo"  instead of each
individual module name.

Does that help?


--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Carlos Sanchez]

+1

On 2/23/07, Brett Porter <[EMAIL PROTECTED]> wrote:

Please vote for the release of Surefire 2.3. This now includes the
API, providers, plugin and report plugin.

[ ] +1
[ ] 0
[ ] -1

Staged at: http://people.apache.org/~brett/release-staging-repo/

Vote is open for 72 hours.

Release notes:

** Bug
 * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
directories after mvn test
 * [SUREFIRE-53] - context classloader not always reset to
original values
 * [SUREFIRE-54] - Remove use of parent classloader in
surefirebooter but keep TestNG support working
 * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
 * [SUREFIRE-101] - Plugin not longer sets system properties when
forking is on and debugging information is not correct
 * [SUREFIRE-105] - Documentation link on website does not point
to surefire parameter docs
 * [SUREFIRE-106] - Classloading problem for getting a resource
 * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
dependencies which generate error
 * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException
when errors occur during TestSetup decorator
 * [SUREFIRE-120] - When you  a JUnit TestSuite (with no
test methods), no tests are run
 * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
 * [SUREFIRE-123] - SurefireBooter can initialize classloader
with badly formed URLs
 * [SUREFIRE-125] - Surefire finds test classes but ignores test
methods and configuration methods with TestNG and includes tag
 * [SUREFIRE-127] - Wrong issue-site URL on website
 * [SUREFIRE-263] - Source repository information on the web site
is out of date

** Improvement
 * [SUREFIRE-31] - support junit 4.0
 * [SUREFIRE-134] - Display location of test failures/errors on
summary
 * [SUREFIRE-135] - when fork is enabled, Surefire should use the
same JVM running Maven (i.e. use java.home sysprop), rather than
expecting java to be in the system PATH
 * [SUREFIRE-138] - Add option to redirect stdout from tests to a
file

** New Feature
 * [SUREFIRE-129] - add a property to skip tests execution (but
not tests compilation)

** Task
 * [SUREFIRE-133] - Review Plugin Documentation

Note: a 2.4 release is being worked on immediately to resolve some
issues with TestNG. This release is being made available to users
having the above problems before that work begins.

Cheers,
Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Jason van Zyl]

On 23 Feb 07, at 10:39 AM 23 Feb 07, John Casey wrote:

+1, though I would be interested to see if there are any plans to  
write up

documentation for it...the website is pretty bad.



Yah, but I think we've forced people to read the code now so getting  
the release out is more important. It's tough to write docs and we're  
historically not very good it. So out it goes. We would probably have  
better luck writing a plugin that writes documentation. We would  
probably finish the AI engine necessary for that first.


Jason.


http://maven.apache.org/surefire

-john

On 2/23/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:



+1  - we've been waiting for this for WAY too long.  (we're still  
using

2.1.3 due to some of the bugs)


Dan


On Friday 23 February 2007 03:52, Brett Porter wrote:
> Please vote for the release of Surefire 2.3. This now includes the
> API, providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
>  * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
> directories after mvn test
>  * [SUREFIRE-53] - context classloader not always reset to
> original values
>  * [SUREFIRE-54] - Remove use of parent classloader in
> surefirebooter but keep TestNG support working
>  * [SUREFIRE-99] - Surefire plugin fails if JUnit is not  
available
>  * [SUREFIRE-101] - Plugin not longer sets system properties  
when

> forking is on and debugging information is not correct
>  * [SUREFIRE-105] - Documentation link on website does not  
point

> to surefire parameter docs
>  * [SUREFIRE-106] - Classloading problem for getting a resource
>  * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
> dependencies which generate error
>  * [SUREFIRE-114] - Surefire plugin throws  
NoSuchMethodException

> when errors occur during TestSetup decorator
>  * [SUREFIRE-120] - When you  a JUnit TestSuite  
(with no

> test methods), no tests are run
>  * [SUREFIRE-122] - With forkmode once, XML reports are  
cumulative

>  * [SUREFIRE-123] - SurefireBooter can initialize classloader
> with badly formed URLs
>  * [SUREFIRE-125] - Surefire finds test classes but ignores  
test

> methods and configuration methods with TestNG and includes tag
>  * [SUREFIRE-127] - Wrong issue-site URL on website
>  * [SUREFIRE-263] - Source repository information on the web  
site

> is out of date
>
> ** Improvement
>  * [SUREFIRE-31] - support junit 4.0
>  * [SUREFIRE-134] - Display location of test failures/errors on
> summary
>  * [SUREFIRE-135] - when fork is enabled, Surefire should  
use the

> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
>  * [SUREFIRE-138] - Add option to redirect stdout from tests  
to a

> file
>
> ** New Feature
>  * [SUREFIRE-129] - add a property to skip tests execution (but
> not tests compilation)
>
> ** Task
>  * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users
> having the above problems before that work begins.
>
> Cheers,
> Brett
>
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WSS4J pom.xml should include runtime xalan dependency

[Carlos Sanchez]

Please read http://maven.apache.org/guides/mini/guide-maven-evangelism.html

On 2/23/07, Frank Cornelis <[EMAIL PROTECTED]> wrote:

Hi,

The Maven2 pom.xml for WSS4J 1.5.1 should also contain the next
dependency:


xalan
xalan
2.7.0
runtime




Regards,
Frank.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Jason van Zyl]

+1

On 23 Feb 07, at 3:52 AM 23 Feb 07, Brett Porter wrote:

Please vote for the release of Surefire 2.3. This now includes the  
API, providers, plugin and report plugin.


[ ] +1
[ ] 0
[ ] -1

Staged at: http://people.apache.org/~brett/release-staging-repo/

Vote is open for 72 hours.

Release notes:

** Bug
* [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName  
directories after mvn test
* [SUREFIRE-53] - context classloader not always reset to  
original values
* [SUREFIRE-54] - Remove use of parent classloader in  
surefirebooter but keep TestNG support working

* [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
* [SUREFIRE-101] - Plugin not longer sets system properties  
when forking is on and debugging information is not correct
* [SUREFIRE-105] - Documentation link on website does not point  
to surefire parameter docs

* [SUREFIRE-106] - Classloading problem for getting a resource
* [SUREFIRE-113] - surefire-providers-2.0.pom contains strange  
dependencies which generate error
* [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException  
when errors occur during TestSetup decorator
* [SUREFIRE-120] - When you  a JUnit TestSuite (with  
no test methods), no tests are run

* [SUREFIRE-122] - With forkmode once, XML reports are cumulative
* [SUREFIRE-123] - SurefireBooter can initialize classloader  
with badly formed URLs
* [SUREFIRE-125] - Surefire finds test classes but ignores test  
methods and configuration methods with TestNG and includes tag

* [SUREFIRE-127] - Wrong issue-site URL on website
* [SUREFIRE-263] - Source repository information on the web  
site is out of date


** Improvement
* [SUREFIRE-31] - support junit 4.0
* [SUREFIRE-134] - Display location of test failures/errors on  
summary
* [SUREFIRE-135] - when fork is enabled, Surefire should use  
the same JVM running Maven (i.e. use java.home sysprop), rather  
than expecting java to be in the system PATH
* [SUREFIRE-138] - Add option to redirect stdout from tests to  
a file


** New Feature
* [SUREFIRE-129] - add a property to skip tests execution (but  
not tests compilation)


** Task
* [SUREFIRE-133] - Review Plugin Documentation

Note: a 2.4 release is being worked on immediately to resolve some  
issues with TestNG. This release is being made available to users  
having the above problems before that work begins.


Cheers,
Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] merge Archiva MRM-239 branch to trunk

[Brett Porter]

+1

I'm not done, but I can't see any issues at a high level. I'll post  
any thoughts I have later.


- Brett

On 23/02/2007, at 7:54 PM, Brett Porter wrote:

Applying them now won't help... they'd still need to painstakingly  
be applied to the branch. Just as easy to do that after the merge  
(if they are still relevant).


I believe some things on trunk may have changed since the last  
merge - a final check of that will be needed first.


I'm still reviewing the code, myself... vote to arrive later  
tonight :)


- Brett

On 23/02/2007, at 7:49 PM, Arnaud HERITIER wrote:


One thing before ...
Can we have the list of patchs that aren't yet applied on the trunk ?
Don't we have to apply them before or we'll never be able to do it  
(due to

the important changes you made) ?

Arnaud

On 2/23/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


+1

Emmanuel

Joakim Erdfelt a écrit :
> I would like to merge the archiva-MRM-239 branch back to trunk.
>
> Not sure how long I should wait for the vote replies, but I'll  
do the

> usual 72.
>
> - Joakim
>
>
>

Re: [vote] Release Maven Surefire 2.3

[Brett Porter]

I'll drop this task into JIRA along with the test suite for 2.4.

On 24/02/2007, at 3:39 AM, Jason van Zyl wrote:



On 23 Feb 07, at 10:39 AM 23 Feb 07, John Casey wrote:

+1, though I would be interested to see if there are any plans to  
write up

documentation for it...the website is pretty bad.



Yah, but I think we've forced people to read the code now so  
getting the release out is more important. It's tough to write docs  
and we're historically not very good it. So out it goes. We would  
probably have better luck writing a plugin that writes  
documentation. We would probably finish the AI engine necessary for  
that first.


Jason.


http://maven.apache.org/surefire

-john

On 2/23/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:



+1  - we've been waiting for this for WAY too long.  (we're still  
using

2.1.3 due to some of the bugs)


Dan


On Friday 23 February 2007 03:52, Brett Porter wrote:
> Please vote for the release of Surefire 2.3. This now includes the
> API, providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
>  * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
> directories after mvn test
>  * [SUREFIRE-53] - context classloader not always reset to
> original values
>  * [SUREFIRE-54] - Remove use of parent classloader in
> surefirebooter but keep TestNG support working
>  * [SUREFIRE-99] - Surefire plugin fails if JUnit is not  
available
>  * [SUREFIRE-101] - Plugin not longer sets system  
properties when

> forking is on and debugging information is not correct
>  * [SUREFIRE-105] - Documentation link on website does not  
point

> to surefire parameter docs
>  * [SUREFIRE-106] - Classloading problem for getting a  
resource
>  * [SUREFIRE-113] - surefire-providers-2.0.pom contains  
strange

> dependencies which generate error
>  * [SUREFIRE-114] - Surefire plugin throws  
NoSuchMethodException

> when errors occur during TestSetup decorator
>  * [SUREFIRE-120] - When you  a JUnit TestSuite  
(with no

> test methods), no tests are run
>  * [SUREFIRE-122] - With forkmode once, XML reports are  
cumulative

>  * [SUREFIRE-123] - SurefireBooter can initialize classloader
> with badly formed URLs
>  * [SUREFIRE-125] - Surefire finds test classes but ignores  
test

> methods and configuration methods with TestNG and includes tag
>  * [SUREFIRE-127] - Wrong issue-site URL on website
>  * [SUREFIRE-263] - Source repository information on the  
web site

> is out of date
>
> ** Improvement
>  * [SUREFIRE-31] - support junit 4.0
>  * [SUREFIRE-134] - Display location of test failures/ 
errors on

> summary
>  * [SUREFIRE-135] - when fork is enabled, Surefire should  
use the

> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
>  * [SUREFIRE-138] - Add option to redirect stdout from  
tests to a

> file
>
> ** New Feature
>  * [SUREFIRE-129] - add a property to skip tests execution  
(but

> not tests compilation)
>
> ** Task
>  * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users
> having the above problems before that work begins.
>
> Cheers,
> Brett
>
>
>  
 
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] merge Archiva MRM-239 branch to trunk

[Joakim Erdfelt]

With the following voters in favor ...

  Brett, Arnaud, Emmanuel, Nicolas

... the merge will commence shortly

- Joakim


Brett Porter wrote:
> +1
>
> I'm not done, but I can't see any issues at a high level. I'll post
> any thoughts I have later.
>
> - Brett
>
> On 23/02/2007, at 7:54 PM, Brett Porter wrote:
>
>> Applying them now won't help... they'd still need to painstakingly be
>> applied to the branch. Just as easy to do that after the merge (if
>> they are still relevant).
>>
>> I believe some things on trunk may have changed since the last merge
>> - a final check of that will be needed first.
>>
>> I'm still reviewing the code, myself... vote to arrive later tonight :)
>>
>> - Brett
>>
>> On 23/02/2007, at 7:49 PM, Arnaud HERITIER wrote:
>>
>>> One thing before ...
>>> Can we have the list of patchs that aren't yet applied on the trunk ?
>>> Don't we have to apply them before or we'll never be able to do it
>>> (due to
>>> the important changes you made) ?
>>>
>>> Arnaud
>>>
>>> On 2/23/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:

 +1

 Emmanuel

 Joakim Erdfelt a écrit :
 > I would like to merge the archiva-MRM-239 branch back to trunk.
 >
 > Not sure how long I should wait for the vote replies, but I'll do
 the
 > usual 72.
 >
 > - Joakim
 >
 >
 >


>

Re: Questions on remote resources plugin

[Daniel Kulp]

Brett,

On Friday 23 February 2007 10:38, Daniel Kulp wrote:
> On Friday 23 February 2007 03:14, Brett Porter wrote:
> > I've worked around it for now, but I wanted to understand a couple of
> > things:
> > - is there a way to append a custom notice? surefire-api contains
> > code from springframework (not a dependency), and I couldn't get
> > anything to append the right text
> > - what does appended-resources do? I thought it was the above, but it
> > didn't seem to work for me
>
> Hmm...   that IS what's it's supposed to do.  I'll take a look.   The
> file in the appended-resources has to EXACTLY match the target name of
> the remote-resource.

I just verified that this does work, but for a moment, I thought it wasn't 
working and got confused.  Maybe you did too.   :-)

The name is VERY important.   The name of the resource 
is "META-INF/NOTICE".   Thus, the text you want appended would be in:

${basedir}/src/main/appended-resources/META-INF/NOTICE

I had originally just put it in:
${basedir}/src/main/appended-resources/NOTICE
and it wasn't working.

Can you verify that the full name of the appended stuff is correct and 
re-try?


Thanks!
Dan



> > - alpha-2 seems to include notices for all of the dependencies. I
> > don't believe this to be correct - it should only be needed if they
> > are actually included in the distribution, which for a jar they are
> > not. Should this be made a flag?
>
> Depends on which lawyers you're talking to.  :-(   Some want a complete
> description of everything that's needed to use the jar as well.   I'm of
> the opinion that more is better.  apache-jar-resource-bundle:1.1 changes
> the wording to "This product includes/uses software" to allow the
> "not included, but does use it" case.
>
> This is not a part of the remote-resources, but of the
> apache-jar-resource-bundle.   alpha-2 of RR didn't provide access to the
> dependencies at all, but the apache-jar-resource-bundle:1.0 pretended it
> did.   With apache-jar-resource-bundle:1.1, the velocity templates have
> been updated to allow some flags to be passed in.   One flag is the
> noProjects.  You can add:
> 
>  true
> 
> to the config and it will turn those off.
>
> apache-jar-resource-bundle:1.1 ALSO adds preProjectText and
> postProjectText properties where you can provide extra text to be put
> before/after the project list.
>
> apache-jar-resource-bundle:1.1.1-SNAPSHOT adds a "projectName" property
> that can be used to specify the project name used (instead
> of "project.name" from the pom).   That's more for the large
> multi-module projects.   Example:  "Apache Geronimo"  instead of each
> individual module name.
>
> Does that help?

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[John Casey]

+1, though I would be interested to see if there are any plans to write up
documentation for it...the website is pretty bad.

http://maven.apache.org/surefire

-john

On 2/23/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:



+1  - we've been waiting for this for WAY too long.  (we're still using
2.1.3 due to some of the bugs)


Dan


On Friday 23 February 2007 03:52, Brett Porter wrote:
> Please vote for the release of Surefire 2.3. This now includes the
> API, providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
>  * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
> directories after mvn test
>  * [SUREFIRE-53] - context classloader not always reset to
> original values
>  * [SUREFIRE-54] - Remove use of parent classloader in
> surefirebooter but keep TestNG support working
>  * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
>  * [SUREFIRE-101] - Plugin not longer sets system properties when
> forking is on and debugging information is not correct
>  * [SUREFIRE-105] - Documentation link on website does not point
> to surefire parameter docs
>  * [SUREFIRE-106] - Classloading problem for getting a resource
>  * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
> dependencies which generate error
>  * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException
> when errors occur during TestSetup decorator
>  * [SUREFIRE-120] - When you  a JUnit TestSuite (with no
> test methods), no tests are run
>  * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
>  * [SUREFIRE-123] - SurefireBooter can initialize classloader
> with badly formed URLs
>  * [SUREFIRE-125] - Surefire finds test classes but ignores test
> methods and configuration methods with TestNG and includes tag
>  * [SUREFIRE-127] - Wrong issue-site URL on website
>  * [SUREFIRE-263] - Source repository information on the web site
> is out of date
>
> ** Improvement
>  * [SUREFIRE-31] - support junit 4.0
>  * [SUREFIRE-134] - Display location of test failures/errors on
> summary
>  * [SUREFIRE-135] - when fork is enabled, Surefire should use the
> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
>  * [SUREFIRE-138] - Add option to redirect stdout from tests to a
> file
>
> ** New Feature
>  * [SUREFIRE-129] - add a property to skip tests execution (but
> not tests compilation)
>
> ** Task
>  * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users
> having the above problems before that work begins.
>
> Cheers,
> Brett
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Questions on remote resources plugin

[Daniel Kulp]

On Friday 23 February 2007 03:14, Brett Porter wrote:
> I've worked around it for now, but I wanted to understand a couple of
> things:
> - is there a way to append a custom notice? surefire-api contains
> code from springframework (not a dependency), and I couldn't get
> anything to append the right text
> - what does appended-resources do? I thought it was the above, but it
> didn't seem to work for me

Hmm...   that IS what's it's supposed to do.  I'll take a look.   The file 
in the appended-resources has to EXACTLY match the target name of the 
remote-resource.

> - alpha-2 seems to include notices for all of the dependencies. I
> don't believe this to be correct - it should only be needed if they
> are actually included in the distribution, which for a jar they are
> not. Should this be made a flag?

Depends on which lawyers you're talking to.  :-(   Some want a complete 
description of everything that's needed to use the jar as well.   I'm of 
the opinion that more is better.  apache-jar-resource-bundle:1.1 changes 
the wording to "This product includes/uses software" to allow the "not 
included, but does use it" case.

This is not a part of the remote-resources, but of the 
apache-jar-resource-bundle.   alpha-2 of RR didn't provide access to the 
dependencies at all, but the apache-jar-resource-bundle:1.0 pretended it 
did.   With apache-jar-resource-bundle:1.1, the velocity templates have 
been updated to allow some flags to be passed in.   One flag is the 
noProjects.  You can add:

 true

to the config and it will turn those off.

apache-jar-resource-bundle:1.1 ALSO adds preProjectText and postProjectText 
properties where you can provide extra text to be put before/after the 
project list.

apache-jar-resource-bundle:1.1.1-SNAPSHOT adds a "projectName" property 
that can be used to specify the project name used (instead 
of "project.name" from the pom).   That's more for the large multi-module 
projects.   Example:  "Apache Geronimo"  instead of each individual module 
name.  

Does that help?

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Daniel Kulp]

+1  - we've been waiting for this for WAY too long.  (we're still using 
2.1.3 due to some of the bugs)


Dan


On Friday 23 February 2007 03:52, Brett Porter wrote:
> Please vote for the release of Surefire 2.3. This now includes the
> API, providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
>  * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
> directories after mvn test
>  * [SUREFIRE-53] - context classloader not always reset to
> original values
>  * [SUREFIRE-54] - Remove use of parent classloader in
> surefirebooter but keep TestNG support working
>  * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
>  * [SUREFIRE-101] - Plugin not longer sets system properties when
> forking is on and debugging information is not correct
>  * [SUREFIRE-105] - Documentation link on website does not point
> to surefire parameter docs
>  * [SUREFIRE-106] - Classloading problem for getting a resource
>  * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
> dependencies which generate error
>  * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException
> when errors occur during TestSetup decorator
>  * [SUREFIRE-120] - When you  a JUnit TestSuite (with no
> test methods), no tests are run
>  * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
>  * [SUREFIRE-123] - SurefireBooter can initialize classloader
> with badly formed URLs
>  * [SUREFIRE-125] - Surefire finds test classes but ignores test
> methods and configuration methods with TestNG and includes tag
>  * [SUREFIRE-127] - Wrong issue-site URL on website
>  * [SUREFIRE-263] - Source repository information on the web site
> is out of date
>
> ** Improvement
>  * [SUREFIRE-31] - support junit 4.0
>  * [SUREFIRE-134] - Display location of test failures/errors on
> summary
>  * [SUREFIRE-135] - when fork is enabled, Surefire should use the
> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
>  * [SUREFIRE-138] - Add option to redirect stdout from tests to a
> file
>
> ** New Feature
>  * [SUREFIRE-129] - add a property to skip tests execution (but
> not tests compilation)
>
> ** Task
>  * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users
> having the above problems before that work begins.
>
> Cheers,
> Brett
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Inviting Proximity Devs to work with Maven Enterprise

[Jason van Zyl]

On 23 Feb 07, at 8:58 AM 23 Feb 07, Tamás Cservenák wrote:


Hi,

The main Proximity developer is here! :)

Thank you the invitation and we (at AbstractHorizon.org) think
it is pretty neat idea.

Proximity1 (note the 1 at the end) is in usable shape (even sorted
out the issue of WebDAV and deployment) and it is very near main 1.0
release.

Licensing wise, we were thinking about the final license of Proximity
(and all other Abstract Horizon projects) and so far it looks like
we will just go for LGPL. Hopefully that is something you can use.


Unfortunately it's not something we can use here, but Proximity can  
be combined in another open project outside Apache. If you want to  
distribute it from Apache with Maven Enterprise then it must be a  
compatible license as far as distribution goes and our legal folks  
have ruled out LGPL.



If not - I don't think that there will be a problem finding out some
common ground or a solution for integration of Proximity to ME.



That would help with distribution and that would also allow, if you  
wished, to incubate the code and bring to Apache. But for inclusion  
in ME we just need need a compatible license. Here is a draft of what  
will mostly likely be our official policy and what we follow now anyway:


http://people.apache.org/~cliffs/3party.html


Collaboration wise, your e-mail couldn't come in the better time -
since Proximity is closing to the 1.0 release we have already
started preparations for Proximity 2 which should be all singing
and dancing version of Proximity 1 and more. Functionality
of existing Proximity is going to be a bit more formalised and
all these border cases are to be given as a choice to the end user.
Your input into this area is going to be appreciated!

Aside Proximity 2 there are some other grand ideas two of us already
touched some time ago and collaboration in the area Maven is
really good way forward. Who knows what else (long term of course) can
come out of it :)

Ok, for a start, please let us know about specifics we can be of
help to you and if you had anything else in mind.



The licensing is the real issue for now as that would prevent  
redistribution in ME. Next would be a discussion of how to integrate  
and that would most likely be security. I know you have your own  
security system it appeared from the code so a good way to bridge  
that would be cool. And all these discussions we can have here.


I'm really just interested in supporting anyone who's written a good  
Maven applications who have alleviated some pain for users. If you  
need help with resources or helping get the word out. I believe we  
should be helping anyone creating applications that are of use the  
Maven folks even if they are external to the ASF. It simply doesn't  
matter, a good application put out by folks who are answering user  
questions and supporting their application deserves out support.



Looking forward working together,



Cool, glad you piped up! :-)

Jason.


Tamas,

On 2/22/07, Jason van Zyl < [EMAIL PROTECTED] > wrote:


Hi,

I think the main Proximity developer is here, and I was wondering if
you would like to work with us on Maven Enterprise (ME)? Essentially
this means us putting a small wrapper around Proximity and firing it
up from the ME server? I'm not sure what the licensing is on
Proximity but if it's a license compatible with the ASF then we could
package up Proximity with ME which I think would be very cool. I've
heard good things about Proximity, and only tried it out for a week
but I think you guys have done the leg work and have something that
works well and we should support you instead of our meagre efforts in
this area. You have made something that works and people like and I
think it would be wise to incorporate it into ME if you're
interested. We should be encouraging people making good Maven-based
applications and I think Proximity is a perfect example.

This doesn't mean moving your project anywhere, really just
redistributing a binary of Proximity with some integration pieces. I
am using an extended version of ME for a client which wraps a Spring
application so I don't think wrapping Proximity would be any
different. I honestly have a couple clients who want proxy support
and they have already started looking at Proximity because maven-
proxy is not supported and Archiva didn't really work. I also have
some training in the near future and at ApacheCon and I'm going to be
using ME or an open variant of it and so I would like to include
Proximity because that's what I would like to promote in the
training. I can go ahead and just make a bundle that includes
Proximity for training but some official collaboration would be
preferable and I think that's ultimately more beneficial to Maven
users who want enterprise grade proxy support.

Any of the Proximity developers care to comment?

Thanks,

Jason.



-
To unsubscribe, e-mail: [EMAIL PROTE

Re: [vote-result] injecting attributes into the Site mojo failing?

[Elliot Metsger]

Hey Vincent,

Do you recall if the solution was in the Site Plugin itself, or some other
component like Plexus?  I'm having a bear of a time searching Codehaus' Jira
and anything I can do to narrow the search result would help.

Best,
Elliot

Vincent Siveton wrote:
> 
> Hi Elliot,
> 
> I am remembering this issue and I was thinking that it was already
> closed in the past.
> 
> Cheers,
> 
> Vincent
> 
> 2007/2/22, Elliot Metsger <[EMAIL PROTECTED]>:
>>
>> I'm attempting to inject attributes into the site plugin like so in my
>> pom:
>> 
>> 
>> bar
>> 
>> 
>>   bar
>> 
>> site.vm
>> 
>> 
>>
>> Supposedly I'm allowed to do this according to the online documentation,
>> and
>> according to the annotation on the attributes field of the
>> AbstractSiteRender class.
>>
>> However, when running 'mvn -X site', the attributes do not show up:
>> [DEBUG] Configuring mojo
>> 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:site' -->
>> [DEBUG]   (f) generateReports = true
>> [DEBUG]   (f) generatedSiteDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/target/generated-site
>> [DEBUG]   (f) inputEncoding = ISO-8859-1
>> [DEBUG]   (f) localRepository = [local] ->
>> file:///Users/esm/.m2/repository
>> [DEBUG]   (f) outputDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/target/site
>> [DEBUG]   (f) outputEncoding = ISO-8859-1
>> [DEBUG]   (f) project = [EMAIL PROTECTED]
>> [DEBUG]   (f) reactorProjects =
>> [EMAIL PROTECTED]
>> [DEBUG]   (f) reports =
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED]
>> [DEBUG]   (f) repositories = [[apache.snapshots] ->
>> http://people.apache.org/repo/m2-snapshot-repository, [central] ->
>> http://repo1.maven.org/maven2]
>> [DEBUG]   (f) siteDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/src/site
>> [DEBUG]   (f) template = site.vm
>> [DEBUG]   (f) templateDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/src/site
>> [DEBUG]   (f) xdocDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/xdocs
>> [DEBUG] -- end configuration --
>>
>> I've added debugging to the AbstractSiteRenderingMojo, and indeed the
>> attributes Map is null, despite it being configured in the POM.
>>
>> I've discovered that if I change
>> /**
>>  * @parameter expression="${attributes}"
>>  */
>> protected Map attributes;
>>
>> to (take away expression="${attributes}"):
>>
>> /**
>>  * @parameter
>>  */
>> protected Map attributes;
>>
>> and re-install the site plugin, my / element
>> is
>> used.
>>
>> Any ideas?
>>
>> Thanks,
>> Elliot
>> --
>> View this message in context:
>> http://www.nabble.com/injecting-attributes-into-the-Site-mojo-failing--tf3276726s177.html#a9112657
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/injecting-attributes-into-the-Site-mojo-failing--tf3276726s177.html#a9119857
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: build loop feature 4 continuum?

[Tilman.Rossmy]

allright, I understand now, if you force a build (through the webfrontend) it's 
going to build regardless of scm result (see 
org.apache.maven.continuum.buildcontroller.DefaultBuildController). so no 
starteam provider problem here, thanx

-Original Message-
From: Edwin Punzalan [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 23, 2007 6:42 AM
To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?


That's odd.  Mine doesn't build a project if there are no SCM changes.  
The projects in my Continuum instance are from an SVN repo.  Maybe its an 
SCM-related problem.  What's your SCM provider?  Are you sure there aren't any 
changes?


[EMAIL PROTECTED] wrote:
> can I configure that a clean install is only executed if there are any scm 
> changes? Right now the build is executed regardless if there are any changes 
> (the message 'Changes found, building' seems to appear independent of the scm 
> result). and also send a notification on every  update event (indicated by 
> the 'Updated x files' message).
>
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 21, 2007 2:20 PM
> To: continuum-dev@maven.apache.org
> Subject: Re: build loop feature 4 continuum?
>
> yes.
>
> [EMAIL PROTECTED] a écrit :
>   
>> ok, cool, so before doing the 'clean install' in the default build continuum 
>> executes a 'scm:update'?
>>
>> -Original Message-
>> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, February 20, 2007 5:23 PM
>> To: continuum-dev@maven.apache.org
>> Subject: Re: build loop feature 4 continuum?
>>
>> It's the base of continuum.
>>
>> [EMAIL PROTECTED] a écrit :
>> 
>>> Hi guys!
>>> I need something like the build loop feature of CruiseControl:
>>> "The Build Loop is designed to run as a daemon process which will 
>>> periodically check your source control tool for changes to your 
>>> codebase, build if necessary, and send out a notification regarding 
>>> the status of the build."
>>> So before I start developing a plugin myself, does something like 
>>> that already exist or is being developed?
>>>
>>> Thanx
>>> Tilman
>>>
>>>
>>>
>>>
>>>   
>>
>>
>> 
>
>
>   

Re: Inviting Proximity Devs to work with Maven Enterprise

[Tamás Cservenák]

Hi,

The main Proximity developer is here! :)

Thank you the invitation and we (at AbstractHorizon.org) think
it is pretty neat idea.

Proximity1 (note the 1 at the end) is in usable shape (even sorted
out the issue of WebDAV and deployment) and it is very near main 1.0
release.

Licensing wise, we were thinking about the final license of Proximity
(and all other Abstract Horizon projects) and so far it looks like
we will just go for LGPL. Hopefully that is something you can use.
If not - I don't think that there will be a problem finding out some
common ground or a solution for integration of Proximity to ME.

Collaboration wise, your e-mail couldn't come in the better time -
since Proximity is closing to the 1.0 release we have already
started preparations for Proximity 2 which should be all singing
and dancing version of Proximity 1 and more. Functionality
of existing Proximity is going to be a bit more formalised and
all these border cases are to be given as a choice to the end user.
Your input into this area is going to be appreciated!

Aside Proximity 2 there are some other grand ideas two of us already
touched some time ago and collaboration in the area Maven is
really good way forward. Who knows what else (long term of course) can
come out of it :)

Ok, for a start, please let us know about specifics we can be of
help to you and if you had anything else in mind.

Looking forward working together,

Tamas,

On 2/22/07, Jason van Zyl < [EMAIL PROTECTED] > wrote:


Hi,

I think the main Proximity developer is here, and I was wondering if
you would like to work with us on Maven Enterprise (ME)? Essentially
this means us putting a small wrapper around Proximity and firing it
up from the ME server? I'm not sure what the licensing is on
Proximity but if it's a license compatible with the ASF then we could
package up Proximity with ME which I think would be very cool. I've
heard good things about Proximity, and only tried it out for a week
but I think you guys have done the leg work and have something that
works well and we should support you instead of our meagre efforts in
this area. You have made something that works and people like and I
think it would be wise to incorporate it into ME if you're
interested. We should be encouraging people making good Maven-based
applications and I think Proximity is a perfect example.

This doesn't mean moving your project anywhere, really just
redistributing a binary of Proximity with some integration pieces. I
am using an extended version of ME for a client which wraps a Spring
application so I don't think wrapping Proximity would be any
different. I honestly have a couple clients who want proxy support
and they have already started looking at Proximity because maven-
proxy is not supported and Archiva didn't really work. I also have
some training in the near future and at ApacheCon and I'm going to be
using ME or an open variant of it and so I would like to include
Proximity because that's what I would like to promote in the
training. I can go ahead and just make a bundle that includes
Proximity for training but some official collaboration would be
preferable and I think that's ultimately more beneficial to Maven
users who want enterprise grade proxy support.

Any of the Proximity developers care to comment?

Thanks,

Jason.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JBoss Support

[Robert Dale]

I don't know how much of an issue this really is, but it's not a
terrible idea to have an ear activated only by profile.  But one thing
to consider is if application server-specific files should be allowed.
If you let jboss in, who and how many are next? Where do you draw the
line?  Fringe configurations like that are an unneeded maintenance
issue.  A better place might be the wiki with instructions on where to
place the file.

Alternatively, you could change the name of the webapp by adding
your-name-here to the  definition in the
webapp's pom.xml.  You could even use a property in there like
${myName} and set it from command-line -DmyName= or from a .

--
Robert Dale

On 2/23/07, Thierry Lach <[EMAIL PROTECTED]> wrote:

As far as the ear goes, the patch does add a separate module named
continuum-ear.  It's only content is the pom and it uses the ear plugin with
very little configuration other than the context root name.  The other thing
it does is add the continuum-ear module to the root pom in a profile named
"ear", and a property naming the ear context root.

The main (and only) reason I added the ear module is simplification of
install.  Dropping in a war file in JBoss means that you have to rename the
war file to the context root you want.  This way I can leave the ear file
name as generated and be sure which version of the ear I have installed.
Alternatively, deploying on Websphere (which is our standard deployment
server) does not require entering the context root with an ear, while with a
war it does.  One less thing to get wrong.

On 2/22/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:
>
> there is an ear pluginif you rework that patch to be another
> module all together and generate that artifact with the ear plugin
> then I'll be happy to take a look and apply it I think...but its not
> standard practice to have a war artifact producing and ear :)
>
> out of curiousity, what are you adding that would require an ear over
> a war j2ee wise?
>
> jesse
>
> On 2/22/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> > I've just added an updated patch on
> > http://jira.codehaus.org/browse/CONTINUUM-1167.  Continuum will now
> > successfully send emails under JBoss.
> >
> > The patch also contains a new module to create an ear file for the war.
> This
> > is only activated through a profile named "ear", so to create the ear
> file
> > you must "mvn -Pear .". The context root is defined in the main pom
> as
> > continuum and can be overridden using -
> > Dcontinuum.ear.contextRoot=whateverYouWantItToBe.  [ Show
> > »]
> >  thierry lach<
> http://jira.codehaus.org/secure/ViewProfile.jspa?name=thierrylach>
> > [22/Feb/07 03:55 PM] I've added to the patch a little bit. It contains a
> fix
> > so that email can get sent. It also contains a new module to create an
> ear
> > file for the war. This is only activated through a profile named "ear",
> so
> > to create the ear file you must "mvn -Pear .". The context root is
> > defined in the main pom and can be overridden using -
> > Dcontinuum.ear.contextRoot=whateverYouWantItToBe.
> >
> >
> > On 2/16/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> > >
> > > BTW it looks like someone corrected application.xml so the existing
> patch
> > > should be sufficient.
> > >
> > > On 2/15/07, Thierry Lach < [EMAIL PROTECTED]> wrote:
> > > >
> > > > SUCCESS!
> > > >
> > > > OK it looks like the root cause is the inability to find class
> > > > org.codehaus.plexus.registry.CommonsConfigurationRegistry.  I think
> the
> > > > correct class name should be
> > > > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.
> since
> > > > that is what is contained in the plexus-registry-commons jar.  I've
> changed
> > > > the implementation name in the file
> > > > continuum-webapp/src/main/resources/META-INF/plexus/application.xml
> and it
> > > > seems to work now - I've been able to configure it and am now
> running a
> > > > maven1 build.  I'll update the patch sometime this evening to
> include the
> > > > change to application.xml.
> > > >
> > > >
> > > > On 2/15/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Yep - my rejoicing was a little premature it seems.  War deploy
> seems
> > > > > to behave fine but the website itself doesn't get up and run.
> > > > >
> > > > > On 2/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> >
> > > > > wrote:
> > > > > >
> > > > > > allright here we go:
> > > > > > with these two datasources things start moving the right
> direction
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > -Original Message-
> > > > > > From: Hilco Wijbenga [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Thursday, February 15, 2007 6:39 PM
> > > > > > To: continuum-dev@maven.apache.org
> > > > > > Subject: Re: JBoss Support
> > > > > >
> > > > > > On 2/15/07, Thierry Lach <[EMAIL PROTECTED] > wrote:
> > > > > > > Can you post the contents of your derby-ds.xml file
> please?  I'm

Re: [vote-result] injecting attributes into the Site mojo failing?

[Elliot Metsger]

Ok - I'll check Jira.  I'm on the latest release of the site plugin, so maybe
the fix is in an as-of-yet unreleased version of the site plugin.

Thanks for the heads up Vincent,

Elliot

Vincent Siveton wrote:
> 
> Hi Elliot,
> 
> I am remembering this issue and I was thinking that it was already
> closed in the past.
> 
> Cheers,
> 
> Vincent
> 
> 2007/2/22, Elliot Metsger <[EMAIL PROTECTED]>:
>>
>> I'm attempting to inject attributes into the site plugin like so in my
>> pom:
>> 
>> 
>> bar
>> 
>> 
>>   bar
>> 
>> site.vm
>> 
>> 
>>
>> Supposedly I'm allowed to do this according to the online documentation,
>> and
>> according to the annotation on the attributes field of the
>> AbstractSiteRender class.
>>
>> However, when running 'mvn -X site', the attributes do not show up:
>> [DEBUG] Configuring mojo
>> 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:site' -->
>> [DEBUG]   (f) generateReports = true
>> [DEBUG]   (f) generatedSiteDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/target/generated-site
>> [DEBUG]   (f) inputEncoding = ISO-8859-1
>> [DEBUG]   (f) localRepository = [local] ->
>> file:///Users/esm/.m2/repository
>> [DEBUG]   (f) outputDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/target/site
>> [DEBUG]   (f) outputEncoding = ISO-8859-1
>> [DEBUG]   (f) project = [EMAIL PROTECTED]
>> [DEBUG]   (f) reactorProjects =
>> [EMAIL PROTECTED]
>> [DEBUG]   (f) reports =
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED],
>> [EMAIL PROTECTED]
>> [DEBUG]   (f) repositories = [[apache.snapshots] ->
>> http://people.apache.org/repo/m2-snapshot-repository, [central] ->
>> http://repo1.maven.org/maven2]
>> [DEBUG]   (f) siteDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/src/site
>> [DEBUG]   (f) template = site.vm
>> [DEBUG]   (f) templateDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/src/site
>> [DEBUG]   (f) xdocDirectory =
>> /Users/esm/workspace/pluto11trunk/pluto-site/xdocs
>> [DEBUG] -- end configuration --
>>
>> I've added debugging to the AbstractSiteRenderingMojo, and indeed the
>> attributes Map is null, despite it being configured in the POM.
>>
>> I've discovered that if I change
>> /**
>>  * @parameter expression="${attributes}"
>>  */
>> protected Map attributes;
>>
>> to (take away expression="${attributes}"):
>>
>> /**
>>  * @parameter
>>  */
>> protected Map attributes;
>>
>> and re-install the site plugin, my / element
>> is
>> used.
>>
>> Any ideas?
>>
>> Thanks,
>> Elliot
>> --
>> View this message in context:
>> http://www.nabble.com/injecting-attributes-into-the-Site-mojo-failing--tf3276726s177.html#a9112657
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/injecting-attributes-into-the-Site-mojo-failing--tf3276726s177.html#a9118972
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Vincent Siveton]

+1

I saw that NestedRuntimeException and NestedCheckedException have old licenses.

Vincent

2007/2/23, Emmanuel Venisse <[EMAIL PROTECTED]>:

+1

Emmanuel

Brett Porter a écrit :
> Please vote for the release of Surefire 2.3. This now includes the API,
> providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
> * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName directories
> after mvn test
> * [SUREFIRE-53] - context classloader not always reset to original
> values
> * [SUREFIRE-54] - Remove use of parent classloader in surefirebooter
> but keep TestNG support working
> * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
> * [SUREFIRE-101] - Plugin not longer sets system properties when
> forking is on and debugging information is not correct
> * [SUREFIRE-105] - Documentation link on website does not point to
> surefire parameter docs
> * [SUREFIRE-106] - Classloading problem for getting a resource
> * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
> dependencies which generate error
> * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException when
> errors occur during TestSetup decorator
> * [SUREFIRE-120] - When you  a JUnit TestSuite (with no
> test methods), no tests are run
> * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
> * [SUREFIRE-123] - SurefireBooter can initialize classloader with
> badly formed URLs
> * [SUREFIRE-125] - Surefire finds test classes but ignores test
> methods and configuration methods with TestNG and includes tag
> * [SUREFIRE-127] - Wrong issue-site URL on website
> * [SUREFIRE-263] - Source repository information on the web site is
> out of date
>
> ** Improvement
> * [SUREFIRE-31] - support junit 4.0
> * [SUREFIRE-134] - Display location of test failures/errors on summary
> * [SUREFIRE-135] - when fork is enabled, Surefire should use the
> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
> * [SUREFIRE-138] - Add option to redirect stdout from tests to a file
>
> ** New Feature
> * [SUREFIRE-129] - add a property to skip tests execution (but not
> tests compilation)
>
> ** Task
> * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users having
> the above problems before that work begins.
>
> Cheers,
> Brett
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JBoss Support

[Thierry Lach]

Thanks much.  I probably wouldn't have gotten it done without your original
patch.

On 2/22/07, Hilco Wijbenga <[EMAIL PROTECTED]> wrote:


Nice work!

Re: JBoss Support

[Thierry Lach]

As far as the ear goes, the patch does add a separate module named
continuum-ear.  It's only content is the pom and it uses the ear plugin with
very little configuration other than the context root name.  The other thing
it does is add the continuum-ear module to the root pom in a profile named
"ear", and a property naming the ear context root.

The main (and only) reason I added the ear module is simplification of
install.  Dropping in a war file in JBoss means that you have to rename the
war file to the context root you want.  This way I can leave the ear file
name as generated and be sure which version of the ear I have installed.
Alternatively, deploying on Websphere (which is our standard deployment
server) does not require entering the context root with an ear, while with a
war it does.  One less thing to get wrong.

On 2/22/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:


there is an ear pluginif you rework that patch to be another
module all together and generate that artifact with the ear plugin
then I'll be happy to take a look and apply it I think...but its not
standard practice to have a war artifact producing and ear :)

out of curiousity, what are you adding that would require an ear over
a war j2ee wise?

jesse

On 2/22/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> I've just added an updated patch on
> http://jira.codehaus.org/browse/CONTINUUM-1167.  Continuum will now
> successfully send emails under JBoss.
>
> The patch also contains a new module to create an ear file for the war.
This
> is only activated through a profile named "ear", so to create the ear
file
> you must "mvn -Pear .". The context root is defined in the main pom
as
> continuum and can be overridden using -
> Dcontinuum.ear.contextRoot=whateverYouWantItToBe.  [ Show
> »]
>  thierry lach<
http://jira.codehaus.org/secure/ViewProfile.jspa?name=thierrylach>
> [22/Feb/07 03:55 PM] I've added to the patch a little bit. It contains a
fix
> so that email can get sent. It also contains a new module to create an
ear
> file for the war. This is only activated through a profile named "ear",
so
> to create the ear file you must "mvn -Pear .". The context root is
> defined in the main pom and can be overridden using -
> Dcontinuum.ear.contextRoot=whateverYouWantItToBe.
>
>
> On 2/16/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> >
> > BTW it looks like someone corrected application.xml so the existing
patch
> > should be sufficient.
> >
> > On 2/15/07, Thierry Lach < [EMAIL PROTECTED]> wrote:
> > >
> > > SUCCESS!
> > >
> > > OK it looks like the root cause is the inability to find class
> > > org.codehaus.plexus.registry.CommonsConfigurationRegistry.  I think
the
> > > correct class name should be
> > > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.
since
> > > that is what is contained in the plexus-registry-commons jar.  I've
changed
> > > the implementation name in the file
> > > continuum-webapp/src/main/resources/META-INF/plexus/application.xml
and it
> > > seems to work now - I've been able to configure it and am now
running a
> > > maven1 build.  I'll update the patch sometime this evening to
include the
> > > change to application.xml.
> > >
> > >
> > > On 2/15/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Yep - my rejoicing was a little premature it seems.  War deploy
seems
> > > > to behave fine but the website itself doesn't get up and run.
> > > >
> > > > On 2/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]
>
> > > > wrote:
> > > > >
> > > > > allright here we go:
> > > > > with these two datasources things start moving the right
direction
> > > > >
> > > >
> > > > 
> > > >
> > > > -Original Message-
> > > > > From: Hilco Wijbenga [mailto:[EMAIL PROTECTED]
> > > > > Sent: Thursday, February 15, 2007 6:39 PM
> > > > > To: continuum-dev@maven.apache.org
> > > > > Subject: Re: JBoss Support
> > > > >
> > > > > On 2/15/07, Thierry Lach <[EMAIL PROTECTED] > wrote:
> > > > > > Can you post the contents of your derby-ds.xml file
please?  I'm
> > > > > > guessing that the example I used for the Continuum+on_JBoss
> > > > > example
> > > > > > isn't correct enough for continuum.
> > > > >
> > > > > See http://docs.codehaus.org/display/MAVENUSER/Archiva+on+JBoss
> > > > >
> > > > > There used to be something similar for Continuum. I think your
JNDI
> > > > > name
> > > > > is wrong; all the silly stuff (comp/env/jdbc/) will be added by
> > > > > JBoss
> > > > > ... IIRC, it's been a while. :-)
> > > > >
> > > >
> > > >
> > >
> >
>


--
jesse mcconnell
[EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Emmanuel Venisse]

+1

Emmanuel

Brett Porter a écrit :
Please vote for the release of Surefire 2.3. This now includes the API, 
providers, plugin and report plugin.


[ ] +1
[ ] 0
[ ] -1

Staged at: http://people.apache.org/~brett/release-staging-repo/

Vote is open for 72 hours.

Release notes:

** Bug
* [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName directories 
after mvn test
* [SUREFIRE-53] - context classloader not always reset to original 
values
* [SUREFIRE-54] - Remove use of parent classloader in surefirebooter 
but keep TestNG support working

* [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
* [SUREFIRE-101] - Plugin not longer sets system properties when 
forking is on and debugging information is not correct
* [SUREFIRE-105] - Documentation link on website does not point to 
surefire parameter docs

* [SUREFIRE-106] - Classloading problem for getting a resource
* [SUREFIRE-113] - surefire-providers-2.0.pom contains strange 
dependencies which generate error
* [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException when 
errors occur during TestSetup decorator
* [SUREFIRE-120] - When you  a JUnit TestSuite (with no 
test methods), no tests are run

* [SUREFIRE-122] - With forkmode once, XML reports are cumulative
* [SUREFIRE-123] - SurefireBooter can initialize classloader with 
badly formed URLs
* [SUREFIRE-125] - Surefire finds test classes but ignores test 
methods and configuration methods with TestNG and includes tag

* [SUREFIRE-127] - Wrong issue-site URL on website
* [SUREFIRE-263] - Source repository information on the web site is 
out of date


** Improvement
* [SUREFIRE-31] - support junit 4.0
* [SUREFIRE-134] - Display location of test failures/errors on summary
* [SUREFIRE-135] - when fork is enabled, Surefire should use the 
same JVM running Maven (i.e. use java.home sysprop), rather than 
expecting java to be in the system PATH

* [SUREFIRE-138] - Add option to redirect stdout from tests to a file

** New Feature
* [SUREFIRE-129] - add a property to skip tests execution (but not 
tests compilation)


** Task
* [SUREFIRE-133] - Review Plugin Documentation

Note: a 2.4 release is being worked on immediately to resolve some 
issues with TestNG. This release is being made available to users having 
the above problems before that work begins.


Cheers,
Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Surefire 2.3

[Joakim Erdfelt]

+1

- Joakim

Brett Porter wrote:
> Please vote for the release of Surefire 2.3. This now includes the
> API, providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
> * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
> directories after mvn test
> * [SUREFIRE-53] - context classloader not always reset to original
> values
> * [SUREFIRE-54] - Remove use of parent classloader in
> surefirebooter but keep TestNG support working
> * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
> * [SUREFIRE-101] - Plugin not longer sets system properties when
> forking is on and debugging information is not correct
> * [SUREFIRE-105] - Documentation link on website does not point to
> surefire parameter docs
> * [SUREFIRE-106] - Classloading problem for getting a resource
> * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
> dependencies which generate error
> * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException
> when errors occur during TestSetup decorator
> * [SUREFIRE-120] - When you  a JUnit TestSuite (with no
> test methods), no tests are run
> * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
> * [SUREFIRE-123] - SurefireBooter can initialize classloader with
> badly formed URLs
> * [SUREFIRE-125] - Surefire finds test classes but ignores test
> methods and configuration methods with TestNG and includes tag
> * [SUREFIRE-127] - Wrong issue-site URL on website
> * [SUREFIRE-263] - Source repository information on the web site
> is out of date
>
> ** Improvement
> * [SUREFIRE-31] - support junit 4.0
> * [SUREFIRE-134] - Display location of test failures/errors on
> summary
> * [SUREFIRE-135] - when fork is enabled, Surefire should use the
> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
> * [SUREFIRE-138] - Add option to redirect stdout from tests to a file
>
> ** New Feature
> * [SUREFIRE-129] - add a property to skip tests execution (but not
> tests compilation)
>
> ** Task
> * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users
> having the above problems before that work begins.
>
> Cheers,
> Brett
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: injecting attributes into the Site mojo failing?

[Vincent Siveton]

Hi Elliot,

I am remembering this issue and I was thinking that it was already
closed in the past.

Cheers,

Vincent

2007/2/22, Elliot Metsger <[EMAIL PROTECTED]>:


I'm attempting to inject attributes into the site plugin like so in my pom:


bar


  bar

site.vm



Supposedly I'm allowed to do this according to the online documentation, and
according to the annotation on the attributes field of the
AbstractSiteRender class.

However, when running 'mvn -X site', the attributes do not show up:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:site' -->
[DEBUG]   (f) generateReports = true
[DEBUG]   (f) generatedSiteDirectory =
/Users/esm/workspace/pluto11trunk/pluto-site/target/generated-site
[DEBUG]   (f) inputEncoding = ISO-8859-1
[DEBUG]   (f) localRepository = [local] -> file:///Users/esm/.m2/repository
[DEBUG]   (f) outputDirectory =
/Users/esm/workspace/pluto11trunk/pluto-site/target/site
[DEBUG]   (f) outputEncoding = ISO-8859-1
[DEBUG]   (f) project = [EMAIL PROTECTED]
[DEBUG]   (f) reactorProjects =
[EMAIL PROTECTED]
[DEBUG]   (f) reports =
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
[DEBUG]   (f) repositories = [[apache.snapshots] ->
http://people.apache.org/repo/m2-snapshot-repository, [central] ->
http://repo1.maven.org/maven2]
[DEBUG]   (f) siteDirectory =
/Users/esm/workspace/pluto11trunk/pluto-site/src/site
[DEBUG]   (f) template = site.vm
[DEBUG]   (f) templateDirectory =
/Users/esm/workspace/pluto11trunk/pluto-site/src/site
[DEBUG]   (f) xdocDirectory =
/Users/esm/workspace/pluto11trunk/pluto-site/xdocs
[DEBUG] -- end configuration --

I've added debugging to the AbstractSiteRenderingMojo, and indeed the
attributes Map is null, despite it being configured in the POM.

I've discovered that if I change
/**
 * @parameter expression="${attributes}"
 */
protected Map attributes;

to (take away expression="${attributes}"):

/**
 * @parameter
 */
protected Map attributes;

and re-install the site plugin, my / element is
used.

Any ideas?

Thanks,
Elliot
--
View this message in context: 
http://www.nabble.com/injecting-attributes-into-the-Site-mojo-failing--tf3276726s177.html#a9112657
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: build loop feature 4 continuum?

[Franz Allan Valencia See]

Good day,

The maven scm provider for Star Stream is in [1].

Cheers,
Franz

[1] 
http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-providers/maven-scm-provider-starteam

On 2/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

we are having to use starteam...so good to know that it works on svn...what's 
the component that is responsible for it so I can debug it?

-Original Message-
From: Edwin Punzalan [mailto:[EMAIL PROTECTED]
Sent: Friday, February 23, 2007 6:42 AM
To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?


That's odd.  Mine doesn't build a project if there are no SCM changes.
The projects in my Continuum instance are from an SVN repo.  Maybe its an 
SCM-related problem.  What's your SCM provider?  Are you sure there aren't any 
changes?


[EMAIL PROTECTED] wrote:
> can I configure that a clean install is only executed if there are any scm 
changes? Right now the build is executed regardless if there are any changes (the 
message 'Changes found, building' seems to appear independent of the scm result). 
and also send a notification on every  update event (indicated by the 'Updated x 
files' message).
>
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 21, 2007 2:20 PM
> To: continuum-dev@maven.apache.org
> Subject: Re: build loop feature 4 continuum?
>
> yes.
>
> [EMAIL PROTECTED] a écrit :
>
>> ok, cool, so before doing the 'clean install' in the default build continuum 
executes a 'scm:update'?
>>
>> -Original Message-
>> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, February 20, 2007 5:23 PM
>> To: continuum-dev@maven.apache.org
>> Subject: Re: build loop feature 4 continuum?
>>
>> It's the base of continuum.
>>
>> [EMAIL PROTECTED] a écrit :
>>
>>> Hi guys!
>>> I need something like the build loop feature of CruiseControl:
>>> "The Build Loop is designed to run as a daemon process which will
>>> periodically check your source control tool for changes to your
>>> codebase, build if necessary, and send out a notification regarding
>>> the status of the build."
>>> So before I start developing a plugin myself, does something like
>>> that already exist or is being developed?
>>>
>>> Thanx
>>> Tilman
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

AW: [vote] Release Maven Surefire 2.3

[Marc Wilhelm]

+1  works fine for our projects;)

Cheers,
Marc

-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 23. Februar 2007 09:53
An: Maven Developers List
Betreff: [vote] Release Maven Surefire 2.3


Please vote for the release of Surefire 2.3. This now includes the  
API, providers, plugin and report plugin.

[ ] +1
[ ] 0
[ ] -1

Staged at: http://people.apache.org/~brett/release-staging-repo/

Vote is open for 72 hours.

Release notes:

** Bug
 * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName  
directories after mvn test
 * [SUREFIRE-53] - context classloader not always reset to  
original values
 * [SUREFIRE-54] - Remove use of parent classloader in  
surefirebooter but keep TestNG support working
 * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
 * [SUREFIRE-101] - Plugin not longer sets system properties when  
forking is on and debugging information is not correct
 * [SUREFIRE-105] - Documentation link on website does not point  
to surefire parameter docs
 * [SUREFIRE-106] - Classloading problem for getting a resource
 * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange  
dependencies which generate error
 * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException  
when errors occur during TestSetup decorator
 * [SUREFIRE-120] - When you  a JUnit TestSuite (with no  
test methods), no tests are run
 * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
 * [SUREFIRE-123] - SurefireBooter can initialize classloader  
with badly formed URLs
 * [SUREFIRE-125] - Surefire finds test classes but ignores test  
methods and configuration methods with TestNG and includes tag
 * [SUREFIRE-127] - Wrong issue-site URL on website
 * [SUREFIRE-263] - Source repository information on the web site  
is out of date

** Improvement
 * [SUREFIRE-31] - support junit 4.0
 * [SUREFIRE-134] - Display location of test failures/errors on  
summary
 * [SUREFIRE-135] - when fork is enabled, Surefire should use the  
same JVM running Maven (i.e. use java.home sysprop), rather than  
expecting java to be in the system PATH
 * [SUREFIRE-138] - Add option to redirect stdout from tests to a  
file

** New Feature
 * [SUREFIRE-129] - add a property to skip tests execution (but  
not tests compilation)

** Task
 * [SUREFIRE-133] - Review Plugin Documentation

Note: a 2.4 release is being worked on immediately to resolve some  
issues with TestNG. This release is being made available to users  
having the above problems before that work begins.

Cheers,
Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

WSS4J pom.xml should include runtime xalan dependency

[Frank Cornelis]

Hi,

The Maven2 pom.xml for WSS4J 1.5.1 should also contain the next
dependency:


xalan
xalan
2.7.0
runtime




Regards,
Frank.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: build loop feature 4 continuum?

[Edwin Punzalan]

You can look at starteam wagon provider.  Its trunk is here: 
http://svn.apache.org/repos/asf/maven/wagon/trunk



[EMAIL PROTECTED] wrote:
we are having to use starteam...so good to know that it works on svn...what's the component that is responsible for it so I can debug it? 


-Original Message-
From: Edwin Punzalan [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 23, 2007 6:42 AM

To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?


That's odd.  Mine doesn't build a project if there are no SCM changes.  
The projects in my Continuum instance are from an SVN repo.  Maybe its an SCM-related problem.  What's your SCM provider?  Are you sure there aren't any changes?



[EMAIL PROTECTED] wrote:
  

can I configure that a clean install is only executed if there are any scm 
changes? Right now the build is executed regardless if there are any changes 
(the message 'Changes found, building' seems to appear independent of the scm 
result). and also send a notification on every  update event (indicated by the 
'Updated x files' message).

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 2:20 PM
To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?

yes.

[EMAIL PROTECTED] a écrit :
  


ok, cool, so before doing the 'clean install' in the default build continuum 
executes a 'scm:update'?

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 20, 2007 5:23 PM
To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?

It's the base of continuum.

[EMAIL PROTECTED] a écrit :

  

Hi guys!
I need something like the build loop feature of CruiseControl:
"The Build Loop is designed to run as a daemon process which will 
periodically check your source control tool for changes to your 
codebase, build if necessary, and send out a notification regarding 
the status of the build."
So before I start developing a plugin myself, does something like 
that already exist or is being developed?


Thanx
Tilman




  


  
  



  

Re: build loop feature 4 continuum?

[Emmanuel Venisse]

maven-scm starteam provider : 
http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-providers/maven-scm-provider-starteam/

[EMAIL PROTECTED] a écrit :
we are having to use starteam...so good to know that it works on svn...what's the component that is responsible for it so I can debug it? 


-Original Message-
From: Edwin Punzalan [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 23, 2007 6:42 AM

To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?


That's odd.  Mine doesn't build a project if there are no SCM changes.  
The projects in my Continuum instance are from an SVN repo.  Maybe its an SCM-related problem.  What's your SCM provider?  Are you sure there aren't any changes?



[EMAIL PROTECTED] wrote:

can I configure that a clean install is only executed if there are any scm 
changes? Right now the build is executed regardless if there are any changes 
(the message 'Changes found, building' seems to appear independent of the scm 
result). and also send a notification on every  update event (indicated by the 
'Updated x files' message).

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 2:20 PM
To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?

yes.

[EMAIL PROTECTED] a écrit :
  

ok, cool, so before doing the 'clean install' in the default build continuum 
executes a 'scm:update'?

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 20, 2007 5:23 PM
To: continuum-dev@maven.apache.org
Subject: Re: build loop feature 4 continuum?

It's the base of continuum.

[EMAIL PROTECTED] a écrit :


Hi guys!
I need something like the build loop feature of CruiseControl:
"The Build Loop is designed to run as a daemon process which will 
periodically check your source control tool for changes to your 
codebase, build if necessary, and send out a notification regarding 
the status of the build."
So before I start developing a plugin myself, does something like 
that already exist or is being developed?


Thanx
Tilman




  





  

Re: [vote] merge Archiva MRM-239 branch to trunk

[Brett Porter]

Applying them now won't help... they'd still need to painstakingly be  
applied to the branch. Just as easy to do that after the merge (if  
they are still relevant).


I believe some things on trunk may have changed since the last merge  
- a final check of that will be needed first.


I'm still reviewing the code, myself... vote to arrive later tonight :)

- Brett

On 23/02/2007, at 7:49 PM, Arnaud HERITIER wrote:


One thing before ...
Can we have the list of patchs that aren't yet applied on the trunk ?
Don't we have to apply them before or we'll never be able to do it  
(due to

the important changes you made) ?

Arnaud

On 2/23/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


+1

Emmanuel

Joakim Erdfelt a écrit :
> I would like to merge the archiva-MRM-239 branch back to trunk.
>
> Not sure how long I should wait for the vote replies, but I'll  
do the

> usual 72.
>
> - Joakim
>
>
>

[vote] Release Maven Surefire 2.3

[Brett Porter]

Please vote for the release of Surefire 2.3. This now includes the  
API, providers, plugin and report plugin.


[ ] +1
[ ] 0
[ ] -1

Staged at: http://people.apache.org/~brett/release-staging-repo/

Vote is open for 72 hours.

Release notes:

** Bug
* [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName  
directories after mvn test
* [SUREFIRE-53] - context classloader not always reset to  
original values
* [SUREFIRE-54] - Remove use of parent classloader in  
surefirebooter but keep TestNG support working

* [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
* [SUREFIRE-101] - Plugin not longer sets system properties when  
forking is on and debugging information is not correct
* [SUREFIRE-105] - Documentation link on website does not point  
to surefire parameter docs

* [SUREFIRE-106] - Classloading problem for getting a resource
* [SUREFIRE-113] - surefire-providers-2.0.pom contains strange  
dependencies which generate error
* [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException  
when errors occur during TestSetup decorator
* [SUREFIRE-120] - When you  a JUnit TestSuite (with no  
test methods), no tests are run

* [SUREFIRE-122] - With forkmode once, XML reports are cumulative
* [SUREFIRE-123] - SurefireBooter can initialize classloader  
with badly formed URLs
* [SUREFIRE-125] - Surefire finds test classes but ignores test  
methods and configuration methods with TestNG and includes tag

* [SUREFIRE-127] - Wrong issue-site URL on website
* [SUREFIRE-263] - Source repository information on the web site  
is out of date


** Improvement
* [SUREFIRE-31] - support junit 4.0
* [SUREFIRE-134] - Display location of test failures/errors on  
summary
* [SUREFIRE-135] - when fork is enabled, Surefire should use the  
same JVM running Maven (i.e. use java.home sysprop), rather than  
expecting java to be in the system PATH
* [SUREFIRE-138] - Add option to redirect stdout from tests to a  
file


** New Feature
* [SUREFIRE-129] - add a property to skip tests execution (but  
not tests compilation)


** Task
* [SUREFIRE-133] - Review Plugin Documentation

Note: a 2.4 release is being worked on immediately to resolve some  
issues with TestNG. This release is being made available to users  
having the above problems before that work begins.


Cheers,
Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] merge Archiva MRM-239 branch to trunk

[Arnaud HERITIER]

One thing before ...
Can we have the list of patchs that aren't yet applied on the trunk ?
Don't we have to apply them before or we'll never be able to do it (due to
the important changes you made) ?

Arnaud

On 2/23/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


+1

Emmanuel

Joakim Erdfelt a écrit :
> I would like to merge the archiva-MRM-239 branch back to trunk.
>
> Not sure how long I should wait for the vote replies, but I'll do the
> usual 72.
>
> - Joakim
>
>
>

Re: [vote] merge Archiva MRM-239 branch to trunk

[Emmanuel Venisse]

+1

Emmanuel

Joakim Erdfelt a écrit :

I would like to merge the archiva-MRM-239 branch back to trunk.

Not sure how long I should wait for the vote replies, but I'll do the
usual 72.

- Joakim

Questions on remote resources plugin

[Brett Porter]

Hi,

I've worked around it for now, but I wanted to understand a couple of  
things:
- is there a way to append a custom notice? surefire-api contains  
code from springframework (not a dependency), and I couldn't get  
anything to append the right text
- what does appended-resources do? I thought it was the above, but it  
didn't seem to work for me
- alpha-2 seems to include notices for all of the dependencies. I  
don't believe this to be correct - it should only be needed if they  
are actually included in the distribution, which for a jar they are  
not. Should this be made a flag?


Thanks,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]