date:20051114

 [ http://jira.codehaus.org/browse/CONTINUUM-443?page=all ]
 
Emmanuel Venisse closed CONTINUUM-443:
--

 Assign To: Emmanuel Venisse
Resolution: Fixed

Done.

 Jabber and MSN not working in latest CI build
 -

  Key: CONTINUUM-443
  URL: http://jira.codehaus.org/browse/CONTINUUM-443
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
 Assignee: Emmanuel Venisse
  Fix For: 1.0.1



 I hvae configured a jabber notifier on ci.codehaus.org to send me a message 
 talk.google.com.
 I get this though:
 @4000437883e00cc3e02c java.lang.NullPointerException
 @4000437883e00cc3e414   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.getPreviousBuild(JabberContinuumNotifier.java:250)
 @4000437883e00cc3e7fc   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:177)
 @4000437883e00cc3ebe4   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendNotification(JabberContinuumNotifier.java:126)
 @4000437883e00cc4555c   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:170)
 @4000437883e00cc45944   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
 @4000437883e00cc45d2c   at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:262)
 @4000437883e00cc470b4   at 
 org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
 @4000437883e00cc497c4   at 
 org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
 @4000437883e00cc49bac   at java.lang.Thread.run(Thread.java:534)
 (see /service/continuum/log/main/current)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[continuum build - SUCCESS - update] Mon Nov 14 13:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051114.133000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.133000.txt

[jira] Reopened: (CONTINUUM-443) Jabber and MSN not working in latest CI build

 [ http://jira.codehaus.org/browse/CONTINUUM-443?page=all ]
 
Brett Porter reopened CONTINUUM-443:



still getting this with the 13:30 build. Can you please verify the fix works 
locally?

 Jabber and MSN not working in latest CI build
 -

  Key: CONTINUUM-443
  URL: http://jira.codehaus.org/browse/CONTINUUM-443
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
 Assignee: Emmanuel Venisse
  Fix For: 1.0.1



 I hvae configured a jabber notifier on ci.codehaus.org to send me a message 
 talk.google.com.
 I get this though:
 @4000437883e00cc3e02c java.lang.NullPointerException
 @4000437883e00cc3e414   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.getPreviousBuild(JabberContinuumNotifier.java:250)
 @4000437883e00cc3e7fc   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:177)
 @4000437883e00cc3ebe4   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendNotification(JabberContinuumNotifier.java:126)
 @4000437883e00cc4555c   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:170)
 @4000437883e00cc45944   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
 @4000437883e00cc45d2c   at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:262)
 @4000437883e00cc470b4   at 
 org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
 @4000437883e00cc497c4   at 
 org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
 @4000437883e00cc49bac   at java.lang.Thread.run(Thread.java:534)
 (see /service/continuum/log/main/current)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (CONTINUUM-443) Jabber and MSN not working in latest CI build

 [ http://jira.codehaus.org/browse/CONTINUUM-443?page=all ]
 
Emmanuel Venisse closed CONTINUUM-443:
--

Resolution: Fixed

Fixed

 Jabber and MSN not working in latest CI build
 -

  Key: CONTINUUM-443
  URL: http://jira.codehaus.org/browse/CONTINUUM-443
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
 Assignee: Emmanuel Venisse
  Fix For: 1.0.1



 I hvae configured a jabber notifier on ci.codehaus.org to send me a message 
 talk.google.com.
 I get this though:
 @4000437883e00cc3e02c java.lang.NullPointerException
 @4000437883e00cc3e414   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.getPreviousBuild(JabberContinuumNotifier.java:250)
 @4000437883e00cc3e7fc   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:177)
 @4000437883e00cc3ebe4   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendNotification(JabberContinuumNotifier.java:126)
 @4000437883e00cc4555c   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:170)
 @4000437883e00cc45944   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
 @4000437883e00cc45d2c   at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:262)
 @4000437883e00cc470b4   at 
 org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
 @4000437883e00cc497c4   at 
 org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
 @4000437883e00cc49bac   at java.lang.Thread.run(Thread.java:534)
 (see /service/continuum/log/main/current)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[continuum build - SUCCESS - update] Mon Nov 14 14:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051114.143000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.143000.txt

[jira] Closed: (CONTINUUM-444) link build number to last build on front page, as per original design

 [ http://jira.codehaus.org/browse/CONTINUUM-444?page=all ]
 
Emmanuel Venisse closed CONTINUUM-444:
--

 Assign To: Emmanuel Venisse
Resolution: Fixed

Done.

 link build number to last build on front page, as per original design
 -

  Key: CONTINUUM-444
  URL: http://jira.codehaus.org/browse/CONTINUUM-444
  Project: Continuum
 Type: Improvement
 Reporter: Brett Porter
 Assignee: Emmanuel Venisse
  Fix For: 1.0.1



 perhaps link icon to that instead/as well so that we can access failure 
 reports?
 It is currently really annoying to navigate to a failed build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[continuum build - SUCCESS - update] Mon Nov 14 17:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051114.173000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.173000.txt

[continuum build - FAILED - update] Tue Nov 15 02:30:00 GMT 2005

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051115.023000.txt

[continuum build - SUCCESS - update] Tue Nov 15 03:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051115.033001.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051115.033001.txt

[jira] Closed: (MNG-1526) NoClassDefFound when unit tests are being executed

2005-11-14 Thread Anuerin Diaz (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1526?page=all ]
 
Anuerin Diaz closed MNG-1526:
-

Resolution: Incomplete

I have decided to close this issue for the mean time until I have more 
information. This is in relation to the discussion in 
http://www.mail-archive.com/users@maven.apache.org/msg27931.html



 NoClassDefFound when unit tests are being executed
 --

  Key: MNG-1526
  URL: http://jira.codehaus.org/browse/MNG-1526
  Project: Maven 2
 Type: Bug
   Components: maven-surefire-plugin
 Versions: 2.0
  Environment: Windows XP Professional/ Maven 2.0
 Reporter: Anuerin Diaz



Surefire is failing on its execution and from what I can surmise from the 
 error is that maven tries to run the non-existent
 org.codehaus.surefire.Runner class. I already opened up the 1.3 and 1.4 
 surefire group of jar files and there is really no Runner class in there.
   Is there a special step or requirement to run test cases in maven? The 
 JUnit tests run fine from the Ant JUnit task. The stacktrace is shown below.
 ---
  T E S T S
 ---
 java.lang.NoClassDefFoundError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at com.meridea.cs.logging.Logger.getDelegatePlugin(Logger.java:306)
at com.meridea.cs.logging.Logger.init(Logger.java:64)
at com.meridea.cs.logging.Logger.getLogger(Logger.java:285)
at 
 test.com.meridea.cs.charfilter.AllowedCharacterFilterTest.clinit(AllowedCharacterFilterTest.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
 org.codehaus.surefire.battery.JUnitBattery.init(JUnitBattery.java:134)
at 
 org.codehaus.surefire.Surefire.instantiateBatteries(Surefire.java:318)
at org.codehaus.surefire.Surefire.run(Surefire.java:130)
at org.codehaus.surefire.Surefire.run(Surefire.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104)
at 
 org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:303)
at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301
 )
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 RUN ABORTED
 java.lang.NoClassDefFoundError
 org.codehaus.surefire.Runner
 An exception or error caused a run to abort.
 null

-- 
This

[jira] Created: (MNG-1554) Assembly plugin fails to resolve dependency when it tries to package the application

2005-11-14 Thread Anuerin Diaz (JIRA)

Assembly plugin fails to resolve dependency when it tries to package the 
application


 Key: MNG-1554
 URL: http://jira.codehaus.org/browse/MNG-1554
 Project: Maven 2
Type: Bug
  Components: maven-assembly-plugin  
Versions: 2.0
 Environment: windows XP Prof, Maven 2.0, maven-assembly-plugin 2.0
Reporter: Anuerin Diaz


When invoking goals in the assembly plugin, it tries to build the application 
modules. However it fails when trying to resolve the dependencies because the 
artifacts of the base modules are not yet installed in the local repository. It 
seems that the plugin is not able to read the reactor/storage that tthe normal 
compiler environment uses. 

Issuing the package command on the project works so the fix should be such that 
the assembly plugin utilitze the same mechanism that mvn package uses for 
building the application, or else dont attempt to build the application and 
just assume that the artifacts are already built and only needs to be packaged 
as described in the assembly descriptor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-785) m2 tomcat plugin

2005-11-14 Thread Mark Hobson (JIRA)

[ http://jira.codehaus.org/browse/MNG-785?page=comments#action_50860 ] 

Mark Hobson commented on MNG-785:
-

Thanks for this, I'll try to incorporate this into the next version.  BTW, 
probably worth raising future issues against the sandbox component in the MOJO 
project.

 m2 tomcat plugin
 

  Key: MNG-785
  URL: http://jira.codehaus.org/browse/MNG-785
  Project: Maven 2
 Type: New Feature
   Components: maven-plugins
 Versions: 2.0-beta-1
 Reporter: Mark Hobson
 Assignee: Brett Porter
  Attachments: maven-tomcat-plugin.tar.gz, maven-tomcat-plugin.zip


 See attached for an initial stab at a m2 Tomcat plugin.  The plugin provides 
 the following goals:
 tomcat:deploy
 tomcat:undeploy
 tomcat:reload
 tomcat:start
 tomcat:stop
 It's geared towards Tomcat 5.5 in which the install/remove commands are 
 depreciated in preference of deploy/undeploy.  It shouldn't be much work to 
 add these for Tomcat 5.0 users if necessary.
 I tried to keep the config to a minimum since the vast number of deployment 
 options that Tomcat provides tends to complicate plugins.  The core config 
 params for all tasks are:
 url - the Tomcat manager URL (default = http://localhost:8080/manager;)
 username - the Tomcat manager username (default = admin)
 password - the Tomcat manager password (default = )
 charset - the Tomcat manager request URL encoding charset (default = 
 ISO-8859-1)
 path - the web context path (default = /${project.build.finalName})
 The tomcat:deploy goal requires further parameters to customise the type of 
 deployment.  After considering the various deployment methods supported by 
 manager, I decided that the project-centric ones applicable to a m2 plugin 
 come down to three modes of operation:
 remote
 - the war is deployed via a HTTP PUT to manager
 - war plugin mode must be normal (i.e. not exploded)
 - suitable for cross-network
 local
 - the war is deployed by supplying a path to the war file/dir
 - the war plugin mode config param determines whether the war is deployed as 
 a file or as a dir
 - suitable for localhost tomcat
 inplace
 - the war is deployed via a context.xml file that refers to the war dir
 - the war plugin mode must be exploded
 - suitable for dev
 The other Tomcat deployment methods didn't seem too useful for 
 project-orientation deployment - they are summarised here:
 http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
 So the tomcat:deploy specific config params are:
 mode - remote, local or inplace (default = remote)
 war - the war file path (default = 
 ${project.build.directory}/${project.build.finalName}.war)
 warDir - the war dir path (default = 
 ${project.build.directory}/${project.build.finalName})
 config - the context.xml path (default = 
 ${project.build.directory}/${project.build.finalName}/META-INF/context.xml)
 update - whether to undeploy before deploying (default = false)
 When deploying inplace the context.xml Context/@docBase attribute needs to be 
 set to the war dir.  I noticed the discussion on the m2 mailing list 
 regarding resource filtering, so hopefully that can perform this task pre-war.
 The code is inspired by the Tomcat Ant tasks, but rewritten for m2.  This is 
 my first m2 plugin so any constructive comments are welcome!  In particular, 
 feedback on the following would be appreciated:
 - opinions on the remote/local/inplace mode of operations
 - any config options I've missed
 - is the method of introspecting the war plugin config the norm, or is there 
 a nicer way?
 You're welcome to the code  I'm happy to adopt this plugin time-permitting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: ClearCase implementation

2005-11-14 Thread Emmanuel Venisse

Wim Deblauwe a écrit :

Hi,

3 questions:

1) what maven commando's can I try to test my implementation?

You can try mojos in maven-scm-plugin.

2) About the checkout command: In ClearCase, you are looking at
read-only files and you check out 1 file to edit that file. After that
you check your file in. This is not the same for SVN for instance, where
checkout means, get me all the files of a certain project. Am I correct?
How should I then implement checkout. What is it used for in
Maven/Continuum?

yes, a checkout command get all files. We need this feature for Maven and continuum for
obtaining all files and build a project.
For Clearcase implementation, you can get all files in read-only mode (if it's a clearcase
standard) and eventually add an optional parameter in checkout command for editing a file
(Is it an equivalent to a lock command?).

3) What are the *Consumer classes for in the ClearCase implementation?
Looking at the SVN implementation, they don't have that there. Also the
current ones are copy/paste. We can probably use the same class
everywhere instead?

In svn, we have consumer classes.
Consumer classes parse command output and put the result in object model. So we can parse
the command result via api.
We can't use the same class for all provider because each provider have a different output
(data, format...)

Emmanuel

regards,

Wim

2005/11/12, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:

tag nale is a string defined by user. Each user can user its own
naming convention.

Emmanuel

Wim Deblauwe a écrit :
One other question on tags ( labels ). How is the tag name formed? We
have a naming convention at work here on how labels should be named.

regards,

Wim

2005/11/12, Wim Deblauwe [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:

ok.
What is the difference on cleartool usage for all clearcase
connection type?

Don't have a clue, I only know what we use, I'm not really a
ClearCase guru :)

regards,

Wim

Re: ClearCase implementation

2005-11-14 Thread Wim Deblauwe

Hi,

3 questions:

1) what maven commando's can I try to test my implementation?

2) About the checkout command: In ClearCase, you are looking at
read-only files and you check out 1 file to edit that file. After
that you check your file in. This is not the same for SVN for instance,
where checkout means, get me all the files of a certain project. Am I
correct? How should I then implement checkout. What is it used for in
Maven/Continuum?

3) What are the *Consumer classes for in the ClearCase implementation?
Looking at the SVN implementation, they don't have that there. Also the
current ones are copy/paste. We can probably use the same class
everywhere instead?

regards,

Wim2005/11/12, Emmanuel Venisse [EMAIL PROTECTED]:
tag nale is a string defined by user. Each user can user its own naming convention.EmmanuelWim Deblauwe a écrit : One other question on tags ( labels ). How is the tag name formed? We have a naming convention at work here on how labels should be named.
 regards, Wim 2005/11/12, Wim Deblauwe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
: ok. What is the difference on cleartool usage for all clearcase connection type? Don't have a clue, I only know what we use, I'm not really a
 ClearCase guru :) regards, Wim

Re: making behaviour of ide plugins consistent

2005-11-14 Thread Mark Hobson

The eclipse plugin *does* create different project files depending on
where it's run. It uses project references if the other projects are
within the reactor build. It's also very particular regarding
versions, as this thread details:

http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272

I agree we need to be consistent across IDEs and would like things to
be simplified and configurable.

Cheers,

Mark

On 14/11/05, Kaare Nilsen [EMAIL PROTECTED] wrote:
Well, no..
I think that what you are describing is somewhat to magical for me ;)
You say that the idea plugin creates different projects depending on
where you run the command, i personally finds that very confusing. In
my opinion a plugin after configured in the module pom (or a parent)
should behave consistently, and create equivalent projects on every
run, not depending on where the command is executed.

The eclipse plugin creates project references if they share the same
parent pom (i have seen there are ppl out there struggeling with that,
but in my experience it works) no matter if you run the plugin from
the root or in a subdirectory.
Personally i find this to be a more consise solution.

hehe, i litteraly can se my self trying to explain it to a coworker.
Oh.. yeah.. by the way. please do remember to check where your run
your project generation. The result may vary, and then i can imagine
the look of confusion i would get back ;)

So If an IDE project is generated for a module in a multimodule
project, it should always by default use project references.

But then again. perhaps the notion of project generation strategy
would be a cool common setting.
like this (using one of the values inside[] )
...
configuration
projectReferenceStrategy
[direct,directIfSameVersion,repsitory,snapshot-repository]
/projectReferenceStrategy
...

On 14/11/05, Brett Porter [EMAIL PROTECTED] wrote:
Yes, I definitely agree with that. This discussion should be about the
default, but be configurable.

So, you say the eclipse plugin does well - is it the same or different
to the idea plugin as I described it?

- Brett

Kaare Nilsen wrote:
Then supply good default behaviour (where i really do think the
current eclipseplugin does a good job). And finally let the users
choose how they want to use it.

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

[jira] Created: (MAVENUPLOAD-588) please upload A2J beta2

2005-11-14 Thread nicolas de loof (JIRA)

please upload A2J beta2
---

 Key: MAVENUPLOAD-588
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-588
 Project: maven-upload-requests
Type: Task
Reporter: nicolas de loof


A2J is a tool for converting ASN specifications into a collection of java 
classes capable of encoding and decoding the data units defined by those 
specifications. A2J also includes a set of runtime classes that support 
serialising ASN types to and from BER streams. A2J is licensed under the LGPL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (SCM-72) Remove tagbase usage and use insted mecanism use in update command

 [ http://jira.codehaus.org/browse/SCM-72?page=all ]
 
Emmanuel Venisse closed SCM-72:
---

  Assign To: Emmanuel Venisse
 Resolution: Fixed
Fix Version: 1.0-beta-1

Applied, thanks.

For your two point on status mojo and diff command, you can file an issue for 
each

 Remove tagbase usage and use insted mecanism use in update command
 --

  Key: SCM-72
  URL: http://jira.codehaus.org/browse/SCM-72
  Project: Maven SCM
 Type: Task
   Components: maven-scm-provider-svn
 Versions: 1.0-beta-1
 Reporter: Emmanuel Venisse
 Assignee: Emmanuel Venisse
  Fix For: 1.0-beta-1
  Attachments: SCM-72-maven-scm-test.patch, SCM-72-maven.scm-provider-svn.patch


 David Hawkins, do you want work on it?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (CONTINUUM-443) Jabber not working in latest CI build

Jabber not working in latest CI build
-

 Key: CONTINUUM-443
 URL: http://jira.codehaus.org/browse/CONTINUUM-443
 Project: Continuum
Type: Bug
Reporter: Brett Porter
 Fix For: 1.0.1


I hvae configured a jabber notifier on ci.codehaus.org to send me a message 
talk.google.com.

I get this though:
@4000437883e00cc3e02c java.lang.NullPointerException
@4000437883e00cc3e414   at 
org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.getPreviousBuild(JabberContinuumNotifier.java:250)
@4000437883e00cc3e7fc   at 
org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:177)
@4000437883e00cc3ebe4   at 
org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendNotification(JabberContinuumNotifier.java:126)
@4000437883e00cc4555c   at 
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:170)
@4000437883e00cc45944   at 
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
@4000437883e00cc45d2c   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:262)
@4000437883e00cc470b4   at 
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
@4000437883e00cc497c4   at 
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
@4000437883e00cc49bac   at java.lang.Thread.run(Thread.java:534)

(see /service/continuum/log/main/current)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (MNG-1556) Update to work with automatic tagBase resolution of maven-scm-provider-svn

2005-11-14 Thread David Hawkins (JIRA)

Update to work with automatic tagBase resolution of maven-scm-provider-svn
--

 Key: MNG-1556
 URL: http://jira.codehaus.org/browse/MNG-1556
 Project: Maven 2
Type: Bug
  Components: maven-release-plugin  
Versions: 2.0.1
Reporter: David Hawkins


I'll take this one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (CONTINUUM-444) link build number to last build on front page, as per original design

link build number to last build on front page, as per original design
-

 Key: CONTINUUM-444
 URL: http://jira.codehaus.org/browse/CONTINUUM-444
 Project: Continuum
Type: Improvement
Reporter: Brett Porter
 Fix For: 1.0.1


perhaps link icon to that instead/as well so that we can access failure reports?

It is currently really annoying to navigate to a failed build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: making behaviour of ide plugins consistent

2005-11-14 Thread Kaare Nilsen

My mistake
You are right Mark. So it seems like the eclipse plugin does it alot
like what Brett are describing.. But again.. this is to automagically
for me ;)

On 14/11/05, Mark Hobson [EMAIL PROTECTED] wrote:
The eclipse plugin *does* create different project files depending on
where it's run. It uses project references if the other projects are
within the reactor build. It's also very particular regarding
versions, as this thread details:

http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272

I agree we need to be consistent across IDEs and would like things to
be simplified and configurable.

Cheers,

Mark

So If an IDE project is generated for a module in a multimodule
project, it should always by default use project references.

On 14/11/05, Brett Porter [EMAIL PROTECTED] wrote:
Yes, I definitely agree with that. This discussion should be about the
default, but be configurable.

So, you say the eclipse plugin does well - is it the same or different
to the idea plugin as I described it?

- Brett

Kaare Nilsen wrote:
Then supply good default behaviour (where i really do think the
current eclipseplugin does a good job). And finally let the users
choose how they want to use it.

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

[jira] Updated: (CONTINUUM-443) Jabber and MSN not working in latest CI build

 [ http://jira.codehaus.org/browse/CONTINUUM-443?page=all ]

Brett Porter updated CONTINUUM-443:
---

Summary: Jabber and MSN not working in latest CI build  (was: Jabber not 
working in latest CI build)

likewise, MSN:

@4000437889311f57a4bc java.lang.NullPointerException
@4000437889311f57a8a4   at 
org.apache.maven.continuum.notification.msn.MsnContinuumNotifier.getPreviousBuild(MsnContinuumNotifier.java:217)
@4000437889311f57ac8c   at 
org.apache.maven.continuum.notification.msn.MsnContinuumNotifier.sendMessage(MsnContinuumNotifier.java:161)
@4000437889311f57b074   at 
org.apache.maven.continuum.notification.msn.MsnContinuumNotifier.sendNotification(MsnContinuumNotifier.java:110)
@4000437889311f57cbcc   at 
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:170)
@4000437889311f57cfb4   at 
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
@4000437889311f57d39c   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:262)
@4000437889311f57e724   at 
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
@4000437889311f57eb0c   at 
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
@4000437889311f580664   at java.lang.Thread.run(Thread.java:534)


 Jabber and MSN not working in latest CI build
 -

  Key: CONTINUUM-443
  URL: http://jira.codehaus.org/browse/CONTINUUM-443
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
  Fix For: 1.0.1



 I hvae configured a jabber notifier on ci.codehaus.org to send me a message 
 talk.google.com.
 I get this though:
 @4000437883e00cc3e02c java.lang.NullPointerException
 @4000437883e00cc3e414   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.getPreviousBuild(JabberContinuumNotifier.java:250)
 @4000437883e00cc3e7fc   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:177)
 @4000437883e00cc3ebe4   at 
 org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendNotification(JabberContinuumNotifier.java:126)
 @4000437883e00cc4555c   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:170)
 @4000437883e00cc45944   at 
 org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
 @4000437883e00cc45d2c   at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:262)
 @4000437883e00cc470b4   at 
 org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
 @4000437883e00cc497c4   at 
 org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
 @4000437883e00cc49bac   at java.lang.Thread.run(Thread.java:534)
 (see /service/continuum/log/main/current)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (MNG-1557) Dependency Ignored

2005-11-14 Thread Stephen Duncan Jr (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1557?page=all ]

Stephen Duncan Jr updated MNG-1557:
---

Attachment: effective-pom.txt

Added output of projecthelp:effective-pom

 Dependency Ignored
 --

  Key: MNG-1557
  URL: http://jira.codehaus.org/browse/MNG-1557
  Project: Maven 2
 Type: Bug
 Versions: 2.0
  Environment: Fedora Core 4
 Reporter: Stephen Duncan Jr
  Attachments: debug-output.txt, effective-pom.txt


 A typical dependency (with version, scope, and exclusions set by parent POM 
 via dependency management) shows up in the effective pom and the exported 
 pom.  However, it does not show up in the dependency tree in the debug output 
 of an attempt to package the project, it doesn't show up in the resulting war 
 (which it should by it's scope of runtime), and if it's deleted from the 
 local repository, Maven does not attemtp to download it.  Other project with 
 this dependency specified the same way, with the same parent, download the 
 dependency, and work as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MNG-1557) Dependency Ignored

2005-11-14 Thread Stephen Duncan Jr (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1557?page=all ]

Stephen Duncan Jr updated MNG-1557:
---

Attachment: debug-output.txt

Added result of running m2 -X clean package (debug-output.txt)

 Dependency Ignored
 --

  Key: MNG-1557
  URL: http://jira.codehaus.org/browse/MNG-1557
  Project: Maven 2
 Type: Bug
 Versions: 2.0
  Environment: Fedora Core 4
 Reporter: Stephen Duncan Jr
  Attachments: debug-output.txt, effective-pom.txt


 A typical dependency (with version, scope, and exclusions set by parent POM 
 via dependency management) shows up in the effective pom and the exported 
 pom.  However, it does not show up in the dependency tree in the debug output 
 of an attempt to package the project, it doesn't show up in the resulting war 
 (which it should by it's scope of runtime), and if it's deleted from the 
 local repository, Maven does not attemtp to download it.  Other project with 
 this dependency specified the same way, with the same parent, download the 
 dependency, and work as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1557) Dependency Ignored

2005-11-14 Thread Stephen Duncan Jr (JIRA)

Dependency Ignored
--

 Key: MNG-1557
 URL: http://jira.codehaus.org/browse/MNG-1557
 Project: Maven 2
Type: Bug
Versions: 2.0
 Environment: Fedora Core 4
Reporter: Stephen Duncan Jr
 Attachments: debug-output.txt, effective-pom.txt

A typical dependency (with version, scope, and exclusions set by parent POM via 
dependency management) shows up in the effective pom and the exported pom.  
However, it does not show up in the dependency tree in the debug output of an 
attempt to package the project, it doesn't show up in the resulting war (which 
it should by it's scope of runtime), and if it's deleted from the local 
repository, Maven does not attemtp to download it.  Other project with this 
dependency specified the same way, with the same parent, download the 
dependency, and work as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[Maven Wiki] Update of AssemblyPlugin by AlexanderHars

2005-11-14 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Maven Wiki for change 
notification.

The following page has been changed by AlexanderHars:
http://wiki.apache.org/maven/AssemblyPlugin

New page:
= AssemblyPlugin =

[http://maven.apache.org/guides/mini/guide-assemblies.html Guide to creating 
assemblies] 

[http://maven.apache.org/plugins/maven-assembly-plugin/howto.html How to use 
assembly plugin] - good

[http://maven.apache.org/plugins/maven-assembly-plugin/descriptor.html 
Predefined Descriptors] - very useful

[http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html Descriptor 
format] - most descriptors have no description


== Goals ==

 * assembly:assembly (default goal) Creates a distribution artifact
 * assembly:directory copies files into a directory structure without packing 
those file
 * assembly:unpack  unpacks packed files

== Descriptors ==

An assembly file consists of three sections


=== General assembly properties ===

|| id  || the id.  ||
|| formats || list of package formats that should be generated, each in 
format descriptor ||
|| format  || jar, tar.gz, tar.bz2, zip ''if you know of others, please add 
them here'' ||
|| includeBaseDirectory  || defaults to false. Determines if the base 
directory should be included in the package. ||


=== filesets ===

|| outputDirectory || Directory in the target tree where the files should be 
copied to. ||
|| directory || copies the contents of this directory to the specified target 
directory. Copies files by name, does not copy path. ''if anyone could clarify 
what other types of patterns can be specified that would be great!''||
|| includes   || copies the specified files that match the pattern (e.g. 
*.txt) to the target directory. Includes the directory path when copying. ||
|| excludes   || Excludes the specified files that match the pattern (e.g. 
*.txt) from being copied to the target directory. ||
|| lineEnding  ||  ||
|| directoryMode  ||  ||
|| fileMode  ||  ||

=== dependencySets ===

|| outputDirectory || Directory in the target tree where the dependencies 
should be copied to. ||
|| includes   || Includes the specified dependency ||
|| excludes   || Excludes the specified dependency ||
|| unpack  || Unpacks the contents of the dependencies ||
|| scope  ||  ||
|| outputFileNameMapping  ||  ||
|| directoryMode  ||  ||
|| fileMode  ||  ||


== How To ==

  * How to copy files into some target directory structure without packaging. 

  This can be accomplished with the assembly:directory goal. There is only a 
small downside: The directory  
  goal always creates a folder below the target directory that is 
version-specific. This version-specific directory
  is even created when includeBaseDirectory is set to false (that may be a 
bug). 

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

[Maven Wiki] Trivial Update of AssemblyPlugin by AlexanderHars

2005-11-14 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Maven Wiki for change 
notification.

The following page has been changed by AlexanderHars:
http://wiki.apache.org/maven/AssemblyPlugin

--
- = AssemblyPlugin =
  
  [http://maven.apache.org/guides/mini/guide-assemblies.html Guide to creating 
assemblies] 
  

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

RE: ClearCase implementation

2005-11-14 Thread Jeff Jensen

Hi guys,

I've recently started monitoring this list as I am very interested in the
Perforce Maven SCM implementation (I recently obtained the source and
started looking at how far along it is).

I'm butting in here as I have some thoughts that may have use to your
implementations.  I have used a number of SCMs, such as Perforce, ClearCase,
CVS, SVN, PVCS, StarTeam, and others you've never heard of ;-).  Some I know
really well (even setup and admin experience), and some just a casual user.

I have a couple of comments I will inline.
 

 -Original Message-
 From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
 Sent: Monday, November 14, 2005 4:26 AM
 To: scm-dev@maven.apache.org
 Subject: Re: ClearCase implementation
 
 
 
 Wim Deblauwe a écrit :

[snip]

  2) About the checkout command: In ClearCase, you are looking at 
  read-only files and you check out 1 file to edit that file. After 
  that you check your file in. This is not the same for SVN for 
  instance, where checkout means, get me all the files of a 
 certain project. Am I correct?
  How should I then implement checkout. What is it used for in 
  Maven/Continuum?
 
 yes, a checkout command get all files. We need this feature 
 for Maven and continuum for obtaining all files and build a project.
 For Clearcase implementation, you can get all files in 
 read-only mode (if it's a clearcase
 standard) and eventually add an optional parameter in 
 checkout command for editing a file

CVS and SVN are a couple of the few SCMs that use checkout in this manner.
Most of the other SCMs use some type of get latest command for that, and
use checkout to tell the server the user will now edit a file.

The concept is much clearer to the non-CVS/SVN populace with get latest,
checkout, checkin.  It will be very weird for those users to do the Maven
scm checkout command to get latest for SCMs like Perforce, ClearCase, VSS,
etc. many others.

For example, CVS uses checkout/update commands to get latest, and edit for
tracking with watchers.

Polymorphism and overloading is usually what I prefer, but here I am not
sure - the very different use of commands like checkout gives concern, and
I suggest using the traditional sense of these (e.g. ClearCase, Perforce
manner) for all SCMs or using separate commands/having them mean different
things per SCM type).


 (Is it an equivalent to a lock command?).

Checkout is not equivalent to a lock command.  It may also do a lock,
depending on the checkout mode (if the SCM has a checkout mode): pessimistic
lock or optimistic lock (reserved or unreserved checkouts in ClearCase
terms).  Some SCMs give the user the choice on checkout (e.g. Perforce,
ClearCase), others only have a system setting that determines it for
everyone every time (e.g. VSS).

[snip]

[maven2 build - SUCCESS - update] Mon Nov 14 13:45:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~maven/builds/m2-20051114.134500.tar.gz

Log:
http://maven.zones.apache.org/~maven/logs/m2-build-log-20051114.134500.txt

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

[jira] Reopened: (MNG-1324) System dependencies path non correctly added to eclipse buildpath

2005-11-14 Thread Giorgio Gallo (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1324?page=all ]
 
Giorgio Gallo reopened MNG-1324:



Sorry to bother Fabrizio..

I updated my m2 to the last svn snapshot this morning, but the eclipse plugin 
still can't handle system dependencies...


 System dependencies path non correctly added to eclipse buildpath
 ---

  Key: MNG-1324
  URL: http://jira.codehaus.org/browse/MNG-1324
  Project: Maven 2
 Type: Bug
   Components: maven-eclipse-plugin
  Environment: SVN snapshot a few days old
 Reporter: Giorgio Gallo
 Assignee: fabrizio giustina



 Eclipse plugin handles systemPath as if it was a path into the repository, 
 transforming a dependency like this one:
 dependency
...
   scopesystem/scope
   systemPath${basebir}/lib/myjdbcdriver.jar/systemPath
 /dependency
 into 
 M2_REPO/pom.xml location dir/lib/myjdbcdriver.jar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MAVEN-1723) xdoc goal crashes

2005-11-14 Thread Guy Rixon (JIRA)

xdoc goal crashes
-

 Key: MAVEN-1723
 URL: http://jira.codehaus.org/browse/MAVEN-1723
 Project: Maven
Type: Bug
 Environment: Windows XP,  SUN JDK 1.4.2 build 08
Reporter: Guy Rixon
 Fix For: 1.1-beta-2


The xdoc goal crashes like this:

BUILD FAILED
File.. C:\Documents and Settings\gtr\.maven\cache\maven-xdoc-plugin-1.9.2\pl
ugin.jelly
Element... j:include
Line.. 479
Column -1
file:/C:/Documents and Settings/gtr/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-
resources/site.jsl:33:-1: jsl:stylesheet file:/C:/Documents and Settings/gtr/.
maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:-1: jsl:apply
Templates file:/C:/Documents and Settings/gtr/.maven/cache/maven-xdoc-plugin-1.
9.2/plugin-resources/site.jsl:240:-1: maven:property You must define an attrib
ute called 'defaultValue' for this tag.

On investigating the named file in the plug-in, I find this at line 240:

maven:property var=version name=maven.xdoc.version 
defaultValue=${pom.currentVersion}/

The same error occurs whether or not the POM has a currentVersion.

A similar, but less-well described error happens in Maven 1.0.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1050) [2.0,) should not select 3.0 and above by default

2005-11-14 Thread Joerg Schaible (JIRA)

[ http://jira.codehaus.org/browse/MNG-1050?page=comments#action_50879 ] 

Joerg Schaible commented on MNG-1050:
-

IMHO [2.0,) is perfect for any new version. It depends on the version naming 
policy of the depending artifact's project, if a new release is compatible. 
E.g. a lot of Jakarta common jars are not even compatible for minor version 
upgrades, while e.g. CGLIB 2.x is backward compatible to 1.x. Additionally it 
depends on the current artifact's usega of the dependency. If only API is used 
that is part of the official API (e.g. avalon-framework-api) or also classes 
that are supposed to be internal (avalon-framework-impl). So the author of an 
artifact may define the compatible version range for a dependency depending on 
the usage e.g. [2.0,3.0) if he really cares. A compatible-since would help 
tremendously though ;-)

Also it should be possible to make a hint, if the (major?) versions of a 
library can coexist, e.g. webwork 1.x and webwork 2.x. This is interesting for 
library authors, that want to support both versions in their project (as e.g. 
nanocontainer-nanowar does for webwork). ASM 1.x and 2.x is an example, where 
this is not possible.

 [2.0,) should not select 3.0 and above by default
 -

  Key: MNG-1050
  URL: http://jira.codehaus.org/browse/MNG-1050
  Project: Maven 2
 Type: Bug
   Components: maven-artifact
 Reporter: Brett Porter
  Fix For: 2.1



 I think that we need to assume major versions are incompatible as it is 
 easier to later state compatibility than fix it when broken.
 This might just be a default compatibility scheme, but a project can define 
 its own (eg, compatible-since 2.1).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1324) System dependencies path non correctly added to eclipse buildpath

2005-11-14 Thread fabrizio giustina (JIRA)

[ http://jira.codehaus.org/browse/MNG-1324?page=comments#action_50880 ] 

fabrizio giustina commented on MNG-1324:


 I updated my m2 to the last svn snapshot this morning, but the eclipse plugin 
 still can't handle system dependencies... 
sounds strange, one of the tests run before the plugin is installed just tests 
for system dependencies. Did you upgrade m2 or the eclipse plugin? You need to 
install the eclipse plugin from the version in svn to get this fixed (the bug 
in maven core is still open, a workaround has been added directly to the plugin)


 System dependencies path non correctly added to eclipse buildpath
 ---

  Key: MNG-1324
  URL: http://jira.codehaus.org/browse/MNG-1324
  Project: Maven 2
 Type: Bug
   Components: maven-eclipse-plugin
  Environment: SVN snapshot a few days old
 Reporter: Giorgio Gallo
 Assignee: fabrizio giustina



 Eclipse plugin handles systemPath as if it was a path into the repository, 
 transforming a dependency like this one:
 dependency
...
   scopesystem/scope
   systemPath${basebir}/lib/myjdbcdriver.jar/systemPath
 /dependency
 into 
 M2_REPO/pom.xml location dir/lib/myjdbcdriver.jar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: making behaviour of ide plugins consistent

2005-11-14 Thread Kaare Nilsen

Ok.. after some thought I need to reevaluate my opinion on this.
I have now played a little with the eclipse plugin, and well.. i must
admit that i like the way it behaves. So using project references for
projects in the same reactor build where the version of the project in
the reactor, and the version of the dependency seems like a good
default behaviour to me.

On 14/11/05, Kaare Nilsen [EMAIL PROTECTED] wrote:
My mistake
You are right Mark. So it seems like the eclipse plugin does it alot
like what Brett are describing.. But again.. this is to automagically
for me ;)

http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272

I agree we need to be consistent across IDEs and would like things to
be simplified and configurable.

Cheers,

Mark

So If an IDE project is generated for a module in a multimodule
project, it should always by default use project references.

On 14/11/05, Brett Porter [EMAIL PROTECTED] wrote:
Yes, I definitely agree with that. This discussion should be about the
default, but be configurable.

So, you say the eclipse plugin does well - is it the same or different
to the idea plugin as I described it?

- Brett

Kaare Nilsen wrote:
Then supply good default behaviour (where i really do think the
current eclipseplugin does a good job). And finally let the users
choose how they want to use it.

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

[jira] Commented: (MNG-1178) weird junit classloader issue

2005-11-14 Thread Christian Mouttet (JIRA)

[ http://jira.codehaus.org/browse/MNG-1178?page=comments#action_50889 ] 

Christian Mouttet commented on MNG-1178:


Brett,

to reproduce the bug you can write a simple TestCase like this (initializing 
Log4J):

public class SimpleTest extends TestCase {
static {
URL url = AbstractTestCase.class.getResource(/test-log4j.xml);
DOMConfigurator.configure(url);
}

// any tests you like to do ...

}


I have maven-2.0 with surefire-1.4 and junit-3.8.1.

 weird junit classloader issue
 -

  Key: MNG-1178
  URL: http://jira.codehaus.org/browse/MNG-1178
  Project: Maven 2
 Type: Bug
  Environment: java 1.5, linux
 Reporter: Matthew Pocock
 Assignee: Brett Porter
  Attachments: mng-1178-1.tar.gz


 In some cases (that I've not narrowed down), I get this exception when doing 
 m2 install. The affected projects have no test cases and no dependencies taht 
 use JUnit in any way. i can get rid of this exceptino if Junit is added as a 
 test scope dependency. It smells like a class loader issue where something 
 funkey is going on to make the no-args constructor of UnitTest unavailable 
 for chaining from BatteryAssert. Beats me.
 org.apache.maven.plugin.MojoExecutionException: Error executing surefire
 at 
 org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:294)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:419)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:599)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:326)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:152)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:237)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:251)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104)
 at 
 org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:289)
 ... 16 more
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at 
 org.codehaus.surefire.Surefire.instantiateBatteries(Surefire.java:274)
 at org.codehaus.surefire.Surefire.run(Surefire.java:82)
 at org.codehaus.surefire.Surefire.run(Surefire.java:76)
 ... 22 more
 Caused by: java.lang.IllegalAccessError: tried to access method 
 junit.framework.TestCase.init()V from class 
 org.codehaus.surefire.battery.assertion.BatteryAssert
 at 
 org.codehaus.surefire.battery.assertion.BatteryAssert.init(BatteryAssert.java:23)
 at 
 org.codehaus.surefire.battery.AbstractBattery.init(AbstractBattery.java:31)
 at 
 org.codehaus.surefire.battery.DirectoryBattery.init(DirectoryBattery.java:39)
 ... 29 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - SUCCESS - update] Mon Nov 14 16:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051114.163000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.163000.txt

The assembly plugin (and its uses in other installer/distribution builders)

2005-11-14 Thread John Allen


Request for comments:

How should I go about designing a NullSoft Installer plugin so that it works 
well with the assembly paradigm?


The assembly plugin seems to have been designed to operate in a stand-alone 
fashion, firing off the project's package build, rather than cooperate 
within the existing lifecycle (@execute package declaration)


This design choice confuses me a little as i would have thought that an 
'assembled' project should just be considered another type of 'packaging' 
and should therefore be invoked by the normal project build plugin setup, 
ie.:-


plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
executionsexecutionphasepackage/phase/execution/executions
configuration.../configuration
/plugin

As is detailed in MNG-1311 the above will result in an endless loop as the 
assembly Mojo's are not designed to be launched from another lifecycle 
phase.


I guess the thinking was that assembly was something that you'd do rarely 
and would only be invoked via '#mvn assembly:assembly' explicit invocation 
and the resulting 'assembly-packaged' distribution artifact 
(.zip/gzip/bzip), would not be consumed by, or of use to, any other build 
lifecycle component.


I think that this assumption is a bit restrictive considering the fact that 
the assembly plugin performs the very useful job of preparing a distribution 
area and is exactly the kind of thing a thirdparty installer will need done 
before it will generate its custom distribution archive (say an installer 
exe).


Which leads me to the design questions regarding NSIS plugin.

Why should the assembly zip or tar be any different to the NSIS-exe archive? 
Semantically they are the same, a package that is interpreted by an external 
tool (winzip/OS)


I see the steps for building a distribution to be:

build required distribution artifacts
prepare a distribution area (layout the directory structure, copy in deps 
etc)
compile the distriubution into the target distribution media (zip, bzip, 
NSIS-exe)


If we are to keep the existing assmbly:assembly package forking 
functionality should the NSIS just be a complex archiver thats configured as 
part of the assemby plugin?


Or should assembly be made so its a lifecycle cooperating Mojo and one 
builds a distribution assemby by simply running the package phase (mvn 
package)?


Or should a NSIS generated exe be a project packaging type in its own right, 
and a separate project be used to assemble and generate the resulting exe 
(in which case the assembly:directory functionality would still be required 
to layout the NSIS 'source' directory to be compiled into the exe but that 
can be easily done via new assembly facade mojo (MNG-1462 has done this)).


So...

Whats the thinking behind the assembly plugin and its @execution package 
design?

And how shall we integrate it with other distribution packagers?



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

Re: making behaviour of ide plugins consistent


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is going to sound completely ugly, but what I've found to work best
when I have multiple interrelated (ie. same application) projects is to
create one massive eclipse project with all the subprojects' source
roots mapped as src dirs, all the resource roots mapped as class dirs,
and all the dependencies added for all subprojects. Yes, when your
subprojects depend on different versions of a single dependency, you may
have problems. However, this should never be the case when a set of
projects will always be used together - those version conflicts will
have to be resolved at some point.

The reason I prefer this approach is to preserve the call hierarchy
within the application as a whole. If I have projects A and B, such that
B - A, then I can navigate to the implementation of a particular method
from it's usage. This is true regardless of which approach is taken,
provided either project references are intact, or source attachments are
used. HOWEVER, if I have the method implementation in front of me, and
need to open the call hierarchy to see where that method is called, I'm
limited to the current project and its dependencies. If the dependency
projects call this code, it's a Bad Thing, but that's tangential to the
topic at hand. The point is I can't see where the client projects (the
projects dependent on the one with the method implementation) call that
particular method. It may seem trivial, but I use this feature of
eclipse dozens of times a day when I'm code-reading (to learn a new API,
for example).

I know that most people won't like this approach, because it generates
an 800# gorilla of a project, and can make it hard to navigate all the
myriad source dirs. Still, it does have its uses, and I find this
feature indispensible. It'd be a shame to have to let it go just so I
can use Maven to generate my Eclipse project files...

What about having multiple mojos, each implementing a different project
file-generation strategy?? So, normal usage might be:


mvn eclipse:eclipse -Declipse.workspace=/path/to/workspace


My particular usage might be handled by:


mvn eclipse:monolithic


Beyond this, I think there's a lot of value in having a series of
projects depend on the artifacts of their dependency projects. It tends
to enforce cleaner separation of APIs, and keeps your IDE more lined up
with your build environment...it also keeps the versions of your
dependencies up to date.

Just my 2c.

- -john

Brett Porter wrote:
| Hi,
|
| Can we discuss how to make the ide plugins behave consistently? It
| appears that, in particular, there are a lot of discussions about
| Eclipse and direct project references, and as I'm not a user I don't
| really follow them - but I'm concerned that they might be arriving at a
| different solution to what is already in place for the idea plugin.
|
| So, could folks provide feedback on this strategy, and if there are any
| other places that might differ (eg source/javadoc binding), please
| comment on that.
|
| For project references: the idea plugin uses a reference if and only if
| the project exists in the reactor - ie, you run it from the root and it
| creates all the files and the single project file. If run from a
| subdirectory later, it will not create a link, but use the JAR from the
| repository.
|
| I think I'd want to enhance that to use a reference if it is found in
| the USD/workspace - but that's not there just yet as there isn't an API
| for the USD, it's only used in finding parent POMs.
|
| Thoughts?
|
| - Brett
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDeMSPK3h2CZwO/4URAspDAJ9DxfrO4E5PR87wqKTtkbA7pL3h9ACfT+XG
L0CThEcpSvUhiuW7ojyhvlI=
=UoKu
-END PGP SIGNATURE-

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

[jira] Closed: (CONTINUUM-442) plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes

 [ http://jira.codehaus.org/browse/CONTINUUM-442?page=all ]
 
Emmanuel Venisse closed CONTINUUM-442:
--

Resolution: Fixed

fixed in plexus-runtime-builder

 plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes
 

  Key: CONTINUUM-442
  URL: http://jira.codehaus.org/browse/CONTINUUM-442
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
  Fix For: 1.0.1



 (if you can get it into 1.0.1)
 Make the following changes:
 PLEXUS_OPTS=$PLEXUS_OPTS -Xmx128m
 (to pass on plexus opts)
 ...
 exec $JAVACMD \
 (to delegate process)
 This is required to get it running as a service from the plexus script.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Reopened: (CONTINUUM-442) plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes

 [ http://jira.codehaus.org/browse/CONTINUUM-442?page=all ]
 
Emmanuel Venisse reopened CONTINUUM-442:


 Assign To: Emmanuel Venisse

 plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes
 

  Key: CONTINUUM-442
  URL: http://jira.codehaus.org/browse/CONTINUUM-442
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
 Assignee: Emmanuel Venisse
  Fix For: 1.0.1



 (if you can get it into 1.0.1)
 Make the following changes:
 PLEXUS_OPTS=$PLEXUS_OPTS -Xmx128m
 (to pass on plexus opts)
 ...
 exec $JAVACMD \
 (to delegate process)
 This is required to get it running as a service from the plexus script.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (CONTINUUM-442) plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes

 [ http://jira.codehaus.org/browse/CONTINUUM-442?page=all ]
 
Emmanuel Venisse closed CONTINUUM-442:
--

Resolution: Fixed

 plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes
 

  Key: CONTINUUM-442
  URL: http://jira.codehaus.org/browse/CONTINUUM-442
  Project: Continuum
 Type: Bug
 Reporter: Brett Porter
 Assignee: Emmanuel Venisse
  Fix For: 1.0.1



 (if you can get it into 1.0.1)
 Make the following changes:
 PLEXUS_OPTS=$PLEXUS_OPTS -Xmx128m
 (to pass on plexus opts)
 ...
 exec $JAVACMD \
 (to delegate process)
 This is required to get it running as a service from the plexus script.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (MNG-1105) remove release.properties after successful release:perform

2005-11-14 Thread Trent Rosenbaum (JIRA)

[ http://jira.codehaus.org/browse/MNG-1105?page=comments#action_50897 ] 

Trent Rosenbaum commented on MNG-1105:
--

I feel that the release.properties file should not be removed after the perform 
method has been run.  A message to explain this, (as suggested earlier) could 
be the default behaviour of the maven-release plugin and maybe a configuration 
element could be used to set it otherwise?  This is a good file to keep around 
in large companies because you may few people taking part in the release 
process.  This file allows others to quickly extract and deploy project 
deliverables to new locations.

 remove release.properties after successful release:perform
 --

  Key: MNG-1105
  URL: http://jira.codehaus.org/browse/MNG-1105
  Project: Maven 2
 Type: Bug
   Components: maven-release-plugin
 Reporter: Brett Porter
 Priority: Minor



 can't do this until exit codes work on windows though as it reports success 
 even on failure

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Moved: (MPXDOC-182) xdoc goal crashes

2005-11-14 Thread Lukas Theussl (JIRA)

 [ http://jira.codehaus.org/browse/MPXDOC-182?page=all ]

Lukas Theussl moved MAVEN-1723 to MPXDOC-182:
-

Fix Version: (was: 1.1-beta-2)
 1.10
   Workflow: jira  (was: Maven)
Key: MPXDOC-182  (was: MAVEN-1723)
Project: maven-xdoc-plugin  (was: Maven)

 xdoc goal crashes
 -

  Key: MPXDOC-182
  URL: http://jira.codehaus.org/browse/MPXDOC-182
  Project: maven-xdoc-plugin
 Type: Bug
  Environment: Windows XP,  SUN JDK 1.4.2 build 08
 Reporter: Guy Rixon
  Fix For: 1.10



 The xdoc goal crashes like this:
 BUILD FAILED
 File.. C:\Documents and 
 Settings\gtr\.maven\cache\maven-xdoc-plugin-1.9.2\pl
 ugin.jelly
 Element... j:include
 Line.. 479
 Column -1
 file:/C:/Documents and 
 Settings/gtr/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-
 resources/site.jsl:33:-1: jsl:stylesheet file:/C:/Documents and 
 Settings/gtr/.
 maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:-1: 
 jsl:apply
 Templates file:/C:/Documents and 
 Settings/gtr/.maven/cache/maven-xdoc-plugin-1.
 9.2/plugin-resources/site.jsl:240:-1: maven:property You must define an 
 attrib
 ute called 'defaultValue' for this tag.
 On investigating the named file in the plug-in, I find this at line 240:
 maven:property var=version name=maven.xdoc.version 
 defaultValue=${pom.currentVersion}/
 The same error occurs whether or not the POM has a currentVersion.
 A similar, but less-well described error happens in Maven 1.0.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1105) remove release.properties after successful release:perform

2005-11-14 Thread Arik Kfir (JIRA)

[ http://jira.codehaus.org/browse/MNG-1105?page=comments#action_50899 ] 

Arik Kfir commented on MNG-1105:


What about putting it in the 'target' dir?

Reason: I think this file is both temporary (used for the build only) AND 
useful. For instance, I couldn't figure out why my release fails until I 
glanced at the file and saw that it used the wrong svn username...this way, it 
is still temporary, but if it needs to be looked at after the release, the 
developer can still do so (provided that he/she knows that it is there - a 
message might be in place here).


 remove release.properties after successful release:perform
 --

  Key: MNG-1105
  URL: http://jira.codehaus.org/browse/MNG-1105
  Project: Maven 2
 Type: Bug
   Components: maven-release-plugin
 Reporter: Brett Porter
 Priority: Minor



 can't do this until exit codes work on windows though as it reports success 
 even on failure

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MPXDOC-182) xdoc goal crashes

2005-11-14 Thread Lukas Theussl (JIRA)

 [ http://jira.codehaus.org/browse/MPXDOC-182?page=all ]
 
Lukas Theussl closed MPXDOC-182:


Resolution: Duplicate

Duplicate of MPXDOC-174

 xdoc goal crashes
 -

  Key: MPXDOC-182
  URL: http://jira.codehaus.org/browse/MPXDOC-182
  Project: maven-xdoc-plugin
 Type: Bug
  Environment: Windows XP,  SUN JDK 1.4.2 build 08
 Reporter: Guy Rixon
  Fix For: 1.10



 The xdoc goal crashes like this:
 BUILD FAILED
 File.. C:\Documents and 
 Settings\gtr\.maven\cache\maven-xdoc-plugin-1.9.2\pl
 ugin.jelly
 Element... j:include
 Line.. 479
 Column -1
 file:/C:/Documents and 
 Settings/gtr/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-
 resources/site.jsl:33:-1: jsl:stylesheet file:/C:/Documents and 
 Settings/gtr/.
 maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:-1: 
 jsl:apply
 Templates file:/C:/Documents and 
 Settings/gtr/.maven/cache/maven-xdoc-plugin-1.
 9.2/plugin-resources/site.jsl:240:-1: maven:property You must define an 
 attrib
 ute called 'defaultValue' for this tag.
 On investigating the named file in the plug-in, I find this at line 240:
 maven:property var=version name=maven.xdoc.version 
 defaultValue=${pom.currentVersion}/
 The same error occurs whether or not the POM has a currentVersion.
 A similar, but less-well described error happens in Maven 1.0.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

(Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)

2005-11-14 Thread Donszelmann, Mark

Hi

I get the message:

(Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)

when I use my own packaging, while the (nar)plugin is indeed in the list and 
included,
when I run the clean goal. 

Any other goal works fine (no message).

I guess this is because the clean goal will not download/look for any 
dependencies
and plugins. 

Should this message just be ignored/left out?

Regards
Mark Donszelmann

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

[jira] Closed: (SCM-64) ability to store user password in settings.xml

 [ http://jira.codehaus.org/browse/SCM-64?page=all ]
 
Emmanuel Venisse closed SCM-64:
---

 Assign To: Emmanuel Venisse
Resolution: Fixed

 ability to store user password in settings.xml
 --

  Key: SCM-64
  URL: http://jira.codehaus.org/browse/SCM-64
  Project: Maven SCM
 Type: Bug
   Components: maven-plugin
 Versions: 1.0-alpha-4
  Environment: xp
 Reporter: Dan Tran
 Assignee: Emmanuel Venisse
  Fix For: 1.0-beta-1
  Attachments: SCM-64.diff


 It think we should manage user/password via settings.xml and command line can 
 overide them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

RE: [M2][Proposal] J2EE builds best practices and conventions

2005-11-14 Thread Vincent Massol

Hi Jesse,

Thanks for restarting this thread!

See below

 -Original Message-
 From: Jesse McConnell [mailto:[EMAIL PROTECTED]
 Sent: lundi 7 novembre 2005 20:00
 To: Maven Developers List
 Subject: Re: [M2][Proposal] J2EE builds best practices and conventions

 ok, digging this old thing out the dust bin..

 I have abandoned my old layout (and the current structure provided by the
 j2ee archetype) and shifting towards something that is more like the
 current
 state of the maven repo...and I am trying to decide the lvl of nesting
 that
 is useful for the components when factoring vincents threads above..

 first off, I concede the usefulness of having actual source in the war
 files...while my architecture doesn't really require/use that kinda thing,
 it would be silly to design around the idea in any sort of best practices
 way :) (that being that war's and the like don't need any compiled source
 at
 all, just suck in the associated dependencies)

Cool :-)

 ok...I'll start with the basics of the maven layout since that is a pretty
 simple no brainer place to start..and for this discussion to make sense as
 a
 best practices discussion I'll invent a little project and if it makes
 sense
 to later we can apply the daytrader app to it (I don't know enough of the
 daytrader to do it justice atm). I know brett alluded to an exercise like
 this in the initial mail above..

 Lets say we have a mythical project called dropit...

 flat:

 dropit
 dropit-logging
 dropit-config
 dropit-interfaces
 dropit-frontend-servlet
 dropit-backdoor-servlet
 dropit-site
 dropit-war
 dropit-ear

 pretty simple project, three discrete source modules with a seperate
 interfaces module for other systems to program against..the site, a war
 and
 an ear..

Could you explain what the dropit-*-servlet projects are? Shouldn't they be
located in the dropit-war project?

 starting simple I guess there are a couple of questions we ought to answer
 if we want to arrive at a best practice module layout...

 1. do we want to distingish wars, servlets, ears and other packaging
 concepts by the name of the directory or by nesting them? if so, how many
 lvls deep?

 dropit (the primary source, sister element)
 wars
 wars/dropit-frontend
 wars/dropit-backdoor

+1

 or go for the gusto?

 ear/wars/dropit-frontend
 ear/wars/dropit-backend

I don't think this can be considered a best practice. It may happen in very
particular circumstances that it'll work but not generally speaking. That's
because the same jar/war/etc can be packaged into different wars, ears, etc.

Also it sounds very weird to me to have a directory structure like:

My project
  |_ src/...
  |_ pom.xml
  |_ dropit-frontend/
  |_ dropit-backend/

Mixing src/ and subprojects at the same level doesn't resonate too well I
think.

 2. if we follow another common approach of nesting

 component/dropit

What is this dropit project inside component?

 component/dropit-logging
 component/dropit-config
 packaging/war/dropit-frontend
 packaging/war/dropit-backdoor
 packaging/dropit (type ear, generates dropit-1.0.ear)

For me a jar, war, rar, even ear are all the same: they are modules (aka
components).

 this kinda approach still kind of rubs me raw with there being actual
 source
 in the wars since that means you have source under packaging
 subprojects...

Yep agreed. I don't like it either. I prefer the directory layout I had
proposed in my earlier posts.

 now we can move on to my personal psychosis :)

:-)

 I think my personal problem with trying to figure out a nice clean module
 layout is that with maven's multiproject abilities it makes it difficult
 to
 seperate my previous layout experiences stemming from one overriding
 build.xml file containing everything woven together, from the more clean
 seperation of discrete units that maven2 encourages...working through the
 repository for unit artifacts as opposed to other directories in the
 project
 really frees things up a lot.

 to be honest, working out my current setup and reading through the backlog
 of this message I find myself leaning towards a best practices j2ee setup
 of
 very close to the maven-components one, just utilizing a naming convention
 for j2ee components.

 dropit
 dropit-logging
 dropit-config
 dropit-interfaces-api
 dropit-frontend-servlet
 dropit-backdoor-servlet
 dropit-war
 dropit-ear

Yes, I fine with this too except that I'd name it a bit differently:

dropit/
  |_ logging/
  |_ config/
  |_ interfaces-api/
  |_ frontend-servlet/
  |_ backend-servlet/
  |_ war/
  |_ ear/

But again this is a very simple project that doesn't have everything
automated? What about functional tests? Where do they fit? What about
container configuration files? What about deployment to the container? What
about database start/stop/loading of data? Etc...

This is why I was suggesting an additional directory level in my previous
posts:

dropit/
  |_ components/
|_ [...]
  |_ applications/
|_

Re: svn commit: r332953 - /maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java

2005-11-14 Thread Lukas Theussl


Fabrizio,

This can only be a temporary solution, I am still hoping that we will be 
 able to make validation work with full namespace awareness. If we 
succeed, we'll have to undo this commit.


-Lukas


[EMAIL PROTECTED] wrote:

Author: fgiust
Date: Sun Nov 13 01:21:00 2005
New Revision: 332953

URL: http://svn.apache.org/viewcvs?rev=332953view=rev
Log:
quick hack for removing wrong error messages for poms with an xsd declaration

Modified:

maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java

Modified: 
maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java?rev=332953r1=332952r2=332953view=diff
==
--- 
maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java 
(original)
+++ 
maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java 
Sun Nov 13 01:21:00 2005
@@ -181,6 +181,14 @@
 
 public void error(SAXParseException e) throws SAXException

 {
+if (e.getMessage() != null  
e.getMessage().indexOf(xsi:schemaLocation)  -1)
+{
+// unexpected attribute xsi:schemaLocation
+// ignore, this is due to a valid xsd declaration
+// Jaxp ignores additionals namespaces declared in the xml 
file (xmlns:xsi) and it can't validate
+// using multiple schema at once
+return;
+}
 errorMessage(e, MSV_ERROR);
 setValid(false);
 }




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

[jira] Commented: (MNG-1105) remove release.properties after successful release:perform

2005-11-14 Thread Trent Rosenbaum (JIRA)

[ http://jira.codehaus.org/browse/MNG-1105?page=comments#action_50902 ] 

Trent Rosenbaum commented on MNG-1105:
--

Putting the release.properties file in the target directory makes complete 
sense.  This way the file has a life time that is inline with the checkout 
directory also created by the maven-release plugin.  If the developer wants to 
store the file in a new location then that is done before the mvn clean:clean 
is executed.  A message explaining this would be more appropriate.

 remove release.properties after successful release:perform
 --

  Key: MNG-1105
  URL: http://jira.codehaus.org/browse/MNG-1105
  Project: Maven 2
 Type: Bug
   Components: maven-release-plugin
 Reporter: Brett Porter
 Priority: Minor



 can't do this until exit codes work on windows though as it reports success 
 even on failure

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[maven2 build - SUCCESS - update] Mon Nov 14 18:15:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~maven/builds/m2-20051114.181500.tar.gz

Log:
http://maven.zones.apache.org/~maven/logs/m2-build-log-20051114.181500.txt

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

[jira] Reopened: (MEV-193) Patched activemq-core-3.2.pom

2005-11-14 Thread David Blevins (JIRA)

 [ http://jira.codehaus.org/browse/MEV-193?page=all ]
 
David Blevins reopened MEV-193:
---


 Patched activemq-core-3.2.pom
 -

  Key: MEV-193
  URL: http://jira.codehaus.org/browse/MEV-193
  Project: Maven Evangelism
 Type: Bug
   Components: Invalid POM
 Reporter: David Blevins
 Assignee: Edwin Punzalan
  Attachments: activemq-core-3.2.pom.patch


 This pom has javacc-2.1 commented out as it doesn't exist yet in the maven 
 repo.  Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to 
 org.apache.derby

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - SUCCESS - update] Mon Nov 14 18:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051114.183000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.183000.txt

[jira] Updated: (MNG-1190) Attach source code and/or documentation to library jars

2005-11-14 Thread Arik Kfir (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1190?page=all ]

Arik Kfir updated MNG-1190:
---

Attachment: MNG-1190-maven-idea-plugin.patch

Updated patch: refrains from retrying to download previously attempted 
artifacts. This shortens the time it takes for the plugin to download all 
dependencies. This goals for both failed and successful downloads.

NOTE: there's a very ugly hack in the patch, that uses a static map - this was 
done because I don't know how to have data that is persisted across reactor 
invocations. I tried storing the map in the getPluginContext() but it didn't 
work. If someone could fix that it would be much better.

 Attach source code and/or documentation to library jars
 ---

  Key: MNG-1190
  URL: http://jira.codehaus.org/browse/MNG-1190
  Project: Maven 2
 Type: Improvement
   Components: maven-idea-plugin
 Versions: 2.0-beta-3
 Reporter: Thomas Christensen
  Attachments: MNG-1190-maven-idea-plugin.patch, 
 MNG-1190-maven-idea-plugin.patch


 If the maven 2 repository supports source code and javadocs artifacts, it 
 would be great if the idea plugin could attach this to the library jars. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In your nar plugin definition (within the pom.xml that uses it, that
is), add this:
plugin
...
extensionstrue/extensions
...
/plugin

HTH,

john

Donszelmann, Mark wrote:
| Hi
|
| I get the message:
|
| (Nonexistent component:
org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
|
| when I use my own packaging, while the (nar)plugin is indeed in the
list and included,
| when I run the clean goal.
|
| Any other goal works fine (no message).
|
| I guess this is because the clean goal will not download/look for
any dependencies
| and plugins.
|
| Should this message just be ignored/left out?
|
| Regards
| Mark Donszelmann
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDeN+yK3h2CZwO/4URAhizAKCKoexJ0iFGwwN5l7AkfzdV5bygywCdEKUN
d8CwAgGc+c9YhCvmPW6jWMA=
=7yJ6
-END PGP SIGNATURE-

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

[jira] Created: (MNG-1558) Manifest generation problems caused by valid POM information

2005-11-14 Thread Bob Allison (JIRA)

Manifest generation problems caused by valid POM information


 Key: MNG-1558
 URL: http://jira.codehaus.org/browse/MNG-1558
 Project: Maven 2
Type: Bug
  Components: maven-jar-plugin  
Versions: 2.0
Reporter: Bob Allison


It looks like we have some problems with the contents of manifests in jar files.

According to Sun's documentation 
(http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic 
formatting rules which are not always being enforced:
   1) All text must be UTF-8
   2) Lines are limited to 72 characters; longer lines must be continued
   3) Sections are divided by blank lines

Where are these rules being violated?  The first rule can be violated by any 
POM which is in a character set other than UTF-8.  The last two rules can be 
violated by any POM value which spans multiple lines.  Both of these are 
potential problems since a number of POM values go directly into the manifest 
without sufficient checking.


Example:
The plugin I have been working on suddenly stopped working.  It stopped when I 
added a two-line description to the POM.  I have been able to determine that 
converting the second line of the description into a proper manifest 
continuation line fixed the problem.  As it turns out, the class loader was 
ignoring the jar; this created an error where the name of the Mojo class was 
found but the class could not be loaded.

Workarounds for the present:
   -- Any POM fields which end up in a jar manifest needs to be limited to 
UTF-8 characters.
   -- Multi-line values should be constructed so that all lines start with a 
space character (not strictly required for the first line but it doesn't hurt).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MPJALOPY-8) Change Apache license in Jalopy header to version 2.0

2005-11-14 Thread Lukas Theussl (JIRA)

 [ http://jira.codehaus.org/browse/MPJALOPY-8?page=all ]
 
Lukas Theussl closed MPJALOPY-8:


 Resolution: Fixed
Fix Version: 1.4

Fixed long time ago

 Change Apache license in Jalopy header to version 2.0
 -

  Key: MPJALOPY-8
  URL: http://jira.codehaus.org/browse/MPJALOPY-8
  Project: maven-jalopy-plugin
 Type: Bug
  Environment: All
 Reporter: Yoav Shapira
 Priority: Trivial
  Fix For: 1.4


 Original Estimate: 15 minutes
 Remaining: 15 minutes

 The Jalopy header uses Apache license v1.1, and it should use Apache license 
 v2.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MEV-193) Patched activemq-core-3.2.pom

2005-11-14 Thread David Blevins (JIRA)

 [ http://jira.codehaus.org/browse/MEV-193?page=all ]

David Blevins updated MEV-193:
--

Attachment: activemq-core-3.2.pom.patch2

ActiveMQ core requires the concurrent library as it states on their website.

 Patched activemq-core-3.2.pom
 -

  Key: MEV-193
  URL: http://jira.codehaus.org/browse/MEV-193
  Project: Maven Evangelism
 Type: Bug
   Components: Invalid POM
 Reporter: David Blevins
 Assignee: Edwin Punzalan
  Attachments: activemq-core-3.2.pom.patch, activemq-core-3.2.pom.patch2


 This pom has javacc-2.1 commented out as it doesn't exist yet in the maven 
 repo.  Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to 
 org.apache.derby

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MEV-193) Patched activemq-core-3.2.pom

2005-11-14 Thread David Blevins (JIRA)

[ http://jira.codehaus.org/browse/MEV-193?page=comments#action_50908 ] 

David Blevins commented on MEV-193:
---

Here is the stacktrace you get without the concurrent jar.  Comes from a test 
case that uses ActiveMQ

java.lang.NoClassDefFoundError: 
EDU/oswego/cs/dl/util/concurrent/ConcurrentHashMap
at org.activemq.broker.BrokerContext.init(BrokerContext.java:38)
at org.activemq.broker.BrokerContext.clinit(BrokerContext.java:36)
at 
org.activemq.broker.impl.BrokerContainerImpl.init(BrokerContainerImpl.java:96)
at 
org.activemq.broker.impl.BrokerContainerImpl.init(BrokerContainerImpl.java:92)
at org.activemq.broker.impl.Main.main(Main.java:44)


 Patched activemq-core-3.2.pom
 -

  Key: MEV-193
  URL: http://jira.codehaus.org/browse/MEV-193
  Project: Maven Evangelism
 Type: Bug
   Components: Invalid POM
 Reporter: David Blevins
 Assignee: Edwin Punzalan
  Attachments: activemq-core-3.2.pom.patch, activemq-core-3.2.pom.patch2


 This pom has javacc-2.1 commented out as it doesn't exist yet in the maven 
 repo.  Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to 
 org.apache.derby

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1316) Dependency report breaks on systemPath artifacts

2005-11-14 Thread Bernd Bohmann (JIRA)

[ http://jira.codehaus.org/browse/MNG-1316?page=comments#action_50909 ] 

Bernd Bohmann commented on MNG-1316:


Please vote for http://jira.codehaus.org/browse/MNG-1455

 Dependency report breaks on systemPath artifacts
 

  Key: MNG-1316
  URL: http://jira.codehaus.org/browse/MNG-1316
  Project: Maven 2
 Type: Bug
   Components: maven-project-info-reports-plugin
 Versions: 2.0
 Reporter: Wilfred Springer
 Assignee: Brett Porter



 My project refers to several artifacts that have a systemPath element, 
 refering to jar files in the ${basedir}/lib directory. The projects builds 
 fine, but the dependency reports breaks when it starts processing these 
 dependencies.
 java.lang.NullPointerException
 at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
 at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:380)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:346)
 at 
 org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.getMavenProjectFromRepository(DependenciesReport.java:362)
 at 
 org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:242)
 at 
 org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
 at 
 org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:157)
 at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
 at 
 org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:789)
 at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

RE: (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)

2005-11-14 Thread Donszelmann, Mark

Hi John,

I have these tags in my POM. Without them any goal would
give the error message. 

However, ONLY when I run the clean goal is the message
still there. Clean still works properly, it is just 
this message which would confuse users (and myself).

Could it be that the message comes from the fact that
it does not understand (and does not have to understand) 
the packaging for clean. In that case, the clean goal
should not complain if it does not find the packaging,
maybe the same way that it does not complain about any missing
plugins/dependencies. 

Regards
Mark
 

 -Original Message-
 From: John Casey [mailto:[EMAIL PROTECTED] 
 Sent: Monday, November 14, 2005 11:04 AM
 To: Maven Developers List
 Subject: Re: (Nonexistent component: 
 org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 In your nar plugin definition (within the pom.xml that uses 
 it, that is), add this:
 plugin
 ...
 extensionstrue/extensions
 ...
 /plugin
 
 HTH,
 
 john
 
 Donszelmann, Mark wrote:
 | Hi
 |
 | I get the message:
 |
 | (Nonexistent component:
 org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
 |
 | when I use my own packaging, while the (nar)plugin is indeed in the
 list and included,
 | when I run the clean goal.
 |
 | Any other goal works fine (no message).
 |
 | I guess this is because the clean goal will not download/look for
 any dependencies
 | and plugins.
 |
 | Should this message just be ignored/left out?
 |
 | Regards
 | Mark Donszelmann
 |
 | 
 -
 | To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 | additional commands, e-mail: [EMAIL PROTECTED]
 |
 |
 |
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.6 (GNU/Linux)
 
 iD8DBQFDeN+yK3h2CZwO/4URAhizAKCKoexJ0iFGwwN5l7AkfzdV5bygywCdEKUN
 d8CwAgGc+c9YhCvmPW6jWMA=
 =7yJ6
 -END PGP SIGNATURE-
 
 -
 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: (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This may have to do with the introduction of a lifecycle for cleaning a
project. If so, it should quietly use the default lifecycle when it
cannot find a 'clean' lifecycle mapping for the 'nar' packaging.

Can you verify this by calling:

mvn clean:clean

If this succeeds, it would lead me to believe that plugin handling
itself is find, but that the lifecycle handling is a bit messed up by
the implementation of multiple lifecycles...

HTH,

- -j

Donszelmann, Mark wrote:
| Hi John,
|
| I have these tags in my POM. Without them any goal would
| give the error message.
|
| However, ONLY when I run the clean goal is the message
| still there. Clean still works properly, it is just
| this message which would confuse users (and myself).
|
| Could it be that the message comes from the fact that
| it does not understand (and does not have to understand)
| the packaging for clean. In that case, the clean goal
| should not complain if it does not find the packaging,
| maybe the same way that it does not complain about any missing
| plugins/dependencies.
|
| Regards
| Mark
|
|
|
|-Original Message-
|From: John Casey [mailto:[EMAIL PROTECTED]
|Sent: Monday, November 14, 2005 11:04 AM
|To: Maven Developers List
|Subject: Re: (Nonexistent component:
|org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
|
| In your nar plugin definition (within the pom.xml that uses
| it, that is), add this:
| plugin
| ...
| extensionstrue/extensions
| ...
| /plugin
|
| HTH,
|
| john
|
| Donszelmann, Mark wrote:
| | Hi
| |
| | I get the message:
| |
| | (Nonexistent component:
| org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
| |
| | when I use my own packaging, while the (nar)plugin is indeed in the
| list and included,
| | when I run the clean goal.
| |
| | Any other goal works fine (no message).
| |
| | I guess this is because the clean goal will not download/look for
| any dependencies
| | and plugins.
| |
| | Should this message just be ignored/left out?
| |
| | Regards
| | Mark Donszelmann
| |
| |
| -
| | 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]



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDeO4zK3h2CZwO/4URAvFTAKCvbvR+ASR+cAJc6Ymyia+Ak/lTWQCfYZN3
khE7Ws/CXyPlaHJHn+6pLNE=
=16XF
-END PGP SIGNATURE-

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

RE: (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)

2005-11-14 Thread Donszelmann, Mark

Hi John,

mvn clean:clean 

does not output the error message. 

Is there something special I should implement/specify to handle
the clean (which I want the standard/clean lifecycle to handle).

The only thing I currently have is a set of plugins and a components.xml
file. 

Regards
Mark
 

 -Original Message-
 From: John Casey [mailto:[EMAIL PROTECTED] 
 Sent: Monday, November 14, 2005 12:06 PM
 To: Maven Developers List
 Subject: Re: (Nonexistent component: 
 org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 This may have to do with the introduction of a lifecycle for 
 cleaning a project. If so, it should quietly use the default 
 lifecycle when it cannot find a 'clean' lifecycle mapping for 
 the 'nar' packaging.
 
 Can you verify this by calling:
 
 mvn clean:clean
 
 If this succeeds, it would lead me to believe that plugin 
 handling itself is find, but that the lifecycle handling is a 
 bit messed up by the implementation of multiple lifecycles...
 
 HTH,
 
 - -j
 
 Donszelmann, Mark wrote:
 | Hi John,
 |
 | I have these tags in my POM. Without them any goal would give the 
 | error message.
 |
 | However, ONLY when I run the clean goal is the message 
 still there. 
 | Clean still works properly, it is just this message which would 
 | confuse users (and myself).
 |
 | Could it be that the message comes from the fact that it does not 
 | understand (and does not have to understand) the packaging 
 for clean. 
 | In that case, the clean goal should not complain if it does 
 not find 
 | the packaging, maybe the same way that it does not complain 
 about any 
 | missing plugins/dependencies.
 |
 | Regards
 | Mark
 |
 |
 |
 |-Original Message-
 |From: John Casey [mailto:[EMAIL PROTECTED]
 |Sent: Monday, November 14, 2005 11:04 AM
 |To: Maven Developers List
 |Subject: Re: (Nonexistent component:
 |org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
 |
 | In your nar plugin definition (within the pom.xml that uses 
 it, that 
 | is), add this:
 | plugin
 | ...
 | extensionstrue/extensions
 | ...
 | /plugin
 |
 | HTH,
 |
 | john
 |
 | Donszelmann, Mark wrote:
 | | Hi
 | |
 | | I get the message:
 | |
 | | (Nonexistent component:
 | org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
 | |
 | | when I use my own packaging, while the (nar)plugin is 
 indeed in the
 | list and included,
 | | when I run the clean goal.
 | |
 | | Any other goal works fine (no message).
 | |
 | | I guess this is because the clean goal will not 
 download/look for
 | any dependencies
 | | and plugins.
 | |
 | | Should this message just be ignored/left out?
 | |
 | | Regards
 | | Mark Donszelmann
 | |
 | |
 | 
 -
 | | 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]
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.6 (GNU/Linux)
 
 iD8DBQFDeO4zK3h2CZwO/4URAvFTAKCvbvR+ASR+cAJc6Ymyia+Ak/lTWQCfYZN3
 khE7Ws/CXyPlaHJHn+6pLNE=
 =16XF
 -END PGP SIGNATURE-
 
 -
 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: (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

what does your components.xml look like? I'd like to compare it against
a packaging definition I wrote, to see whether both will cause the
error, or what...

I don't *think* you should have to do anything special to handle the
clean lifecycle. None of the other lifecycle mappings specify bindings
for the clean lifecycle; they all use the defaults for 'clean'. I'll
have to investigate this a bit more...can you file a JIRA issue, to help
keep this on the radar?

- -j

Donszelmann, Mark wrote:
| Hi John,
|
| mvn clean:clean
|
| does not output the error message.
|
| Is there something special I should implement/specify to handle
| the clean (which I want the standard/clean lifecycle to handle).
|
| The only thing I currently have is a set of plugins and a components.xml
| file.
|
| Regards
| Mark
|
|
|
|-Original Message-
|From: John Casey [mailto:[EMAIL PROTECTED]
|Sent: Monday, November 14, 2005 12:06 PM
|To: Maven Developers List
|Subject: Re: (Nonexistent component:
|org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
|
| This may have to do with the introduction of a lifecycle for
| cleaning a project. If so, it should quietly use the default
| lifecycle when it cannot find a 'clean' lifecycle mapping for
| the 'nar' packaging.
|
| Can you verify this by calling:
|
| mvn clean:clean
|
| If this succeeds, it would lead me to believe that plugin
| handling itself is find, but that the lifecycle handling is a
| bit messed up by the implementation of multiple lifecycles...
|
| HTH,
|
| -j
|
| Donszelmann, Mark wrote:
| | Hi John,
| |
| | I have these tags in my POM. Without them any goal would give the
| | error message.
| |
| | However, ONLY when I run the clean goal is the message
| still there.
| | Clean still works properly, it is just this message which would
| | confuse users (and myself).
| |
| | Could it be that the message comes from the fact that it does not
| | understand (and does not have to understand) the packaging
| for clean.
| | In that case, the clean goal should not complain if it does
| not find
| | the packaging, maybe the same way that it does not complain
| about any
| | missing plugins/dependencies.
| |
| | Regards
| | Mark
| |
| |
| |
| |-Original Message-
| |From: John Casey [mailto:[EMAIL PROTECTED]
| |Sent: Monday, November 14, 2005 11:04 AM
| |To: Maven Developers List
| |Subject: Re: (Nonexistent component:
| |org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
| |
| | In your nar plugin definition (within the pom.xml that uses
| it, that
| | is), add this:
| | plugin
| | ...
| | extensionstrue/extensions
| | ...
| | /plugin
| |
| | HTH,
| |
| | john
| |
| | Donszelmann, Mark wrote:
| | | Hi
| | |
| | | I get the message:
| | |
| | | (Nonexistent component:
| | org.apache.maven.lifecycle.mapping.LifecycleMappingnar)
| | |
| | | when I use my own packaging, while the (nar)plugin is
| indeed in the
| | list and included,
| | | when I run the clean goal.
| | |
| | | Any other goal works fine (no message).
| | |
| | | I guess this is because the clean goal will not
| download/look for
| | any dependencies
| | | and plugins.
| | |
| | | Should this message just be ignored/left out?
| | |
| | | Regards
| | | Mark Donszelmann
| | |
| | |
| |
| -
| | | 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]
|
|
|

- -
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]



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDePF/K3h2CZwO/4URAplNAKCbYgO3M4URN33AV+0jdruwB1ZB9wCePhHj
EEmUQiztxWKqVxJM0r5N/2I=
=6qXn
-END PGP SIGNATURE-

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

[maven2 build - SUCCESS - update] Mon Nov 14 20:15:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~maven/builds/m2-20051114.201500.tar.gz

Log:
http://maven.zones.apache.org/~maven/logs/m2-build-log-20051114.201500.txt

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

[jira] Created: (MNG-1559) Error (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar) for clean goal.

2005-11-14 Thread Mark Donszelmann (JIRA)

Error  (Nonexistent component: 
org.apache.maven.lifecycle.mapping.LifecycleMappingnar) for clean goal.
--

 Key: MNG-1559
 URL: http://jira.codehaus.org/browse/MNG-1559
 Project: Maven 2
Type: Bug
  Components: maven-clean-plugin  
Versions: 2.0
Reporter: Mark Donszelmann
Priority: Minor
 Attachments: components.xml

This may or may not be a bug.

The attached nar packaging works fine for any other goal than clean.

The clean goal works, but outputs the error message:

 (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar)

When run with the clean:clean goal the message does not appear.

 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[maven2 build - SUCCESS - update] Mon Nov 14 20:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~maven/builds/m2-20051114.203000.tar.gz

Log:
http://maven.zones.apache.org/~maven/logs/m2-build-log-20051114.203000.txt

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

[continuum build - FAILED - update] Mon Nov 14 20:30:00 GMT 2005

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.203000.txt

[jira] Created: (MNG-1560) Guide to accessing repository with https client authentication

2005-11-14 Thread Arnaud Bailly (JIRA)

Guide to accessing repository with https client authentication
--

 Key: MNG-1560
 URL: http://jira.codehaus.org/browse/MNG-1560
 Project: Maven 2
Type: Improvement
  Components: documentation - guides  
Versions: 2.0
Reporter: Arnaud Bailly
Priority: Minor
 Fix For: 2.0
 Attachments: MavenRepoSSLAccess.apt

The attachment describes a way (in APT format) to use a remote repository 
through HTTPS with client-side certificate authentication. This may be useful 
in corporate or private development settings.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MAVENUPLOAD-587) openutils-log4j 1.0

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-587?page=all ]
 
Carlos Sanchez closed MAVENUPLOAD-587:
--

 Assign To: Carlos Sanchez
Resolution: Fixed

 openutils-log4j 1.0
 ---

  Key: MAVENUPLOAD-587
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-587
  Project: maven-upload-requests
 Type: Task
 Reporter: fabrizio giustina
 Assignee: Carlos Sanchez





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1561) -Dgoals to use comma separator

2005-11-14 Thread Dan Tran (JIRA)

-Dgoals to use comma separator
--

 Key: MNG-1561
 URL: http://jira.codehaus.org/browse/MNG-1561
 Project: Maven 2
Type: Bug
  Components: maven-release-plugin  
 Environment: xp
Reporter: Dan Tran
 Fix For: 2.0.1


I am writting a custom plugin in order to do release via maven-release-plugin 
in once step

So the custom plugin run 2 plexus Commanline, one for prepare and one for 
release.

However I am not able able to get commandLine to create this argument

mvn release:perform -Dgoals=deploy site:site site:deploy  using plexus 
commandLine

In order to make this happen, maven-release-plugin should use String[] for the 
goals field instead of String
so that the command should look like this

mvn release:perform -Dgoals=deploy site:site site:deploy 


Another option is to keep goals fieds as String, but requires to use comma as 
separtor, this way 
the command line will be

mvn release:perform -Dgoals=deploy,site:site,site:deploy

plexus' commandline is happy about those 2 resolutions

I perfer resolution 2 since maven-scm-plugin (m1 and m2)  already uses this 
approach in it scm:bootstrap





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: svn commit: r332953 - /maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java

2005-11-14 Thread Fabrizio Giustina

Hi Lukas

On 11/14/05, Lukas Theussl [EMAIL PROTECTED] wrote:
 This can only be a temporary solution, I am still hoping that we will be
   able to make validation work with full namespace awareness. If we
 succeed, we'll have to undo this commit.

Sure, if we can make MSV validate files properly we will have to
remove this temporary hack... anyway, let make it work now, till we
find a better solution.
Also note that this has nothing to do with namespace awareness, also
if we can make namespaces working it will not solve the problem: the
only solution would be validating project.xml against 2 schemas at the
same time (maven xsd+schema xsd), but AFAIK msv doesn't support that
at all...

fabrizio


 -Lukas


 [EMAIL PROTECTED] wrote:
  Author: fgiust
  Date: Sun Nov 13 01:21:00 2005
  New Revision: 332953
 
  URL: http://svn.apache.org/viewcvs?rev=332953view=rev
  Log:
  quick hack for removing wrong error messages for poms with an xsd 
  declaration
 
  Modified:
  
  maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java
 
  Modified: 
  maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java
  URL: 
  http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java?rev=332953r1=332952r2=332953view=diff
  ==
  --- 
  maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java
   (original)
  +++ 
  maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java
   Sun Nov 13 01:21:00 2005
  @@ -181,6 +181,14 @@
 
   public void error(SAXParseException e) throws SAXException
   {
  +if (e.getMessage() != null  
  e.getMessage().indexOf(xsi:schemaLocation)  -1)
  +{
  +// unexpected attribute xsi:schemaLocation
  +// ignore, this is due to a valid xsd declaration
  +// Jaxp ignores additionals namespaces declared in the xml 
  file (xmlns:xsi) and it can't validate
  +// using multiple schema at once
  +return;
  +}
   errorMessage(e, MSV_ERROR);
   setValid(false);
   }
 
 

 -
 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]

[jira] Created: (MNG-1562) Exception with dependencies that have type and implied version from parents

2005-11-14 Thread Arik Kfir (JIRA)

Exception with dependencies that have type and implied version from parents
---

 Key: MNG-1562
 URL: http://jira.codehaus.org/browse/MNG-1562
 Project: Maven 2
Type: Bug
  Components: maven-project  
Versions: 2.0
 Environment: JDK 1.5.0_05, Kubuntu Linux 5.1
Reporter: Arik Kfir


I have the following POM structure:

POM_PARENT
  +--POM_EJB (packaging=ejb)
  +--POM_EAR (packaging=ear)

As you can see, POM_EJB and POM_EAR extend POM_PARENT.

The POM_PARENT defines a dependencyManagement which specifies the correct 
version of POM_EJB that POM_EAR should depend upon, like this:
dependencyManagement
  ...
  dependency
groupId.../groupId
artifactIdPOM_EJB/artifactId
version.../version
  /dependency
/dependencyManagement

POM_EAR contains the following:
dependency
  groupId.../groupId
  artifactIdPOM_EJB/artifactId
/dependency

This works well, until I use the maven-ear-plugin to package the POM_EAR 
project. I get the error:

Artifact[org.corleon.crm:crm-ejb-dummy:ejb] is not a dependency of the project.

Note the :ejb at the end of the artifact ID. I've poked around the 
maven-ear-plugin and I see it makes sure that EJB modules' for the 
application.xml *are indeed of TYPE ejb*, which is fine. However, when I add 
the typeejb/type clause to the POM_EAR's dependency (either in the 
depManagement in POM_PARENT or in POM_EAR itself) I get the exception:

[EMAIL PROTECTED]:~/projects/crm/ear$ mvn package
[INFO] Scanning for projects...
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] Error building POM (may not be this project's POM).


Project ID: org.corleon.crm:crm-ear
POM Location: /home/arik/projects/crm/ear/pom.xml
Validation Messages:

[0]  'dependencies.dependency.version' is missing.


Reason: Failed to validate POM


[INFO] 

[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate POM
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to 
validate POM
at 
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:774)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:624)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345)
... 11 more
[INFO] 

[INFO] Total time:  1 second
[INFO] Finished at: Mon Nov 14 22:58:26 IST 2005
[INFO] Final Memory: 1M/2M
[INFO] 


This happens anytime there's a dependency that has a type clause without a 
version clause (even though the version should be taken from a 
dependencyManagement clause in the parent POM).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MAVENUPLOAD-588) please upload A2J beta2

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-588?page=comments#action_50911 ] 

Carlos Sanchez commented on MAVENUPLOAD-588:


groupId tag is not correctly closed

 please upload A2J beta2
 ---

  Key: MAVENUPLOAD-588
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-588
  Project: maven-upload-requests
 Type: Task
 Reporter: nicolas de loof



 A2J is a tool for converting ASN specifications into a collection of java 
 classes capable of encoding and decoding the data units defined by those 
 specifications. A2J also includes a set of runtime classes that support 
 serialising ASN types to and from BER streams. A2J is licensed under the LGPL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - FAILED - update] Mon Nov 14 21:00:00 GMT 2005

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.210001.txt

[jira] Commented: (MNG-1528) Ability to pass user defined arguments into release:perform

2005-11-14 Thread Dan Tran (JIRA)

[ http://jira.codehaus.org/browse/MNG-1528?page=comments#action_50912 ] 

Dan Tran commented on MNG-1528:
---

This request may be redundant because of MNG-1561 depending how clean we want 
to be.

 Ability to pass user defined arguments into release:perform
 ---

  Key: MNG-1528
  URL: http://jira.codehaus.org/browse/MNG-1528
  Project: Maven 2
 Type: Improvement
 Versions: 2.0
  Environment: xp
 Reporter: Dan Tran
  Fix For: 2.0.1



 There are cases where I need to passing more arguments to go along with 
 -Dgoals only at release time
 Currently the work around is 
   -Dgoals=somegoals -Darg=value 
 It is best with
   -Dgoals=some goals -Darguments=some args
 Is it reasonable to allow this new improvement?
 I can send a patch in right away.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[Maven Wiki] Update of AssemblyPlugin by AlexanderHars

2005-11-14 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Maven Wiki for change 
notification.

The following page has been changed by AlexanderHars:
http://wiki.apache.org/maven/AssemblyPlugin

The comment on the change is:
Clarified the includes, excludes element. 

--
- 
  [http://maven.apache.org/guides/mini/guide-assemblies.html Guide to creating 
assemblies] 
  
  [http://maven.apache.org/plugins/maven-assembly-plugin/howto.html How to use 
assembly plugin] - good
@@ -33, +32 @@

  
  || outputDirectory || Directory in the target tree where the files should 
be copied to. ||
  || directory || copies the contents of this directory to the specified 
target directory. Copies files by name, does not copy path. ''if anyone could 
clarify what other types of patterns can be specified that would be great!''||
- || includes   || copies the specified files that match the pattern (e.g. 
*.txt) to the target directory. Includes the directory path when copying. ||
+ || includes   || Contains include../include elements. Copies the 
specified files that match the pattern (e.g. *.txt) to the target directory. 
Includes the directory path when copying. ||
- || excludes   || Excludes the specified files that match the pattern (e.g. 
*.txt) from being copied to the target directory. ||
+ || excludes   || Contains exclude../exclude elements. Excludes the 
specified files that match the pattern (e.g. *.txt) from being copied to the 
target directory. ||
  || lineEnding  ||  ||
  || directoryMode  ||  ||
  || fileMode  ||  ||
@@ -42, +41 @@

  === dependencySets ===
  
  || outputDirectory || Directory in the target tree where the dependencies 
should be copied to. ||
- || includes   || Includes the specified dependency ||
- || excludes   || Excludes the specified dependency ||
+ || includes   || Contains include../include elements. Includes the 
specified dependency. Specify the dependency as groupId : artifactId. Example: 
includesincludeorg.eclipse:swt/include/includes ||
+ || excludes   || Contains exclude../exclude elements. Excludes the 
specified dependencies. Specify the dependency as groupId : artifactId. 
Example: excludesexcludeorg.eclipse:swt/exclude/excludes ||
  || unpack  || Unpacks the contents of the dependencies ||
  || scope  ||  ||
  || outputFileNameMapping  ||  ||

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

[jira] Moved: (MAVENUPLOAD-589) Upload iBATIS 2.1.6 to iBiblio

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-589?page=all ]

Carlos Sanchez moved MEV-205 to MAVENUPLOAD-589:


   Group ID:   (was: com.ibatis)
 Bundle URL: x
Artifact ID:   (was: ibatis2-sqlmap)
Key: MAVENUPLOAD-589  (was: MEV-205)
Project: maven-upload-requests  (was: Maven Evangelism)

 Upload iBATIS 2.1.6 to iBiblio
 --

  Key: MAVENUPLOAD-589
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-589
  Project: maven-upload-requests
 Type: Improvement
 Reporter: Matt Raible



 http://ibatis.apache.org/downloads.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Moved: (MAVENUPLOAD-590) Add postgresql-8.1-404.jdbc3.jar to Maven 2 Repository

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-590?page=all ]

Carlos Sanchez moved MEV-203 to MAVENUPLOAD-590:


   Group ID:   (was: postgresql)
 Bundle URL: x
Artifact ID:   (was: postgresql)
Version:   (was: 8.1-404.jdbc3)
Key: MAVENUPLOAD-590  (was: MEV-203)
Project: maven-upload-requests  (was: Maven Evangelism)

 Add postgresql-8.1-404.jdbc3.jar to Maven 2 Repository
 --

  Key: MAVENUPLOAD-590
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-590
  Project: maven-upload-requests
 Type: Wish
   Components: Dependencies
 Reporter: Matt Raible



 The latest version of PostgreSQL (8.0.4) does not work with the latest driver 
 (8.0-312) in Maven's repository.  Please upload the latest JDBC Driver so 
 it's possible to use M2+PostgreSQL's latest database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MPJIRA-15) An extra secure is added to the issue tracking url when maven fetch data from jira

2005-11-14 Thread fabrizio giustina (JIRA)

 [ http://jira.codehaus.org/browse/MPJIRA-15?page=all ]
 
fabrizio giustina closed MPJIRA-15:
---

  Assign To: fabrizio giustina
 Resolution: Fixed
Fix Version: 1.2

already fixed in svn for 1.2

 An extra secure is added to the issue tracking url when maven fetch data 
 from jira
 

  Key: MPJIRA-15
  URL: http://jira.codehaus.org/browse/MPJIRA-15
  Project: maven-jira-plugin
 Type: Bug
 Versions: 1.1.2
  Environment: maven 1.0.2, maven-jira-plugin 1.1.2, MacOS X 10.4.2, jira 3.1.1
 Reporter: Kaj Hejer
 Assignee: fabrizio giustina
  Fix For: 1.2



 It seems like an extra secure is added to the url the plugin use.
 The issueTrackingUrl I have defined in project.xml is
 http://www.mydomain.com//jira/secure/BrowseProject.jspa?id=10270
  
 When I run maven maven-jira-plugin:report I see the following output:
 Downloading 
 http://www.mydomain.com/jira/secure/secure/IssueNavigator.jspa?view=rsspid=10270sorter/field=issuekeysorter/order=DESCsorter/field=statussorter/order=DESCtempMax=1000reset=truedecorator=none
 Notice that url contain secure twice in the url used by maven, but only 
 once in the issueTrackingUrl.
 Can this be a bug in the maven-jira-plugin?
 I found this problem when debuging why I couldn't get the property 
 maven.jira.filter to work as intended.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[maven2 build - SUCCESS - update] Mon Nov 14 21:15:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~maven/builds/m2-20051114.211500.tar.gz

Log:
http://maven.zones.apache.org/~maven/logs/m2-build-log-20051114.211500.txt

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

[jira] Closed: (MEV-200) sslext/sslext-1.2-0 jar contains no class files (should have several)

 [ http://jira.codehaus.org/browse/MEV-200?page=all ]
 
Carlos Sanchez closed MEV-200:
--

 Assign To: Carlos Sanchez
Resolution: Fixed

The upload bundle was wrong

 sslext/sslext-1.2-0 jar contains no class files (should have several)
 -

  Key: MEV-200
  URL: http://jira.codehaus.org/browse/MEV-200
  Project: Maven Evangelism
 Type: Bug
 Reporter: Adam Hardy
 Assignee: Carlos Sanchez



 The jar on ibiblio has 1.8kB. The jar from the source has 23kB.
 For reasons unknown all the class files are missing from the ibiblio jar.
 http://sourceforge.net/project/showfiles.php?group_id=59967package_id=130891

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MEV-202) dependency wrong

[ http://jira.codehaus.org/browse/MEV-202?page=comments#action_50915 ] 

Carlos Sanchez commented on MEV-202:


javax.xml.xsdlib is right

you can provide a pom for javax.xml namespace, but the jar cannot be uploaded 
due to license restrictions (jar from Sun)

 dependency wrong
 

  Key: MEV-202
  URL: http://jira.codehaus.org/browse/MEV-202
  Project: Maven Evangelism
 Type: Bug
   Components: Dependencies
 Reporter: Adam Hardy



 javax.xml.namespace doesn't exist on ibiblio
 and
 javax.xml.xsdlib is xsdlib.xsdlib

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Moved: (MAVENUPLOAD-591) pom for eclipse osgi

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-591?page=all ]

Carlos Sanchez moved MEV-199 to MAVENUPLOAD-591:


   Group ID:   (was: org.eclipse.equinox)
 Bundle URL: x
Artifact ID:   (was: osgi)
Version:   (was: 3.1.1)
Key: MAVENUPLOAD-591  (was: MEV-199)
Project: maven-upload-requests  (was: Maven Evangelism)

 pom for eclipse osgi
 

  Key: MAVENUPLOAD-591
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-591
  Project: maven-upload-requests
 Type: Improvement
   Components: Missing POM
 Reporter: Dain Sundstrom
  Attachments: osgi-3.1.1.jar, osgi-3.1.1.pom




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - SUCCESS - update] Mon Nov 14 21:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051114.213000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.213000.txt

[jira] Closed: (MPJIRA-5) jira plugin does not work with jira 3.0.2

2005-11-14 Thread fabrizio giustina (JIRA)

 [ http://jira.codehaus.org/browse/MPJIRA-5?page=all ]
 
fabrizio giustina closed MPJIRA-5:
--

  Assign To: fabrizio giustina  (was: Emmanuel Venisse)
 Resolution: Duplicate
Fix Version: 1.2

seems to be working properly in the version currently in svn, this sounds like 
a duplicate of MPJIRA-3.

 jira plugin does not work with jira 3.0.2
 -

  Key: MPJIRA-5
  URL: http://jira.codehaus.org/browse/MPJIRA-5
  Project: maven-jira-plugin
 Type: Bug
  Environment: jira-3.0.2
 Reporter: Ryan Sonnek
 Assignee: fabrizio giustina
  Fix For: 1.2



 running the maven jira plugin with these settings generates an error:
 issueTrackingUrl: http://www.codecrate.com/jira/BrowseProject.jspa?id=1
 Downloading 
 http://www.codecrate.com/jira/secure/IssueNavigator.jspa?view=rsspid=1sorter/field=issuekeysorter/order=DESCsorter/field=statussorter/order=DESCtempMax=1000reset=true
  
 BUILD FAILED
 File.. /home/rsonnek/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly
 Element... x:parse
 Line.. 120
 Column 48
 Error on line 31 of document http://www.w3.org/TR/html4/loose.dtd : The 
 declaration for the entity HTML.Version must end with ''. Nested 
 exception: The declaration for the entity HTML.Version must end with ''.
 com.werken.werkz.UnattainableGoalException: Unable to obtain goal [site] -- 
 /home/rsonnek/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly:120:48: 
 x:parse Error on line 31 of document http://www.w3.org/TR/html4/loose.dtd : 
 The declaration for the entity HTML.Version must end with ''. Nested 
 exception: The declaration for the entity HTML.Version must end with ''.
 at com.werken.werkz.Goal.fire(Goal.java:646)
 at com.werken.werkz.Goal.attain(Goal.java:575)
 at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
 at 
 org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634)
 at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266)
 at org.apache.maven.cli.App.doMain(App.java:486)
 at org.apache.maven.cli.App.main(App.java:1215)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at com.werken.forehead.Forehead.run(Forehead.java:551)
 at com.werken.forehead.Forehead.main(Forehead.java:581)
 org.apache.commons.jelly.JellyTagException: 
 /home/rsonnek/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly:120:48: 
 x:parse Error on line 31 of document http://www.w3.org/TR/html4/loose.dtd : 
 The declaration for the entity HTML.Version must end with ''. Nested 
 exception: The declaration for the entity HTML.Version must end with ''.
 at 
 org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:186)
 at 
 org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.java:106)
 at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
 at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
 at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
 at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
 at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
 at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
 at com.werken.werkz.Goal.fire(Goal.java:639)
 at com.werken.werkz.Goal.attain(Goal.java:575)
 at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
 at 
 org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
 at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
 at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
 at

[jira] Commented: (MAVENUPLOAD-591) pom for eclipse osgi

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-591?page=comments#action_50918 ] 

Carlos Sanchez commented on MAVENUPLOAD-591:


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

 pom for eclipse osgi
 

  Key: MAVENUPLOAD-591
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-591
  Project: maven-upload-requests
 Type: Improvement
   Components: Missing POM
 Reporter: Dain Sundstrom
  Attachments: osgi-3.1.1.jar, osgi-3.1.1.pom




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1563) guide to integration test writing

2005-11-14 Thread Matthew Pocock (JIRA)

guide to integration test writing
-

 Key: MNG-1563
 URL: http://jira.codehaus.org/browse/MNG-1563
 Project: Maven 2
Type: Improvement
Reporter: Matthew Pocock


There doesn't seem to be a guide about either testing or integration testing. 
It would be nice to see two guides:

plain vanilla junit tests:
  how to write a simple one that will run in m2
  how to write one that uses the test suite API

integration testing:
  test building e.g. plugin that does code generation
  test resulting application e.g. command-line app or gui
  test deployment e.g. to a test web service container

I have no idea what of this is currently implemented or even possible using 
mvn, but then the documentation isn't giving my wishes any boundaries either...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1415) quoted arguments are not being protected

2005-11-14 Thread Matthew Pocock (JIRA)

[ http://jira.codehaus.org/browse/MNG-1415?page=comments#action_50919 ] 

Matthew Pocock commented on MNG-1415:
-

This seems to definitely be an issue with bash, not anything in maven. However, 
I've not been able to work arround it in bash, so the *nix mvn script is by 
deffinition affected.

 quoted arguments are not being protected
 

  Key: MNG-1415
  URL: http://jira.codehaus.org/browse/MNG-1415
  Project: Maven 2
 Type: Bug
  Environment: Linux
 Reporter: Matthew Pocock
 Priority: Critical
  Fix For: 2.0.1



 Arguments with whitespace protected by quotes are broken up into individual 
 arguments by maven. It's not happening inside the mvn script - I've echoed 
 the generated command-line to check that. This same exception is raised 
 regardless of using...
 -x=y z
 -x=\y z\
 -x='y z'
 -x=y z
 and several other combinations I can't remember.
 Here's an example failure:
 [EMAIL PROTECTED]:~/devel/fluxion/trunk/stack/sql-schema$ ~/m2_home/bin/mvn 
 org.codehaus.mojo:maven-execute-plugin:0.1-SNAPSHOT:resources 
 -Dexecute.class=org.comparagrid.fluxion.sql.schema.OWLFromSchema 
 -Dexecute.args=-baseURI=fish -Xdebug
 + Error stacktraces are turned on.
 [DEBUG] Building Maven user-level plugin registry from: 
 '/home/nmrp3/.m2/plugin-registry.xml'
 [DEBUG] Building Maven global-level plugin registry from: 
 '/home/nmrp3/m2_home/conf/plugin-registry.xml'
 [INFO] Scanning for projects...
 [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for 
 project: org.comparagrid.fluxion:sql-schema:jar:0.1-SNAPSHOT
 [DEBUG] Skipping disabled repository central
 [DEBUG] Skipping disabled repository central
 [DEBUG] maven-execute-plugin: using locally installed snapshot
 [DEBUG] Retrieving parent-POM from the repository for project: 
 null:maven-execute-plugin:maven-plugin:0.1-SNAPSHOT
 [DEBUG] maven-execute-plugin: using locally installed snapshot
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Invalid task 'debug': you must specify a valid lifecycle phase, or a 
 goal in the format plugin:goal or 
 pluginGroupId:pluginArtifactId:pluginVersion:goal
 [INFO] 
 
 [DEBUG] Trace
 org.apache.maven.BuildFailureException: Invalid task 'debug': you must 
 specify a valid lifecycle phase, or a goal in the format plugin:goal or 
 pluginGroupId:pluginArtifactId:pluginVersion:goal
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1351)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:376)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:132)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] 
 
 [INFO] Total time:  1 second
 [INFO] Finished at: Thu Nov 03 23:35:37 GMT 2005
 [INFO] Final Memory: 1M/3M
 [INFO] 
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: svn commit: r332953 - /maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java

2005-11-14 Thread Lukas Theussl


Hi Fabrizio,

AFAICT, namespace awareness should solve our problem.

Try the following:  set factory.setNamespaceAware(true) in 
JaxpMsvBean.java, and insert a default and targetNamespace (the same as 
in maven-project-3.xsd) in pom-strict-3.xsd (pom plugin): with this 
setup you will correctly validate the current pom of the eclipse plugin 
(which includes a xsi:schemaLocation declaration).


The problem is that now, msv seems to hang on poms without a namespace 
declaration (after correctly identifying them as invalid). It actually 
doesn't hang but the parsing gets very slow because it expects a 
namespace declaration for every element, so in practice I always have to 
kill the process. I've been trying to turn namespace awareness off after 
the first violation (the project element), but I didn't succeed.


Maybe somebody on the list knows a bit more about that than I do...

-Lukas


Fabrizio Giustina wrote:

Hi Lukas

On 11/14/05, Lukas Theussl [EMAIL PROTECTED] wrote:


This can only be a temporary solution, I am still hoping that we will be
 able to make validation work with full namespace awareness. If we
succeed, we'll have to undo this commit.



Sure, if we can make MSV validate files properly we will have to
remove this temporary hack... anyway, let make it work now, till we
find a better solution.
Also note that this has nothing to do with namespace awareness, also
if we can make namespaces working it will not solve the problem: the
only solution would be validating project.xml against 2 schemas at the
same time (maven xsd+schema xsd), but AFAIK msv doesn't support that
at all...

fabrizio



-Lukas


[EMAIL PROTECTED] wrote:


Author: fgiust
Date: Sun Nov 13 01:21:00 2005
New Revision: 332953

URL: http://svn.apache.org/viewcvs?rev=332953view=rev
Log:
quick hack for removing wrong error messages for poms with an xsd declaration

Modified:
   maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java

Modified: 
maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java?rev=332953r1=332952r2=332953view=diff
==
--- 
maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java 
(original)
+++ 
maven/maven-1/plugins/trunk/plugin/src/main/org/apache/maven/JaxpMsvBean.java 
Sun Nov 13 01:21:00 2005
@@ -181,6 +181,14 @@

public void error(SAXParseException e) throws SAXException
{
+if (e.getMessage() != null  
e.getMessage().indexOf(xsi:schemaLocation)  -1)
+{
+// unexpected attribute xsi:schemaLocation
+// ignore, this is due to a valid xsd declaration
+// Jaxp ignores additionals namespaces declared in the xml 
file (xmlns:xsi) and it can't validate
+// using multiple schema at once
+return;
+}
errorMessage(e, MSV_ERROR);
setValid(false);
}




-
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]

[jira] Commented: (MNG-1415) quoted arguments are not being protected

2005-11-14 Thread Matthew Pocock (JIRA)

[ http://jira.codehaus.org/browse/MNG-1415?page=comments#action_50922 ] 

Matthew Pocock commented on MNG-1415:
-

Think we have a work-arround:

#!/bin/sh

arg_list=
while [ $1 !=  ] ; do
  arg_list=$arg_list \$1\
  shift
done

echo TestMain $arg_list
exec /bin/sh -c java TestMain $arg_list

This seems to behave as required. The $* and $@ vars loose quotes arround args 
very early. Just incase you care, here's TestMain as well:

public class TestMain
{
public static void main(String[] args)
{
for(String arg : args)
{
System.out.println(arg);
}
}
}


 quoted arguments are not being protected
 

  Key: MNG-1415
  URL: http://jira.codehaus.org/browse/MNG-1415
  Project: Maven 2
 Type: Bug
  Environment: Linux
 Reporter: Matthew Pocock
 Priority: Critical
  Fix For: 2.0.1



 Arguments with whitespace protected by quotes are broken up into individual 
 arguments by maven. It's not happening inside the mvn script - I've echoed 
 the generated command-line to check that. This same exception is raised 
 regardless of using...
 -x=y z
 -x=\y z\
 -x='y z'
 -x=y z
 and several other combinations I can't remember.
 Here's an example failure:
 [EMAIL PROTECTED]:~/devel/fluxion/trunk/stack/sql-schema$ ~/m2_home/bin/mvn 
 org.codehaus.mojo:maven-execute-plugin:0.1-SNAPSHOT:resources 
 -Dexecute.class=org.comparagrid.fluxion.sql.schema.OWLFromSchema 
 -Dexecute.args=-baseURI=fish -Xdebug
 + Error stacktraces are turned on.
 [DEBUG] Building Maven user-level plugin registry from: 
 '/home/nmrp3/.m2/plugin-registry.xml'
 [DEBUG] Building Maven global-level plugin registry from: 
 '/home/nmrp3/m2_home/conf/plugin-registry.xml'
 [INFO] Scanning for projects...
 [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for 
 project: org.comparagrid.fluxion:sql-schema:jar:0.1-SNAPSHOT
 [DEBUG] Skipping disabled repository central
 [DEBUG] Skipping disabled repository central
 [DEBUG] maven-execute-plugin: using locally installed snapshot
 [DEBUG] Retrieving parent-POM from the repository for project: 
 null:maven-execute-plugin:maven-plugin:0.1-SNAPSHOT
 [DEBUG] maven-execute-plugin: using locally installed snapshot
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Invalid task 'debug': you must specify a valid lifecycle phase, or a 
 goal in the format plugin:goal or 
 pluginGroupId:pluginArtifactId:pluginVersion:goal
 [INFO] 
 
 [DEBUG] Trace
 org.apache.maven.BuildFailureException: Invalid task 'debug': you must 
 specify a valid lifecycle phase, or a goal in the format plugin:goal or 
 pluginGroupId:pluginArtifactId:pluginVersion:goal
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1351)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:376)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:132)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] 
 
 [INFO] Total time:  1 second
 [INFO] Finished at: Thu Nov 03 23:35:37 GMT 2005
 [INFO] Final Memory: 1M/3M
 [INFO] 
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

EJB3 Pluggin and .par MNG-699 (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingpar)

2005-11-14 Thread cameron clarke

ejb3 and par packaging types.
when I attempt to build a multi-module I get the following error:

[INFO] Building Unnamed - uk.co.abc:abc-data-access:par:1.0-SNAPSHOT
[INFO] task-segment: [compile]
[INFO]

[ERROR] Nonexistent component:
org.apache.maven.lifecycle.mapping.LifecycleMappingpar
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Cannot find lifecycle mapping for packaging: 'par'.
Component descriptor cannot be found in the component repository:
org.apache.maven.life
cycle.mapping.LifecycleMappingpar.
[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot find
lifecycle mapping f
or packaging: 'par'.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
(DefaultLifecycleExecutor.java:945)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackagin
g(DefaultLifecycleExecutor.java:879)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappin
gs(DefaultLifecycleExecutor.java:862)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifec
ycleExecutor.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFail
ures(DefaultLifecycleExecutor.java:301)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments
(Defa
ultLifecycleExecutor.java:268)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycle
Executor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:39
)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor cannot be found in the component repository:
org.apache.maven.lif
ecycle.mapping.LifecycleMappingpar.
at org.codehaus.plexus.DefaultPlexusContainer.lookup(
DefaultPlexusContainer.jav
a:319)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(
DefaultPlexusContainer.jav
a:436)
at org.apache.maven.execution.MavenSession.lookup(MavenSession.java:120)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
(DefaultLifecycleExecutor.java:938)
... 17 more
[INFO]

[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Sep 28 00:05:24 BST 2005
[INFO] Final Memory: 2M/8M
[INFO] ---

I read MNG-699, downloaded JarMojo.java-patch.zip and
maven2-ejb3-support.zip successfully compiled and installed these pluggins
into a local repository but if I try to build my own simple multi-module
project or the one included in http://www.bzdyl.net/demo-app.zip (thks to
Piotrek Bzdyl and all you folks working on m2) I get a lifecycle error ! Pls
help :-) thks

Re: EJB3 Pluggin and .par MNG-699 (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingpar)

2005-11-14 Thread cameron clarke

:

 ejb3 and par packaging types.
 when I attempt to build a multi-module I get the following error:

 [INFO] Building Unnamed - uk.co.abc:abc-data-access:par:1.0-SNAPSHOT
 [INFO] task-segment: [compile]
 [INFO]
 
 [ERROR] Nonexistent component:
 org.apache.maven.lifecycle.mapping.LifecycleMappingpar
 [INFO]
 

 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Cannot find lifecycle mapping for packaging: 'par'.
 Component descriptor cannot be found in the component repository:
 org.apache.maven.life
 cycle.mapping.LifecycleMappingpar.
 [INFO]
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Cannot find
 lifecycle mapping f
 or packaging: 'par'.
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
 (DefaultLifecycleExecutor.java:945)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackagin
 g(DefaultLifecycleExecutor.java:879)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappin
 gs(DefaultLifecycleExecutor.java:862)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifec
 ycleExecutor.java:447)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFail
 ures(DefaultLifecycleExecutor.java:301)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Defa
 ultLifecycleExecutor.java:268)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
 (DefaultLifecycle
 Executor.java:137)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(
 NativeMethodAccessorImpl.java:39
 )
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl
 .java:25)
 at java.lang.reflect.Method.invoke (Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by:
 org.codehaus.plexus.component.repository.exception.ComponentLookupException
 :
 Component descriptor cannot be found in the component repository:
 org.apache.maven.lif
 ecycle.mapping.LifecycleMappingpar.
 at org.codehaus.plexus.DefaultPlexusContainer.lookup(
 DefaultPlexusContainer.jav
 a:319)
 at org.codehaus.plexus.DefaultPlexusContainer.lookup (
 DefaultPlexusContainer.jav
 a:436)
 at org.apache.maven.execution.MavenSession.lookup(MavenSession.java:120)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
 (DefaultLifecycleExecutor.java :938)
 ... 17 more
 [INFO]
 
 [INFO] Total time: 2 seconds
 [INFO] Finished at: Wed Sep 28 00:05:24 BST 2005
 [INFO] Final Memory: 2M/8M
 [INFO] ---

 I read MNG-699, downloaded JarMojo.java-patch.zip and
 maven2-ejb3-support.zip successfully compiled and installed these pluggins
 into a local repository but if I try to build my own simple multi-module
 project or the one included in http://www.bzdyl.net/demo-app.zip (thks to
 Piotrek Bzdyl and all you folks working on m2) I get a lifecycle error ! Pls
 help :-) thks

Re: EJB3 Pluggin and .par MNG-699 (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingpar)

2005-11-14 Thread cameron clarke

:-( oh my understanding of the commentary in
http://jira.codehaus.org/secure/Dashboard.jspa?os_destination=%2Fbrowse%2FMNG-699

and bleeding edge build from svn source with the addition of
JarMojo.java-patch.zip and maven2-ejb3-support.zip enabled this
functionality although it's not there out of the box with version 2.


On 14/11/05, cameron clarke [EMAIL PROTECTED] wrote:

 ejb3 and par packaging types.
 when I attempt to build a multi-module I get the following error:

 [INFO] Building Unnamed - uk.co.abc:abc-data-access:par:1.0-SNAPSHOT
 [INFO] task-segment: [compile]
 [INFO]
 
 [ERROR] Nonexistent component:
 org.apache.maven.lifecycle.mapping.LifecycleMappingpar
 [INFO]
 

 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Cannot find lifecycle mapping for packaging: 'par'.
 Component descriptor cannot be found in the component repository:
 org.apache.maven.life
 cycle.mapping.LifecycleMappingpar.
 [INFO]
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Cannot find
 lifecycle mapping f
 or packaging: 'par'.
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
 (DefaultLifecycleExecutor.java:945)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackagin
 g(DefaultLifecycleExecutor.java:879)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappin
 gs(DefaultLifecycleExecutor.java:862)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifec
 ycleExecutor.java:447)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFail
 ures(DefaultLifecycleExecutor.java:301)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Defa
 ultLifecycleExecutor.java:268)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
 (DefaultLifecycle
 Executor.java:137)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(
 NativeMethodAccessorImpl.java:39
 )
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl
 .java:25)
 at java.lang.reflect.Method.invoke (Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by:
 org.codehaus.plexus.component.repository.exception.ComponentLookupException
 :
 Component descriptor cannot be found in the component repository:
 org.apache.maven.lif
 ecycle.mapping.LifecycleMappingpar.
 at org.codehaus.plexus.DefaultPlexusContainer.lookup(
 DefaultPlexusContainer.jav
 a:319)
 at org.codehaus.plexus.DefaultPlexusContainer.lookup (
 DefaultPlexusContainer.jav
 a:436)
 at org.apache.maven.execution.MavenSession.lookup(MavenSession.java:120)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
 (DefaultLifecycleExecutor.java :938)
 ... 17 more
 [INFO]
 
 [INFO] Total time: 2 seconds
 [INFO] Finished at: Wed Sep 28 00:05:24 BST 2005
 [INFO] Final Memory: 2M/8M
 [INFO] ---

 I read MNG-699, downloaded JarMojo.java-patch.zip and
 maven2-ejb3-support.zip successfully compiled and installed these pluggins
 into a local repository but if I try to build my own simple multi-module
 project or the one included in http://www.bzdyl.net/demo-app.zip (thks to
 Piotrek Bzdyl and all you folks working on m2) I get a lifecycle error ! Pls
 help :-) thks

Re: svn commit: r344256 - in /maven/components/trunk/maven-plugins: maven-assembly-plugin/pom.xml pom.xml

2005-11-14 Thread Brett Porter

If you are referencing the new API, then this will be 2.0.1. Is that 
really what you want - ie is there no way around it?


If not, then you need to add the prerequisites tag or there'll be some 
unhappy 2.0 users when it gets released.


- Brett

[EMAIL PROTECTED] wrote:

Author: jdcasey
Date: Mon Nov 14 14:52:06 2005
New Revision: 344256

URL: http://svn.apache.org/viewcvs?rev=344256view=rev
Log:
Bumping Plugin-Parent version to 2.0.1-SNAPSHOT to reference API changes to 
MavenProjectHelper, and changing maven-assembly-plugin's pom to reference that 
new parent POM.

Modified:
maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml
maven/components/trunk/maven-plugins/pom.xml

Modified: maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml
URL: 
http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml?rev=344256r1=344255r2=344256view=diff
==
--- maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml 
(original)
+++ maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml Mon Nov 
14 14:52:06 2005
@@ -2,7 +2,7 @@
   parent
 artifactIdmaven-plugin-parent/artifactId
 groupIdorg.apache.maven.plugins/groupId
-version2.0/version
+version2.0.1-SNAPSHOT/version
   /parent
   modelVersion4.0.0/modelVersion
   artifactIdmaven-assembly-plugin/artifactId

Modified: maven/components/trunk/maven-plugins/pom.xml
URL: 
http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/pom.xml?rev=344256r1=344255r2=344256view=diff
==
--- maven/components/trunk/maven-plugins/pom.xml (original)
+++ maven/components/trunk/maven-plugins/pom.xml Mon Nov 14 14:52:06 2005
@@ -150,7 +150,7 @@
   dependency
 groupIdorg.apache.maven/groupId
 artifactIdmaven-project/artifactId
-version2.0/version
+version2.0.1-SNAPSHOT/version
   /dependency
   dependency
 groupIdorg.codehaus.plexus/groupId




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

[jira] Closed: (MNG-1424) Specifying version for a plugin in pluginManagement does not force Maven to use this version

2005-11-14 Thread John Casey (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1424?page=all ]
 
John Casey closed MNG-1424:
---

Resolution: Fixed

Changed the ordering of:

* verify plugin
* add plugin to project

to:

* add plugin to project
* verify plugin

This is important, since it allows pluginManagment to take effect and specify a 
plugin version before the plugin version is resolved using repository metadata.

 Specifying version for a plugin in pluginManagement does not force Maven 
 to use this version
 

  Key: MNG-1424
  URL: http://jira.codehaus.org/browse/MNG-1424
  Project: Maven 2
 Type: Bug
   Components: maven-core
 Versions: 2.0
  Environment: Win2k, M2.0, Java 1.4.2
 Reporter: Fabrice BELLINGARD
 Assignee: John Casey
 Priority: Critical
  Fix For: 2.0.1



 I had the problem when I wanted to use the final release of the surefire 
 plugin. I put the following in my root POM:
   build
 ...
 pluginManagement
   plugins
 ...
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-surefire-plugin/artifactId
   version2.0/version
 /plugin
   /plugins
 /pluginManagement
   /build
 , but Maven still used version 2.0-beta-4 (and therefore did not try to 
 download version 2.0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MAVENUPLOAD-592) Apache Jakarta BSF

2005-11-14 Thread Eric Redmond (JIRA)

Apache Jakarta BSF
--

 Key: MAVENUPLOAD-592
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-592
 Project: maven-upload-requests
Type: Task
Reporter: Eric Redmond


A bundle of the Apache BSF code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1324) System dependencies path non correctly added to eclipse buildpath

2005-11-14 Thread Giorgio Gallo (JIRA)

[ http://jira.codehaus.org/browse/MNG-1324?page=comments#action_50933 ] 

Giorgio Gallo commented on MNG-1324:


I updated my svn snapshot and run m2-bootstrap-all, I also deleted the eclipse 
plugin from my local repository and re-run m2-bootstrap-all...

You saying I should have mvn install from the plugin project dir? Doesn't it 
all get built and deployed to my local repo running m2-bootstrap-all?

TIA

 System dependencies path non correctly added to eclipse buildpath
 ---

  Key: MNG-1324
  URL: http://jira.codehaus.org/browse/MNG-1324
  Project: Maven 2
 Type: Bug
   Components: maven-eclipse-plugin
  Environment: SVN snapshot a few days old
 Reporter: Giorgio Gallo
 Assignee: fabrizio giustina



 Eclipse plugin handles systemPath as if it was a path into the repository, 
 transforming a dependency like this one:
 dependency
...
   scopesystem/scope
   systemPath${basebir}/lib/myjdbcdriver.jar/systemPath
 /dependency
 into 
 M2_REPO/pom.xml location dir/lib/myjdbcdriver.jar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[maven2 build - FAILED - update] Tue Nov 15 00:00:00 GMT 2005