Re: [Vote] Move plugin site.xml up to Maven or Shared

On 08/04/2007, at 1:12 PM, Brian E. Fox wrote: I'm not familiar enough yet with the site and related tech to know how to fix this. It seems like changing the skin isn't what we want, somehow we need to tell site not to make these externalLinks. The Maven site overrides this in a custom sit

RE: [Vote] Move plugin site.xml up to Maven or Shared

I moved the site stuff up to the main maven pom. I staged the maven main site here: http://people.apache.org/~brianf/maven/ I think this is pretty good. I also staged a shared component to see how it looks by inheriting the info here: http://people.apache.org/~brianf/enforcer/ The problem is that

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

+1 Dan On Friday 06 April 2007 10:55, John Casey wrote: > Hi everyone, > > This is the third attempt, after fixing: > > * > http://jira.codehaus.org/browse/MASSEMBLY-194/browse/MASSEMBLY-155> > > This bugfix actualy adds a new flag to the dependencySet, called > useTra

Re: [Vote] Move plugin site.xml up to Maven or Shared

Makes sense. Another option is to have those links in the bottom of the left nav on every site too. I'm not against either of those solutions, as long as the links section isn't too bloated. I can certainly see the merits in consistency of the header section. - Brett On 08/04/2007, at 11

RE: [Vote] Move plugin site.xml up to Maven or Shared

I agree they may be irrelevant for most plugins. However, the more consistent the header, the more tied together everything feels. I actually am always jumping around from section to section (almost always a maven.apache.org page open in a tab already) and it's nice to have those links right there

Re: [Vote] Move plugin site.xml up to Maven or Shared

I definitely agree with the breadcrumbs on the left. I don't mind where the publish date goes as long as it's consistent (maybe bottom is more suitable/traditional). For the links, I find them to be too noisy with all the subprojects. On the main site these were put into the left nav. I thi

exception running surefire-2.4-SNAPSHOT with junit4.

Hi there guys, I am getting the following exception. Any ideas?? java.lang.IllegalArgumentException at java.lang.ProcessImpl.(ProcessImpl.java:69) at java.lang.ProcessImpl.start(ProcessImpl.java:30) at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) at java.

Re: mvn site not happy for archetype plugins

2007/4/7, Jason Dillon <[EMAIL PROTECTED]>: Does an archetype module really need to be 'maven-plugin'? I would have answered: to inherit the plugin-metadata Raphaël

Re: [embedder] Retrieving available versions of an artifact

On 6 Apr 07, at 1:48 PM 6 Apr 07, Carlos Sanchez wrote: I opened MNG-2940 The only methods I see using MavenExecutionRequest is execute and readProjectWithDependencies. I don't see how useful would be using it as parameter. It's very useful. Those two methods demonstrate execution vs non- e

Re: dependency on system library (java.library.path)

We can change the license to something else, no problem. Regards Mark On Apr 7, 2007, at 12:37 AM, Jason Dillon wrote: Ah, I remember reading about this before, though it was a while ago. Too bad this is LGPL, as that is going to prevent a lot of folks from using it :-( --jason On Apr 6

Re: dependency on system library (java.library.path)

Ah, I remember reading about this before, though it was a while ago. Too bad this is LGPL, as that is going to prevent a lot of folks from using it :-( --jason On Apr 6, 2007, at 7:21 PM, Mark Donszelmann wrote: Hi the freehep-nar-plugin does exactly what you describe. http://java.freeh