Re: Using multiple source directories to produce on artefact

2006-01-12 Thread Chad Brandon
I completely agree.  If anything, generated source will become more and 
more common as time goes on, the pom really should support multiple 
sourceDirectory elements (its much cleaner and clearer than having to 
use a plugin for it).


Jason Dillon wrote:
This functionality should be added to the core pom IMO. 


--jason



 


-Original Message-
From: dan tran
To: Maven Users List
Sent: Thu Jan 12 00:13:03 2006
Subject: Re: Using multiple source directories to produce on artefact

oh mine this question is getting popular ;-)
check out

  build-helper-maven-plugin at http://mojo.codehaus.org

maven 2 books are comming out first quater of 2006, i heard

;-)



On 1/12/06, Andreas Zschorn [EMAIL PROTECTED] wrote:
  

Hi,
I have a question regarding maven 2 and the use of multiple source
directories.
I want to migrate from ant to maven and have a problem with compiling 2
source directories to one output directory.
Directory structure is the following.
./src/ -- with the main source files
./gen-src/ -- with generated ejb-source files from xdoclet.
./target/ -- target of compiled files

In the build section I can only state on source-directory.
The documentation
under
http://maven.apache.org/guides/mini/guide-using-one-source-directory.html
state there is no problem in using several source directories but they
forgot to say how.
Quote:
There should be no limitations in this approach. Maven natively supports
multiple source directories for the purposes of generated sources.:

I already tried the approach to include the directories in the
configuration
section. The result was, that maven always reported that no files have
changed.

plugins
 plugin
   artifactIdmaven-compiler-plugin/artifactId
   configuration
 includes
   include${basedir}/src/include
   include${basedir}/gen-src/include
/includes
/configuration
  /plugin
/plugins


I already searched for a solution but the most answers were to change the
directory layout which is in my case not possible.
I really appreciate your help.
Another question regarding documentation. Perhaps I was to stupid to find
it, but is there any good documentation, or book out there for maven 2.
The
current docu on the website does not have the deep I would expect, for
example a good plugin howto or an overview which xml-configurations tags
are
available for a plugin.

Andreas


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




N�zfj|��֜�g���azފ{^�ם~���z���v���笝��v�z)ڝٚ��'��\��+��u�ݢ�(��z{bjX�~��jب���z���X�i�^��*.jaz)�zw^v�����zf��*.j��z���z-��u��v+,zh�jب�جب��ܢ���
��zfj|��֜�g���az���+,\���bn+^t���Z���q�y�a��(�k��ƭ뢺ey���b+azǧu�ڷ�y��v�M(���n�w�j)Z��,�fk拜��jwiz�'^��^���(��\֧��)ʇڟ'�j)Z�֧ʚ��.��^��N��*.~���ܢ�^��bon==



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



Re: Using multiple source directories to produce on artefact

2006-01-12 Thread Chad Brandon

dan tran wrote:
Yes, build-helper is there for legacy build.  However, if a build is 
completely

mavenized, I see no need to have more than one primary source trees and
adding a generated source tree the project , shoud be done by the 
generated source plugin

itself.
Well here's why it should be supported. I develop all my applications 
using AndroMDA (with a maven2 build, we previously used maven1).  During 
the build, we generate sources from one mda module (this module 
contains the model of the application) into all other modules (each 
project has about 5 to 6 submodules).


Generating source from the same model for each module wouldn't be time 
efficient (among other things), so its not possible to have the plugin 
add the source directory to each module because the andromda plugin 
isn't run for each module..  So in this case it makes sense to allow the 
pom.xml to have the multiple source directories specified.  For now I 
created another simple plugin which adds the generated source to each 
module, however it would be much easier and clearer if multple source 
directories could be specified in the pom.
 
For now, i dont see a way out until at least 2.1, if it supports 
multiple main source trees ;-)
That's my point, it doesn't work now, but it *should* support multiple 
source directories,.
 
-D
 
On 1/12/06, *Chad Brandon* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


I completely agree.  If anything, generated source will become
more and
more common as time goes on, the pom really should support multiple
sourceDirectory elements (its much cleaner and clearer than having to
use a plugin for it).

Jason Dillon wrote:
 This functionality should be added to the core pom IMO.

 --jason





 -Original Message-
 From: dan tran
 To: Maven Users List
 Sent: Thu Jan 12 00:13:03 2006
 Subject: Re: Using multiple source directories to produce on
artefact

 oh mine this question is getting popular ;-)
 check out

   build-helper-maven-plugin at http://mojo.codehaus.org

 maven 2 books are comming out first quater of 2006, i heard

 ;-)



 On 1/12/06, Andreas Zschorn [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

 Hi,
 I have a question regarding maven 2 and the use of multiple source
 directories.
 I want to migrate from ant to maven and have a problem with
compiling 2
 source directories to one output directory.
 Directory structure is the following.
 ./src/ -- with the main source files
 ./gen-src/ -- with generated ejb-source files from xdoclet.
 ./target/ -- target of compiled files

 In the build section I can only state on source-directory.
 The documentation
 under

http://maven.apache.org/guides/mini/guide-using-one-source-directory.html
 state there is no problem in using several source directories
but they
 forgot to say how.
 Quote:
 There should be no limitations in this approach. Maven
natively supports
 multiple source directories for the purposes of generated
sources.:

 I already tried the approach to include the directories in the
 configuration
 section. The result was, that maven always reported that no
files have
 changed.

 plugins
  plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
  includes
include${basedir}/src/include
include${basedir}/gen-src/include
 /includes
 /configuration
   /plugin
 /plugins


 I already searched for a solution but the most answers were to
change the
 directory layout which is in my case not possible.
 I really appreciate your help.
 Another question regarding documentation. Perhaps I was to
stupid to find
 it, but is there any good documentation, or book out there for
maven 2.
 The
 current docu on the website does not have the deep I would
expect, for
 example a good plugin howto or an overview which
xml-configurations tags
 are
 available for a plugin.

 Andreas



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



 N�zfj|��֜�g���azފ{^�ם~���z���v���笝��v�z)ڝٚ��'��
\��+��

u�ݢ�(��z{bjX�~��jب���z���X�i�^��*.jaz)�zw^v�����zf��*.j��z���z-��u��v+,zh�jب�جب��ܢ���


��zfj|��֜�g���az���+,\���bn+^t���Z���q�y�a��(�k��ƭ
뢺ey���b

+azǧu�ڷ�y��v�M(���n�w�j)Z��,�fk拜��jwiz�'^��^���(��\֧��)ʇڟ'�j)Z�֧ʚ��.��^��N��*.~���ܢ�^��bon

Re: [m2] finalName ${version} being picked up from System properties?

2006-01-03 Thread Chad Brandon
I guess this was missed when I sent a couple weeks ago, does anyone have 
any thoughts on this?  Should I file a JIRA issue?


Thanks,

Chad


Chad Brandon wrote:

Hi,

I'm using maven 2.0.1 for AndroMDA's build (its a fairly large 
multiproject build).


It appears that if I have a version property in my System 
properties, it sometimes gets picked up and used for the version of my 
project when creating the final name (during pom interpolation I'm 
assuming).  I  then get an unresolved dependency error because of 
course the version is not the one defined as the version in my 
pom.xml.  Is this a know issue and shouldn't information in the pom 
take precedence over System properties?  I'm assuming this call in 
DefaultMavenProjectBuilder is the culprit (since this context is then 
passed to the RegexBasedModelInterpolator for use in project 
interpolation) :


   // TODO: Clean this up...we're using this to 'jump' the 
interpolation step for model properties not expressed in XML.

   //  [BP] - Can this above comment be explained?
   // We don't need all the project methods that are added over 
those in the model, but we do need basedir

   Map context = new HashMap( System.getProperties() );

I also have a similar issue with ${basedir}, the value that sometimes 
gets picked up, is the value for the previous project (which of course 
breaks the build), I resorted to using ${pom.basedir} which seems to 
fix things.  I've tried using ${pom.version} instead of ${version} 
to fix my issue with the wrong version, however it doesn't help 
because it looks like the DefaultModelInheritanceAssembler sets the 
final name as ${artifactId}-${version} (I put some debug in that 
code to see what was being set).  For now I've put a hack in one of my 
m2 plugins to remove the version System property (not sure where its 
coming from really) so that I can get past this, but of course this 
isn't the best solution :)


Thanks,

Chad




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



[m2] finalName ${version} being picked up from System properties?

2005-12-17 Thread Chad Brandon

Hi,

I'm using maven 2.0.1 for AndroMDA's build (its a fairly large 
multiproject build).


It appears that if I have a version property in my System properties, 
it sometimes gets picked up and used for the version of my project when 
creating the final name (during pom interpolation I'm assuming).  I  
then get an unresolved dependency error because of course the version is 
not the one defined as the version in my pom.xml.  Is this a know issue 
and shouldn't information in the pom take precedence over System 
properties?  I'm assuming this call in DefaultMavenProjectBuilder is the 
culprit (since this context is then passed to the 
RegexBasedModelInterpolator for use in project interpolation) :


   // TODO: Clean this up...we're using this to 'jump' the 
interpolation step for model properties not expressed in XML.

   //  [BP] - Can this above comment be explained?
   // We don't need all the project methods that are added over 
those in the model, but we do need basedir

   Map context = new HashMap( System.getProperties() );

I also have a similar issue with ${basedir}, the value that sometimes 
gets picked up, is the value for the previous project (which of course 
breaks the build), I resorted to using ${pom.basedir} which seems to fix 
things.  I've tried using ${pom.version} instead of ${version} to 
fix my issue with the wrong version, however it doesn't help because it 
looks like the DefaultModelInheritanceAssembler sets the final name as 
${artifactId}-${version} (I put some debug in that code to see what 
was being set).  For now I've put a hack in one of my m2 plugins to 
remove the version System property (not sure where its coming from 
really) so that I can get past this, but of course this isn't the best 
solution :)


Thanks,

Chad

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



Re: [m2] clean plugin needs dependant plugins?

2005-12-16 Thread Chad Brandon

Thanks Edwin,

Yeah it appears that any plugins that are in my pom.xml need to be 
downloaded before clean can work, otherwise it fails with unsatisfied 
dependencies (for example, I can't clean our distribution until the rest 
of the plugins of our build are installed).  I'll reopen the issue.


Chad

Edwin Punzalan wrote:



According to jira, this has been fixed in 2.0-alpha-3, if you're sure 
that its not working again, you can reopen 
http://jira.codehaus.org/browse/MNG-489



Chad Brandon wrote:


Hi,

Is there any reason why the clean plugin needs to have dependent 
plugins downloaded before it can do its thing?  It would be nice if 
it ignored all dependencies (including plugins).


Thanks,

Chad

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



[m2] clean plugin needs dependant plugins?

2005-12-15 Thread Chad Brandon

Hi,

Is there any reason why the clean plugin needs to have dependent plugins 
downloaded before it can do its thing?  It would be nice if it ignored 
all dependencies (including plugins).


Thanks,

Chad

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



Re: [m2] What happened to Spring - now it includes all its dependencies

2005-11-21 Thread Chad Brandon

Matt Raible wrote:

On 11/19/05, Carlos Sanchez [EMAIL PROTECTED] wrote:
  

Hi all,

I'll try to put a bit of light at this.

- I've put the spring jars in the repo so you guys can use them in m1 and m2
- At first there were no poms because it takes me some time to have them ready
- I'm working on the poms, I've put the ones i was using first, but
there was no optional dependencies though, so now I'm pretty close to
have them ready with the optional stuff.

About spring full jar, I don't suggest you to use it depends in a lot
of stuff, in fact I don't know if I'll make a pom for it.



IMO, there should be a POM for Spring - mainly because I believe that
there's a lot of folks just using spring.jar rather than the
individual JARs.
  
I completely agree with this, why would I want to include 5 dependencies 
if all I need to include is one?
  

To make
transitive dependencies work correctly you should add only what you
need.



Sure, but shouldn't ease of use be a concern as well?
  
  

 I believe that if you depend on

spring-support
spring-orm
spring-hibernate
spring-remoting
spring-core

you get the same things as in spring jar.



So now I have to have 25 lines of XML in my pom.xml - instead of 5 for
spring.jar?  Ugh.
  
I couldn't agree more.  I think all these emails about transitive 
dependency issues proves there really should be an option to turn them 
off for a given dependency.  Transitive dependencies are a great idea, 
and work in a lot of cases, but a lot of times you just want to turn 
them off and specify the dependencies you need.

Matt

  

About the groupId you should use org.springframework. Just
springframework will work but it's just a relocation to
org.springframework.

If you wanna know the status of this you can subscribe to the jira
issues MEV-108 and MEV-133.

Sorry for the inconvenience.

On 11/19/05, Matt Raible [EMAIL PROTECTED] wrote:


Stephen,

I was using groupId=springframework, but switched to
org.springframework when I tried to upgrade 1.2.6 today.  I was hoping
to revert back to springframework and have all my problems solved -
but no dice.

The easiest thing for me to do seems to be to upload my own POM and
JAR to my own repository.  This is likely what I'll do for many
dependencies since the ibiblio repository seems to change dependencies
often - and just when you think you've got a library cleaned up -
something like this happens.

Matt

On 11/19/05, Stephen Duncan [EMAIL PROTECTED] wrote:
  

Matt,

I've been using a groupId of springframework, instead of
org.springframework.  Also I've started depending on the individual
spring modules, instead of the full jar.  Same issue though: a bunch
of exclusions.  Usually a new version (such as Spring 1.2.6 right now)
has no dependencies at first, but then a week or so later they add all
the dependencies in.

Here's a couple of the Maven Evangelism tickets open about the issue:

http://jira.codehaus.org/browse/MEV-108
http://jira.codehaus.org/browse/MEV-133

Here's the current dependencies with exclusions I have (in a global
parent POM in dependencyManagement).  Note that parts are particular
to me, because I'm using Hibernate 2 and not 3, for instance.  Still,
it's a start:

dependency
groupIdspringframework/groupId
artifactIdspring-aop/artifactId
version1.2.5/version
scopecompile/scope
exclusions
exclusion

groupIdcommons-attributes/groupId

artifactIdcommons-attributes-compiler/artifactId
/exclusion
exclusion

groupIdcommons-attributes/groupId

artifactIdcommons-attributes-api/artifactId
/exclusion
exclusion
groupIdaopalliance/groupId

artifactIdaopalliance/artifactId
/exclusion
exclusion
groupIdcommons-pool/groupId

artifactIdcommons-pool/artifactId
/exclusion
exclusion
groupIdoro/groupId
artifactIdoro/artifactId
/exclusion
exclusion
groupIdcom.jamonapi/groupId

Re: [m2] Windows input line too long

2005-11-09 Thread Chad Brandon

Michael,

The same thing happened to me; what fixed it for me was adding junit as 
a dependency even though I had no tests (I would think that surefire 
would handle it if it doesn't have the dependency, but it seems to not 
be the case).  Its strange; the error only seems to happen when some 
dependencies are in my pom.xml, but doesn't happen with other 
dependencies (for example it started occuring when I added 
commons-beanutils, but went away when I removed it), but with the junit 
dependency it never happens.


Chad

Michael McCrann wrote:

Brett,

I have rebuilt the maven-error-diagnostic.jar and installed it into
M2_HOME/lib. This is the output now:

[ERROR] BUILD ERROR
[INFO]


[INFO] Error executing surefire

tried to access method junit.framework.TestCase.init()V from class
org.codehaus.surefire.battery.assertion.BatteryAsse
rt
[INFO]


[INFO] For more information, run Maven with the -e switch
[INFO]

 


Michael
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 10 November 2005 1:28 PM

To: Maven Users List
Subject: Re: [m2] Windows input line too long

Unfortunately that is the same error. The only solution I can propose at
the moment is to build a replacement for maven-error-diagnostics from
SVN, and install it in $M2_HOME/lib.

- Brett

On 11/10/05, Michael McCrann [EMAIL PROTECTED] wrote:
  

Brett,

Here is the full output:




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



NOTICE
This e-mail and any attachments are confidential and may contain copyright 
material of Macquarie Bank or third parties. If you are not the intended 
recipient of this email you should not read, print, re-transmit, store or act 
in reliance on this e-mail or any attachments, and should destroy all copies of 
them. Macquarie Bank does not guarantee the integrity of any emails or any 
attached files. The views or opinions expressed are the author's own and may 
not reflect the views or opinions of Macquarie Bank.


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



[m2] lifecycle phase ordering?

2005-10-25 Thread Chad Brandon
Hello,

I'm currently writing am m2 plugin for AndroMDA
(http://www.andromda.org), at the moment our build is
based on m1, but I'll be converting that to m2
shortly.  Anyway I have a question: how would I force
the process-resources phase to be called before the
generate-sources phase within my plugin?  I need the
process-resources phase to happen before
generate-sources because we have a configuration file
(andromda.xml) that needs to have resource filtering
occur before its passed to the AndroMDA engine that
processes the model(s).

Thanks in advance,

Chad

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



Re: HSQLDB locking when using tomcat plugin

2005-05-26 Thread Chad Brandon

Sebastien Arbogast wrote:


2005/5/26, Siegfried Goeschl [EMAIL PROTECTED]:
 

I'm also not a Spring expert - actually I never used it - but 


+) you might be able to derive from
org.apache.commons.dbcp.BasicDataSource and overwrite the
close() method 
   



I like this one but I can't figure out how I can access my database
from there to send the SQL instruction (I'm not an expert with dbcp at
all).

 


+) add a custom HSQLDB shutdown bean for Spring
+) or write a little servlet which does the magic
   



Why not but haven't a clue about how to do that.

 


Would it be a good approach to use an AOP approach :
- you create an aspect that will add behaviour to the close() method of
your dataSource bean.
   



Technically that would be the most elegant solution even if I've never
used AOP. But there is another problem here : all my Spring files are
automatically generated through a MDA process (AndroMDA) and I'm quite
sure I can't integrate AOP in the process.
 

You can easily use AOP with MDA, I use aspectj with my AndroMDA apps all 
the time, because your system is generated does not mean you can't 
introduce aspects into the process.



I think the most pragmatic solution right now would be to customize
the close method of my BasicDataSource. But the question is : can I
access my JDBC connection from there to issue my SHUTDOWN ?

(Why did they introduce that SHUTDOWN thing anyway ?!!! grr...)

 




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



Re: Building on Unix AND Windows

2005-05-03 Thread Chad Brandon
Jamie Bisotti wrote:
We have setup CruiseControl, which is using Maven to build, on a Linux
box, but most (all) developers are currently using Maven on Windows. 
We have a parent project, containing the common project.xml, and
several child project's, containing project.xml's that extend the
parent project.xml.  With me so far?

The child project.xml files have the following:
...
   extend..\project.xml/extend
...
That works fine on Windows, but fails on Linux (semi understandable). 
I haven't had a chance to try it yet, but I'm guessing switching the
slash will get it to work on Linux, but fail on Windows.  How can we
get it to work regardless of OS?
 

The forward slash will work fine on both operating systems.
Thanks!
 


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


RE: ClassNotFoundException with maven 1.0.2

2004-12-14 Thread Chad Brandon
Its probably because of the fact that ibiblio was down and incorrect or
bogus jars were being downloaded.  I would say try removing your repository
and build again since ibiblio seems to be up now. 

-Original Message-
From: Chris Huisman [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 14, 2004 2:43 PM
To: Maven Users List
Subject: Re: ClassNotFoundException with maven 1.0.2

I am experiencing the same problem.

c.

Kris Nuttycombe wrote:

 Hi, all,

 Maven is giving me some headaches today. I just downloaded version 
 1.0.2 and now both 1.0.2 and 1.0-rc3 (what I was using before) crash 
 with the following exception:

 __  __
 |  \/  |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
 |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

 Could not find the class: 
 org.apache.commons.jelly.tags.antlr.AntlrTagLibrary
 java.lang.ClassNotFoundException: 
 org.apache.commons.jelly.tags.antlr.AntlrTagLibrary
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at 
 org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:425)


at 

org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.jav
a:171) 

at 
 org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:415)


at 

org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.jav
a:171) 

at 
 org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033)
at 
 org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647)


at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
at 

org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(Unknown 
 Source)
at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown

 Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.jelly.parser.XMLParser.parse(XMLParser.java:299)
at 
 org.apache.maven.jelly.JellyUtils.compileScript(JellyUtils.java:222)
at 
 org.apache.maven.jelly.JellyUtils.compileScript(JellyUtils.java:180)
at 
 org.apache.maven.jelly.JellyUtils.compileScript(JellyUtils.java:146)
at 
 org.apache.maven.plugin.PluginManager.loadScript(PluginManager.java:1109)
at 
 org.apache.maven.plugin.PluginManager.runScript(PluginManager.java:1135)
at 

org.apache.maven.plugin.PluginManager.initialiseHousingPluginContext(PluginM
anager.java:770) 

at 

org.apache.maven.plugin.PluginManager.prepAttainGoal(PluginManager.java:725)


at 
 org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:656)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
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 com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
 Underlying exception: java.lang.ClassNotFoundException: antlr
 Could not create taglib or URI: jelly:antlr tag name: antlr
 java.lang.ClassNotFoundException: antlr
at 

org.apache.commons.jelly.parser.XMLParser.createSAXException(XMLParser.java:
1234) 

at 
 org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1044)
at 
 org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647)


at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
 Source)
at 

org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(Unknown 
 Source)
...

 I've attached the output of maven --info. Any help would be greatly 
 appreciated.

 Interestingly enough, the behavior is different when I run maven 
 through mevenide for NetBeans on the same project - in that case, the 
 exception I get is this:

 Could not find the class: 
 org.apache.commons.jelly.tags.velocity.VelocityTagLibrary
 java.lang.ClassNotFoundException: 
 org.apache.commons.jelly.tags.velocity.VelocityTagLibrary
at 

0K jars being downloaded

2004-12-14 Thread Chad Brandon
Something strange is going on, http://www.ibiblio.org/maven is currently
down and if we have this in our remote repository list, SNAPSHOTs (from
other repositories) are being downloaded as 0 length files, is this a known
bug? 

 

Chad



RE: 1.0.2 startup slow

2004-12-08 Thread Chad Brandon
Yep!  That was it...I just ran it this morning and all was fine :)  I missed
the PM for the 10 when I looked at the timestamp yesterday of the plugins
within maven-1.0.2/plugins. Sorry about that, that would have answered the
question yesterday when you asked me to compare the timestamps!

Chad  

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 08, 2004 2:10 AM
To: Maven Users List
Subject: Re: 1.0.2 startup slow

How funny! Being in +11 at the moment, that certainly made it as bad
as it could be.

Thanks Leif!

Ok, I'll either set my clock back or build with significant lead time
in future...

Chad - can you confim it was the same for you?

Thanks,
Brett


On Wed, 08 Dec 2004 01:01:17 -0700, Leif Nelson [EMAIL PROTECTED] wrote:
 I think I figured out what the problem is.  When I did what you suggest
 (checkout the tagged version of maven, add logging, build and test) it
 works fine. 2 seconds on windows xp.  So, on a hunch, I looked in the
 .zip file for maven-1.0.2.zip.  And guess what, the date/time stamp of
 all the files in there is for 12/7/2004 at 10:13 PM.  Well, us early
 adopters were running 1.0.2 before 10:13 PM on 12/7/04!  The code in
 PluginManager.unpackPlugin() compares the date/time of the plugin.jar
 file with the date/time of the plugin cache dir.  And of course, every
 time, it found that the jar was newer because it had a future date/time
 stamp, causing a cache invalidation for every invocation.
 
 So, for anyone who had this problem on 12/7, it will magically fix
 itself when their local time ticks past 10:13 PM.  So, is the time wrong
 on the box that created the maven-1.0.2.zip file?  Or, are zip files
 dumb enough to not contain a GMT offset?  Who knows.
 
 Anyway, I'd bet the problem goes away now.  I re-unzipped the
 distribution zip file, and since it's 12/8/04 12:58AM my time now, it
 takes 2 seconds to run maven on my windows box.
 
 Hope that helps,
 --Leif
 
 
 
 Brett Porter wrote:
 
 Ok, this has got me stumped. I don't know what's different.
 
 Let me outline where we are at:
 - first run is always slower
 - second run should not unpack any plugins or touch the cache
 - the reason that blowing away the cache is faster than running with
 it when the unpacking is happening is because it is actually manually
 erasing each, then recaching instead of just the last step, so that's
 fine.
 
 We need to sort out what is triggering the unpacking.
 
 Is anyone experiencing this problem comfortable with building from tag
 MAVEN-1_0_2, then adding debug statements to PluginManager.java and
 recompiling?
 If not, I can do this and provide a debugging maven.jar to try out...
 
 Can someone let me know (Chad?) when you are able to look at this, and
 if possible jump onto irc.codehaus.org (you can get there by HTTP if
 needed) so we can walk through it.
 
 Thanks,
 Brett
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


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


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



1.0.2 startup slow

2004-12-07 Thread Chad Brandon
Hi,

First of all, great job on the 1.0.2 release!  I just download the release
this morning and have been using it, and I've noticed the startup time has
dramatically increased.  Startup time for just typing maven was between
2-3 seconds on my machine for versions prior to 1.0.2, but 1.0.2 seems to
take around 25 seconds just to start up.  Has anyone else noticed this? And
is there anything I can do to improve the time? I know about the maven
console plugin however I change directories a lot so it's not a great
alternative unless I just stay in the same directory the entire time.

Thanks!

Chad


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



RE: 1.0.2 startup slow

2004-12-07 Thread Chad Brandon
Strange, what OS are you running on? I'm on an XP 3.2 ghz with 2 gigs of
memory.

Chad

-Original Message-
From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 11:15 AM
To: Maven Users List
Subject: Re: 1.0.2 startup slow


I'm not seeing that behavior.  Working fine for me on a 800mhz pig
nonetheless:

|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

BUILD SUCCESSFUL
Total time: 5 seconds
Finished at: Tue Dec 07 12:19:12 CST 2004

 On Tue, 07 Dec 2004 10:48:46 -0700, Charles Daniels [EMAIL PROTECTED]
said:

 Same here.  Unpacking plugin jars every time.  Startup time for me
 is consistently 16 seconds.

 -Original Message- From: Joe Shomphe
 [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:40
 AM To: Maven Users List Subject: Re: 1.0.2 startup slow
 
 Yeah, I am seeing the same thing here.
 
 Every time maven runs, it seems to be unpacking its jars to my
 local repo every time.
 
 I have tried removing my ~/.maven directory, but that didnt seem to
 work.
 
 
 Output from maven -X:
 
 
 Unpacking maven-announcement-plugin-1.3.jar to directory --
 C:\Documents and
 Settings\joes\.maven\cache\maven-announcement-plugin-1.3
 Invalidating plugin maven-announcement-plugin-1.3 removing
 dynataglib cache entry for uri announcement removing goal and
 plugin cache entry for goal announcement:generate removing goal and
 plugin cache entry for goal announcement:generate-all removing goal
 and plugin cache entry for goal announcement:mail removing goal and
 plugin cache entry for goal announcement:init removing goal and
 plugin cache entry for goal announcement:check-version removing
 goal and plugin cache entry for goal announcement removing dynatag
 dependency cache entry removing artifactId cache entry
 
 
 
 
 On Tue, 7 Dec 2004 10:28:23 -0700, Chad Brandon
 [EMAIL PROTECTED] wrote:
  Hi,
  
  First of all, great job on the 1.0.2 release!  I just download
 the release  this morning and have been using it, and I've noticed
 the startup time has  dramatically increased.  Startup time for
 just typing maven was between  2-3 seconds on my machine for
 versions prior to 1.0.2, but 1.0.2 seems to  take around 25
 seconds just to start up.  Has anyone else noticed this? And  is
 there anything I can do to improve the time? I know about the maven
  console plugin however I change directories a lot so it's not a
 great  alternative unless I just stay in the same directory the
 entire time.
  
  Thanks!
  
  Chad
  
  
 -
  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]

-- 
=
Jeffrey D. Brekke   [EMAIL PROTECTED]
Wisconsin,  USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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


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



RE: 1.0.2 startup slow

2004-12-07 Thread Chad Brandon
Yeah removed my plugin cache, haven't tried removing the repo however (since
I figured that wouldn't matter), maybe I'll try that.


-Original Message-
From: Eric Lapierre [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 11:30 AM
To: 'Maven Users List'
Subject: RE: 1.0.2 startup slow

Have you tried cleaning up your local repo first? 

-Original Message-
From: Chad Brandon [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 1:27 PM
To: 'Maven Users List'
Subject: RE: 1.0.2 startup slow


Strange, what OS are you running on? I'm on an XP 3.2 ghz with 2 gigs of
memory.

Chad

-Original Message-
From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 11:15 AM
To: Maven Users List
Subject: Re: 1.0.2 startup slow


I'm not seeing that behavior.  Working fine for me on a 800mhz pig
nonetheless:

|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

BUILD SUCCESSFUL
Total time: 5 seconds
Finished at: Tue Dec 07 12:19:12 CST 2004

 On Tue, 07 Dec 2004 10:48:46 -0700, Charles Daniels 
 [EMAIL PROTECTED]
said:

 Same here.  Unpacking plugin jars every time.  Startup time for me is 
 consistently 16 seconds.

 -Original Message- From: Joe Shomphe 
 [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:40 AM 
 To: Maven Users List Subject: Re: 1.0.2 startup slow
 
 Yeah, I am seeing the same thing here.
 
 Every time maven runs, it seems to be unpacking its jars to my local 
 repo every time.
 
 I have tried removing my ~/.maven directory, but that didnt seem to 
 work.
 
 
 Output from maven -X:
 
 
 Unpacking maven-announcement-plugin-1.3.jar to directory -- 
 C:\Documents and 
 Settings\joes\.maven\cache\maven-announcement-plugin-1.3
 Invalidating plugin maven-announcement-plugin-1.3 removing dynataglib 
 cache entry for uri announcement removing goal and plugin cache entry 
 for goal announcement:generate removing goal and plugin cache entry 
 for goal announcement:generate-all removing goal and plugin cache 
 entry for goal announcement:mail removing goal and plugin cache entry 
 for goal announcement:init removing goal and plugin cache entry for 
 goal announcement:check-version removing goal and plugin cache entry 
 for goal announcement removing dynatag dependency cache entry 
 removing artifactId cache entry
 
 
 
 
 On Tue, 7 Dec 2004 10:28:23 -0700, Chad Brandon 
 [EMAIL PROTECTED] wrote:
  Hi,
  
  First of all, great job on the 1.0.2 release!  I just download
 the release  this morning and have been using it, and I've noticed 
 the startup time has  dramatically increased.  Startup time for just 
 typing maven was between  2-3 seconds on my machine for versions 
 prior to 1.0.2, but 1.0.2 seems to  take around 25 seconds just to 
 start up.  Has anyone else noticed this? And  is there anything I 
 can do to improve the time? I know about the maven
  console plugin however I change directories a lot so it's not a
 great  alternative unless I just stay in the same directory the 
 entire time.
  
  Thanks!
  
  Chad
  
  
 -
  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]

-- 
=
Jeffrey D. Brekke   [EMAIL PROTECTED]
Wisconsin,  USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
[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]



RE: 1.0.2 startup slow

2004-12-07 Thread Chad Brandon
Yeah so it sounds like its working fine on Linux but not on windows?  Anyone
have it working ok on Windows?  I just tried deleting my local repo and like
I expected that had no affect.

-Original Message-
From: Leif Nelson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 11:55 AM
To: Maven Users List
Subject: Re: 1.0.2 startup slow

Weird..  running on RedHat AS 3.0 it's 3 seconds.  1.7GHz xenon.  maven 
-X shows it's not re-unpacking all of the jars.
$ maven
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

BUILD SUCCESSFUL
Total time: 3 seconds
Finished at: Tue Dec 07 10:32:17 PST 2004

I made a fresh local repo (empty dir), and deleted ~/.maven on windows 
XP, and it's still 31 seconds.  (2.2 GHz box)
C:\maven
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

BUILD SUCCESSFUL
Total time: 31 seconds
Finished at: Tue Dec 07 11:37:04 MST 2004

C:\

Windows JDK 1.4.2_06
Linux JDK 1.4.2_05

--Leif

Chad Brandon wrote:

Hi,

First of all, great job on the 1.0.2 release!  I just download the release
this morning and have been using it, and I've noticed the startup time has
dramatically increased.  Startup time for just typing maven was between
2-3 seconds on my machine for versions prior to 1.0.2, but 1.0.2 seems to
take around 25 seconds just to start up.  Has anyone else noticed this? And
is there anything I can do to improve the time? I know about the maven
console plugin however I change directories a lot so it's not a great
alternative unless I just stay in the same directory the entire time.

Thanks!

Chad


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


  



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


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



RE: 1.0.2 startup slow

2004-12-07 Thread Chad Brandon
Very strange, I have XP sp2 but that shouldn't have any affect.

-Original Message-
From: Erik Husby [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 12:07 PM
To: Maven Users List
Subject: Re: 1.0.2 startup slow

Works fine on Windows XP sp1

Z:\IdeaProjects\SquidMaven\sequencejava -version
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)

Z:\IdeaProjects\SquidMaven\sequencemaven build:start
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

BUILD SUCCESSFUL
Total time: 2 seconds
Finished at: Tue Dec 07 14:06:00 EST 2004

Z:\IdeaProjects\SquidMaven\sequence


-- 
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard 
Rm. 2192  320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, [EMAIL PROTECTED]


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


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



RE: 1.0.2 startup slow

2004-12-07 Thread Chad Brandon


-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 07, 2004 1:04 PM
To: Chad Brandon
Cc: Maven Users List
Subject: Re: 1.0.2 startup slow

Thanks.

Do you have anything in here?
C:\Documents and Settings\Administrator\.maven\plugins
I'm assuming its empty.

[CB] I guess those were left over from an earlier version, deleted that
directory.

Do the timestamps on any files in:
C:\Documents and Settings\Administrator\.maven\cache
change after every run? How do they compare to:
d:\java\maven-1.0.2\plugins

[CB] Yes, they all change to the current time of the run (newer than the
files in d:\java\maven-1.0.2\plugins).  Of course the files that are
actually extracted from the plugins have the same date from inside the
plugin jar.

You say you get this even if you rename C:\Documents and
Settings\Administrator\.maven\cache to something else (or delete it)?

[CB] Yeah I tried placing the .maven directory in a new location and set the
maven.plugin.upacked.dir to that (also tried moving the local repo as well).


What about if you set -Dmaven.home.local=d:/java/maven-cache?
(just keeping it out of the Windows Profile to see if that helps)

[CB] Tried that, same thing happens.

[CB] Another thing I noticed is that if I actually delete the plugin cache
its about 8 seconds faster than if I run it with the plugin cache (don't
know if that's helpful or not).

Cheers,
Brett

On Tue, 7 Dec 2004 12:55:38 -0700, Chad Brandon [EMAIL PROTECTED]
wrote:
 Yes I can reproduce it every run, in fact I can't get it to not load
without
 unpacking the plugins every time (I've run it on w machines that have XP
 sp2).  My output from running with -X is attached.
 
 Thanks!
 
 Chad
 
 
 
 
 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, December 07, 2004 12:51 PM
 To: Maven Users List
 Subject: Re: 1.0.2 startup slow
 
 I've just done an install on a machine running only 1.0.1. No
 problems, and no cache fudging necessary.
 
 Is anyone able to reproduce this every run still? I'd like to find out
 what your -X output is to see if it is:
 a) unpacking the plugins every time
 b) recaching any plugins if not (a)
 
 If (a), would want to compare timestamps.
 
 Thanks,
 Brett
 
 On Tue, 7 Dec 2004 12:16:35 -0700, Chad Brandon [EMAIL PROTECTED]
 wrote:
  Very strange, I have XP sp2 but that shouldn't have any affect.
 
 
 
  -Original Message-
  From: Erik Husby [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, December 07, 2004 12:07 PM
  To: Maven Users List
  Subject: Re: 1.0.2 startup slow
 
  Works fine on Windows XP sp1
 
  Z:\IdeaProjects\SquidMaven\sequencejava -version
  java version 1.5.0
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
  Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)
 
  Z:\IdeaProjects\SquidMaven\sequencemaven build:start
   __  __
  |  \/  |__ _Apache__ ___
  | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
  |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
 
  BUILD SUCCESSFUL
  Total time: 2 seconds
  Finished at: Tue Dec 07 14:06:00 EST 2004
 
  Z:\IdeaProjects\SquidMaven\sequence
 
  --
  Erik Husby
  Team Lead for Software Quality Automation
  Broad Institute of MIT and Harvard
  Rm. 2192  320 Charles St
  Cambridge, MA 02141-2023
  mobile: 781.354.6669, office: 617.258.9227, [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]



Re: Including util:properties does not work for subprojects

2004-09-29 Thread Chad Brandon
- Original Message - 
From: Sascha-Matthias Kulawik [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 9:31 AM
Subject: RE: Including util:properties does not work for subprojects



 I've a project using multiproject and the reactor, in the main
 maven.xml file is a referenced build.properties like

 util:properties file=../standards/build.properties/

 which referrs a properties file with some standard values, like
 repository path for example. This works fine in normal
projects, but
 in the multiproject a subproject won't recognize the
properties - in
 my project it won't find the referenced jars because there
aren't at
 ibiblio and the property was not readed.

 Any suggestions? Is this a bug?
I assume not. You have to take into account, that the working
directory is, where you've started Maven. So I assume, that
you are at a different directory level. Help youself with
something like:
util:properties
file=${maven.multiproject.basedir}/../standards/build.properties/
Thank you, but it won't work. The util:properties is written into the main
maven.xml, there I shouldn't change it, i assume. Adding this
util:properties to the subproject wont work as well.
Any other suggestions?
What you're saying is that the properties aren't being inherited by 
subprojects, like normal properties that are defined directly in the 
project.properties file...thats what you're saying right?  I've seen the 
same thing..


-
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: Excludes in multiproject

2004-06-15 Thread Chad Brandon
That used to work before rc3, but you can no longer
change the property with j:set, see:
http://jira.codehaus.org/browse/MAVEN-1251

--- Jefferson K. French [EMAIL PROTECTED] wrote:
 It's valid for the rest of the build, so if you want
 to do something
 afterwards for all subprojects, adding:
 
   j:set var=maven.multiproject.excludes
 value=/
 
 after the multiproject:site should work.
 
   Jeff
 
 On Tue, 15 Jun 2004, at 18:02:01 [GMT +0200] Michael
 Mattox wrote:
 
  If you do that is the j:set valid only during the
 goal or is it set for the
  rest of the build??
 
  Michael
 
  -Message d'origine-
  De : Jefferson K. French
 [mailto:[EMAIL PROTECTED]
  Envoyé : mardi 15 juin 2004 17:22
  À : Maven Users List
  Objet : Re: Excludes in multiproject
 
 
  How about something like this:
 
goal name=gensite
  j:set var=maven.multiproject.excludes

 value=client-ejb.jar/project.xml,foo/project.xml/
  attainGoal name=multiproject:site/
/goal
 
Jeff
 
  On Tue, 15 Jun 2004, at 08:54:35 [GMT +0200] Jörg
 Schaible wrote:
 
   Hi folks,
 
   what is the best way to exclude some
 subprojects from the site
  generation, but nor from the other goals? I
 separated some of my
  subprojects into a main part and a
 sublementatry part to generate
   the different artifacts (e.g. the
 client-ejb.jar), but it does
  not make sense to have anything of it in the site
 documentation.
 
   Regards,
   Jörg
 
  --
  mailto:[EMAIL PROTECTED]
 
 
 
 
 
  --
  This E-mail is confidential.  It may also be
 legally privileged.  If you are
  not the addressee you may not copy, forward,
 disclose or use any part of it.
  If you have received this message in error, please
 delete it and all copies
  from your system and notify the sender immediately
 by return E-mail.
  Internet communications cannot be guaranteed to be
 timely, secure, error or
  virus-free.  The sender does not accept liability
 for any errors or omissions.
 
 
 

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

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


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



Re: XP %HOME% and Maven

2004-06-12 Thread Chad Brandon
On windows it  should be %USERPROFILE%, on linux its $HOME. 

- Original Message - 
From: niksa_os [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 12, 2004 1:42 AM
Subject: XP %HOME% and Maven


I try Maven

In install guide stand: install_repo.bat %HOME%\.maven\repository

Problem is that I get new dir C:\Documents\some_files_and_dir and I should
get
C:\Documents and Settings\mvelic\.maven ???

Also %HOMEDRIVE%%HOMEPATH%\.maven\repository same thing.

I did try with install_repo.bat %HOME%\.maven\repository, but then I get
new dir

C:\maven\bin\%HOME%

Do I need to get C:\Documents and Settings\mvelic\.maven?
And how can I get it?

Thanks.


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



Re: Overwriting properties

2004-05-23 Thread Chad Brandon

- Original Message - 
From: Brett Porter [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Sunday, May 23, 2004 7:19 PM
Subject: RE: Overwriting properties


 The third one is correct. Are you using RC3? That notation was only added
in
 RC3.

Hi Brett,

It doesn't work for me in maven-1.0-rc3 either.   Just downloaded 1.0-rc3
when it was released a couple days ago.

Thanks,

Chad


 - Brett

  -Original Message-
  From: Heidi Schuster [mailto:[EMAIL PROTECTED]
  Sent: Saturday, 22 May 2004 12:56 AM
  To: Maven Users List
  Subject: Overwriting properties
 
 
 
  Hi,
 
  I am trying to overwrite a property for the multiproject
  plugin in my maven.xml Neither the ant property task or the
  jelly set task works (see code below). The value stays as
  defined in project.properties.
 
 
  property file = site.properties/
  property name = maven.multiproject.includes
  value=app*/project.xml/
 
  maven:set
  plugin=maven-multiproject-plugin
  property=maven.multiproject.includes
  value=app*/project.xml /
 
 
  Any ideas?
 
  thanks you very much,
  Heidi
 
 
  -
  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: Compile from CVS

2004-05-03 Thread Chad Brandon
Well said :)

- Original Message - 
From: Vincent Massol [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Monday, May 03, 2004 3:28 PM
Subject: RE: Compile from CVS


Building from HEAD or branch HEAD is reserved to power-users/developers.
I'd suggest you use the latest released version (rc2). Otherwise, stop
whining and start participating :-)

Thanks
-Vincent

 -Original Message-
 From: Jarrell, Maury [mailto:[EMAIL PROTECTED]
 Sent: 03 May 2004 20:50
 To: 'Maven Users List'
 Subject: RE: Compile from CVS

 Amen.  I think I was lulled into believing it's a more mature project
than
 it is by all the Built With Maven graphics on so many Jakarta
projects.

  -Original Message-
  From: Miguel Griffa [mailto:[EMAIL PROTECTED]
  Sent: Monday, May 03, 2004 1:54 PM
  To: Maven Users List
  Subject: Re: Compile from CVS
 
  Hi
  I'm getting the same problem there,
  I just run
  cvs up -r MAVEN-1_0-BRANCH -d -C
  on maven and maven-plugins checkouts...
  I's so happy with maven that I want to start building and
contributing
  (if I can) but debugging the bootstrap seems a bit difficult fo rthe
  first task..
 
   [exec]  __  __
   [exec] |  \/  |__ _Apache__ ___
   [exec] | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
   [exec] |_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc3-SNAPSHOT
 
   [exec] com.werken.werkz.NoSuchGoalException: No goal [clean]
   [exec] at
 

org.apache.maven.plugin.GoalToJellyScriptHousingMapper.resolveJellyScrip
tH
  ousings(GoalToJellyScriptHousingMapper.java:254)
   [exec] at
 

org.apache.maven.plugin.PluginManager.prepAttainGoal(PluginManager.java:
64
  5)
   [exec] at
 

org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:597
)
   [exec] at
  org.apache.maven.MavenSession.attainGoals(MavenSession.java:266)
   [exec] at org.apache.maven.cli.App.doMain(App.java:485)
   [exec] at org.apache.maven.cli.App.main(App.java:1208)
   [exec] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
  Method)
   [exec] at
 

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:
  39)
   [exec] at
 

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Im
  pl.java:25)
   [exec] at java.lang.reflect.Method.invoke(Method.java:324)
   [exec] at
com.werken.forehead.Forehead.run(Forehead.java:551)
   [exec] at
com.werken.forehead.Forehead.main(Forehead.java:581)
 
 
  Arnaud Heritier wrote:
 
  
  
  -Message d'origine-
  De : Miguel Griffa [mailto:[EMAIL PROTECTED]
  Envoyé : lundi 3 mai 2004 20:01
  À : Maven Users List
  Objet : Re: Compile from CVS
  
  Hi I checked out the HEAD
  But I'm used to compile without problems HEADs (from open source
  projects...)
  I posted all info at jira here (included the ouput of ant -d )
  
  http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1253
  
  Shouldn't the head version compile?
  
  
  
  Ok Miguel.
  In theory the Head must compile but in reality I'm not sure that
all
  modifications are done in the two branches.
  The dev team is trying to produce a 1.0 RC3 (Final we hope) as soon
as
  possible.
  Waiting for this, I advise you to get the branch : MAVEN-1_0-BRANCH
  We are sure that this one compile.
  
  I will try to find what the problem is with the HEAD.
  
  
  #Arnaud.
  
  
 
-
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
 
  --
 
  Miguel Griffa
  Software Architect
  Technisys.NET  The First Digital e-nabler
  Transactional Solutions
 
  Miami +1 305 357 8109
  Madrid +34 915 726 763
  Buenos Aires: +54 11 43227100
  [EMAIL PROTECTED]
  http://www.technisys.net
 
 
 
-
  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]



Re: [Andromda-devel] Wrapping Maven

2004-04-26 Thread Chad Brandon
Hi Harald,

One of the maven developers would probably be able to help you out more with
this than I can, so I'm forwarding your question to their list.

Thanks,

Chad
- Original Message - 
From: Harald Weyhing [EMAIL PROTECTED]
To: 'Developers AndroMDA' [EMAIL PROTECTED]
Sent: Thursday, April 22, 2004 2:46 PM
Subject: [Andromda-devel] Wrapping Maven


 Hi Chad and others,

 I am currently tying to wrap some Java class around running Maven. This
 is quite strange, because Maven does not start with some
 org.apache.Maven.main(), but wit Forehead.main.
 (http://forehead.werken.com/)

 Forehead is a small framework to help controlling the runtime
 ClassLoader hirarchy via some property file.

 Well, this means Maven get's started, will stop after work and that's
 it. I wanted to keep at leas the metamodells in memory in order to have
 an AndroMDA build starter that will parse the xmi only once... perhaps
 there are more things that could be optimized by wrapping the build
 process...
 With Forehead I do not know if Maven leaves garbage if i subclass the
 initial Maven class to prevent Maven from stopping...

 Does anybody have any idea that might help with this?

 Chers
 Harald




 ---
 This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
 For a limited time only, get FREE Ground shipping on all orders of $35
 or more. Hurry up and shop folks, this offer expires April 30th!
 http://www.thinkgeek.com/freeshipping/?cpg=12297
 ___
 Andromda-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/andromda-devel




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



Re: Maven 1.0 RC2 released

2004-03-23 Thread Chad Brandon
Good work guys! one thing does seem to be broken though:  I have plugin
dependencies within my projects, and with rc1, they would be download when
needed and then the goals made available as I was building, but now it seems
like if the plugin doesn't already exist in the repository or
$MAVEN_HOME/plugins directory, Maven doesn't find it, and fails telling me
it can't find the specified goal (even if the plugin is successfully
downloaded).

Thanks,

Chad

- Original Message - 
From: Brett Porter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 7:40 PM
Subject: Maven 1.0 RC2 released


 The Apache Maven team is pleased to announce the release of Maven 1.0 RC2.

 http://maven.apache.org/start/download.html

 Maven is a Java project management and project comprehension
 tool. Maven is based on the concept of a project object model (POM).
 The intent of Maven is to make intra-project development highly manageable
 in the hopes of providing more time for cross-project development.

 RC2 is a release candidate for Maven 1.0. The main focus for this release
was
   - Remove a memory leak in long-lived and multiple project builds
   - Reworking the internals for more maintainability while retaining full
backwards
 compatibility with RC1.
   - Many other bugfixes

 For a complete list of changes in the Maven core, see JIRA:

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10030fixfor=10245

 While no new features have been added to Maven's central architecture, RC2
 includes all the latest releases of the plugins developed at Apache. Most
 plugins include bugfixes and new functionality since the RC1 release.

 In addition, the following plugins have been added to the release:
   - announcement: generates templated release announcements for a project
   - aspectwerkz: Aspectwerkz integration
   - caller: A goal interface for Maven plugins
   - dashboard: A report plugin that aggregates reports from multiple
projects
   - javacc: generates code based on user-supplied Javacc/JJtree grammars
   - jdiff: generates an api difference report between versions
   - jetty: Jetty integration
   - jira: generates a Maven report from JIRA
   - multichanges: A report plugin that aggregates changes reports from
multiple
 projects
   - nsis: generates a Windows Installer for your project using the
Nullsoft
 Installer System

 The following plugins have had major upgrades since the last release:
   - pdf: a complete rewrite now produces a much better PDF representation
of
 your project site.
   - xdoc: Maven site's now have a new default look-and-feel and are more
 customisable

 For changes made to individual plugins since the last release, you can
review
 the release history at JIRA.

 The following plugins are no longer distributed with Maven and must be
downloaded
 from an external source:
   - cactus: download instructions at
 http://jakarta.apache.org/cactus/integration/maven.html
   - word2html, was40: download from
 http://maven-plugins.sf.net

 We hope you enjoy using Maven! If you have any questions, please consult:
   - the FAQ: http://maven.apache.org/faq.html
   - the Wiki: http://wiki.codehaus.org/maven/
   - the maven-user mailing list: http://maven.apache.org/mail-lists.html

 For news and information, see:
   - Maven Blogs: http://www.mavenblogs.com/

 - The Apache Maven Team





 -
 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: Maven 1.0 RC2 released

2004-03-23 Thread Chad Brandon

- Original Message - 
From: Brett Porter [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 9:10 PM
Subject: RE: Maven 1.0 RC2 released


 So it works on second run?

Thanks for the quick response Brett,

Well 2nd run no ...since I have more than one plugin dependencies in
different subprojects :)...but once they are all downloaded it runs.  Seems
like they need to be downloaded and in place before it will find the goal
for the plugin.  I'll file an issue with JIRA.


 File an issue in JIRA and I'll fix ASAP. The next release of Maven will
not
 be another 6 months away as there are currently only 19 issues left to
 resolve for Maven 1.0 :)

 - Brett

  -Original Message-
  From: Chad Brandon [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, 24 March 2004 1:04 PM
  To: Maven Users List; [EMAIL PROTECTED]
  Subject: Re: Maven 1.0 RC2 released
 
 
  Good work guys! one thing does seem to be broken though:  I
  have plugin dependencies within my projects, and with rc1,
  they would be download when needed and then the goals made
  available as I was building, but now it seems like if the
  plugin doesn't already exist in the repository or
  $MAVEN_HOME/plugins directory, Maven doesn't find it, and
  fails telling me it can't find the specified goal (even if
  the plugin is successfully downloaded).
 
  Thanks,
 
  Chad
 
  - Original Message - 
  From: Brett Porter [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
  [EMAIL PROTECTED]
  Sent: Tuesday, March 23, 2004 7:40 PM
  Subject: Maven 1.0 RC2 released
 
 
   The Apache Maven team is pleased to announce the release of
  Maven 1.0
   RC2.
  
   http://maven.apache.org/start/download.html
  
   Maven is a Java project management and project comprehension tool.
   Maven is based on the concept of a project object model (POM). The
   intent of Maven is to make intra-project development highly
  manageable
   in the hopes of providing more time for cross-project development.
  
   RC2 is a release candidate for Maven 1.0. The main focus for this
   release
  was
 - Remove a memory leak in long-lived and multiple project builds
 - Reworking the internals for more maintainability while
  retaining
   full
  backwards
   compatibility with RC1.
 - Many other bugfixes
  
   For a complete list of changes in the Maven core, see JIRA:
  
  http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true
  pid=10030fixfor=10245
  
   While no new features have been added to Maven's central
  architecture,
   RC2 includes all the latest releases of the plugins developed at
   Apache. Most plugins include bugfixes and new functionality
  since the
   RC1 release.
  
   In addition, the following plugins have been added to the release:
 - announcement: generates templated release announcements
  for a project
 - aspectwerkz: Aspectwerkz integration
 - caller: A goal interface for Maven plugins
 - dashboard: A report plugin that aggregates reports from multiple
  projects
 - javacc: generates code based on user-supplied
  Javacc/JJtree grammars
 - jdiff: generates an api difference report between versions
 - jetty: Jetty integration
 - jira: generates a Maven report from JIRA
 - multichanges: A report plugin that aggregates changes
  reports from
  multiple
   projects
 - nsis: generates a Windows Installer for your project using the
  Nullsoft
   Installer System
  
   The following plugins have had major upgrades since the
  last release:
 - pdf: a complete rewrite now produces a much better PDF
   representation
  of
   your project site.
 - xdoc: Maven site's now have a new default look-and-feel
  and are more
   customisable
  
   For changes made to individual plugins since the last
  release, you can
  review
   the release history at JIRA.
  
   The following plugins are no longer distributed with Maven
  and must be
  downloaded
   from an external source:
 - cactus: download instructions at
   http://jakarta.apache.org/cactus/integration/maven.html
 - word2html, was40: download from
   http://maven-plugins.sf.net
  
   We hope you enjoy using Maven! If you have any questions,
  please consult:
 - the FAQ: http://maven.apache.org/faq.html
 - the Wiki: http://wiki.codehaus.org/maven/
 - the maven-user mailing list:
   http://maven.apache.org/mail-lists.html
  
   For news and information, see:
 - Maven Blogs: http://www.mavenblogs.com/
  
   - The Apache Maven Team
  
  
  
  
  
  
  -
   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: Precompiling jsps

2004-02-18 Thread Chad Brandon
I'm not sure if there is one out there, but I've
written one we use, if you'd like I can send it to
you.  It precompiles using Tomcat's Jasper compiler.

--- DeGraff, Adam [EMAIL PROTECTED] wrote:
 Is there a plugin to do this, or should I write a
 custom goal?  Thanks.
 
 -Adam
 

-
 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: extend the project.properties file

2004-01-27 Thread Chad Brandon
Is it in 1.1 in CVS?  If so, whats the syntax to use to extend the
properties?

Thanks,

Chad

- Original Message - 
From: Emmanuel Venisse [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 9:50 AM
Subject: Re: extend the project.properties file


 Yes, in the next version.

 - Original Message - 
 From: Sean Kelly [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, January 27, 2004 3:47 PM
 Subject: extend the project.properties file


  A subproject can use the extend in its project.xml to inherit
  information from another project.xml file.
 
  However, it seems not all project knowledge is contained in the Project
  Object Model.  Some of that resides in the project.properties (mostly
  look-and-feel things).  Is there a way to extend the
  project.properties file?
 
  Something like:
 
  ---
  # My Subproject's properties:
  extend = ../project.properties
  override.value = 2
  my.value = 5
  ---
 
  If not, is there a way to specify properties that normally appear only
  in project.properties in the project.xml file instead?
 
  Thanks,
  Sean.
 
  -- 
  Sean Kelly
  Independent Consultant
  http://seankelly.biz/
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

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




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



Re: Classpath within a plugin?

2004-01-27 Thread Chad Brandon
Alex,

Eric almost got it right, but it should be plugin.getDependencyClasspath()
instead of pom.getDependencyClasspath() if you're within a plugin. Or you
can include a single dependency at a time:
plugin:getDependencyPath(groupId:artifactId).

Chad

- Original Message - 
From: Eric Giguere [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 1:26 PM
Subject: Re: Classpath within a plugin?


 Hi Alex

 Did you try using this call : pom.getDependencyClasspath() ?
 By embedding this in an ant tag, you can pass it classpath info.
 ...
 ant:path id=project.class.path
 pathelement location=${maven.build.dest}/
 pathelement path=${pom.getDependencyClasspath()}/
 /ant:path
 ... Alex Vollmer wrote:

 I have a Java executable class I need to run and I am unable to
 determine how to run the java task with a classpath that points to the

 Hope it helps, I'm not sure though. My example is made in a maven.xml
 file of a project, not from a plugin but still... should work.

 Eric.


 classes packaged within my plugin. Is there any way to access this?
 
 Alex Vollmer
 
 [EMAIL PROTECTED]
 
 Software Engineer
 Tenzing Communications, Inc.
 705 Fifth Avenue South, Suite 700
 Seattle, WA 98104 USA
 
 T:  +1 206.607.2869
 
 Bring your laptop and try inflight email on your next United,
 Continental or Cathay Pacific flight. All you need is your laptop, user
 ID, password, and email server URL. Tenzing Communications, Inc.
 provides inflight email systems that help airborne travelers stay in
 touch.
 
 
 


 -
 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: extend the project.properties file

2004-01-27 Thread Chad Brandon
Great!  That's one thing that is kind of a pain in 1.0-RC1.

Thanks,

Chad

- Original Message - 
From: Michal Maczka [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 1:35 PM
Subject: RE: extend the project.properties file


 
 
  -Original Message-
  From: Chad Brandon [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, January 27, 2004 4:05 PM
  To: Maven Users List
  Subject: Re: extend the project.properties file
  
  
  Is it in 1.1 in CVS?  If so, whats the syntax to use to extend the
  properties?
  
 AFAIK there is no special syntax. It will be inherited automatically. 
 
 
 Michal
 
 
 -
 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: viewable info on individual plugins and maven.xml goals

2004-01-07 Thread Chad Brandon
I agree...I think that would be really helpful if
something like that existed.


--- __matthewHawthorne [EMAIL PROTECTED] wrote:
 Although I would prefer not to, I frequently need to
 create a maven.xml 
 to do some special things.
 
 One great thing from Ant was the '-projecthelp'
 option that would output 
 the available targets and documentation.  I find
 that 'maven -g' is 
 overwhelming, since I usually only need to view one
 plugin at a time.  I 
 usually create a 'help' goal that documents all of
 my special goals and 
 properties.
 
 
 It would be nice if:
 
 1) 'maven -g plugin' would show all of the goals
 from the specified plugin
 
 2) maven -go (goal override, or something similar)
 could show all goals 
 from maven.xml, like Ant's projecthelp.
 
 
 Questions:
 
 1) Have I missed something -- does this
 functionality already exist 
 somehwere?
 
 2) Do others agree that these are good ideas?
 
 
 Thanks for any input!
 
 

-
 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: Migrate Maven to using Ant1.6

2004-01-04 Thread Chad Brandon
- Original Message - 
From: [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Sunday, January 04, 2004 7:18 AM
Subject: Re: Migrate Maven to using Ant1.6


 I've done this, but not yet committed it, as it required a change to 
 commons-grant.
 
 If you desperately need it, let me know.
 
 Does anyone else need Ant 1.6 support?

It'd be great to have Ant 1.6 support.

 --
 dIon Gillard, Multitask Consulting
 Blog:  http://blogs.codehaus.org/people/dion/
 
 
 
 Eric Chow [EMAIL PROTECTED] wrote on 26/12/2003 05:48:33 PM:
 
  Hello,
  
  How can I migrate Maven to use Ant1.6?
  
  Eric
  
  ==
  If you know what you are doing, 
  it is not called RESEARCH!
  ==
  
  -
  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]



Comparison of large numbers?

2003-12-05 Thread Chad Brandon
Hi,

I'm using maven-rc1.

This may be a dumb question, but is there some thing
special I need to do to get jelly to evaluate
expressions with large numbers?  I'm trying to compare
the last modified dates of two files within a plugin,
but it ignores the comparison expression. I then just
tried to echo the result of comparing the actual
numbers, and I get the below exception.  

'echo ${124 lt; 6452} echo' works fine.

'echo ${10705036627 lt; 1070503662761} /echo'
produces: 

com.werken.werkz.UnattainableGoalException: Unable to
obtain goal [subproject] -- file:/C:/Documents and
Settings/Administrator/.m
aven/plugins/maven-subproject-plugin-1.1.1/:41:34:
maven:reactor Runtime Exception:
org.apache.commons.jelly.JellyException: nul
l:-1:-1: null Unable to create expression:
10705036627  1070503662761
at com.werken.werkz.Goal.fire(Goal.java:646)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448)
at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:348)
at
org.apache.maven.cli.App.doMain(App.java:543)
at
org.apache.maven.cli.App.main(App.java:1109)
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:
file:/C:/Documents and
Settings/Administrator/.maven/plugins/maven-subproject-plugin-1
.1.1/:41:34: maven:reactor Runtime Exception:
org.apache.commons.jelly.JellyException: null:-1:-1:
null Unable to create expre
ssion: 10705036627  1070503662761
at
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:387)
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.ForEachTag.doTag(ForEachTag.java:145)
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
com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128)
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
com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134)
at
org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107)
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
com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448)
at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:348)
at
org.apache.maven.cli.App.doMain(App.java:543)
at
org.apache.maven.cli.App.main(App.java:1109)
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)
Caused by: org.apache.commons.jelly.JellyException:
null:-1:-1: null Unable to create expression:
10705036627  1070503662761
... 30 more
Root cause
org.apache.commons.jelly.JellyException: null:-1:-1:
null Unable to create expression: 10705036627 
1070503662761
at
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:387)
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.ForEachTag.doTag(ForEachTag.java:145)
at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at

Re: Comparison of large numbers?

2003-12-05 Thread Chad Brandon
You're right that's much better.  Thanks Kevin. 
Although its still strange jelly won't allow
large numbers to be compared.


--- Kevin Hagel [EMAIL PROTECTED] wrote:
 http://ant.apache.org/manual/CoreTasks/uptodate.html
 
 I use ant's updtodate for such things, have you
 tried it?
 
 - Original Message - 
 From: Chad Brandon [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, December 05, 2003 7:27 AM
 Subject: Comparison of large numbers?
 
 
  Hi,
 
  I'm using maven-rc1.
 
  This may be a dumb question, but is there some
 thing
  special I need to do to get jelly to evaluate
  expressions with large numbers?  I'm trying to
 compare
  the last modified dates of two files within a
 plugin,
  but it ignores the comparison expression. I then
 just
  tried to echo the result of comparing the actual
  numbers, and I get the below exception.
 
  'echo ${124 lt; 6452} echo' works fine.
 
  'echo ${10705036627 lt; 1070503662761} /echo'
  produces:
 
  com.werken.werkz.UnattainableGoalException: Unable
 to
  obtain goal [subproject] -- file:/C:/Documents and
  Settings/Administrator/.m
  aven/plugins/maven-subproject-plugin-1.1.1/:41:34:
  maven:reactor Runtime Exception:
  org.apache.commons.jelly.JellyException: nul
  l:-1:-1: null Unable to create expression:
  10705036627  1070503662761
  at
 com.werken.werkz.Goal.fire(Goal.java:646)
  at
 com.werken.werkz.Goal.attain(Goal.java:575)
  at
 

org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448)
  at
 

org.apache.maven.MavenSession.attainGoals(MavenSession.java:348)
  at
  org.apache.maven.cli.App.doMain(App.java:543)
  at
  org.apache.maven.cli.App.main(App.java:1109)
  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:
  file:/C:/Documents and
 

Settings/Administrator/.maven/plugins/maven-subproject-plugin-1
  .1.1/:41:34: maven:reactor Runtime Exception:
  org.apache.commons.jelly.JellyException:
 null:-1:-1:
  null Unable to create expre
  ssion: 10705036627  1070503662761
  at
 

org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:387)
  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.ForEachTag.doTag(ForEachTag.java:145)
  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
 

com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128)
  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
 

com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134)
  at
 

org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.
 java:107)
  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
 

com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128)
  at
 com.werken.werkz.Goal.fire(Goal.java:639)
  at
 com.werken.werkz.Goal.attain(Goal.java:575)
  at
 

org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448)
  at
 

org.apache.maven.MavenSession.attainGoals(MavenSession.java:348)
  at
  org.apache.maven.cli.App.doMain(App.java:543)
  at
  org.apache.maven.cli.App.main(App.java:1109)
  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)
  Caused by:
 org.apache.commons.jelly.JellyException:
  null:-1:-1: null Unable to create expression:
  10705036627  1070503662761