Re: Including Javadocs (API) with project website

2009-04-27 Thread Wendy Smoak 
On Mon, Apr 27, 2009 at 4:35 PM, REMIJAN, MICHAEL J [AG/1000]
 wrote:
> Two part question,
>
> 1) is it possible for 'mvn site' to automatically generate javadocs or
> do I always have to do javadoc:javadoc before running 'mvn site'

Put it in the  section, as described on
http://maven.apache.org/plugins/maven-javadoc-plugin/usage.html

> 2) Is there standard  in site.xml to generate the hyperlink to the
> javadocs?

I think it shows up automatically in the Project Reports section.  You
can add a link from other pages/menus if you want.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

using archetype version in archetype

2009-04-27 Thread Niels van Kampenhout 
Hi,

Is there any way to use the version of an archetype in the templates
for that archetype (e.g. use the -DarchetypeVersion command line
parameter as ${archetypeVersion})?

My use case is a multi module project, where one module is the
archetype, which generates a project that has dependencies on the
other modules. All modules inherit their version number from the root
pom so I could use the archetype version to specify the version in the
dependencies on the other modules. The problem right now is that the
version number in the archetype's template for pom.xml is not updated
by the release plugin when releasing the complete project, so manual
updating is necessary which can/will lead to errors in tags/releases.

Or is this project structure bad practice and should the archetype be
a separate project? I do not really see the benefit of that since the
archetype will always have the same release cycle as the rest of the
project.

Thanks!
Niels

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Including Javadocs (API) with project website

2009-04-27 Thread REMIJAN, MICHAEL J [AG/1000] 
Two part question,

1) is it possible for 'mvn site' to automatically generate javadocs or
do I always have to do javadoc:javadoc before running 'mvn site'

2) Is there standard  in site.xml to generate the hyperlink to the
javadocs?

Thanks!
Mike

-
This e-mail message may contain privileged and/or confidential information, and 
is intended to be received only by persons entitled to receive such 
information. If you have received this e-mail in error, please notify the 
sender immediately. Please delete it and all attachments from any servers, hard 
drives or any other media. Other use of this e-mail by you is strictly 
prohibited.


All e-mails and attachments sent and received are subject to monitoring, 
reading and archival by Monsanto, including its subsidiaries. The recipient of 
this e-mail is solely responsible for checking for the presence of "Viruses" or 
other "Malware". Monsanto, along with its subsidiaries, accepts no liability 
for any damage caused by any such code transmitted by or accompanying this 
e-mail or any attachment.
-


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [maven-eclipse-plugin] We need your help to test the future 2.7

2009-04-27 Thread Arnaud HERITIER 
thx for this feedbackI deployed a new snapshot : 2.7-20090427.230850-4
It includes the fixe for
MECLIPSE-455
 : Invalid dependent module archive name for EJB artifact
*
*
Cheers

Arnaud

On Tue, Apr 21, 2009 at 2:15 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> The co-worker reported back that the plugin works as advertised
> (latest snapshot)
>
> Martijn
>
> On Tue, Apr 21, 2009 at 10:27 AM, Martijn Dashorst
>  wrote:
> > A co-worker tested it, and found it not working. He'll comment later.
> >
> > Martijn
> >
> > On Tue, Apr 21, 2009 at 12:20 AM, Arnaud HERITIER 
> wrote:
> >> Ping ??Nobody wants to test it ?
> >> Without your help, will never be able to produce a plugin which replies
> to
> >> your needs.
> >> Cheers,
> >>
> >> Arnaud
> >>
> >> On Thu, Apr 16, 2009 at 10:42 AM, Arnaud HERITIER  >wrote:
> >>
> >>> Hi Community,
> >>>   The recent release 2.6 of the maven-eclipse-plugin created many
> problems
> >>> for all of those who had/wanted to store non-java files under
> src/*/java
> >>> (which is required for wicket, ajdt, and probably others usecases).
> >>>   Even we have many integration tests in this plugin we didn't notice
> this
> >>> issue because our testcases allow us to check that generated
> configuration
> >>> files aren't evolving and that we are able to import and use a project
> in
> >>> eclipse (too heavy to do).
> >>>
> >>>   To fix this issue we (Barrie to be honest) improved the plugin to
> allow
> >>> the usage of includes and excludes. :
> >>> http://jira.codehaus.org/browse/MECLIPSE-104
> >>>   The documentation of these feature is here :
> >>>
> >>>
> http://maven.apache.org/plugins/maven-eclipse-plugin-2.7-SNAPSHOT/examples/specifying-source-path-inclusions-and-exclusions.html
> >>> There are many broken links on the site and I don't know why. I'll
> >>> investigate later.
> >>> Others pages are the same in
> >>> http://maven.apache.org/plugins/maven-eclipse-plugin/
> >>> For AJDT project you can have a look at this page :
> >>> http://maven.apache.org/plugins/maven-eclipse-plugin-
> >>> 2.7-SNAPSHOT/examples/ajdt-projects.html
> >>>
> >>> To test the plugin you have to add in your project or in your settings
> this
> >>> repository :
> >>> https://repository.apache.org/content/repositories/snapshots/
> >>> (be careful to the https protocol)
> >>> The last version I deployed is : 2.7-20090416.000603-3
> >>>
> >>> Please, test it and give us your feedback. If it is positive this week,
> >>> we'll launch the release process the next one.
> >>>
> >>> cheers,
> >>>
> >>> --
> >>> Arnaud
> >>>
> >>
> >>
> >>
> >> --
> >> Arnaud
> >>
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > Apache Wicket 1.3.5 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Arnaud

RE: Is it possible to add files to an archetype from other directories?

2009-04-27 Thread mraible 

I was able to solve this by changing from maven-archetype-core to
archetype-common and using the new API. Full changelog on moving from old to
new is at:

http://source.appfuse.org/changelog/appfuse/?cs=3228



mgainty wrote:
> 
> 
> Encountered:  after : "" means you have a null value followed by EOF
> when reading the xml
> Here are the examples I have seen for getTestFile
> File f1 = getTestFile(
> "src/test/resources/projects/grandchild-check/child/pom.xml");
> getProject( f1 );
> //The key is to acquire the pom.xml
> 
> If you are getting Security permissions try using
> filename.getCanonicalFile()
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#getCanonicalFile()
> 
> does this help?
> Martin 
> __ 
> Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung /
> Note de déni et de confidentialité 
> This message is confidential. If you should not be the intended receiver,
> then we ask politely to report. Each unauthorized forwarding or
> manufacturing of a copy is inadmissible. This message serves only for the
> exchange of information and has no legal binding effect. Due to the easy
> manipulation of emails we cannot take responsibility over the the
> contents.
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
> copie de ceci est interdite. Ce message sert à l'information seulement et
> n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
> les email peuvent facilement être sujets à la manipulation, nous ne
> pouvons accepter aucune responsabilité pour le contenu fourni.
> 
> 
> 
> 
> 
> 
>> Date: Mon, 27 Apr 2009 14:36:13 -0700
>> From: m...@raibledesigns.com
>> To: users@maven.apache.org
>> Subject: Re: Is it possible to add files to an archetype from other 
>> directories?
>> 
>> 
>> I was able to code a workaround using Ant to create the project then
>> "archetype:create-from-project" to create it. The nice thing about using
>> Ant
>> to do this was I was also able to modify errors in the create process to
>> make working archetypes.
>> 
>> After doing this, I've discovered that the code I was using to
>> materialize
>> archetypes automatically no longer works. The code is below and the error
>> I'm experiencing is as follows:
>> 
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
>>  at
>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
>> Caused by: org.apache.velocity.exception.ParseErrorException: Lexical
>> error:
>> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line
>> 102,
>> column 93.  Encountered:  after : ""
>>  at org.apache.velocity.Template.process(Template.java:141)
>>  at
>> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:423)
>>  at
>> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:341)
>>  at
>> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
>>  at
>> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440)
>>  at
>> org.apache.maven.archetype.DefaultArchetype.processTemplate(DefaultArchetype.java:904)
>> 
>> 
>> protected void createTestProject(String archetypeArtifactId, String
>> archetypeVersion) throws Exception {
>> MavenProject project = getMavenProject();
>> FileUtils.deleteDirectory(getTestFile("target/" +
>> project.getArtifactId()));
>> 
>> Map parameters = new HashMap();
>> 
>> parameters.put("groupId", project.getGroupId());
>> parameters.put("artifactId", project.getArtifactId());
>> parameters.put("version", "1.0-SNAPSHOT");
>> parameters.put("basedir",
>> getTestFile("target").getAbsolutePath());
>> 
>> Archetype archetype = (Archetype) lookup(Archetype.ROLE);
>> 
>> ArtifactRepositoryLayout layout =
>> (ArtifactRepositoryLayout)
>> container.lookup(ArtifactRepositoryLayout.ROLE, "default");
>> 
>> String mavenRepoLocal = "file://" +
>> System.getProperty("user.home")
>> + System.getProperty("file.separator") +
>> ".m2" + System.getProperty("file.separator") +
>> "repository";
>> ArtifactRepository localRepository = new
>> DefaultArtifactRepository("local", mavenRepoLocal, layout)

RE: Is it possible to add files to an archetype from other directories?

2009-04-27 Thread Martin Gainty 

Encountered:  after : "" means you have a null value followed by EOF when 
reading the xml
Here are the examples I have seen for getTestFile
File f1 = getTestFile( 
"src/test/resources/projects/grandchild-check/child/pom.xml");
getProject( f1 );
//The key is to acquire the pom.xml

If you are getting Security permissions try using filename.getCanonicalFile()
http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#getCanonicalFile()

does this help?
Martin 
__ 
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note de 
déni et de confidentialité 
This message is confidential. If you should not be the intended receiver, then 
we ask politely to report. Each unauthorized forwarding or manufacturing of a 
copy is inadmissible. This message serves only for the exchange of information 
and has no legal binding effect. Due to the easy manipulation of emails we 
cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.






> Date: Mon, 27 Apr 2009 14:36:13 -0700
> From: m...@raibledesigns.com
> To: users@maven.apache.org
> Subject: Re: Is it possible to add files to an archetype from other  
> directories?
> 
> 
> I was able to code a workaround using Ant to create the project then
> "archetype:create-from-project" to create it. The nice thing about using Ant
> to do this was I was also able to modify errors in the create process to
> make working archetypes.
> 
> After doing this, I've discovered that the code I was using to materialize
> archetypes automatically no longer works. The code is below and the error
> I'm experiencing is as follows:
> 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
>   at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> Caused by: org.apache.velocity.exception.ParseErrorException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 102,
> column 93.  Encountered:  after : ""
>   at org.apache.velocity.Template.process(Template.java:141)
>   at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:423)
>   at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:341)
>   at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
>   at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440)
>   at
> org.apache.maven.archetype.DefaultArchetype.processTemplate(DefaultArchetype.java:904)
> 
> 
> protected void createTestProject(String archetypeArtifactId, String
> archetypeVersion) throws Exception {
> MavenProject project = getMavenProject();
> FileUtils.deleteDirectory(getTestFile("target/" +
> project.getArtifactId()));
> 
> Map parameters = new HashMap();
> 
> parameters.put("groupId", project.getGroupId());
> parameters.put("artifactId", project.getArtifactId());
> parameters.put("version", "1.0-SNAPSHOT");
> parameters.put("basedir", getTestFile("target").getAbsolutePath());
> 
> Archetype archetype = (Archetype) lookup(Archetype.ROLE);
> 
> ArtifactRepositoryLayout layout =
> (ArtifactRepositoryLayout)
> container.lookup(ArtifactRepositoryLayout.ROLE, "default");
> 
> String mavenRepoLocal = "file://" + System.getProperty("user.home")
> + System.getProperty("file.separator") +
> ".m2" + System.getProperty("file.separator") + "repository";
> ArtifactRepository localRepository = new
> DefaultArtifactRepository("local", mavenRepoLocal, layout);
> 
> List remoteRepositories = new
> ArrayList();
> /*String mavenRepoRemote = "http://repo1.maven.org/maven2";;
> ArtifactRepository remoteRepository = new
> DefaultArtifactRepository("remote", mavenRepoRemote, layout);
> 
> remoteRepositories.add(remoteRepository);*/
> 
> String archetypeGroupId = "org.appfuse.archetypes";
>

Re: Strange profiles problem

2009-04-27 Thread Mark Derricutt 
No responses :(  But it turns out this is regression in 2.1.0 -
http://jira.codehaus.org/browse/MNG-3732

On Fri, Apr 24, 2009 at 2:29 PM, Mark Derricutt  wrote:

> And getting stranger...
>
> The trunk profile only gives properties:
>
> 
>
>
>trunk
>
>true
>
>
>1.2.0
>1.2.0
>
> When I change to my launchpad-tests module, and run mvn
> help:effective-pom, I see these properties being defined, but
> help:active-profiles never shows "trunk" as being active and the build
> works fine.
>
> If I copy the profiles.xml file into the launchpad-tests folder, I see
> it the profile now listed as being active.  Am I missing some
> fundamental understanding of how profiles.xml should work?
>
> ...and then Buffy staked Edward.  The End.
>
> On Fri, Apr 24, 2009 at 2:20 PM, Mark Derricutt  wrote:
> > Hi all,
>

Re: Is it possible to add files to an archetype from other directories?

2009-04-27 Thread mraible 

I was able to code a workaround using Ant to create the project then
"archetype:create-from-project" to create it. The nice thing about using Ant
to do this was I was also able to modify errors in the create process to
make working archetypes.

After doing this, I've discovered that the code I was using to materialize
archetypes automatically no longer works. The code is below and the error
I'm experiencing is as follows:

org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: org.apache.velocity.exception.ParseErrorException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 102,
column 93.  Encountered:  after : ""
at org.apache.velocity.Template.process(Template.java:141)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:423)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:341)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440)
at
org.apache.maven.archetype.DefaultArchetype.processTemplate(DefaultArchetype.java:904)


protected void createTestProject(String archetypeArtifactId, String
archetypeVersion) throws Exception {
MavenProject project = getMavenProject();
FileUtils.deleteDirectory(getTestFile("target/" +
project.getArtifactId()));

Map parameters = new HashMap();

parameters.put("groupId", project.getGroupId());
parameters.put("artifactId", project.getArtifactId());
parameters.put("version", "1.0-SNAPSHOT");
parameters.put("basedir", getTestFile("target").getAbsolutePath());

Archetype archetype = (Archetype) lookup(Archetype.ROLE);

ArtifactRepositoryLayout layout =
(ArtifactRepositoryLayout)
container.lookup(ArtifactRepositoryLayout.ROLE, "default");

String mavenRepoLocal = "file://" + System.getProperty("user.home")
+ System.getProperty("file.separator") +
".m2" + System.getProperty("file.separator") + "repository";
ArtifactRepository localRepository = new
DefaultArtifactRepository("local", mavenRepoLocal, layout);

List remoteRepositories = new
ArrayList();
/*String mavenRepoRemote = "http://repo1.maven.org/maven2";;
ArtifactRepository remoteRepository = new
DefaultArtifactRepository("remote", mavenRepoRemote, layout);

remoteRepositories.add(remoteRepository);*/

String archetypeGroupId = "org.appfuse.archetypes";
archetype.createArchetype(archetypeGroupId, archetypeArtifactId,
archetypeVersion, localRepository,
remoteRepositories, parameters);
}

Any ideas?

Thanks,

Matt

Grant Rettke wrote:
> 
> On Fri, Apr 24, 2009 at 4:24 AM, mraible  wrote:
>> I'd like to hand-craft an archetype that consists of a single pom.xml and
>> pulls it's sources from other modules/directories in my project. Is that
>> possible?
> 
> That seems to go against the grain of Maven.
> 
> Does Maven make stuff like this easy?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Is-it-possible-to-add-files-to-an-archetype-from-other-directories--tp23212840p23265718.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: dependency to run jetty on a dependent project

2009-04-27 Thread Grant Rettke 
On Mon, Apr 27, 2009 at 1:48 PM, ZsJoska  wrote:
> Thanks for your answer but is that possible to attach to the code-generation
> (i think is more suitable) phase the jetty:run goal from/for another
> pom.xml?

You can attach that goal to any phase you wish.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-27 Thread Frédéric Camblor 
Hi Olivier,

This is only a point of view but...
Isn't the problem coming from the slf4f framework ?

I don't really know this logging framework, but it astonishes me that it
complains about multiple configuration in the classpath.

Generally, framework takes (like commons-logging or log4j) the first config
file found in the classpath so that responsibility is delegated to the order
in which you put artefacts in your  section.

Have you searched in slf4j if it isn't possible to "disable" this
"complaining" ?

Cheers,
Frederic

2009/4/27 Brian Fox 

>
>
> Olivier Cailloux wrote:
>
>> Thanks to everybody who answered. I answer to everyone together:
>> - Projects A and B are to be runnable independently and deployable without
>> C. So putting the log config in test resources would not work.
>> - Putting the log files in a dependent module is possible. But:
>>  - it would render the pom and project management more complex. Currently
>> these projects are not multi-modules, they are very simple,  and that
>> solution would involve transforming them to multi-module projects with one
>> module being a whole module for only one stupid configuration file! And then
>> having the project C exclude the right sub-module. But I admit that it is
>> not my main concern (I could accept a complex solution if it was very good
>> in other aspects) ;
>>
>
> That's right but generally this config file would not be part of the same
> tree that you build everytime. That is to say it has it's own lifecycle and
> is released far less often than the projects that use it.
>
>>  - it is not very elegant as any project depending on A or B would have to
>> not forget to exclude the sub-module containing the log files (any dependent
>> project would have the same problem a
>> s the project C has) ;
>>
> Not true because you don't have to mark it as a dependency. You can use
> dependency unpack (as opposed to unpack-dependencies) and this will not
> affect the dependency tree. Or you could use scope=provided / optional=true
> which means upstream dependencies would ignore it.
>
>>  - it does not solve the question of the log configuration file not being
>> integrated in the jar for easily modification by the end-user after
>> deployment ;
>>  - the problem I face is a general problem, as I always use log
>> configuration files in my projects, so I would like to find a good solution
>> once and for all.
>>
>>  You can unpack the zip file and leave them with just the log config file.
>
>> - The use of Assembly and Dependency plugins is maybe part of a solution,
>> but I don't see clearly how I can configure all this to do what I would like
>> and avoiding ending up with pom files more complex than needed.
>>
>> To re-cap, I dream of a solution allowing me the following two
>> possibilities, for any project I create:
>> - a possibility to create and expose (for use by dependent projects) a
>> .jar file NOT containing the log configuration file ;
>> - a possibility to create and deploy (for end-user usage) a .zip file
>> containing the above .jar AND the log configuration file, which is then easy
>> for the end-user to modify ; and some start-up script (portable) or
>> something equivalent to correctly configure the classpath to include the log
>> configuration file and allow the end-user to easily start the application
>> (this is the part I don't see how to do with the FAQ provided at
>> http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/).
>>
>>
>>  This is also possible, just don't put the log file in /target/classes and
> it won't get jar'd up. You can then use the assembly plugin to zip up the
> final jar along with the config file unpacked earlier.
>
>
>  Although the solutions proposed did not fully satisfy my needs, I have to
>> thank those who responded because it gave me good hints and allowed me to
>> re-think about my problem. Any more advices would be very appreciated
>> because I am a beginner in Maven and I think there must be somehow a simple
>> solution to my needs which I simply overlooked. I am wondering how the
>> others do as this must be a very common problem (everybody use logging
>> framework!).
>>
>> Also, sorry for my English...
>> Olivier
>>
>> Brian Fox a écrit :
>>
>>> See the 9th bullet point here:
>>> http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/
>>>
>>> On 4/26/2009 3:17 PM, Olivier Cailloux wrote:
>>>
 Hello list,

 I am new to maven and couldn't find a simple and elegant solution to
 this (probably) common problem.

 I have three projects : A and B are independent projects and C depends
 on A and B. I use the same logging framework for the three projects (slf4j
 with logback). In A and B, I have a logback.xml configuration file in
 src/main/resources to configure logging behavior (A and B do not 
 necessarily
 have the same configuration). C has also a specific logging configuration
 file. And, naturally, w

Re: dependency to run jetty on a dependent project

2009-04-27 Thread ZsJoska 

Hi,

Thanks for your answer but is that possible to attach to the code-generation
(i think is more suitable) phase the jetty:run goal from/for another
pom.xml?


Grant Rettke wrote:
> 
>> How could I do this automatically?
> 
> Would attaching the jetty:run goal to the pre-test phase solve your
> problem?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/dependency-to-run-jetty-on-a-dependent-project-tp23252831p23262609.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: POM build a JAR file

2009-04-27 Thread Ryan Connolly 
simply run:
mvn package

On Mon, Apr 27, 2009 at 2:40 PM, David Nemer  wrote:
> Hey Everyone,
>
> I'm already able to run the pom.xml file, and maven builds up my classes
> into the target folder.
>
> Now, how do I make a JAR file containing all those classes that maven built?
> (writing it on my POM file).
>
> Cheers,
> --
> David Nemer
> Sent from Kaiserslautern, RP, Germany
>



-- 
�...@n

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

POM build a JAR file

2009-04-27 Thread David Nemer 
Hey Everyone,

I'm already able to run the pom.xml file, and maven builds up my classes
into the target folder.

Now, how do I make a JAR file containing all those classes that maven built?
(writing it on my POM file).

Cheers,
--
David Nemer
Sent from Kaiserslautern, RP, Germany

Re: dependency to run jetty on a dependent project

2009-04-27 Thread Grant Rettke 
> How could I do this automatically?

Would attaching the jetty:run goal to the pre-test phase solve your problem?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-27 Thread Brian Fox 



Olivier Cailloux wrote:

Thanks to everybody who answered. I answer to everyone together:
- Projects A and B are to be runnable independently and deployable 
without C. So putting the log config in test resources would not work.

- Putting the log files in a dependent module is possible. But:
 - it would render the pom and project management more complex. 
Currently these projects are not multi-modules, they are very simple,  
and that solution would involve transforming them to multi-module 
projects with one module being a whole module for only one stupid 
configuration file! And then having the project C exclude the right 
sub-module. But I admit that it is not my main concern (I could accept 
a complex solution if it was very good in other aspects) ;


That's right but generally this config file would not be part of the 
same tree that you build everytime. That is to say it has it's own 
lifecycle and is released far less often than the projects that use it.
 - it is not very elegant as any project depending on A or B would 
have to not forget to exclude the sub-module containing the log files 
(any dependent project would have the same problem a

s the project C has) ;
Not true because you don't have to mark it as a dependency. You can use 
dependency unpack (as opposed to unpack-dependencies) and this will not 
affect the dependency tree. Or you could use scope=provided / 
optional=true which means upstream dependencies would ignore it.
 - it does not solve the question of the log configuration file not 
being integrated in the jar for easily modification by the end-user 
after deployment ;
 - the problem I face is a general problem, as I always use log 
configuration files in my projects, so I would like to find a good 
solution once and for all.



You can unpack the zip file and leave them with just the log config file.
- The use of Assembly and Dependency plugins is maybe part of a 
solution, but I don't see clearly how I can configure all this to do 
what I would like and avoiding ending up with pom files more complex 
than needed.


To re-cap, I dream of a solution allowing me the following two 
possibilities, for any project I create:
- a possibility to create and expose (for use by dependent projects) a 
.jar file NOT containing the log configuration file ;
- a possibility to create and deploy (for end-user usage) a .zip file 
containing the above .jar AND the log configuration file, which is 
then easy for the end-user to modify ; and some start-up script 
(portable) or something equivalent to correctly configure the 
classpath to include the log configuration file and allow the end-user 
to easily start the application (this is the part I don't see how to 
do with the FAQ provided at 
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). 



This is also possible, just don't put the log file in /target/classes 
and it won't get jar'd up. You can then use the assembly plugin to zip 
up the final jar along with the config file unpacked earlier.


Although the solutions proposed did not fully satisfy my needs, I have 
to thank those who responded because it gave me good hints and allowed 
me to re-think about my problem. Any more advices would be very 
appreciated because I am a beginner in Maven and I think there must be 
somehow a simple solution to my needs which I simply overlooked. I am 
wondering how the others do as this must be a very common problem 
(everybody use logging framework!).


Also, sorry for my English...
Olivier

Brian Fox a écrit :
See the 9th bullet point here: 
http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/


On 4/26/2009 3:17 PM, Olivier Cailloux wrote:

Hello list,

I am new to maven and couldn't find a simple and elegant solution to 
this (probably) common problem.


I have three projects : A and B are independent projects and C 
depends on A and B. I use the same logging framework for the three 
projects (slf4j with logback). In A and B, I have a logback.xml 
configuration file in src/main/resources to configure logging 
behavior (A and B do not necessarily have the same configuration). C 
has also a specific logging configuration file. And, naturally, when 
I run the project C, logback complains that it found three 
logback.xml files in the classpath (the ones from A and B and C) 
when I would like it to find only the one from project C.


I am thus wondering how to avoid this duplication of configuration 
files (or avoid exposure of the A and B configuration files /for 
dependent projects/). (Naturally completely "excluding" logback.xml 
in A and B wouldn't solve my problem as it would also exclude the 
configuration file when running A or B themselves.)



More generally, is there some tutorial or best-practice about 
configuring logging for easy deployment and user-tweaking with 
maven? I would ideally like the end-user to be easily able to modify 
the logging strategy, while providing him sensible default

Re: Best practices for avoiding duplicate configuration files

2009-04-27 Thread Olivier Cailloux 

Thanks to everybody who answered. I answer to everyone together:
- Projects A and B are to be runnable independently and deployable 
without C. So putting the log config in test resources would not work.

- Putting the log files in a dependent module is possible. But:
 - it would render the pom and project management more complex. 
Currently these projects are not multi-modules, they are very simple,  
and that solution would involve transforming them to multi-module 
projects with one module being a whole module for only one stupid 
configuration file! And then having the project C exclude the right 
sub-module. But I admit that it is not my main concern (I could accept a 
complex solution if it was very good in other aspects) ;
 - it is not very elegant as any project depending on A or B would have 
to not forget to exclude the sub-module containing the log files (any 
dependent project would have the same problem as the project C has) ;
 - it does not solve the question of the log configuration file not 
being integrated in the jar for easily modification by the end-user 
after deployment ;
 - the problem I face is a general problem, as I always use log 
configuration files in my projects, so I would like to find a good 
solution once and for all.


- The use of Assembly and Dependency plugins is maybe part of a 
solution, but I don't see clearly how I can configure all this to do 
what I would like and avoiding ending up with pom files more complex 
than needed.


To re-cap, I dream of a solution allowing me the following two 
possibilities, for any project I create:
- a possibility to create and expose (for use by dependent projects) a 
.jar file NOT containing the log configuration file ;
- a possibility to create and deploy (for end-user usage) a .zip file 
containing the above .jar AND the log configuration file, which is then 
easy for the end-user to modify ; and some start-up script (portable) or 
something equivalent to correctly configure the classpath to include the 
log configuration file and allow the end-user to easily start the 
application (this is the part I don't see how to do with the FAQ 
provided at 
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/).


Although the solutions proposed did not fully satisfy my needs, I have 
to thank those who responded because it gave me good hints and allowed 
me to re-think about my problem. Any more advices would be very 
appreciated because I am a beginner in Maven and I think there must be 
somehow a simple solution to my needs which I simply overlooked. I am 
wondering how the others do as this must be a very common problem 
(everybody use logging framework!).


Also, sorry for my English...
Olivier

Brian Fox a écrit :
See the 9th bullet point here: 
http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/


On 4/26/2009 3:17 PM, Olivier Cailloux wrote:

Hello list,

I am new to maven and couldn't find a simple and elegant solution to 
this (probably) common problem.


I have three projects : A and B are independent projects and C 
depends on A and B. I use the same logging framework for the three 
projects (slf4j with logback). In A and B, I have a logback.xml 
configuration file in src/main/resources to configure logging 
behavior (A and B do not necessarily have the same configuration). C 
has also a specific logging configuration file. And, naturally, when 
I run the project C, logback complains that it found three 
logback.xml files in the classpath (the ones from A and B and C) when 
I would like it to find only the one from project C.


I am thus wondering how to avoid this duplication of configuration 
files (or avoid exposure of the A and B configuration files /for 
dependent projects/). (Naturally completely "excluding" logback.xml 
in A and B wouldn't solve my problem as it would also exclude the 
configuration file when running A or B themselves.)



More generally, is there some tutorial or best-practice about 
configuring logging for easy deployment and user-tweaking with maven? 
I would ideally like the end-user to be easily able to modify the 
logging strategy, while providing him sensible defaults. Probably the 
logback.xml file should not be embedded in the .jar, but I don't know 
how to do that (and don't know if this is the best solution!)


Thank you for any pointer.
Olivier


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: systemPath for directories not jars

2009-04-27 Thread Lee Mighdoll 
Thanks, that's helpful to know and gives me an excuse to learn a bit about
reactor.

Lee

On Sun, Apr 26, 2009 at 2:42 PM, Brian Fox  wrote:

> Not really, however Maven will do this automatically for projects in the
> same reactor if at least the compile phase is executed.
>
>
> On 4/26/2009 2:18 PM, Lee Mighdoll wrote:
>
>> I'd like to specify a directory of .class files instead of a jar with
>> systemPath.  Is there any way to do this?
>>
>> 1) It would be convenient during development not to have to create a jar
>> of
>> a closely related project
>> 2) It might help work around a problem with the maven aspectj plugin,
>> which
>> afaik will weave compiled classes only when they're specified as a
>> dependencies.
>>
>> Lee
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: systemPath for directories not jars

2009-04-27 Thread Lee Mighdoll 
Thanks, I hadn't tried that.  I found a
patchfor the aspectj
plugin that allows the use of .class directories.

Lee

On Sun, Apr 26, 2009 at 2:58 PM, Martin Gainty  wrote:

>
> Lee
> did you try to put the root folder of .classes in classpathPrefix element
> e.g.
>  
>
>  
> maven-war-plugin
> 
>   
> 
>   true
>   lib/
> 
>   
> 
>  
>
>  
> HTH
> Martin
> __
> Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note
> de déni et de confidentialité
> This message is confidential. If you should not be the intended receiver,
> then we ask politely to report. Each unauthorized forwarding or
> manufacturing of a copy is inadmissible. This message serves only for the
> exchange of information and has no legal binding effect. Due to the easy
> manipulation of emails we cannot take responsibility over the the contents.
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
>
>
>
>
>
> > Date: Sun, 26 Apr 2009 11:18:15 -0700
> > Subject: systemPath for directories not jars
> > From: leemighd...@gmail.com
> > To: users@maven.apache.org
> >
> > I'd like to specify a directory of .class files instead of a jar with
> > systemPath.  Is there any way to do this?
> >
> > 1) It would be convenient during development not to have to create a jar
> of
> > a closely related project
> > 2) It might help work around a problem with the maven aspectj plugin,
> which
> > afaik will weave compiled classes only when they're specified as a
> > dependencies.
> >
> > Lee
>
> _
> Windows Live™ Hotmail®:…more than just e-mail.
> http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_more_042009
>

Re: Can 'mvn site' include resources?

2009-04-27 Thread Ryan Connolly 
I handled this by creating a site skin...

See the following reference for more info:
http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html

Good luck!


On Mon, Apr 27, 2009 at 9:19 AM, REMIJAN, MICHAEL J [AG/1000]
 wrote:
> What is the best way for a site to inherit not only the site.xml from
> its parent but also the /src/site/resources from the parent too?  I'd
> like to be able to share images across projects but when I run mvn site
> on my child projects I do not get the /src/site/resources from the
> parent.  Is this even possible?
>
>
> -
> This e-mail message may contain privileged and/or confidential information, 
> and is intended to be received only by persons entitled to receive such 
> information. If you have received this e-mail in error, please notify the 
> sender immediately. Please delete it and all attachments from any servers, 
> hard drives or any other media. Other use of this e-mail by you is strictly 
> prohibited.
>
>
> All e-mails and attachments sent and received are subject to monitoring, 
> reading and archival by Monsanto, including its subsidiaries. The recipient 
> of this e-mail is solely responsible for checking for the presence of 
> "Viruses" or other "Malware". Monsanto, along with its subsidiaries, accepts 
> no liability for any damage caused by any such code transmitted by or 
> accompanying this e-mail or any attachment.
> -
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>



-- 
�...@n

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven Changes Report Plugin problem

2009-04-27 Thread Alexander Vaysberg 
Hi,
I have a Problem with Maven Changes Report Plugin. I have the
changes.xml file, but if I generate pages with site, i have not the data
from changes.xml. I use the changes:changes-validate and it say, that
all data valide in  changes.xml.  Can you halp me.

Alexander Vaysberg.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: pom-transformed.xml issue

2009-04-27 Thread Surendra . Naidu 
Thanks Oliver. Greatly appreciate your help. 

-Original Message-
From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier 
Lamy
Sent: Saturday, April 25, 2009 5:01 AM
To: Maven Users List
Subject: Re: pom-transformed.xml issue

Hi,
Perso, what I do is changing java.io.tmpdir in my .profile.
All dev who works on the same solaris server have something like that in 
~/.profile :
MAVEN_OPTS="-Xmx512m -Xms512m
-Djava.io.tmpdir=/home/${LOGNAME}/tmp/tmp-dir" export MAVEN_OPTS

HTH,
--
Olivier

2009/4/25  :
> Hi,
>
> While doing builds the generated pom-transformed.xml is placed in 
> /var/tmp/target in a solaris server. When another user does a build 
> for the same project, it failes as the file genereated by the earlier 
> user is still there. Is there any workaround to avoid this issue.
> Specifically can we determin the location of this xml.
>
> Thanks
>
> Surendra
>
> bash-2.05$ mvn -e deploy:deploy-file -DfilePath=../lib-jars 
> -DartifactId=servicesmanager -Dpackaging.type=jar
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> --
> -- [INFO] Building mybiz-accessmanagerservices [INFO]    task-segment: 
> [deploy:deploy-file] (aggregator-style) [INFO]
> --
> --
> [INFO] [deploy:deploy-file]
> [INFO]
> --
> --
> [ERROR] BUILD ERROR
> [INFO]
> --
> -- [INFO] Failed to interpolate POM versions.
>
> /var/tmp/target/pom-transformed.xml (Permission denied) [INFO]
> --
> --
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
> interpolate POM versions.
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defau
> lt
> LifecycleExecutor.java:703)
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneG
> oa
> l(DefaultLifecycleExecutor.java:553)
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defaul
> tL
> ifecycleExecutor.java:523)
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand
> le
> Failures(DefaultLifecycleExecutor.java:371)
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment
> s(
> DefaultLifecycleExecutor.java:268)
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLif
> ec
> ycleExecutor.java:181)
>        at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
>        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
>        at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> av
> a:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> or
> Impl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:324)
>        at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>        at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to 
> interpolate POM versions.
>        at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.j
> av
> a:244)
>        at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugin
> Ma
> nager.java:483)
>        at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defau
> lt
> LifecycleExecutor.java:678)
>        ... 16 more
> Caused by:
> org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed 
> to interpolate POM versions.
>        at
> org.apache.maven.project.artifact.VersionExpressionTransformation.tran
> sf
> ormForDeployment(VersionExpressionTransformation.java:113)
>        at
> org.apache.maven.artifact.transform.DefaultArtifactTransformationManag
> er
> .transformForDeployment(DefaultArtifactTransformationManager.java:78)
>        at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Defa
> ul
> tArtifactDeployer.java:86)
>        at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.j
> av
> a:240)
>        ... 18 more
> Caused by:
> org.apache.maven.project.interpolation.ModelInterpolationException:
> Failed to write transformed POM: /var/tmp/target/pom-transformed.xml
>        at
> org.apache.maven.project.artifact.VersionExpressionTransformation.inte
> rp
> olateVersions(VersionExpressionTransformation.java:386)
>        at
> org.apache.maven.project.artifact.VersionExpressionTra

Re: failed to resolve artifact for maven-install-plugin

2009-04-27 Thread Wayne Fay 
> I don't have any proxies configured. The strange thing is that when I built
> the WAR project - maven was able to download some of the artifacts (from
> central repo), and some of them did not (this is why I tried to install
> manually - for example javax-persistence) - here is my settings.xml file (I
> removed comments):

I would take all of that out except perhaps for the localRepository
and try "mvn -U install:install-file ..." again.

You don't have a proxy and I really have no idea why you're trying to
set up Central as a mirrorOf codehaus/snapshots and then also
involving Java.net. Just take all of that out for now.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reference on ejb module from web module in .component

2009-04-27 Thread Florian MULLER 
Hi all,

I 've got a problem with the deployement of an ejb module. In my case,
i've a multi-projects with WTP 3.0.5.
I reference the ejb module as dependency in the POM of my web project.
But, when i want deploy it on Tomcat 6.0, my ejb module isn't exported.
However if i update manually the "deploy-path" in
"org.eclipse.wst.common.component", with "/WEB-IN/lib" all is ok, it's
works...

After investigation, i've found a comment "ejb's and wars must always
be toplevel" in
org.apache.maven.plugin.eclipse.writers.wtp.AbstractWtpResourceWriter::addDependency(...)

Please, could you tell me, why "ejb must always be toplevel ? How could
I deploy my web module with ejb dependency ?

Thanks a lot,

Best regards,

Florian Müller

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-27 Thread Brian Fox 
See the 9th bullet point here: 
http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/


On 4/26/2009 3:17 PM, Olivier Cailloux wrote:

Hello list,

I am new to maven and couldn't find a simple and elegant solution to 
this (probably) common problem.


I have three projects : A and B are independent projects and C depends 
on A and B. I use the same logging framework for the three projects 
(slf4j with logback). In A and B, I have a logback.xml configuration 
file in src/main/resources to configure logging behavior (A and B do 
not necessarily have the same configuration). C has also a specific 
logging configuration file. And, naturally, when I run the project C, 
logback complains that it found three logback.xml files in the 
classpath (the ones from A and B and C) when I would like it to find 
only the one from project C.


I am thus wondering how to avoid this duplication of configuration 
files (or avoid exposure of the A and B configuration files /for 
dependent projects/). (Naturally completely "excluding" logback.xml in 
A and B wouldn't solve my problem as it would also exclude the 
configuration file when running A or B themselves.)



More generally, is there some tutorial or best-practice about 
configuring logging for easy deployment and user-tweaking with maven? 
I would ideally like the end-user to be easily able to modify the 
logging strategy, while providing him sensible defaults. Probably the 
logback.xml file should not be embedded in the .jar, but I don't know 
how to do that (and don't know if this is the best solution!)


Thank you for any pointer.
Olivier


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Can 'mvn site' include resources?

2009-04-27 Thread REMIJAN, MICHAEL J [AG/1000] 
What is the best way for a site to inherit not only the site.xml from
its parent but also the /src/site/resources from the parent too?  I'd
like to be able to share images across projects but when I run mvn site
on my child projects I do not get the /src/site/resources from the
parent.  Is this even possible?


-
This e-mail message may contain privileged and/or confidential information, and 
is intended to be received only by persons entitled to receive such 
information. If you have received this e-mail in error, please notify the 
sender immediately. Please delete it and all attachments from any servers, hard 
drives or any other media. Other use of this e-mail by you is strictly 
prohibited.


All e-mails and attachments sent and received are subject to monitoring, 
reading and archival by Monsanto, including its subsidiaries. The recipient of 
this e-mail is solely responsible for checking for the presence of "Viruses" or 
other "Malware". Monsanto, along with its subsidiaries, accepts no liability 
for any damage caused by any such code transmitted by or accompanying this 
e-mail or any attachment.
-


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-27 Thread Ketil Aasarød 
If A and B are only utility modules (not runnable), and you only use
the log configuration files for unit testing, I would have moved them
to src/test/resources in A and B. That way they are not made available
to C. C will have the log configuration file in src/main/resources, at
least if it is a war/ear module.

Hope that helps.

-ketil

On Mon, Apr 27, 2009 at 1:23 PM, Stephen Connolly
 wrote:
> Create a new module(s) which just has the log configuration...
>
> then A & B can both depend on this(ese) new module(s)...
>
> C can exclude the module(s) from it's dependencies on A & B
>
> 2009/4/26 Olivier Cailloux 
>
>> Hello list,
>>
>> I am new to maven and couldn't find a simple and elegant solution to this
>> (probably) common problem.
>>
>> I have three projects : A and B are independent projects and C depends on A
>> and B. I use the same logging framework for the three projects (slf4j with
>> logback). In A and B, I have a logback.xml configuration file in
>> src/main/resources to configure logging behavior (A and B do not necessarily
>> have the same configuration). C has also a specific logging configuration
>> file. And, naturally, when I run the project C, logback complains that it
>> found three logback.xml files in the classpath (the ones from A and B and C)
>> when I would like it to find only the one from project C.
>>
>> I am thus wondering how to avoid this duplication of configuration files
>> (or avoid exposure of the A and B configuration files /for dependent
>> projects/). (Naturally completely "excluding" logback.xml in A and B
>> wouldn't solve my problem as it would also exclude the configuration file
>> when running A or B themselves.)
>>
>>
>> More generally, is there some tutorial or best-practice about configuring
>> logging for easy deployment and user-tweaking with maven? I would ideally
>> like the end-user to be easily able to modify the logging strategy, while
>> providing him sensible defaults. Probably the logback.xml file should not be
>> embedded in the .jar, but I don't know how to do that (and don't know if
>> this is the best solution!)
>>
>> Thank you for any pointer.
>> Olivier
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-27 Thread Stephen Connolly 
Create a new module(s) which just has the log configuration...

then A & B can both depend on this(ese) new module(s)...

C can exclude the module(s) from it's dependencies on A & B

2009/4/26 Olivier Cailloux 

> Hello list,
>
> I am new to maven and couldn't find a simple and elegant solution to this
> (probably) common problem.
>
> I have three projects : A and B are independent projects and C depends on A
> and B. I use the same logging framework for the three projects (slf4j with
> logback). In A and B, I have a logback.xml configuration file in
> src/main/resources to configure logging behavior (A and B do not necessarily
> have the same configuration). C has also a specific logging configuration
> file. And, naturally, when I run the project C, logback complains that it
> found three logback.xml files in the classpath (the ones from A and B and C)
> when I would like it to find only the one from project C.
>
> I am thus wondering how to avoid this duplication of configuration files
> (or avoid exposure of the A and B configuration files /for dependent
> projects/). (Naturally completely "excluding" logback.xml in A and B
> wouldn't solve my problem as it would also exclude the configuration file
> when running A or B themselves.)
>
>
> More generally, is there some tutorial or best-practice about configuring
> logging for easy deployment and user-tweaking with maven? I would ideally
> like the end-user to be easily able to modify the logging strategy, while
> providing him sensible defaults. Probably the logback.xml file should not be
> embedded in the .jar, but I don't know how to do that (and don't know if
> this is the best solution!)
>
> Thank you for any pointer.
> Olivier
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Will Central Repository accepts thirdparty repositories in pom.xml JUST FOR SNAPSHOTS?

2009-04-27 Thread mkleint 

Chen SIL wrote:

Guide to uploading artifacts to the Central Repository (
http://maven.apache.org/guides/mini/guide-central-repository-upload.html)
said repositories & pluginRepositories in pom.xml are not allowed because
the central repository must self contained, but in the other hand, the
Central Repository only synchronizes the release version.So, if I need
some other repositories and pluginRepositories, but just for building the
snapshot versions, could I include them in my pom.xml for uploading to the
Central Repository?Thanks.

  
central repository doesn't contain any snapshots. And any released 
artifact shall only depend on non-snapshot artifacts..


Milos

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

dependency to run jetty on a dependent project

2009-04-27 Thread Jozsef Zsido 
Hi,



I have the following setup:

A super pom project which enumerates 2 modules: a web service war project
and a web service client project.

The web service client calls the wsimport goal in order to generate the
client artifacts but that fails if I don’t run the other project with mvn
jetty:run.

In order to run the web service client tests also requires that the jetty to
run.



How could I do this automatically?



Thanks,

Jozsef

failed to resolve artifact for maven-install-plugin

2009-04-27 Thread pjotr 

Hi,

I am not able to get maven-install-plugin (when executing 'mvn install' 
command)- getting the following error:


[INFO]task-segment: [install]
[INFO] 

Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom
Downloading: 
http://download.java.net/maven/2//org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed to resolve artifact.

GroupId: org.apache.maven.plugins
ArtifactId: maven-install-plugin
Version: 2.2

Reason: Unable to download the artifact from any repository

 org.apache.maven.plugins:maven-install-plugin:pom:2.2

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 maven2-repository.dev.java.net (http://download.java.net/maven/2/)

I checked 
(http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2) 
- required jar and pom is there. Any ideas how to solve it?


Regards
pjotr

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Best practices for avoiding duplicate configuration files

2009-04-27 Thread Olivier Cailloux 

Hello list,

I am new to maven and couldn't find a simple and elegant solution to 
this (probably) common problem.


I have three projects : A and B are independent projects and C depends 
on A and B. I use the same logging framework for the three projects 
(slf4j with logback). In A and B, I have a logback.xml configuration 
file in src/main/resources to configure logging behavior (A and B do not 
necessarily have the same configuration). C has also a specific logging 
configuration file. And, naturally, when I run the project C, logback 
complains that it found three logback.xml files in the classpath (the 
ones from A and B and C) when I would like it to find only the one from 
project C.


I am thus wondering how to avoid this duplication of configuration files 
(or avoid exposure of the A and B configuration files /for dependent 
projects/). (Naturally completely "excluding" logback.xml in A and B 
wouldn't solve my problem as it would also exclude the configuration 
file when running A or B themselves.)



More generally, is there some tutorial or best-practice about 
configuring logging for easy deployment and user-tweaking with maven? I 
would ideally like the end-user to be easily able to modify the logging 
strategy, while providing him sensible defaults. Probably the 
logback.xml file should not be embedded in the .jar, but I don't know 
how to do that (and don't know if this is the best solution!)


Thank you for any pointer.
Olivier


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Will Central Repository accepts thirdparty repositories in pom.xml JUST FOR SNAPSHOTS?

2009-04-27 Thread Chen SIL 
Guide to uploading artifacts to the Central Repository (
http://maven.apache.org/guides/mini/guide-central-repository-upload.html)
said repositories & pluginRepositories in pom.xml are not allowed because
the central repository must self contained, but in the other hand, the
Central Repository only synchronizes the release version.So, if I need
some other repositories and pluginRepositories, but just for building the
snapshot versions, could I include them in my pom.xml for uploading to the
Central Repository?Thanks.

Re: [Archetype] Adding a package to an existing project

2009-04-27 Thread Yopy 

Anyone?* Not being able to merge files isn't a big problem per sé, but it'll
involve more work to do for the people that are going to use my archetypes
in the (near?) future.

(*: Note that I don't know the policy on 'bumping' a thread, nor am I
familiar with the proper term to use when it concerns mailing lists. I
prefer forums, tbh =D)


Yopy wrote:
> 
> Okay, that works wonderfully, =D. Time for the next question - and if this
> is documented somewhere, I wasn't able to find it anywhere.
> 
> I now have a 'partial' archetype that can add a skeleton of functionality
> to a project. The general idea is to be able to add the same archetype
> multiple times to a project, but currently, I get an OutputFileExists
> error. I'm pretty sure I saw an 'overwrite=true' or 'allowOverwrite=true'
> property somewhere, which will work just fine for the non-critical stuff
> like images and such resources, but there's also a couple of .properties
> files with language resources, which really shouldn't be overwritten, but
> rather 'merged' with each other.
> 
> Does Maven's Archetype plugin or Velocity offer functionality to do this?
> The language labels will in most cases be unique, so determining whether
> to overwrite or add shouldn't be too difficult.
> 
> Also, is there a way to have the archetype generate goal check for
> duplicate entries for non-overwritable resources before files start to get
> written? Currently, folders and such are created, but only later does the
> plugin figure out that it can't continue due to existing files,
> effectively cluttering the project up. Which isn't a problem right now
> during development, since I just delete the whole project and start anew,
> but it's not something that would be desirable for active projects.
> 
> Can - once again - anyone point me in the right direction? Or at least
> give the proper Google terms to use to find it, I've pretty much expended
> my vocabulary already, :/.
> 
> 
> Raphaël wrote:
>> 
>> Hi
>> 
>> You can find an example of partial archetype in
>> http://svn.apache.org/repos/asf/maven/archetype/trunk/archetype-common/src/test/archetypes/partial-1.0/
>> 
>> You can find some unit tests using that archetype in
>> http://svn.apache.org/repos/asf/maven/archetype/trunk/archetype-common/src/test/java/org/apache/maven/archetype/generator/DefaultArchetypeGeneratorTest.java
>> 
>> Regards,
>> 
>> Raphaël
>> 
>> 2009/4/23 Yopy 
>> 
>>>
>>> Hi all, I'm having issues with the Archetype plugin.
>>>
>>> I've made an archetype that sets up a 'skeleton' application, which can
>>> be
>>> packaged as an OSGI module and distributed. This works fine, no problems
>>> there (yet, and the problems that were there I have managed to solve).
>>>
>>> The next step is to add 'components' to this module. A component, in
>>> this
>>> case, is a set of classes and resources added to the project's src
>>> folder.
>>> I
>>> figured that partial archetypes would - in theory - do the trick, but
>>> I'm
>>> having trouble with that.
>>>
>>> The first problem is that there doesn't seem to be proper documentation
>>> on
>>> the subject. There is some documentation available on the archetype
>>> creation
>>> process, but it's limited and whatnot. There's also no or very little
>>> documentation on creating and using a partial archetype - the one I
>>> found
>>> was for an older version, it seems, where the archetype configuration
>>> file
>>> was still called 'archetype.xml' instead of the current
>>> 'archetype-metadata.xml'.
>>>
>>> But anyways. I've made my archetype's source which is mainly out of a
>>> source
>>> folder that adds a set of classes to the package the user indicates on
>>> the
>>> commandline. I've also had to add a pom.xml file in the root of the
>>> archetype-resources folder, else the archetype would not install.
>>>
>>> I've added an -tag to the archetype-metadata.xml, guessing
>>> that's what you have to add to this file in order to make it a partial
>>> project - please correct me if I'm wrong.
>>>
>>> Next, I go to the commandline, mvn archetype:generate my skeleton
>>> project,
>>> works fine. Next, I archetype:generate the 'partial' archetype, but
>>> that's
>>> where the problems begin.
>>>
>>> When calling the archetype:generate command with the partial archetype,
>>> I
>>> get the error that there is already a Maven2 project with the same name
>>> as
>>> the archetypeId. It doesn't seem like I can leave this value blank,
>>> either.
>>>
>>> The next attempt is to go into the project skeleton directory and call
>>> the
>>> command there, but then I get the error that Maven is 'unable to add
>>> module
>>> to the current project as it is not of packaging type 'pom''.
>>>
>>> I'm starting to suspect that the 'partial' archetype can only add full
>>> modules to a Maven project - is this suspicion correct?
>>>
>>> If not, then what might I be doing wrong? What is required to create a
>>> partial archetype that (attempts to) add files and folders to an
>>> ex

Re: Using buildnumber-maven-plugin together with jetty plugin

2009-04-27 Thread Olivier Lamy 
Hi,
I have deployed a new snapshot (1.0-beta-3-20090427.074600-10) but I
didn't have any issues here.
I will work on a release.
--
Olivier

2009/4/27 nodje :
>
> Hi Olivier,
>
> I got an error following the update of builnumber-maven-plugin
> 1.0-beta-3-SNAPSHOT:
>
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: org.codehaus.mojo:buildnumber-maven-plugin
>
> Reason: Failed to build model from file
> '/Users/nodje/.m2/repository/org/codehaus/mojo/buildnumber-maven-plugin/1.0-beta-3-SNAPSHOT/buildnumber-maven-plugin-1.0-beta-3-SNAPSHOT.pom'.
> Error: 'no more data available - expected end tags
>  to close start tag
>  from line 85 and start tag  from line 83 and start
> tag  from line 57 and start tag  from line 2, parser
> stopped on START_TAG seen ...maven-sc... @85:27' for project
> org.codehaus.mojo:buildnumber-maven-plugin
>
> regards,
> nodje
>
>
>
>
> nodje wrote:
>>
>> Thanks, sorry about that, I was limiting the artifacts to javax/* only.
>>
>> I still don't understand: [WARNING] Attempting to build MavenProject
>> instance for Artifact
>> (org.codehaus.mojo:buildnumber-maven-plugin:1.0-beta-3-20090414.214556-8)
>> of type: maven-plugin; constructing POM artifact instead.
>> but it seems to appear from time to time only (probably on Maven first
>> launch of the day)
>>
>> thanks!
>>
>>
>> Olivier Lamy wrote:
>>>
>>> You have to configure your repo manager (artifactory as I can see in your
>>> logs).
>>> Because the pom is really here [1].
>>>
>>> --
>>> Olivier
>>>
>>> [1] http://download.java.net/maven/2/net/java/dev/jna/jna/3.0.5/
>>>
>>> 2009/4/17 nodje :

 Olivier,

 i'm getting those log lines for each mavengoal invoked:

 [WARNING] Attempting to build MavenProject instance for Artifact
 (org.codehaus.mojo:buildnumber-maven-plugin:1.0-beta-3-20090414.214556-8)
 of type: maven-plugin; constructing POM artifact instead.
 [06:46:25] Downloading:
 http://allence:8081/artifactory/repo/net/java/dev/jna/jna/3.0.5/jna-3.0.5.pom
 [06:46:26] Downloading:
 http://allence:8081/artifactory/repo/net/java/dev/jna/jna/3.0.5/jna-3.0.5.pom

 I don't understand the warning and I'm wondering why it has to
 re-download the jna artifacts each time?

 Can you elaborate a bit on this please?

 thanks
 -nodje


 2009/4/14 Olivier Lamy :
> 2009/4/14 nodje :
>>
>> Hi Olivier,
>>
>> it does actually help! It works in IDEA now.
>> But if it can filter the ${timestamp}, it doesn't work anymore for
>> ${buildNumber}:
>>
>> [INFO] [buildnumber:create {execution: default}]
>> [INFO] Change the default 'svn' provider implementation to 'javasvn'.
>> [INFO] Checking for local modifications: skipped.
>> [INFO] Updating project files from SCM: skipped.
>> [INFO] Storing buildNumber: null at timestamp: 2009-04-14 14:00:16
>>
>> Thats' weird. And same behavior from the CLI (fortunately,
>> consistent):
>>
>> [INFO] [buildnumber:create {execution: default}]
>> [INFO] Change the default 'svn' provider implementation to 'javasvn'.
>> [INFO] Checking for local modifications: skipped.
>> [INFO] Updating project files from SCM: skipped.
>> [INFO] Storing buildNumber: null at timestamp: 2009-04-14 14:03:31
>>
>> It works from the CLI with the regular providerImplemtation
>> (unspecified as it was before) but still the latest version of the
>> plugin:
>>
>> [INFO] [buildnumber:create {execution: default}]
>> [INFO] Checking for local modifications: skipped.
>> [INFO] Updating project files from SCM: skipped.
>> [INFO] Executing: /bin/sh -c cd
>> /Users/nodje/Documents/project/company/project && svn
>> --non-interactive info
>> [INFO] Working directory:
>> /Users/nodje/Documents/project/allence/alpha2
>> [INFO] Storing buildNumber: 3077 at timestamp: 2009-04-14 14:05:13
>>
>> From the trace differences, it looks like the javasvn
>> providerImplementation doesn't actually call the svn info to get the
>> revision number.
> Arghhh, I will check that.

 Should be fixed with last deployed SNAPSHOT.

>>
>> Seems to be a problem on the buildnumber-maven-plugin side. Are you
>> also working on it by the way?
>> Because the [2] link didn't exist yesterday !?  :)
> yes I do
>>
>> cheers
>> -nodje
>>
>>
>> You can try the current trunk of the buildnumber plugin which support
>> using svnjava [1].
>> How to use it it's documented here [2]
>>
>> HTH,
>> --
>> Olivier
>>
>> [1] http://code.google.com/p/maven-scm-provider-svnjava/
>> [2]
>> http://mojo.codehaus.org/buildnumber-maven-plugin/using-svnjava.html
>>
>> 2009/4/13 Stephen Connolly :
>>> 2009/4/13 nodje 
>>>

 I'm not sure of what you mean exactly Stephen.
 This is how I interpreted

Re: failed to resolve artifact for maven-install-plugin

2009-04-27 Thread pjotr 
I don't have any proxies configured. The strange thing is that when I 
built the WAR project - maven was able to download some of the artifacts 
(from central repo), and some of them did not (this is why I tried to 
install manually - for example javax-persistence) - here is my 
settings.xml file (I removed comments):


http://maven.apache.org/settings/1.0.0";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
http://maven.apache.org/xsd/settings-1.0.0.xsd";>


 
C:\_TOOLS\apache-maven-2.0.10\maven-repo


 
 

 
 

 


  codehaus snapshot mirror
  Mirror site of Codehaus
  http://repo1.maven.org/maven2
  snapshots


  codehaus mirror
  Mirror Site of Codehaus
  http://repo1.maven.org/maven2
  codehaus




 
 
   default
   
 
 maven2-repository.dev.java.net
 Java.net Repository for Maven
 http://download.java.net/maven/2/
 default
   
   
   
 

 
   default
 




Am I missing something here?




Brian Fox pisze:

Check that you don't have a proxy blocking you.

On 4/26/2009 11:15 AM, pjotr wrote:

Hi,

I am not able to get maven-install-plugin (when executing 'mvn 
install' command)- getting the following error:


[INFO]task-segment: [install]
[INFO] 

Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 

Downloading: 
http://download.java.net/maven/2//org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 

Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 

[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed to resolve artifact.

GroupId: org.apache.maven.plugins
ArtifactId: maven-install-plugin
Version: 2.2

Reason: Unable to download the artifact from any repository

org.apache.maven.plugins:maven-install-plugin:pom:2.2

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
maven2-repository.dev.java.net (http://download.java.net/maven/2/)

I checked 
(http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2) 
- required jar and pom is there. Any ideas how to solve it?


Regards
pjotr

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org