Re: Method for synching Devlopment Repository to Remote Repository

[Arnaud Bailly]

jp4 <[EMAIL PROTECTED]> writes:

> result, we basically have to allow access to only a single repository which
> a few developers have access to upload libraries and sync to other
> repositories.  The hope is that developers won't be able to just add a new

You can override central by setting a repository (and plugin repo) as
central. Alternatively, you can setup a mirrorOf central using
proximity or archiva. See http://jira.codehaus.org/browse/MNG-479 and
search the list, this question is a recurrent one.

> I am curious if anyone has run into this, and if so, how did you approach
> the problem?  In addition, is it possible to override the SUPER POM?
>

Not sure but the answor is most probably no. You can however override
anything in it so a common practice is creating  company wide POM. 


HTH
-- 
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com


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

pass empty password to svn repository

[Ali Hisham Malik]

Hi,

The svn repository I'm using requires an empty password to be passed
even for anonymous access. I have experiment with several ideas to make
it work with no success. Can anyone tell me what I need to do exactly?

Btw, I'm using scm plugin in combination with the changelog plugin.

Thanks.

Re: Additional features for maven2 plugin

[Max Cooper]

Maven already requires you to define the versions for all of your
dependencies before it builds:
http://maven.apache.org/pom.html#Dependencies


  junit
  junit
  4.0


If you mean something else, please describe it more clearly, perhaps
with an example.

-Max

On Wed, 2006-11-01 at 08:13 +0200, Rahamim, Zvi (Zvi) wrote:
> Hi,
> I think that a very important feature is to have the ability to define,
> before maven starts building, the versions of the dependencies.
> Is there an intention to add this feature?
> Thanks!
> Zvi.
> 
> -
> 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: Additional features for maven2 plugin

[Dan Tran]

so you want to override versions of dependencies on command line?
-D


On 10/31/06, Rahamim, Zvi (Zvi) <[EMAIL PROTECTED]> wrote:


Hi,
I think that a very important feature is to have the ability to define,
before maven starts building, the versions of the dependencies.
Is there an intention to add this feature?
Thanks!
Zvi.

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

Re: Additional features for maven2 plugin

[Wayne Fay]

Defining the version for a dependency is one of the base features of Maven:


 
 
 
 [2.0.8]


The [x.y.z] notation "locks" the artifact to that version. Use [x.y.z,
) to force a minimum but no maximum on the version number ie if a new
feature is added in build 3.1.2 that you require for your code to
work, etc.

Is this not working for you, do you have some other requirement(s)
which are not currently available, or what?

Wayne

On 11/1/06, Rahamim, Zvi (Zvi) <[EMAIL PROTECTED]> wrote:

Hi,
I think that a very important feature is to have the ability to define,
before maven starts building, the versions of the dependencies.
Is there an intention to add this feature?
Thanks!
Zvi.

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

Additional features for maven2 plugin

[Rahamim, Zvi \(Zvi\)]

Hi,
I think that a very important feature is to have the ability to define,
before maven starts building, the versions of the dependencies.
Is there an intention to add this feature?
Thanks!
Zvi.

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

Question about packaging QPAC

[Kendy Yus]

Hi 
All,

 
I am trying to use Maven to package 
an Adobe QPAC component as a JAR file.  These component JAR files have a 
special structure, somewhat like WAR and EAR files, to include dependent 
libraries and some configuration elements. Below is an example component JAR 
file:
 
   
qpac-component.jar
 
|- classes (which contains the classes: 
com/mycompany/...)
 
|- lib (which contains dependent library jar 
files)
 
|- META-INF
 
`- and other resource files (xml configurations, 
etc.)
 
Using the Maven standard JAR 
packaging I get the directory structure like:
 
   
maven-standard.jar
 
|- com/mycompany/... 
 
|- META-INF
 
`- and other resource files (xml configurations, 
etc.)
 
What is the 
best Maven approach for me to be able to create a QPAC component JAR file, with 
all the dependent libraries derived from the POM file?
 
Thank you. 

 




  
  

  

  Kendy 
  Yus Software 
  Engineer Tel:+61 2 9976 4500 
   Fax: +61 2 9976 5055 Web: www.avoka.com  Email: 
  [EMAIL PROTECTED]

 


smime.p7s
Description: S/MIME cryptographic signature

JavaDoc Plug

[Brehm, Robert P]

Hi,

 

I am using Maven 2 and here is my dilemma:  

 

We have internal projects some of which are compiled in Java 1.4 and
some in Java 1.5.

 

My JAVA_HOME is set to  .. j2sdk1.4.2_04

 

In my POM I have included 

 



   



org.apache.maven.plugins

maven-compiler-plugin



true

1.5

1.5

1.5

 
/apps/java/jdk1.5.0_07/bin/javac



 







 

org.apache.maven.plugins

maven-javadoc-plugin



128m

512



  



  

 

I get compilation errors and 

Command line was:/apps/java/j2sdk1.4.2_04/jre/../bin/javadoc
-J-DproxyHost=13.62.6.90 -J-DproxyPort=8080 -J-Xmx512m -J-Xms128m
@options @packages 

 

So it used the JAVA_HOME for the javadoc bin file.

 

I tried adding this to the javadoc configuration:
/apps/java/jdk1.5.0_07/bin/javadoc and this
time javadoc did nothing.

 

I am stuck.

 

Any suggestions?

 

Regards,

 

Bob

 



Robert P. Brehm

Software Engineer, Manufacturing Technology Development

Xerox Office Group, Wilsonville, OR, USA

503-685-2329

 

Re: Using an OSGi bundle built with maven from an eclipse RCP project?

[Barrie Treloar]

Ok.  Thanx!  Now I'm able to add it as a required plug-in in an RCP
project.  But I'm still not able to list its exported package when
clicking "Add.." in "Imported Packages" in the RCP project.


You might be better off asking this on the Eclipse list since it is
probably not a maven specific issue, especially if the plugin is
visible from "reload" on your target.

However, have you tried the Right click on the project in Package
Explorer -> PDE -> Update Classpath? I find that step fixes my woes
most of the time.

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

Re: Using an OSGi bundle built with maven from an eclipse RCP project?

[Tom Huybrechts]

On 10/31/06, Steinar Bang <[EMAIL PROTECTED]> wrote:


> "Tom Huybrechts" <[EMAIL PROTECTED]>:

> You can create a 'target platform' directory which contains all the jars
of
> plugins you use. Then set this directory in Preferences > PDE > Target
> platform. You will have to add ALL the plugins you use, even the core
> eclipse plugins.
> But later you can just add stuff here and press reload on the same
> preference page.

Ok.  Thanx!  Now I'm able to add it as a required plug-in in an RCP
project.  But I'm still not able to list its exported package when
clicking "Add.." in "Imported Packages" in the RCP project.



I can think of two things:
- you have already added it as a required bundle. Remove it, and try to add
an imported package again
- there is something wrong with the export-package header. Open your plugin
in the 'Plugins'-view and check the manifest.



Here's what I did (this is eclipse-3.2 on Ubuntu Dapper):

- Did the commands:
mkdir $HOME/ecplise_pde_plugins
cd $HOME/ecplise_pde_plugins
(cd /usr/local/eclipse-3.2; tar cf - plugins) | tar xf -
- Selected Window->Preferences... from the menus
- Open "Plug-in Development" and select "Target Platform"
- In the "Location" field clicked on "Browse..." and browsed to the
   $HOME/ecplise_pde_plugins directory

That made all of the recular plug-ins show up.

Then I dropped in an OSGi bundle, clicked on "Reload", and as you
said, the plug-in showed up.

> You could even create a POM for your target platform that copies
> everything from the maven repo.

> If you go for the second option, you will probably no longer have a
> PDE project and will lose the PDE's support for running OSGi
> applications.

Quite.

Thanx for the solution! :-)

I'm not sure this is the solution I'll eventually want (I'm not happy
with having a copy of the eclipse platform, and mixing the platform
plug-ins with something particular to one project), but it gives me a
fallback.



I only keep the platform and thirdparty plugins in the target platform, and
it is checked into SVN.  All other projects come as source projects.
Especially if you work in teams, an additional advantage is that you will
not be dependent on the Eclipse version a developer happens to be using - so
you can try out the latest 3.3 milestone while still developping against
3.2...

Tom




-

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

SV: added dependancy to war file

[Hermod Opstvedt]

Hi

You can't have these as dependencies in th parent pom unless you have them
in different profiles. If you don't use profiles you will have to have them
as dependencies in each war's pom.

Hermod


www.opstvedt.com -Opprinnelig melding-
Fra: Mick Knutson [mailto:[EMAIL PROTECTED] 
Sendt: 31. oktober 2006 19:48
Til: maven
Emne: added dependancy to war file

I have a project that has 2 different war file modules.
war 1 uses ADFaces, war 2 uses MyFaces.

My parent pom.xml has the declaration for both under dependacy management.

I cd into the dir for the war 2 and run mvn clean package and I get the ADF
Faces libs as well as MyFaces libs included in the was 2. This is causing me
deployment issues and errors and I have tried to add them in war 2 like:


com.oracle.adf-faces
adf-faces-api
provided


com.oracle.adf-faces
adf-faces-impl
provided


com.oracle.adf-faces
adf-share
provided



but they still are included.

How can I get rid of ADF in war 2?

-- 

Thanks

DJ MICK
http://www.djmick.com
http://www.myspace.com/mickknutson


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

Re: Consistency of deployed modules

[Max Cooper]

Run maven twice:

  mvn clean install
  if (success) mvn deploy

Build server software like Luntbuild can automate this for you.

-Max

[EMAIL PROTECTED] wrote:

I have a multi-project build. I run a "mvn clean deploy" build every
night. Sometimes the builds fail with one of the modules and I end up
with an inconsistent set of deployed modules. How can I delay the
deployment of the modules so that the deploy happens only when all of
the modules have sucessfully completed the install phase of the
life-cycle. This way, I always have a consistent set of modules.

Thanks

-Moiz


-
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: ZIP Dependencies

[Shelley]

The dependencies were being declared in an EAR which only recognizes a
limited set of standard mappings by default.  The zip type had to be
configured as a custom artifactTypeMapping:

 

 

http://maven.apache.org/plugins/maven-ear-plugin/introduction.html


Wendy Smoak-3 wrote:
> 
> You'll need to install or deploy them to your repository, then you can use
> 
> 
>...
>   zip
> 
> http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_dependency
> 

-- 
View this message in context: 
http://www.nabble.com/ZIP-Dependencies-tf2546986s177.html#a7103479
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Maven rant

[Arnaud Bailly]

"Wayne Fay" <[EMAIL PROTECTED]> writes:

> The "Documentation Check" (DOCCK) plugin was recently created to help
> address this very issue. It will help not only Maven but also its
> plugins and even other projects/plugins using Maven.
>

Hello to all, 
And first great thanks to all maven developers and contributors for creating
this really fascinating tool. 
I have been using maven 1.x and 2.z for about three now I think, in
the beginning casually then on a regular basis for later projects (and
when maven 2.0 was released). I have written plugins, filed one or two
Jira issues, contributed to the best of my ability to MLs, started
some discussions about maven reporting. I even use maven to generate
my site and use custom skins (BTW, something painful given that
you have to use such awful things as Velocity. My apologies to any
Velocity team member lurking around there :-)), and tried writing a
custom extension for doxia. I would be more than happy to contribute
further but there are major issues I have been facing:
 1. time is lacking to undertake the kind of things I would like to
 see in maven
 2. development documentation is well below any standard

Point 1 is beyond control, but other point deserve some explanations. As
an example, take the class
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer. This class is
responsible for the whole site generation process in doxia (and then
maven) and there
are about ten lines of comments in it (500 lines of code). Neither in the 
interface
Renderer it implements. I am not particulary proud of my coding
abilities and would certainly not rank among top level coders in any
contest, but I know two things for sure about software engineering:
write comments where they are useful, write thorough unit tests to
further document and assert the quality of your the code (and your
understanding of th erequirements). This have hurt me when I tried
to extend Doxia with a new module. I am not of course pointing at
anyone in particular, as this state of affair is really common in all
maven code fragments I have seen. But when you add poor code documentation
to no user documentation...

Last but not least, I follow Jeff Muntunho in his rant when he says
that support from developers is rather scarce. I know that open source
is a harsh mistress and I am sure this is not a willingful attitude, but it is
sometimes discouraging not to have answers from those who know. 

my 50 cents,
-- 
Arnaud Bailly, PhD.
OQube < software engineering \ génie logiciel >
\web> http://www.oqube.com


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

Consistency of deployed modules

[dohadwala_moiz]

I have a multi-project build. I run a "mvn clean deploy" build every
night. Sometimes the builds fail with one of the modules and I end up
with an inconsistent set of deployed modules. How can I delay the
deployment of the modules so that the deploy happens only when all of
the modules have sucessfully completed the install phase of the
life-cycle. This way, I always have a consistent set of modules.

Thanks

-Moiz


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

Problems with Repos?

[JRatTFT]

Hi,

I sat down to work today and have blown a few hours trying to debug a
project that has very few dependencies. It seems there's some
cross-polination with POMs 

10/31/06 3:51:25 PM EST: Unable to get dependency information: Unable to
read the metadata file for artifact
'org.springframework:spring-context:jar': Error getting POM for
'org.springframework:spring-context' from the repository: Error transferring
file
  org.springframework:spring-context:pom:2.4.1

from the specified remote repositories:
  central (http://ibiblio.org/maven2),
  spring (https://svn.sourceforge.net/svnroot/springframework/repos/repo/),
  mergere (http://repo.mergere.com/maven2)
 org.springframework:spring-context-2.4.1.jar

spring-context-2.4.1? Spring just had a highly popular 2.0 release and the
2.4.1 makes no sense.

This compiled and tested fine yesterday now my dependencies are all messed
up. 

Has this happened to anyone today?
-- 
View this message in context: 
http://www.nabble.com/Problems-with-Repos--tf2548339s177.html#a7102487
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Method for synching Devlopment Repository to Remote Repository

[jp4]

The client that I am currently working for has a very strict process for
approving the use of open source software and third party libraries.  As a
result, we basically have to allow access to only a single repository which
a few developers have access to upload libraries and sync to other
repositories.  The hope is that developers won't be able to just add a new
dependency to their project if the dependency isn't installed on the
development repository.

I am curious if anyone has run into this, and if so, how did you approach
the problem?  In addition, is it possible to override the SUPER POM?

Thanks,

jp4
-- 
View this message in context: 
http://www.nabble.com/Method-for-synching-Devlopment-Repository-to-Remote-Repository-tf2548291s177.html#a7102345
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: [ANT] Passing Maven implicit variables to Ant script

[Manu]

Ok, I'll try one of the two (or even both).
Thx for your rapidity to reply

-Manu-

2006/10/31, Siegfried Goeschl <[EMAIL PROTECTED]>:


Hi Manu,

+) if you need to retrieve more data from the POM you can also use
maven-artifact-ant-2.0

+) AFAIK not even environment variables are passed to ANT script

Cheers,

Siegfried Goeschl

Alexander Sack wrote:
> Manu, just thinking out load, though this may not be what your looking
for,
> could you use some form of
>
> 
>  
> 
>
> Then reference ${somename} in your ant build file.  Something like
that...
>
> -aps
>
> On 10/31/06, Manu <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi all,
>>
>> I'm trying to do something rather simple: pass the Maven "finalName"
>> to my
>> Ant script, and can't make it.
>> Does anyone know how to do it ?
>> I precise I'm calling an external ant script through the following:
>>
>> 
>>  
>>   > />
>> [...]
>>
>>
>> Thxs for any clue.
>>
>> --
>> Manu
>>
>>
>
>

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





--
Manu (:-Þ)

Re: [ANT] Passing Maven implicit variables to Ant script

[Siegfried Goeschl]

Hi Manu,

+) if you need to retrieve more data from the POM you can also use 
maven-artifact-ant-2.0


+) AFAIK not even environment variables are passed to ANT script

Cheers,

Siegfried Goeschl

Alexander Sack wrote:

Manu, just thinking out load, though this may not be what your looking for,
could you use some form of


 


Then reference ${somename} in your ant build file.  Something like that...

-aps

On 10/31/06, Manu <[EMAIL PROTECTED]> wrote:



Hi all,

I'm trying to do something rather simple: pass the Maven "finalName" 
to my

Ant script, and can't make it.
Does anyone know how to do it ?
I precise I'm calling an external ant script through the following:


 
  
[...]


Thxs for any clue.

--
Manu







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

Re: [ANT] Passing Maven implicit variables to Ant script

[Alexander Sack]

Manu, just thinking out load, though this may not be what your looking for,
could you use some form of


 


Then reference ${somename} in your ant build file.  Something like that...

-aps

On 10/31/06, Manu <[EMAIL PROTECTED]> wrote:


Hi all,

I'm trying to do something rather simple: pass the Maven "finalName" to my
Ant script, and can't make it.
Does anyone know how to do it ?
I precise I'm calling an external ant script through the following:


 
  
[...]


Thxs for any clue.

--
Manu





--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson

[ANT] Passing Maven implicit variables to Ant script

[Manu]

Hi all,

I'm trying to do something rather simple: pass the Maven "finalName" to my
Ant script, and can't make it.
Does anyone know how to do it ?
I precise I'm calling an external ant script through the following:



 
   [...]


Thxs for any clue.

--
Manu

Re: [M2]weblogic:appc classpath issue

[Manu]

Hi,

I have the same problem. I need to explicitly set the entire  by
hand to have it worked. In other words, I'm defining another time all the
dependencies that already are in the pom. The plugin does not seem to take
into account the dependencies.

By the way, i'm using version 2.8.0-SNAPSHOT

Thxs
Manu

2006/10/31, Dmystery <[EMAIL PROTECTED]>:



Alos, looking at AppcMojo.class file, i dont see any default classpath
being
set. Here is the stack trace when i try to run the plugin.

[INFO]  Detailed Appc settings information AppcMojo[basicClientJar = false
classpath = null
compiler = null
debugging = true
deprecation = false
forceGeneration = false
idl = false
idlDirectory = null
idlFactrories = false
idlMethodSignatures = null
idlNoAbstractInterfaces = true
idlNoValueTypes = true
idlOrbix = false
idlOverwrite = false
idlVerbose = false
idlVisiBroker = false
iiop = false
iiopDirectory = null
javaOptions = null
keepGenerated = true
lineNumbers = true
nowarnings = false
objectPath =
D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-
1.0.jar
optimization = false
outputFile = null
verbose = true
version = false]
[INFO]  Argument List for Appc settings [-lineNumbers, -keepgenerated, -g,
-verb
ose,
D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-1.0.jar]
[appc] Created working directory:
C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen

[J2EE:160119]Appc is unable to process the file
'D:\Castle-maven\castle\server\s
erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred:
java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB >This is a
compile dependency in the POM
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12
3)
at
weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic
ClassLoader.java:480)
at
weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass
Loader.java:182)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at
weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass
Loader.java:224)
at
weblogic.ejb20.deployer.BeanInfoImpl.loadClass(BeanInfoImpl.java:343)

at
weblogic.ejb20.deployer.BeanInfoImpl.(BeanInfoImpl.java:192)
at
weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.(ClientDrivenB
eanInfoImpl.java:179)
at
weblogic.ejb20.deployer.SessionBeanInfoImpl.(SessionBeanInfoImp
l.java:74)
at
weblogic.ejb20.deployer.BeanInfoImpl.createBeanInfoImpl(BeanInfoImpl.
java:367)
at
weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.initializeBeanInfos(M
BeanDeploymentInfoImpl.java:548)
at
weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.(MBeanDeploymen
tInfoImpl.java:232)
at weblogic.ejb20.ejbc.EJBCompiler.setupEJB(EJBCompiler.java:155)
at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java
:415)
at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java
:387)
at weblogic.appc.compileEJB(appc.java:802)
at weblogic.appc.compileEJB(appc.java:776)
at weblogic.appc.compileInput(appc.java:463)
at weblogic.appc.runBody(appc.java:184)
at weblogic.utils.compiler.Tool.run(Tool.java:192)
at weblogic.utils.compiler.Tool.run(Tool.java:147)
at weblogic.appc.main(appc.java:1030)
at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:276)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:140)
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:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
a

added dependancy to war file

[Mick Knutson]

I have a project that has 2 different war file modules.
war 1 uses ADFaces, war 2 uses MyFaces.

My parent pom.xml has the declaration for both under dependacy management.

I cd into the dir for the war 2 and run mvn clean package and I get the ADF
Faces libs as well as MyFaces libs included in the was 2. This is causing me
deployment issues and errors and I have tried to add them in war 2 like:

   
   com.oracle.adf-faces
   adf-faces-api
   provided
   
   
   com.oracle.adf-faces
   adf-faces-impl
   provided
   
   
   com.oracle.adf-faces
   adf-share
   provided
   


but they still are included.

How can I get rid of ADF in war 2?

--

Thanks

DJ MICK
http://www.djmick.com
http://www.myspace.com/mickknutson

Re: Using an OSGi bundle built with maven from an eclipse RCP project?

[Steinar Bang]

> "Tom Huybrechts" <[EMAIL PROTECTED]>:

> You can create a 'target platform' directory which contains all the jars of
> plugins you use. Then set this directory in Preferences > PDE > Target
> platform. You will have to add ALL the plugins you use, even the core
> eclipse plugins.
> But later you can just add stuff here and press reload on the same
> preference page.

Ok.  Thanx!  Now I'm able to add it as a required plug-in in an RCP
project.  But I'm still not able to list its exported package when
clicking "Add.." in "Imported Packages" in the RCP project.

Here's what I did (this is eclipse-3.2 on Ubuntu Dapper):
 - Did the commands:
mkdir $HOME/ecplise_pde_plugins
cd $HOME/ecplise_pde_plugins
(cd /usr/local/eclipse-3.2; tar cf - plugins) | tar xf -
 - Selected Window->Preferences... from the menus
 - Open "Plug-in Development" and select "Target Platform"
 - In the "Location" field clicked on "Browse..." and browsed to the
   $HOME/ecplise_pde_plugins directory

That made all of the recular plug-ins show up.

Then I dropped in an OSGi bundle, clicked on "Reload", and as you
said, the plug-in showed up.

> You could even create a POM for your target platform that copies
> everything from the maven repo.

> If you go for the second option, you will probably no longer have a
> PDE project and will lose the PDE's support for running OSGi
> applications.

Quite.

Thanx for the solution! :-)

I'm not sure this is the solution I'll eventually want (I'm not happy
with having a copy of the eclipse platform, and mixing the platform
plug-ins with something particular to one project), but it gives me a
fallback.


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

ZIP Dependencies

[Shelley Lock]

With some of our JAR/WAR projects, we create secondary project end states with 
the ZIP format using the assembly plugin.  Is there any way to declare these 
assembled zips as dependencies of other projects?  Thanks!
 
-
Want to start your own business? Learn how on  Yahoo! Small Business. 

Using properties in a parent reference causes problems

[Morgovsky, Alexander \(US - Glen Mills\)]

I defined some properties in my profile in my settings.xml file.  These
properties get resolved correctly unless they are used in a parent
reference.  Is this is a bug?



  
true
  
  
1.0.0
  



Works:


a
a
${app_version}


Does not work:


a
a
${app_version}


Please help. 


This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law.  If 
you are not the intended recipient, you should delete this message. 


Any disclosure, copying, or distribution of this message, or the taking of any 
action based on it, is strictly prohibited. [v.E.1]

Re: Excluding sub-modules when doing site in parent module

[Ralph Pöllath]

On 31.10.2006, at 17:00, Dan Adams wrote:
I have a parent module that I want a site generated for but I don't  
need

the site generated for each of the submodules. Is there an option so
that when I run 'mvn site' it only does the current parent module and
not the submodules? Thanks.


Have you tried the --non-recursive command line switch?

$ mvn -h
Options:
-N,--non-recursiveDo not recurse into sub-projects

Cheers,
-Ralph.


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

Excluding sub-modules when doing site in parent module

[Dan Adams]

I have a parent module that I want a site generated for but I don't need
the site generated for each of the submodules. Is there an option so
that when I run 'mvn site' it only does the current parent module and
not the submodules? Thanks.

-- 
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857


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

Re: ZIP Dependencies

[Wendy Smoak]

On 10/31/06, Shelley Lock <[EMAIL PROTECTED]> wrote:


With some of our JAR/WAR projects, we create secondary project end states with 
the ZIP format using the assembly plugin.  Is there any way to declare these 
assembled zips as dependencies of other projects?  Thanks!


You'll need to install or deploy them to your repository, then you can use


  ...
 zip

http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_dependency

--
Wendy

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

Re: Daily builds

[Raphaël Piéroni]

2006/10/31, Emmanuel Venisse <[EMAIL PROTECTED]>:




Raphaël Piéroni a écrit :
> Hi,
>
> I have found in the nabble archive a way to retrieve the latests version
of
> continuum
> with an URL like people.apache.org/~continuum/...
>
> Is there a same URL for Archiva ? (i had try replacing continuum with
> archive or mrm but without any success)

Not yet.

>
> I ask this question because, i always fail to build archiva (even with a
> fresh checkout and local repository). Is there a special remote
repository
> configuration needed ?

Archiva build fine. What is your pb?



Compilation error on missing class plexus.Archiver (can't remember the exact
name here at work).

Probably because of a misuse of the repositories (i use central, codehaus,
codehaus-snapshot).

Raphaël

SV: mevenide vs. m2eclipse?

[Hermod Opstvedt]

Hi

Why!? - There is already such a plugin from codehaus

Hermod


-Opprinnelig melding-
Fra: Martin van den Bemt [mailto:[EMAIL PROTECTED] 
Sendt: 30. oktober 2006 19:50
Til: Maven Users List
Emne: Re: mevenide vs. m2eclipse?

I am working on a m2 eclipse plugin, but that is not public yet..

Mvgr,
Martin

Steinar Bang wrote:
> I'm currently using the m2eclipse plugin in eclipse 3.2, and it
> works. 
> 
> But today I thought that it was a pity that it didn't have a POM
> editor.  So I googled for "eclipse pom editor" and discovered
> "mevenide". 
>  http://mevenide.codehaus.org/mevenide-ui-eclipse/features.html
> (which has a POM editor, in case you wondered)
> 
> So I'm wondering about the relationship between m2eclipse and
> mevenide, eg. are they in conflict?  Are they complimentary?  What
> advantages do one offer over the other?
> 
> Googling for "mevenide vs. m2eclipse" found me this
>  http://www.onjava.com/pub/a/onjava/2006/03/29/maven-2-0.html?page=last
> search for "mevenide" in that page for "Eclipse integration" and
> you'll find an article saying mevenide only supports maven 1.x.
> 
> But this was in April.  Does anyone know if that's still the case?
> 
> The http://mevenide.codehaus.org/ says the NetBeans plugin has Maven 2
> support, but since nonde of the other mentions it I'm assuming they
> are still on Maven 1.x?
> 
> Thanx!
> 
> 
> - Steinar
> 
> 
> -
> 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: Maven rant

[Wayne Fay]

The "Documentation Check" (DOCCK) plugin was recently created to help
address this very issue. It will help not only Maven but also its
plugins and even other projects/plugins using Maven.

Maven Dev has established a baseline for expected documentation and
will now use this plugin to enforce that baseline for all plugins etc.

This doesn't help much if other Plugin sites (ie Codehaus) don't adopt
the plugin into their process too, or if you're looking to use a
random plugin created and hosted entirely independent of Maven, but it
should help alleviate this issue for many plugins.

Wayne

On 10/31/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

On 10/31/06, Sebastien Arbogast <[EMAIL PROTECTED]> wrote:

> Think of Hibernate or PHP documentation: one base reference book with
> DYNAMIC comments in which people can share their thoughts and
> experiences about each feature/chapter, remarks that can be later
> integrated when the reference is rewritten. The problem is that,
> whereas development itself is a highly-collaborative and efficient
> process, nothing is really done so that documentation writing is
> collaborative enough: no workflow, no direct input, no dynamic
> comments, etc.

Many of the plugins have improved docs that haven't been published
yet.  That's on my list for this weekend, determining whether it's
okay to publish them, or whether we need to establish a separate area
for the latest-and-greatest docs that may not match the released
version.

What I'd like to do for comments is make use of the MAVENUSER wiki
[1].  I'd like to see a link on every plugin site so that users can
share configuration examples or tell us that something is just plain
wrong.

What do you think?  Any ideas on how to present that as an option?
What would the menu link be called?  How should the pages on the wiki
be organized?

(The Better Builds book belongs to Mergere, so they would have to
agree to any changes in the way it is produced.)

[1] http://docs.codehaus.org/display/MAVENUSER/Home

--
Wendy

-
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: Using an OSGi bundle built with maven from an eclipse RCP project?

[Tom Huybrechts]

You can create a 'target platform' directory which contains all the jars of
plugins you use. Then set this directory in Preferences > PDE > Target
platform. You will have to add ALL the plugins you use, even the core
eclipse plugins. But later you can just add stuff here and press reload on
the same preference page. You could even create a POM for your target
platform that copies everything from the maven repo.

If you go for the second option, you will probably no longer have a PDE
project and will lose the PDE's support for running OSGi applications.

Tom

On 10/31/06, Steinar Bang <[EMAIL PROTECTED]> wrote:


If I would like to access an API residing in an OSGi bundle (built
with maven) from an eclipse RCP project, what's the
correct/best/simplest way to make that API available in the RCP
project:

1. stop eclipse, drop the bundle JAR into the plugins project, start
eclipse and browse to the bundle's exported package in the
MANIFEST.MF file editor?

2. create a pom.xml that can be used to generate neccessary
MANIFEST.MF info of the RCP project, and m2eclipse enable that
project so that the MANIFEST.MF in the future will be generated
from pom.xml, and there will be a "Maven2 Dependencies" entry
pointing into the maven repo where the OSGi bundle resides?

3. other...?

or perhaps none of the above (ie. "not possible")?

Thanx!


- Steinar


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

Re: AW: Notify only developers who committed changes?

[Emmanuel Venisse]

I'm not sure it will be in 1.1, but maybe someone will provide a patch.

Emmanuel

Lennart Lopin a écrit :

Will it be available in an upcoming release? Even if its due to some
dependency changes it will still be nice to send an alert to individual
developers based on the source code they just checked in.

Regards,

Lennart

|  -Ursprüngliche Nachricht-
|  Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
|  Gesendet: Dienstag, 31. Oktober 2006 14:48

|  An: continuum-users@maven.apache.org
|  Betreff: Re: Notify only developers who committed changes?
|  
|  
|  No, this feature isn't available.
|  A build broken isn't necessary the fault of a developers 
|  because it can be due to a dependency change.
|  
|  Emmanuel
|  
|  Ralph Pöllath a écrit :

|  > Hi,
|  > 
|  > When a build breaks, is it possible to notify only those 
|  developers 
|  > who

|  > committed changes?
|  > 
|  > Cheers,

|  > -Ralph.
|  > 
|  > 
|  > 
|  > 
|  > 
|  

AW: Notify only developers who committed changes?

[Lennart Lopin]

Will it be available in an upcoming release? Even if its due to some
dependency changes it will still be nice to send an alert to individual
developers based on the source code they just checked in.

Regards,

Lennart

|  -Ursprüngliche Nachricht-
|  Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
|  Gesendet: Dienstag, 31. Oktober 2006 14:48
|  An: continuum-users@maven.apache.org
|  Betreff: Re: Notify only developers who committed changes?
|  
|  
|  No, this feature isn't available.
|  A build broken isn't necessary the fault of a developers 
|  because it can be due to a dependency change.
|  
|  Emmanuel
|  
|  Ralph Pöllath a écrit :
|  > Hi,
|  > 
|  > When a build breaks, is it possible to notify only those 
|  developers 
|  > who
|  > committed changes?
|  > 
|  > Cheers,
|  > -Ralph.
|  > 
|  > 
|  > 
|  > 
|  > 
|  

Daily builds

[Raphaël Piéroni]

Hi,

I have found in the nabble archive a way to retrieve the latests version of
continuum
with an URL like people.apache.org/~continuum/...

Is there a same URL for Archiva ? (i had try replacing continuum with
archive or mrm but without any success)

I ask this question because, i always fail to build archiva (even with a
fresh checkout and local repository). Is there a special remote repository
configuration needed ?


Many thanks in advance for any help.


Raphaël

Re: finalName

[Wendy Smoak]

On 10/30/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

Okay, so the docs for finalName differ on
   http://maven.apache.org/maven-v4_0_0.xsd
and
   http://maven.apache.org/ref/2.0.4/maven-model/maven.html

My guess is that the xsd needs to be re-generated, since the 2.0.4
docs describe the current behavior.


Shelley, thanks for bringing this up.  The xsd has been re-generated
and published.  The docs for finalName now read:

The filename (excluding the extension, and with no path information)
that the produced
artifact will be called. The default value is ${artifactId}-${version}

--
Wendy

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

Re: Codehaus repository needed even using released plugins only

[Carlos Sanchez]

yes, it's already logged in jira and fixed for next version

On 10/31/06, Syvalta <[EMAIL PROTECTED]> wrote:



Syvalta wrote:
>
> Here's the output from my colleague (without stack trace, I'll see if he's
> still seeing the problem and provide the trace if possible).
>

The full stack trace is above. Could it be that if the connection fails,
rest of the repositories aren't searched? I mean, if the file is not found,
it is tried to be loaded from other repos, but if the connection timeouts
etc., it isn't. Would that make sense?

+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from:
'.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'maven\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[INFO] Reactor build order:
...
[INFO]

[INFO] Building parent project
[INFO]task-segment: [install]
[INFO]

[DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository
central
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for
project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project:
org.apache.maven.plugins:maven-plugins:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project:
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG] maven-install-plugin: resolved to version 2.1 from repository
central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
null:maven-install-plugin:maven-plugin:2.1 from the repository.
[DEBUG]
org.apache.maven.plugins:maven-site-plugin:maven-plugin:2.0-beta-5:runtime
(selected for runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project:
null:maven-settings:jar:2.0 from the repository.
[DEBUG]   org.apache.maven:maven-settings:jar:2.0:runtime (selected for
runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for
runtime)
[DEBUG]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime
(selected for runtime)
[DEBUG]   classworlds:classworlds:jar:1.1-alpha-2:runtime (selected for
runtime)
[DEBUG]   junit:junit:jar:3.8.1:runtime (selected for runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project:
org.apache.maven:maven-model:jar:2.0 from the repository.
[DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0.2 for project:
org.apache.maven:maven-artifact:jar:2.0.2 from the repository.
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0.2:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.4 for
project: null:plexus-utils:jar:1.1 from the repository.
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (removed -
nearer found: 1.0.4)
[DEBUG] Retrieving parent-POM: org.mortbay.jetty:project::6.0.0beta12 for
project: org.mortbay.jetty:jetty:jar:6.0.0beta12 from the repository.
[DEBUG]   org.mortbay.jetty:jetty:jar:6.0.0beta12:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.mortbay.jetty:project::6.0.0beta12 for
project: org.mortbay.jetty:servlet-api-2.5:jar:6.0.0beta12 from the
repository.
[DEBUG] org.mortbay.jetty:servlet-api-2.5:jar:6.0.0beta12:runtime
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed -
nearer found: 1.1)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.1:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven.doxia:doxia::1.0-alpha-8 for
project: null:doxia-site-renderer:jar:1.0-alpha-8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project:
org.apache.maven.doxia:doxia:pom:1.0-alpha-8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project:
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG]   org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:runtime
(selected for runtime)
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus-components::1.1.4
for project: null:plexus-i18n:jar:1.0-beta-6 from the repository.
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.4 for
project: org.codehaus.plexus:plexus-components:pom:1.1.4 from the
repository.
[DEBUG] org.codehaus.plexus:plexus-i18n:jar:1.0-beta-6:runtime (selected
for runtime)
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus-components::1.1.5
for project: null:plexus-velocity:jar:1.1.3 from the repository.
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.5 for
project: org.codehaus.plexus:plexus-components:pom:1.1.5 from the
repository.
[DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.3:runtime (selected
for r

Re: Snapshot

[Eric Redmond]

http://maven.apache.org/guides/development/guide-building-m2.html

On 10/31/06, Javier Leyba <[EMAIL PROTECTED]> wrote:


Hi

I want to know how could I get the latest maven2 snapshot...

Thanks in advance


J

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





--
Eric Redmond
http://codehaus.org/~eredmond

Re: Daily builds

[Emmanuel Venisse]

Raphaël Piéroni a écrit :

2006/10/31, Emmanuel Venisse <[EMAIL PROTECTED]>:




Raphaël Piéroni a écrit :
> Hi,
>
> I have found in the nabble archive a way to retrieve the latests 
version

of
> continuum
> with an URL like people.apache.org/~continuum/...
>
> Is there a same URL for Archiva ? (i had try replacing continuum with
> archive or mrm but without any success)

Not yet.

>
> I ask this question because, i always fail to build archiva (even 
with a

> fresh checkout and local repository). Is there a special remote
repository
> configuration needed ?

Archiva build fine. What is your pb?



Compilation error on missing class plexus.Archiver (can't remember the 
exact

name here at work).


I don't see the usage of plexus-archiver except for plugins.



Probably because of a misuse of the repositories (i use central, codehaus,
codehaus-snapshot).


You don't need codehaus repo because it is sync with central.

Emmanuel

Re: Daily builds

[Raphaël Piéroni]

OK i will retry tonite
with a fresh checkout and with only one repository : central.

If i have any problem, i will post the trace on the archiva-dev list.

Thanks

Raphaël

PS: i now remember better, it failed on a test in web-application module,
the archiver compilation failure was with the continuum fresh checkout.

2006/10/31, Emmanuel Venisse <[EMAIL PROTECTED]>:




Raphaël Piéroni a écrit :
> 2006/10/31, Emmanuel Venisse <[EMAIL PROTECTED]>:
>>
>>
>>
>> Raphaël Piéroni a écrit :
>> > Hi,
>> >
>> > I have found in the nabble archive a way to retrieve the latests
>> version
>> of
>> > continuum
>> > with an URL like people.apache.org/~continuum/...
>> >
>> > Is there a same URL for Archiva ? (i had try replacing continuum with
>> > archive or mrm but without any success)
>>
>> Not yet.
>>
>> >
>> > I ask this question because, i always fail to build archiva (even
>> with a
>> > fresh checkout and local repository). Is there a special remote
>> repository
>> > configuration needed ?
>>
>> Archiva build fine. What is your pb?
>
>
> Compilation error on missing class plexus.Archiver (can't remember the
> exact
> name here at work).

I don't see the usage of plexus-archiver except for plugins.

>
> Probably because of a misuse of the repositories (i use central,
codehaus,
> codehaus-snapshot).

You don't need codehaus repo because it is sync with central.

Emmanuel

Re: Not embedding pom is jars

[Wendy Smoak]

On 10/31/06, Sebastien Brunot <[EMAIL PROTECTED]> wrote:


is there an easy way to specify that the pom files shouldn't be embedded
in a jar artifact (resulting from the package command) under META-INF ?


http://maven.apache.org/guides/mini/guide-archive-configuration.html

Try false

--
Wendy

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

Re: Daily builds

[Emmanuel Venisse]

Raphaël Piéroni a écrit :

Hi,

I have found in the nabble archive a way to retrieve the latests version of
continuum
with an URL like people.apache.org/~continuum/...

Is there a same URL for Archiva ? (i had try replacing continuum with
archive or mrm but without any success)


Not yet.



I ask this question because, i always fail to build archiva (even with a
fresh checkout and local repository). Is there a special remote repository
configuration needed ?


Archiva build fine. What is your pb?

Emmanuel

[M2 - eclipse plugin]Specify the eclipse.dependency between artifacts

[Alexandre Touret]

Hello,
is there a way to specify the project dependencies between some 
artifacts of a J2EE application in pom.xml ?
In my application, I have a war which depends of some JARS and I d like 
to specify this depencency with the eclipse  plugin


Is it possible ?
Thanks for your help!  
Regards,

Alexandre

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

Using an OSGi bundle built with maven from an eclipse RCP project?

[Steinar Bang]

If I would like to access an API residing in an OSGi bundle (built
with maven) from an eclipse RCP project, what's the
correct/best/simplest way to make that API available in the RCP
project:

 1. stop eclipse, drop the bundle JAR into the plugins project, start
eclipse and browse to the bundle's exported package in the
MANIFEST.MF file editor?

 2. create a pom.xml that can be used to generate neccessary
MANIFEST.MF info of the RCP project, and m2eclipse enable that
project so that the MANIFEST.MF in the future will be generated
from pom.xml, and there will be a "Maven2 Dependencies" entry
pointing into the maven repo where the OSGi bundle resides?

 3. other...?

or perhaps none of the above (ie. "not possible")?

Thanx!


- Steinar


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

[Reporting] Configuring SiteRenderer to change output format of reports

[Thorsten Kamann]

Hello,

I am planning to use Confluence as project website. Therefore i am searching
for a facillity to change the DefaultSiteRenderer in the pom.
I have tried this, but this doesn't work:


   
   
   org.fornax.toolsupport.maven
   fornax-maven-changelog-plugin
   1.0.0
   
   
org.fornax.toolsupport.maven.changelog.MySiteRenderer
   
   
   


Is there another chance to do this? Or must the Standard ReportMojos
(Issues, SCM, CI, Team...) been rewritten?

Thorsten

--
Thorsten Kamann
Software-Architect, Consultant, Coaching
Germany, NRW
[EMAIL PROTECTED]
http://www.planetes.de/thorsten-kamann/
callto://thorque

Re: Maven rant

[Wendy Smoak]

On 10/31/06, Sebastien Arbogast <[EMAIL PROTECTED]> wrote:


Think of Hibernate or PHP documentation: one base reference book with
DYNAMIC comments in which people can share their thoughts and
experiences about each feature/chapter, remarks that can be later
integrated when the reference is rewritten. The problem is that,
whereas development itself is a highly-collaborative and efficient
process, nothing is really done so that documentation writing is
collaborative enough: no workflow, no direct input, no dynamic
comments, etc.


Many of the plugins have improved docs that haven't been published
yet.  That's on my list for this weekend, determining whether it's
okay to publish them, or whether we need to establish a separate area
for the latest-and-greatest docs that may not match the released
version.

What I'd like to do for comments is make use of the MAVENUSER wiki
[1].  I'd like to see a link on every plugin site so that users can
share configuration examples or tell us that something is just plain
wrong.

What do you think?  Any ideas on how to present that as an option?
What would the menu link be called?  How should the pages on the wiki
be organized?

(The Better Builds book belongs to Mergere, so they would have to
agree to any changes in the way it is produced.)

[1] http://docs.codehaus.org/display/MAVENUSER/Home

--
Wendy

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

Re: Maven rant

[Jeff Mutonho]

On 10/31/06, Vincent Massol <[EMAIL PROTECTED]> wrote:
BTW

there's already a Maven wiki which is opened to anyone interested. It's been
there for more than a year but I wouldn't call the result comprehensive
documentation.

Thanks
-Vincent


I'm sure there are many people who might want to contribute but its
almost impossible to make valuable contribution when one does not the
knowledge.
I do appreciate the fact that as developers we hate documentation or
we might not even be good at it , but is it such a hard task to put a
few lines that say ..."This plugin does this and that , and here's one
or two examples of how to use itThe other flags or options that
you can play with are this and that...blah blah" .How hard is that?If
I wrote a plugin I would do my best to inform people how use it and
prevent them from getting trapped in quagmires  of endless hours
trying to figure out the most of the basic things a plugin can do.

Jeff  Mutonho

GoogleTalk : ejbengine
Skype: ejbengine
Registered Linux user number 366042

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

Re: Notify only developers who committed changes?

[Emmanuel Venisse]

No, this feature isn't available.
A build broken isn't necessary the fault of a developers because it can be due 
to a dependency change.

Emmanuel

Ralph Pöllath a écrit :

Hi,

When a build breaks, is it possible to notify only those developers who 
committed changes?


Cheers,
-Ralph.

Re: Maven rant

[Sebastien Arbogast]

2 thoughts about what you wrote Vincent:

I totally agree on the fact that a few people have to write the core
of the documentation before any community effort can be considered.
But at some point, a PDF and an errata page is not the best way to
create a community effort in order to keep this book up-to-date and
more accessible.

This leads me to the second point: Maven's wiki doesn't work for the
very same reason Cocoon one didn't, for the very same reason I've
never seen one good documentation effort based solely on a WIKI: no
structure! And that's exactly what your book could be useful as: some
sort of a spinal cord on which other content can be aggregated and
accumulated over time, and sometimes assimilated on a rewrite.
Moreover, I don't believe in Wikis at all because instead of adding
some information, it just replaces it, even if it keeps some kind of
version tracking behind the scenes.

IMHO, Maven documentation should look like that: http://drupal.org/handbooks

2006/10/31, Vincent Massol <[EMAIL PROTECTED]>:



> -Original Message-
> From: Sebastien Arbogast [mailto:[EMAIL PROTECTED]
> Sent: mardi 31 octobre 2006 14:18
> To: Maven Users List
> Subject: Re: Maven rant
>
> I totally agree but I think that the problem is very difficult to
> solve, especially with all the incredible amount of undeocumented
> features that Maven has. Moreover, the problem is amplified by the
> fact that Maven allows the generation of most of the documentation:
> but if you don't write it, it won't write itself, so you will endup
> with dead links everywhere.
>
> As I see it, the problem in most Open Source projects is that
> developers do that on their free time, and developers aren't writers:
> those are two completely different tasks and the second one is not the
> most enjoyable.
>
> And last but not least: Open Source software is highly evolutive: why
> bother write some documentation for a feature that can be replaced by
> something more interesting in no-time and without any possible
> anticipation.
>
> The thing is that Maven is not the first Maven project I work with
> which faces that very issue. I had exactly the same problems a few
> months ago with Cocoon guys, and my remark is still the same: why do
> project leaders keep on considering documentation as a static thing.
> Think of Hibernate or PHP documentation: one base reference book with
> DYNAMIC comments in which people can share their thoughts and
> experiences about each feature/chapter, remarks that can be later
> integrated when the reference is rewritten. The problem is that,
> whereas development itself is a highly-collaborative and efficient
> process, nothing is really done so that documentation writing is
> collaborative enough: no workflow, no direct input, no dynamic
> comments, etc. Think of it: "Better Builds With Maven" is the most
> comprehensive documentation about Maven2. But was it written
> collaboratively? No. And I'm convinced that if it had been, it would
> be much higher quality and much more accessible today.

Sebastien, I don't believe this is true. This is the same as any open source
project. It's not the community that creates an open source project. It's
one or two guys (possibly 3 ;-)). Then once there is a strong kernel
developed by these few guys then others will join and help. The same is true
for documentation. You need one or 2 leaders to first write the core of it.
This is what we've done with BBWM. Now I agree that a good idea could be to
build on it by opening it up to the community. But don't believe a single
instant that the community will write a good quality book by itself. BTW
there's already a Maven wiki which is opened to anyone interested. It's been
there for more than a year but I wouldn't call the result comprehensive
documentation.

Thanks
-Vincent

> 2006/10/31, dhoffer <[EMAIL PROTECTED]>:
> >
> > Jeff,
> >
> > I use maven and I really like it and I don't want this to sound like
> > negative criticism but you are right, the learning curve for maven
> newbie's
> > is huge and there just isn't much good docs available.  I have wound
> up
> > getting bits of pieces of info from here and there...it just takes so
> long.
> > It would be great if some maven gurus could solve this problem and
> make
> > maven more accessible.
> >
> >
> >
> > Jeff Mutonho wrote:
> > >
> > > Is maven in the process of unintentionally killing itself due to
> poor
> > > support and documentation?I may be wrong but I strongly feel that
> the
> > > poor support and documentation is hampering adoption of an
> otherwise
> > > brilliant tool.It always seems like the participation of plugin
> > > developers in answering questions from mere users like myself is
> > > non-existent.Then lets not forget the poor documentation.The BB
> book
> > > was an excellent idea ,but sometimes it just does not address
> problems
> > > users face on the "setup battle field" and the "configuration
> > > trenches" we're all familiar with.I'll g

RE: [m2] Surefire plugin - childDelegation

[Darren Hartford]

Anyone please?   

> -Original Message-
> From: Darren Hartford 
> Sent: Friday, October 27, 2006 9:27 AM
> To: users@maven.apache.org
> Subject: [m2] Surefire plugin - childDelegation
> 
> Hi all,
> Between 2.2-SNAPSHOT and 2.2 official, was there a change in 
> the way the childDelegation supported overriding java.* and javax.*?
> 
> I'm trying to identify why Embed EJB3 tests are no longer 
> working (regarding a javax.management issue with 
> JBossMXServerConfig classnotfound).  I have tests that used 
> to work when using an older version of 2.2-SNAPSHOT, but are 
> now no longer working.
> 
> References
> ===
> http://maven.apache.org/plugins/maven-surefire-plugin/examples
> /class-loading.html
> childDelegation property to true:
> Classes in the java.* and javax.* packages can never be overridden.
> 
> http://jira.jboss.com/jira/browse/EJBTHREE-534
> JBossMXServerConfig issue
> 
> http://mail-archives.apache.org/mod_mbox/maven-users/200606.mb
> ox/[EMAIL PROTECTED]
> similar problems
> 
> http://jira.codehaus.org/browse/SUREFIRE-38
> Alpha-6, configuring surefire with 
> pertestfalse
> 
> http://docs.codehaus.org/display/MAVENUSER/How+to+use+the+JBos
> s+Embedded+EJB3+Container+for+Unit+testing
> Sample setup (older surefire that maybe didn't mind 
> overriding javax.* packages) Personally tested on RC8 and 
> Surefire 2.2-SNAPSHOT with success.
> 

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

Re: Maven rant

[dhoffer]

I think your right; I understand it's a hard problem to solve.  That's way
I'm not negative on maven; I just think it's a big issue that needs
attention.  The people that know this stuff, the developers that write maven
probably aren't great documentation people or if they are just don't have
the time.  Is there a way that regular users, such as myself, can help?  I'm
neither a maven guru nor a web master...but once I understand something I
could do a decent job of wordsmithing it.



Sebastien Arbogast wrote:
> 
> I totally agree but I think that the problem is very difficult to
> solve, especially with all the incredible amount of undeocumented
> features that Maven has. Moreover, the problem is amplified by the
> fact that Maven allows the generation of most of the documentation:
> but if you don't write it, it won't write itself, so you will endup
> with dead links everywhere.
> 
> As I see it, the problem in most Open Source projects is that
> developers do that on their free time, and developers aren't writers:
> those are two completely different tasks and the second one is not the
> most enjoyable.
> 
> And last but not least: Open Source software is highly evolutive: why
> bother write some documentation for a feature that can be replaced by
> something more interesting in no-time and without any possible
> anticipation.
> 
> The thing is that Maven is not the first Maven project I work with
> which faces that very issue. I had exactly the same problems a few
> months ago with Cocoon guys, and my remark is still the same: why do
> project leaders keep on considering documentation as a static thing.
> Think of Hibernate or PHP documentation: one base reference book with
> DYNAMIC comments in which people can share their thoughts and
> experiences about each feature/chapter, remarks that can be later
> integrated when the reference is rewritten. The problem is that,
> whereas development itself is a highly-collaborative and efficient
> process, nothing is really done so that documentation writing is
> collaborative enough: no workflow, no direct input, no dynamic
> comments, etc. Think of it: "Better Builds With Maven" is the most
> comprehensive documentation about Maven2. But was it written
> collaboratively? No. And I'm convinced that if it had been, it would
> be much higher quality and much more accessible today.
> 
> Just my 2 cents.
> 
> 2006/10/31, dhoffer <[EMAIL PROTECTED]>:
>>
>> Jeff,
>>
>> I use maven and I really like it and I don't want this to sound like
>> negative criticism but you are right, the learning curve for maven
>> newbie's
>> is huge and there just isn't much good docs available.  I have wound up
>> getting bits of pieces of info from here and there...it just takes so
>> long.
>> It would be great if some maven gurus could solve this problem and make
>> maven more accessible.
>>
>>
>>
>> Jeff Mutonho wrote:
>> >
>> > Is maven in the process of unintentionally killing itself due to poor
>> > support and documentation?I may be wrong but I strongly feel that the
>> > poor support and documentation is hampering adoption of an otherwise
>> > brilliant tool.It always seems like the participation of plugin
>> > developers in answering questions from mere users like myself is
>> > non-existent.Then lets not forget the poor documentation.The BB book
>> > was an excellent idea ,but sometimes it just does not address problems
>> > users face on the "setup battle field" and the "configuration
>> > trenches" we're all familiar with.I'll give an example that relates to
>> > my experience.I posted questions relating to problems with the Maven
>> > Wagon plugin and in the process also thought it wise to see what the
>> > documents say.That led me to http://maven.apache.org/wagon/  and
>> > clicking on the Getting Started link I ended up at the URL
>> > http://maven.apache.org/wagon/guides/getting-started/index.html , and
>> > almost every link there leads to a :
>> > =
>> > Page Not Found
>> > Sorry, the page you requested was not found. This may because:
>> >
>> > * The page has moved, was outdated, or has not been created yet
>> > * You typed the address incorrectly
>> > * You following a link from another site that pointed to this page.
>> >
>> > We have recently reorganised our site, so please try looking in the
>> > navigation on the left for the item you are looking for on Maven 1.x
>> > or the Maven project. For information about Maven 2.0 or Continuum,
>> > please visit their sub sites, available from the links in the top
>> > right of the page. There is no need to report this broken link to the
>> > Maven team, as errors are periodically monitored and repaired.
>> >
>> > ===
>> >
>> > Same thing happens with the "Examples" link.Surely this cannot be a
>> > pleasant user experience for anyone , let alone for a poor newbie who
>> > might think lookin

RE: Maven rant

[Vincent Massol]

> -Original Message-
> From: Sebastien Arbogast [mailto:[EMAIL PROTECTED]
> Sent: mardi 31 octobre 2006 14:18
> To: Maven Users List
> Subject: Re: Maven rant
> 
> I totally agree but I think that the problem is very difficult to
> solve, especially with all the incredible amount of undeocumented
> features that Maven has. Moreover, the problem is amplified by the
> fact that Maven allows the generation of most of the documentation:
> but if you don't write it, it won't write itself, so you will endup
> with dead links everywhere.
> 
> As I see it, the problem in most Open Source projects is that
> developers do that on their free time, and developers aren't writers:
> those are two completely different tasks and the second one is not the
> most enjoyable.
> 
> And last but not least: Open Source software is highly evolutive: why
> bother write some documentation for a feature that can be replaced by
> something more interesting in no-time and without any possible
> anticipation.
> 
> The thing is that Maven is not the first Maven project I work with
> which faces that very issue. I had exactly the same problems a few
> months ago with Cocoon guys, and my remark is still the same: why do
> project leaders keep on considering documentation as a static thing.
> Think of Hibernate or PHP documentation: one base reference book with
> DYNAMIC comments in which people can share their thoughts and
> experiences about each feature/chapter, remarks that can be later
> integrated when the reference is rewritten. The problem is that,
> whereas development itself is a highly-collaborative and efficient
> process, nothing is really done so that documentation writing is
> collaborative enough: no workflow, no direct input, no dynamic
> comments, etc. Think of it: "Better Builds With Maven" is the most
> comprehensive documentation about Maven2. But was it written
> collaboratively? No. And I'm convinced that if it had been, it would
> be much higher quality and much more accessible today.

Sebastien, I don't believe this is true. This is the same as any open source
project. It's not the community that creates an open source project. It's
one or two guys (possibly 3 ;-)). Then once there is a strong kernel
developed by these few guys then others will join and help. The same is true
for documentation. You need one or 2 leaders to first write the core of it.
This is what we've done with BBWM. Now I agree that a good idea could be to
build on it by opening it up to the community. But don't believe a single
instant that the community will write a good quality book by itself. BTW
there's already a Maven wiki which is opened to anyone interested. It's been
there for more than a year but I wouldn't call the result comprehensive
documentation.

Thanks
-Vincent

> 2006/10/31, dhoffer <[EMAIL PROTECTED]>:
> >
> > Jeff,
> >
> > I use maven and I really like it and I don't want this to sound like
> > negative criticism but you are right, the learning curve for maven
> newbie's
> > is huge and there just isn't much good docs available.  I have wound
> up
> > getting bits of pieces of info from here and there...it just takes so
> long.
> > It would be great if some maven gurus could solve this problem and
> make
> > maven more accessible.
> >
> >
> >
> > Jeff Mutonho wrote:
> > >
> > > Is maven in the process of unintentionally killing itself due to
> poor
> > > support and documentation?I may be wrong but I strongly feel that
> the
> > > poor support and documentation is hampering adoption of an
> otherwise
> > > brilliant tool.It always seems like the participation of plugin
> > > developers in answering questions from mere users like myself is
> > > non-existent.Then lets not forget the poor documentation.The BB
> book
> > > was an excellent idea ,but sometimes it just does not address
> problems
> > > users face on the "setup battle field" and the "configuration
> > > trenches" we're all familiar with.I'll give an example that relates
> to
> > > my experience.I posted questions relating to problems with the
> Maven
> > > Wagon plugin and in the process also thought it wise to see what
> the
> > > documents say.That led me to http://maven.apache.org/wagon/  and
> > > clicking on the Getting Started link I ended up at the URL
> > > http://maven.apache.org/wagon/guides/getting-started/index.html ,
> and
> > > almost every link there leads to a :
> > > =
> > > Page Not Found
> > > Sorry, the page you requested was not found. This may because:
> > >
> > > * The page has moved, was outdated, or has not been created yet
> > > * You typed the address incorrectly
> > > * You following a link from another site that pointed to this
> page.
> > >
> > > We have recently reorganised our site, so please try looking in the
> > > navigation on the left for the item you are looking for on Maven
> 1.x
> > > or the Maven project. For information about Maven 2.0 or Continuum

Re: Maven rant

[Sebastien Arbogast]

I totally agree but I think that the problem is very difficult to
solve, especially with all the incredible amount of undeocumented
features that Maven has. Moreover, the problem is amplified by the
fact that Maven allows the generation of most of the documentation:
but if you don't write it, it won't write itself, so you will endup
with dead links everywhere.

As I see it, the problem in most Open Source projects is that
developers do that on their free time, and developers aren't writers:
those are two completely different tasks and the second one is not the
most enjoyable.

And last but not least: Open Source software is highly evolutive: why
bother write some documentation for a feature that can be replaced by
something more interesting in no-time and without any possible
anticipation.

The thing is that Maven is not the first Maven project I work with
which faces that very issue. I had exactly the same problems a few
months ago with Cocoon guys, and my remark is still the same: why do
project leaders keep on considering documentation as a static thing.
Think of Hibernate or PHP documentation: one base reference book with
DYNAMIC comments in which people can share their thoughts and
experiences about each feature/chapter, remarks that can be later
integrated when the reference is rewritten. The problem is that,
whereas development itself is a highly-collaborative and efficient
process, nothing is really done so that documentation writing is
collaborative enough: no workflow, no direct input, no dynamic
comments, etc. Think of it: "Better Builds With Maven" is the most
comprehensive documentation about Maven2. But was it written
collaboratively? No. And I'm convinced that if it had been, it would
be much higher quality and much more accessible today.

Just my 2 cents.

2006/10/31, dhoffer <[EMAIL PROTECTED]>:


Jeff,

I use maven and I really like it and I don't want this to sound like
negative criticism but you are right, the learning curve for maven newbie's
is huge and there just isn't much good docs available.  I have wound up
getting bits of pieces of info from here and there...it just takes so long.
It would be great if some maven gurus could solve this problem and make
maven more accessible.



Jeff Mutonho wrote:
>
> Is maven in the process of unintentionally killing itself due to poor
> support and documentation?I may be wrong but I strongly feel that the
> poor support and documentation is hampering adoption of an otherwise
> brilliant tool.It always seems like the participation of plugin
> developers in answering questions from mere users like myself is
> non-existent.Then lets not forget the poor documentation.The BB book
> was an excellent idea ,but sometimes it just does not address problems
> users face on the "setup battle field" and the "configuration
> trenches" we're all familiar with.I'll give an example that relates to
> my experience.I posted questions relating to problems with the Maven
> Wagon plugin and in the process also thought it wise to see what the
> documents say.That led me to http://maven.apache.org/wagon/  and
> clicking on the Getting Started link I ended up at the URL
> http://maven.apache.org/wagon/guides/getting-started/index.html , and
> almost every link there leads to a :
> =
> Page Not Found
> Sorry, the page you requested was not found. This may because:
>
> * The page has moved, was outdated, or has not been created yet
> * You typed the address incorrectly
> * You following a link from another site that pointed to this page.
>
> We have recently reorganised our site, so please try looking in the
> navigation on the left for the item you are looking for on Maven 1.x
> or the Maven project. For information about Maven 2.0 or Continuum,
> please visit their sub sites, available from the links in the top
> right of the page. There is no need to report this broken link to the
> Maven team, as errors are periodically monitored and repaired.
>
> ===
>
> Same thing happens with the "Examples" link.Surely this cannot be a
> pleasant user experience for anyone , let alone for a poor newbie who
> might think looking at the docs is a good start.In my example, what
> then can a user do besides thinking of  putting one's neck on the
> guillotine?One gets no help on the mailing list and the documentation
> isn't helpful either.
> I understand very well the idea that people are busy etc , but also
> feel that there's need for more participation  from plugin authors in
> helping mere users like myself and others who get stuck with problems
> only the maven gurus can solve...unless of course the plugins are only
> to be used by the authors themselves.
> Please don't take take this as whining , but rather , as a personal
> view and perhaps constructive criticism.
>
> --
>
>
> Jeff  Mutonho
>
> GoogleTalk : ejbengine
> Skype: ejbengine
> R

Re: Maven rant

[dhoffer]

Jeff,

I use maven and I really like it and I don't want this to sound like
negative criticism but you are right, the learning curve for maven newbie’s
is huge and there just isn't much good docs available.  I have wound up
getting bits of pieces of info from here and there...it just takes so long. 
It would be great if some maven gurus could solve this problem and make
maven more accessible.



Jeff Mutonho wrote:
> 
> Is maven in the process of unintentionally killing itself due to poor
> support and documentation?I may be wrong but I strongly feel that the
> poor support and documentation is hampering adoption of an otherwise
> brilliant tool.It always seems like the participation of plugin
> developers in answering questions from mere users like myself is
> non-existent.Then lets not forget the poor documentation.The BB book
> was an excellent idea ,but sometimes it just does not address problems
> users face on the "setup battle field" and the "configuration
> trenches" we're all familiar with.I'll give an example that relates to
> my experience.I posted questions relating to problems with the Maven
> Wagon plugin and in the process also thought it wise to see what the
> documents say.That led me to http://maven.apache.org/wagon/  and
> clicking on the Getting Started link I ended up at the URL
> http://maven.apache.org/wagon/guides/getting-started/index.html , and
> almost every link there leads to a :
> =
> Page Not Found
> Sorry, the page you requested was not found. This may because:
> 
> * The page has moved, was outdated, or has not been created yet
> * You typed the address incorrectly
> * You following a link from another site that pointed to this page.
> 
> We have recently reorganised our site, so please try looking in the
> navigation on the left for the item you are looking for on Maven 1.x
> or the Maven project. For information about Maven 2.0 or Continuum,
> please visit their sub sites, available from the links in the top
> right of the page. There is no need to report this broken link to the
> Maven team, as errors are periodically monitored and repaired.
> 
> ===
> 
> Same thing happens with the "Examples" link.Surely this cannot be a
> pleasant user experience for anyone , let alone for a poor newbie who
> might think looking at the docs is a good start.In my example, what
> then can a user do besides thinking of  putting one's neck on the
> guillotine?One gets no help on the mailing list and the documentation
> isn't helpful either.
> I understand very well the idea that people are busy etc , but also
> feel that there's need for more participation  from plugin authors in
> helping mere users like myself and others who get stuck with problems
> only the maven gurus can solve...unless of course the plugins are only
> to be used by the authors themselves.
> Please don't take take this as whining , but rather , as a personal
> view and perhaps constructive criticism.
> 
> -- 
> 
> 
> Jeff  Mutonho
> 
> GoogleTalk : ejbengine
> Skype: ejbengine
> Registered Linux user number 366042
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Maven-rant-tf2544811s177.html#a7093319
Sent from the Maven - Users mailing list archive at Nabble.com.


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

[Maven2] [WARNING] POM for 'org.apache.axis2:axis2-kernel:pom:1.1-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.

[Saminda Abeyruwan]

Hi,

Why am I getting the following,

[WARNING] POM for 'org.apache.axis2:axis2-kernel:pom:1.1-SNAPSHOT:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0POM.

I'm using repositories with "legacy".

Thank you

Saminda

About the maven-release-plugin and the release generation process

[David]

Just a general question to the list:

Are you using just the maven-release-plugin for the generation of your releases?

I mean, the plugin is supposed to do "all the SCM stuff", but it
doesn't manage on its own the fact that it would be helpful (and
sometimes mandatory), to be able to work on release branches instead
of the de main branch.

Because, if I generate version 1.0 of an app and have maven
automatically generating the 1.1-SNAPSHOT label in the pom.xml...
which is the supposed process to follow if I have to change something
on the 1.0 to generate the 1.0.1 version with just a couple of
bugfixes? I mean, the typical situation when you cannot generate the
1.1 to fix the particular problem because it would contain other
already developed stuff not ready to put in production yet, for
example...


TIA,
David

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

Re: Codehaus repository needed even using released plugins only

[Syvalta]

Syvalta wrote:
> 
> Here's the output from my colleague (without stack trace, I'll see if he's
> still seeing the problem and provide the trace if possible). 
> 

The full stack trace is above. Could it be that if the connection fails,
rest of the repositories aren't searched? I mean, if the file is not found,
it is tried to be loaded from other repos, but if the connection timeouts
etc., it isn't. Would that make sense?

+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from:
'.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'maven\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[INFO] Reactor build order: 
...
[INFO]

[INFO] Building parent project
[INFO]task-segment: [install]
[INFO]

[DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository
central
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for
project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project:
org.apache.maven.plugins:maven-plugins:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project:
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG] maven-install-plugin: resolved to version 2.1 from repository
central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
null:maven-install-plugin:maven-plugin:2.1 from the repository.
[DEBUG]
org.apache.maven.plugins:maven-site-plugin:maven-plugin:2.0-beta-5:runtime
(selected for runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project:
null:maven-settings:jar:2.0 from the repository.
[DEBUG]   org.apache.maven:maven-settings:jar:2.0:runtime (selected for
runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for
runtime)
[DEBUG]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime
(selected for runtime)
[DEBUG]   classworlds:classworlds:jar:1.1-alpha-2:runtime (selected for
runtime)
[DEBUG]   junit:junit:jar:3.8.1:runtime (selected for runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project:
org.apache.maven:maven-model:jar:2.0 from the repository.
[DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0.2 for project:
org.apache.maven:maven-artifact:jar:2.0.2 from the repository.
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0.2:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.4 for
project: null:plexus-utils:jar:1.1 from the repository.
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (removed -
nearer found: 1.0.4)
[DEBUG] Retrieving parent-POM: org.mortbay.jetty:project::6.0.0beta12 for
project: org.mortbay.jetty:jetty:jar:6.0.0beta12 from the repository.
[DEBUG]   org.mortbay.jetty:jetty:jar:6.0.0beta12:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.mortbay.jetty:project::6.0.0beta12 for
project: org.mortbay.jetty:servlet-api-2.5:jar:6.0.0beta12 from the
repository.
[DEBUG] org.mortbay.jetty:servlet-api-2.5:jar:6.0.0beta12:runtime
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed -
nearer found: 1.1)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.1:runtime (selected for
runtime)
[DEBUG] Retrieving parent-POM: org.apache.maven.doxia:doxia::1.0-alpha-8 for
project: null:doxia-site-renderer:jar:1.0-alpha-8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project:
org.apache.maven.doxia:doxia:pom:1.0-alpha-8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project:
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG]   org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:runtime
(selected for runtime)
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus-components::1.1.4
for project: null:plexus-i18n:jar:1.0-beta-6 from the repository.
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.4 for
project: org.codehaus.plexus:plexus-components:pom:1.1.4 from the
repository.
[DEBUG] org.codehaus.plexus:plexus-i18n:jar:1.0-beta-6:runtime (selected
for runtime)
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus-components::1.1.5
for project: null:plexus-velocity:jar:1.1.3 from the repository.
[DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.5 for
project: org.codehaus.plexus:plexus-components:pom:1.1.5 from the
repository.
[DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.3:runtime (selected
for runtime)
[DEBUG]   velocity:velocity:jar:1.4:runtime (selected for runtime)
[DEBUG] velocity

Notify only developers who committed changes?

[Ralph Pöllath]

Hi,

When a build breaks, is it possible to notify only those developers  
who committed changes?


Cheers,
-Ralph.

Integration bundle not copying resources

[David Leangen]

Hello!

I'm building an module for functional tests as explained in the BB book.

However, my resources (located in src/it/resources) are just not being
copied, which causes everything to fail. I must not be understanding
something about the lifecycle...

Any suggestions would be very welcome!


Here is a snip of my pom:

  
src/it

  
src/it/resources
  


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

  

  testCompile

  

  
  
org.apache.maven.plugins
maven-surefire-plugin

  
integration-test

  test

  

  

  



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

Re: jetty-plugin run-exploded: not scanning src/main/webapp ?

[Valerio Schiavoni]

i guess that reading this table:
http://docs.codehaus.org/display/JETTY/What+files+are+scanned+by+the+Jetty+Maven+Plugin

gives me some hint about what's going on. the scanTargets is only used by
the run goal

On 10/31/06, Valerio Schiavoni <[EMAIL PROTECTED]> wrote:


hello everyone,
i'm using the jetty plugin to test and deploy my webapp. because i'm using
filtering (on both web.xml content and on other properties) , i launch
everything with:

mvn jetty:run-exploded

then, if i try to edit a jsp file in the src/main/webapp/WEB-INF/jsp

and i hit 'refresh' on the browser, i don't see the changes. i guess it
measn that the page has not been hot-redeployed. everything was working fine
with mvn jetty:run (which makes sense because it deploy the webapp in-place,
afaik).

this is how i configured the plugin:

 org.mortbay.jetty
 maven-jetty-plugin
 
   5
   ${jetty.webdefaultxml}


src/main/webapp

   


the version of jetty being uses is:

[INFO] Starting jetty 6.1.0pre0 ...

thanks,
valerio
--
http://valerioschiavoni.blogspot.com
http://jroller.com/page/vschiavoni





--
http://valerioschiavoni.blogspot.com
http://jroller.com/page/vschiavoni

SV: Managing Release Jars

[Jonas Olsson]

Ah, I didn't follow-up on your JIRA references. MNG-612 would solve a lot of 
these issues, I agree.

/jonas

-Ursprungligt meddelande-
Från: Mark Hobson [mailto:[EMAIL PROTECTED] 
Skickat: den 31 oktober 2006 11:41
Till: Maven Users List
Ämne: Re: Managing Release Jars

Hi Jonas,

On 31/10/06, Jonas Olsson <[EMAIL PROTECTED]> wrote:
> Perhaps the original question is wrongly put, IMHO?
>
> If you have a shared library it should only be included ONCE in the end 
> product, right?
> And this inclusion should be of a specific version (to allow build 
> re-production), right?

This is correct, although this process is the responsibility of
Maven's pluggable conflict resolution.  See MNG-612.

> So all users of the shared library should list it as "provided" and the 
> dependency will say
> which version was used for that particular build (re-production, once again). 
> The end product will
> have a single "runtime" dependency of the shared library with the actual 
> version to be included/used/provided.

The problem with this approach is that all dependencies will become
provided and it moves the conflict resolution to a manual process
situated in the top-level pom.  The kind of shared components I'm
referring to here would be ones like, say, plexus-utils.  Imagine that
a serious bug was discovered in a released version that many other
components depend on.  If all these components made up the
dependencies hierarchy for a top-level project, then the maintenance
becomes significant.

> PROBLEM: Maven does not automatically dected version mis-matches with 
> "provided" dependencies.
>
> I do not end up with a working solution, but re-stated the issue arrives at a 
> different core problem (one I have recently posted on this very mailing list).

I appreciate your suggestion, although I think it would be impractical
for large component hierarchies and neglects the potential power of
Maven.

Cheers,

Mark

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



This e-mail has been scanned for viruses by http://www.virus112.se


Detta e-mail har blivit undersökt av http://www.virus112.se


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

jetty-plugin run-exploded: not scanning src/main/webapp ?

[Valerio Schiavoni]

hello everyone,
i'm using the jetty plugin to test and deploy my webapp. because i'm using
filtering (on both web.xml content and on other properties) , i launch
everything with:

mvn jetty:run-exploded

then, if i try to edit a jsp file in the src/main/webapp/WEB-INF/jsp

and i hit 'refresh' on the browser, i don't see the changes. i guess it
measn that the page has not been hot-redeployed. everything was working fine
with mvn jetty:run (which makes sense because it deploy the webapp in-place,
afaik).

this is how i configured the plugin:

org.mortbay.jetty
maven-jetty-plugin

  5
  ${jetty.webdefaultxml}
   
   
   src/main/webapp
   
  


the version of jetty being uses is:

[INFO] Starting jetty 6.1.0pre0 ...

thanks,
valerio
--
http://valerioschiavoni.blogspot.com
http://jroller.com/page/vschiavoni

Re: HOWTO: Have assembly plugin call package automatically before doing assembly?

[Damien Viel]

You can also read this, but it's in french...

http://www.dviel.com/archives/35

Damien

Wendy Smoak a écrit :

On 10/30/06, Jan Thomä <[EMAIL PROTECTED]> wrote:

currently i am using the assembly - plugin, to assemble a multi-module 
project
into a single directory containing the binary output of all modules. 
However,
i always have to call package before assembly, otherwise the 
assembly-plugin
states that i should call package before assembly and fails. Is there 
some

way to have package automatically called by assembly, as this is very
repetitive and actually i don't see a reason why assembly does not call
package by default... Any insights are appreciated.


John Casey once explained why you have to call assembly:assembly
separately in Maven 2.0.

See:  
http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html 





--
--
Damien Viel | +33 1 41 97 83 20 | [EMAIL PROTECTED]
--
| http://www.improve-foundations.com
__/ \__ | http://www.improve.fr
improve | http://www.application-servers.com
/_\-| http://www.improve-technologies.com
--

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

Re: Managing Release Jars

[Mark Hobson]

Hi Jonas,

On 31/10/06, Jonas Olsson <[EMAIL PROTECTED]> wrote:

Perhaps the original question is wrongly put, IMHO?

If you have a shared library it should only be included ONCE in the end 
product, right?
And this inclusion should be of a specific version (to allow build 
re-production), right?


This is correct, although this process is the responsibility of
Maven's pluggable conflict resolution.  See MNG-612.


So all users of the shared library should list it as "provided" and the 
dependency will say
which version was used for that particular build (re-production, once again). 
The end product will
have a single "runtime" dependency of the shared library with the actual 
version to be included/used/provided.


The problem with this approach is that all dependencies will become
provided and it moves the conflict resolution to a manual process
situated in the top-level pom.  The kind of shared components I'm
referring to here would be ones like, say, plexus-utils.  Imagine that
a serious bug was discovered in a released version that many other
components depend on.  If all these components made up the
dependencies hierarchy for a top-level project, then the maintenance
becomes significant.


PROBLEM: Maven does not automatically dected version mis-matches with 
"provided" dependencies.

I do not end up with a working solution, but re-stated the issue arrives at a 
different core problem (one I have recently posted on this very mailing list).


I appreciate your suggestion, although I think it would be impractical
for large component hierarchies and neglects the potential power of
Maven.

Cheers,

Mark

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

Re: final name named after active profile id ?

[Valerio Schiavoni]

i ended up using the solution proposed here:
http://mail-archives.apache.org/mod_mbox/maven-users/200511.mbox/[EMAIL 
PROTECTED]

where every profile defines a finalName property.

if there're are better (whatever it means) approaches, please comment !

thanks,
valerio

On 10/31/06, Valerio Schiavoni <[EMAIL PROTECTED]> wrote:


hello everyone,
given the element
myapp-${...}

and given that i have few profiles which I activate through command-line
system properties, is it possible to use the id of the active profile as
part of the final name ?
if for exampel i have:

mvn -Ddbms=postgres package   ->  myapp-postgres.war

i tried with ${profile.id} but i get null values..

or maybe there's a mean to use the maven-help-plugin..but i've no idea on
how to do that.

thanks,
valerio
--
http://valerioschiavoni.blogspot.com
http://jroller.com/page/vschiavoni





--
http://valerioschiavoni.blogspot.com
http://jroller.com/page/vschiavoni

Re: Parent POM across projects

[Sebastien Moreno]

Hi,

What about use  tag inherited into child pom to put 
information?
Parent POM will define  with this property version,
and child module will use also the property to define their version.

For example, you will have Parent like this:

...
pom
2.2
COMMON
http://maven.apache.org/


2.2.0-SNAPSHOT





com.common.tools
MyModule
${common.tools.version}



...

And in child POM:
...
MyModule
jar
${common.tools.version}


com.common.tools
COMMON
2.2

...

But, I don't if this solution suit well with other plugins work, like
release...

Sebastien

Mark Chaimungkalanont wrote:
> 
> Jörg,
> 
> Thanks a ton for the info, really appreciate it. I guess I'll stick to
> using SNAPSHOT as 
> the parent POM's version then.
> 
>  From your comment at http://jira.codehaus.org/browse/MRELEASE-96, it
> seems that we were 
> dealing with exactly the same dilemma!
> 
> Thanks again!
> 
> Mark C
> 
> Jörg Schaible wrote:
>> Jörg Schaible wrote on Wednesday, June 14, 2006 11:30 AM:
>> 
>>> Mark Chaimungkalanont wrote on Wednesday, June 14, 2006 10:54 AM:
>>>
 I'm thinking this *should* be a fairly common use-case, and wondered
 what other solutions there are.
>> 
>> Not that I don't understand your pain: MRELEASE-96
>> 
>> - Jörg
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Parent-POM-across-projects-tf1784776s177.html#a7091745
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Generated properties for plugin configuration

[David Bernard]

G'day,

I wish to generate a port number for my test database to use.

I need to configure the dbunit plugin to use that port number.

Can a property value be loaded from a file other than pom.xml and 
settings.xml?


I don't really what to put a wrapper around maven to edit the pom.xml.

Any ideas?


David Bernard

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

SV: Managing Release Jars

[Jonas Olsson]

Perhaps the original question is wrongly put, IMHO?

If you have a shared library it should only be included ONCE in the end 
product, right?
And this inclusion should be of a specific version (to allow build 
re-production), right?
So all users of the shared library should list it as "provided" and the 
dependency will say
which version was used for that particular build (re-production, once again). 
The end product will
have a single "runtime" dependency of the shared library with the actual 
version to be included/used/provided.

PROBLEM: Maven does not automatically dected version mis-matches with 
"provided" dependencies.

I do not end up with a working solution, but re-stated the issue arrives at a 
different core problem (one I have recently posted on this very mailing list).

/jonas

-Ursprungligt meddelande-
Från: Mark Hobson [mailto:[EMAIL PROTECTED] 
Skickat: den 31 oktober 2006 10:54
Till: Maven Users List
Ämne: Re: Managing Release Jars

I was intending to ask the exact same question since this is quite a
laborious task for us.  Our project hierarchy is highly component
based, and as such, a bug fix release in a shared low-level component
can sometimes require ten to twenty releases of dependent projects.

The solutions I can see for this are:

1) Use dependency management.  Problems: MNG-1577; essentially moves
dependency information to top-level project, causing duplication
across projects and room for error.

2) Up the version to the new point-release in a single component where
the issue was relevant, then rely on MNG-612 to ultimately select the
latest version.  Problems: MNG-612 is far from being implemented.

3) Use version ranges.  Problems: build irreproducibility.

4) Use version ranges, but add support to the release plugin to
resolve ranges to hard versions at release time.  Problems: can't
think of any.

5) Add automated support for this process.  Where would this end up -
Archiva, release plugin, separate tool?

I quite like the idea of (4), what do others think?

Mark

On 30/10/06, John Casey <[EMAIL PROTECTED]> wrote:
> Unless your projects are released in lock-step, you probably want to update
> the dependency version manually. While this is labor intensive, it also
> guarantees that you know exactly what you're building. As you analyze and
> test against newer versions of the dependency, you can manage that small
> piece of dependency metadata manually without much difficulty.
>
> If you're releasing all of the projects as a single app with a single
> version, you might use dependencyManagement from an application-level parent
> POM.
>
> HTH,
>
> John
>
> On 10/30/06, Pin Ngee Koh <[EMAIL PROTECTED]> wrote:
> >
> > I have a jar, say X.jar,  which is reference by numerous projects.
> > Developers are changing and releasing various versions of X.jar for
> > releases.
> > What is the best way to manage the POM files of projects which depends on
> > it.
> >
> > 1. Use version range? E.g [1.0,2.0)
> > This option has potential of picking up unintended latest release of
> > X.jar
> > 2. Manually update reach project's POM file and up a minor version?
> > This option is labor intensive and difficult to manage. Also,
> > increasing a minor version in projects seems wrong and weird.
> >
> > What's a better way you would suggest?
> >
> > -
> > 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]



This e-mail has been scanned for viruses by http://www.virus112.se


Detta e-mail har blivit undersökt av http://www.virus112.se


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

Not embedding pom is jars

[Sebastien Brunot]

Hi,
 
is there an easy way to specify that the pom files shouldn't be embedded
in a jar artifact (resulting from the package command) under META-INF ?
 
thaks for your advices,
 
Sebastien

final name named after active profile id ?

[Valerio Schiavoni]

hello everyone,
given the element
myapp-${...}

and given that i have few profiles which I activate through command-line
system properties, is it possible to use the id of the active profile as
part of the final name ?
if for exampel i have:

mvn -Ddbms=postgres package   ->  myapp-postgres.war

i tried with ${profile.id} but i get null values..

or maybe there's a mean to use the maven-help-plugin..but i've no idea on
how to do that.

thanks,
valerio
--
http://valerioschiavoni.blogspot.com
http://jroller.com/page/vschiavoni

Re: Managing Release Jars

[Mark Hobson]

I was intending to ask the exact same question since this is quite a
laborious task for us.  Our project hierarchy is highly component
based, and as such, a bug fix release in a shared low-level component
can sometimes require ten to twenty releases of dependent projects.

The solutions I can see for this are:

1) Use dependency management.  Problems: MNG-1577; essentially moves
dependency information to top-level project, causing duplication
across projects and room for error.

2) Up the version to the new point-release in a single component where
the issue was relevant, then rely on MNG-612 to ultimately select the
latest version.  Problems: MNG-612 is far from being implemented.

3) Use version ranges.  Problems: build irreproducibility.

4) Use version ranges, but add support to the release plugin to
resolve ranges to hard versions at release time.  Problems: can't
think of any.

5) Add automated support for this process.  Where would this end up -
Archiva, release plugin, separate tool?

I quite like the idea of (4), what do others think?

Mark

On 30/10/06, John Casey <[EMAIL PROTECTED]> wrote:

Unless your projects are released in lock-step, you probably want to update
the dependency version manually. While this is labor intensive, it also
guarantees that you know exactly what you're building. As you analyze and
test against newer versions of the dependency, you can manage that small
piece of dependency metadata manually without much difficulty.

If you're releasing all of the projects as a single app with a single
version, you might use dependencyManagement from an application-level parent
POM.

HTH,

John

On 10/30/06, Pin Ngee Koh <[EMAIL PROTECTED]> wrote:
>
> I have a jar, say X.jar,  which is reference by numerous projects.
> Developers are changing and releasing various versions of X.jar for
> releases.
> What is the best way to manage the POM files of projects which depends on
> it.
>
> 1. Use version range? E.g [1.0,2.0)
> This option has potential of picking up unintended latest release of
> X.jar
> 2. Manually update reach project's POM file and up a minor version?
> This option is labor intensive and difficult to manage. Also,
> increasing a minor version in projects seems wrong and weird.
>
> What's a better way you would suggest?
>
> -
> 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: ftp-wagon : Authentication failed

[Jeff Mutonho]

On 10/31/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

Your repository id ("portal-repository") does not match the server's id.

-- Kenney



Where did you come from , man :) .Thank you.Where is this documented
so I can read upon it.




Jeff  Mutonho

GoogleTalk : ejbengine
Skype: ejbengine
Registered Linux user number 366042

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

Re: ftp-wagon : Authentication failed

[Kenney Westerhof]

Your repository id ("portal-repository") does not match the server's id.

-- Kenney

Jeff Mutonho wrote:

In my  settings.xml I have


 
   165.148.216.14
   maven
   maven
 



and in the top-level pom


   
 165.148.216.14
 Portal App Website
 scp://165.148.216.14/var/www/html/projects/eportal
   
   
portal-repository
Portal Repository
scp://165.148.216.14/home/maven/portal-releases
   
 


When I run 'mvn deploy'  , I get prompted for a my password(even
though its specified in the settings.xml) .After typing the password ,
I get the following authentication error message :

[INFO] [deploy:deploy]
Password for [EMAIL PROTECTED]: maven
[INFO] 


[ERROR] BUILD ERROR
[INFO] 

[INFO] Error deploying artifact: Authentication failed: Cannot connect. 
Reason:

Auth fail

[INFO] 


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


[INFO] Total time: 26 seconds
[INFO] Finished at: Fri Oct 27 10:42:43 CAT 2006
[INFO] Final Memory: 5M/508M
[INFO] 




Q1) Why am I prompted for a password even though I specify one in the
settings.xml file?

Q2)When I get prompted for a password , the connect string is incorrect :
"Password for [EMAIL PROTECTED]:"
The username as stated in the setting.xml is "maven" and I would
expect it to be "[EMAIL PROTECTED]" .
"mutonhj" is my username on the PC.Why is maven using this to
construct the connect string?




Jeff  Mutonho

GoogleTalk : ejbengine
Skype: ejbengine
Registered Linux user number 366042

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

[jiangshachina]

Hello Jeff,
I think it's really a trouble.
But all will be OK, I'm sure of that.
Best Regards.

a cup of Java, cheers!
Sha Jiang


Jeff Mutonho wrote:
> 
> Is maven in the process of unintentionally killing itself due to poor
> support and documentation?I may be wrong but I strongly feel that the
> poor support and documentation is hampering adoption of an otherwise
> brilliant tool.It always seems like the participation of plugin
> developers in answering questions from mere users like myself is
> non-existent.Then lets not forget the poor documentation.The BB book
> was an excellent idea ,but sometimes it just does not address problems
> users face on the "setup battle field" and the "configuration
> trenches" we're all familiar with.I'll give an example that relates to
> my experience.I posted questions relating to problems with the Maven
> Wagon plugin and in the process also thought it wise to see what the
> documents say.That led me to http://maven.apache.org/wagon/  and
> clicking on the Getting Started link I ended up at the URL
> http://maven.apache.org/wagon/guides/getting-started/index.html , and
> almost every link there leads to a :
> =
> Page Not Found
> Sorry, the page you requested was not found. This may because:
> 
> * The page has moved, was outdated, or has not been created yet
> * You typed the address incorrectly
> * You following a link from another site that pointed to this page.
> 
> We have recently reorganised our site, so please try looking in the
> navigation on the left for the item you are looking for on Maven 1.x
> or the Maven project. For information about Maven 2.0 or Continuum,
> please visit their sub sites, available from the links in the top
> right of the page. There is no need to report this broken link to the
> Maven team, as errors are periodically monitored and repaired.
> 
> ===
> 
> Same thing happens with the "Examples" link.Surely this cannot be a
> pleasant user experience for anyone , let alone for a poor newbie who
> might think looking at the docs is a good start.In my example, what
> then can a user do besides thinking of  putting one's neck on the
> guillotine?One gets no help on the mailing list and the documentation
> isn't helpful either.
> I understand very well the idea that people are busy etc , but also
> feel that there's need for more participation  from plugin authors in
> helping mere users like myself and others who get stuck with problems
> only the maven gurus can solve...unless of course the plugins are only
> to be used by the authors themselves.
> Please don't take take this as whining , but rather , as a personal
> view and perhaps constructive criticism.
> 
> -- 
> 
> 
> Jeff  Mutonho
> 
> GoogleTalk : ejbengine
> Skype: ejbengine
> Registered Linux user number 366042
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Maven-rant-tf2544811s177.html#a7091094
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Maven rant

[Jeff Mutonho]

Is maven in the process of unintentionally killing itself due to poor
support and documentation?I may be wrong but I strongly feel that the
poor support and documentation is hampering adoption of an otherwise
brilliant tool.It always seems like the participation of plugin
developers in answering questions from mere users like myself is
non-existent.Then lets not forget the poor documentation.The BB book
was an excellent idea ,but sometimes it just does not address problems
users face on the "setup battle field" and the "configuration
trenches" we're all familiar with.I'll give an example that relates to
my experience.I posted questions relating to problems with the Maven
Wagon plugin and in the process also thought it wise to see what the
documents say.That led me to http://maven.apache.org/wagon/  and
clicking on the Getting Started link I ended up at the URL
http://maven.apache.org/wagon/guides/getting-started/index.html , and
almost every link there leads to a :
=
Page Not Found
Sorry, the page you requested was not found. This may because:

   * The page has moved, was outdated, or has not been created yet
   * You typed the address incorrectly
   * You following a link from another site that pointed to this page.

We have recently reorganised our site, so please try looking in the
navigation on the left for the item you are looking for on Maven 1.x
or the Maven project. For information about Maven 2.0 or Continuum,
please visit their sub sites, available from the links in the top
right of the page. There is no need to report this broken link to the
Maven team, as errors are periodically monitored and repaired.

===

Same thing happens with the "Examples" link.Surely this cannot be a
pleasant user experience for anyone , let alone for a poor newbie who
might think looking at the docs is a good start.In my example, what
then can a user do besides thinking of  putting one's neck on the
guillotine?One gets no help on the mailing list and the documentation
isn't helpful either.
I understand very well the idea that people are busy etc , but also
feel that there's need for more participation  from plugin authors in
helping mere users like myself and others who get stuck with problems
only the maven gurus can solve...unless of course the plugins are only
to be used by the authors themselves.
Please don't take take this as whining , but rather , as a personal
view and perhaps constructive criticism.

--


Jeff  Mutonho

GoogleTalk : ejbengine
Skype: ejbengine
Registered Linux user number 366042

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

Re: Custom Manifest file

[jiangshachina]

Hello Wayne,
> Two manifest files contained in resulting WAR file:
> /META-INF/MANIFEST.MF -- entirely generated by Maven, no data from
> /src/main/resources
> /WEB-INF/classes/META-INF/MANIFEST.MF -- a copy of my
> /src/main/resources file with no extra data from Maven
The matter is very strange. My two MANIFEST.MF files are all affected.
Since MANIFEST.MF is at /src/main/resources/META-INF, and
/src/main/resources is standard resource path, then all of content under dir
resources will be copied into dir classes.
On the other hand, I specify the MANIFEST.MF for war archive file, via the
following statements,
[...]



src/main/resources/META-INF/MANIFEST.MF



[...]
Maven has to obey my command, and add extra data into file
{WAR}/META-INF/MANIFEST.MF.
I think the flow is very natural.
But how to explain your result...?

a cup of Java, cheers!
Sha Jiang


Wayne Fay wrote:
> 
> I ran a little test myself just now and got the following results:
> 
> New manifest file added to /src/main/resources/META-INF/MANIFEST.MF
> "mvn clean package" executed against project
> 
> Two manifest files contained in resulting WAR file:
> /META-INF/MANIFEST.MF -- entirely generated by Maven, no data from
> /src/main/resources
> /WEB-INF/classes/META-INF/MANIFEST.MF -- a copy of my
> /src/main/resources file with no extra data from Maven
> 
> Seems to me that this is basically a bug in the WAR plugin, unless
> someone knows otherwise... I'd expect both files would have the same
> info in them and/or only one file would be created. It seems like the
> META-INF under /classes is probably invalid/not used according to the
> J2EE Specifications.
> 
> Wayne
> 
> On 10/31/06, jiangshachina <[EMAIL PROTECTED]> wrote:
>>
>> Hi Wayne,
>> I'm so sorry that I confused you :(
>> But I think you have understand my mind.
>> Your thinking is compatible with my question.
>>
>> > instead of this file going into {WAR}/META-INF/MANIFEST.MF as I'd
>> expect
>> > based on
>> > the JAR File specifications, the file is instead going into
>> > {WAR}/WEB-INF/classes/META-INF/MANIFEST.MF.
>> Both of {WAR}/META-INF/MANIFEST.MF and
>> {WAR}/WEB-INF/classes/META-INF/MANIFEST.MF are affected by the
>> MANIFEST.MF
>> file.
>>
>> a cup of Java, cheers!
>> Sha Jiang
>>
>>
>> Wayne Fay wrote:
>> >
>> > I'm afraid I still don't understand...
>> >
>> > I think you're trying to ask the following:
>> >
>> > I have added a MANIFEST.MF file to src/main/resources/META-INF as
>> > instructed. However, when I package my Webapp as a WAR, instead of
>> > this file going into {WAR}/META-INF/MANIFEST.MF as I'd expect based on
>> > the JAR File specifications, the file is instead going into
>> > {WAR}/WEB-INF/classes/META-INF/MANIFEST.MF.
>> >
>> > Why is this happening? And can I force the file to go into
>> > {WAR}/META-INF/MANIFEST.MF like I want, rather than under
>> > WEB-INF/classes?
>> >
>> > Is that what you're trying to ask??
>> >
>> > Wayne
>> >
>> > On 10/30/06, jiangshachina <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi Wayne,
>> >> I just think src/main/resources is default directory for MANIFEST.MF
>> >> file(at
>> >> least, in simply Application project) .
>> >> And what's general(not standard/default) directory for MANIFEST.MF?
>> >>
>> >> a cup of Java, cheers!
>> >> Sha Jiang
>> >>
>> >>
>> >> Wayne Fay wrote:
>> >> >
>> >> > Why in the world would you put the file in
>> src/main/resources/META-INF
>> >> > but then not want it copied into the proper place in the resulting
>> Web
>> >> > app WAR file?? I just don't understand the business/use case, can
>> you
>> >> > explain it a little better?
>> >> >
>> >> > If this is really want you want, you might be able to make it work
>> >> > with . Refer to this page for more info on using
>> :
>> >> >
>> >>
>> http://people.apache.org/~aramirez/maven-resources-plugin/examples/include-exclude.html
>> >> >
>> >> > Wayne
>> >> >
>> >> > On 10/30/06, jiangshachina <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> In Web application project, I want to put MANIFEST.MF into
>> >> >> main/resources/META-INF directory(it's the same as that in simply
>> >> >> application project).
>> >> >> And I don't want META-INF/MANIFEST.MF to be copied into
>> >> >> webapp_archive_file/WEB-INF/classes.
>> >> >> How can I achieve that? Use filter file?
>> >> >>
>> >> >> a cup of Java, cheers!
>> >> >> Sha Jiang
>> >> >>
>> >> >>
>> >> >> jiangshachina wrote:
>> >> >> >
>> >> >> > Of course, I can locate MANIFEST.MF to another directory.
>> >> >> > I just be curious of why application project have not the
>> trouble.
>> >> >> > And I cannot use standard directory structure.
>> >> >> >
>> >> >> > a cup of Java, cheers!
>> >> >> > Sha Jiang
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > jiangshachina wrote:
>> >> >> >>
>> >> >> >> I find another problem.
>> >> >> >> If the project is Web application, then META-INF/MANIFEST.MF
>> will
>> >> be
>> >> >> >> inserted into classes direct

Re: M2 Cargo plugin now found...

[Brett Porter]

Kevin,

Please file it in JIRA, and please don't cross post in future.

- Brett

On 31/10/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

Hi all,

The problem I just spent 2 hours banging my head against was related
to where I declared the cargo-maven2-plugin

Declare the plugin under  and it downloads fine, declare it
under  and you get *NO* information about why it
won't download

I'd like to suggest to any mvn2 devs lurking that some kind of
error/info message be displayed if the result of a build is failure
and the reason is that a plugin couldn't be found.

Perhaps:
Failure [Build Error]
xxx-plugin could not be found : Have you checked to ensure that you
have declared it under  not  ?

A simple message like this would have saved me two hours

Thanks,
Kev

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





--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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

M2 Cargo plugin now found...

[Kevin Jackson]

Hi all,

The problem I just spent 2 hours banging my head against was related
to where I declared the cargo-maven2-plugin

Declare the plugin under  and it downloads fine, declare it
under  and you get *NO* information about why it
won't download

I'd like to suggest to any mvn2 devs lurking that some kind of
error/info message be displayed if the result of a build is failure
and the reason is that a plugin couldn't be found.

Perhaps:
Failure [Build Error]
xxx-plugin could not be found : Have you checked to ensure that you
have declared it under  not  ?

A simple message like this would have saved me two hours

Thanks,
Kev

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