Re: Writing own plugin: The parameter annotation - does it work?

[Martin Hoeller]

Hi Gerrit!

If you search for some examples have a look at
https://github.com/matinh/vdldoc-maven-plugin

I created this project some time ago as a proove of concept for myself
to write a simple maven plugin including integration testing. Use the
"run-its" profile to enable integration-tests and have a look at the
main pom.xml resp. the POMs of the ITs in src/it/*.

hth,
- martin

On Tue, 17 Apr 2018 09:25 wrote :

> With Maven Invoker you create Maven projects like your plugin-users
> do. And then Maven will be called to run this project. It is as close
> as possible to the real world .
> If you want to make unittests, maven-plugin-testing-harness should
> work, but it lacks good documentation.
> Downside of this is that you're testing it with 1 specific version
> of Maven. The takari plugin seems to be able to cover multiple Maven  
> versions, but you won't be able to debug issues for a specific Maven  
> version.
> 
> thanks,
> Robert
> 
> On Tue, 17 Apr 2018 09:16:51 +0200,  wrote:
> 
> > Hi Robert,
> >
> > thanks a lot for your mail.
> > I create 2 issues about this.
> >
> > About that Maven Invoker Plugin:
> > Are there any examples how to use that in a JUnit test?
> >
> > Regards,
> > Gerrit


pgpo1YVvHWSLr.pgp
Description: Digitale Signatur von OpenPGP

Re: old version of dependencies getting included into project

[Martin Hoeller]

Hi!

On 14 Mar 2018, Jonathan Yom-Tov wrote:

> I have a fairly large project which compiles to a war file. I've upgraded
> the jackson dependency to 2.7.3 but for some reason 2.4.3 and 2.4.0 jar
> files are included into the war file in addition to the 2.7.3 version. I
> ran mvn dependency:tree to figure out the reason but the old versions don't
> appear there. They also don't appear in the build log. I deleted the old
> versions from my local maven repo. Didn't help. Any ideas on how to figure
> this out?

Did you do a "mvn clean" after upgrading?
Maybe the old JARs just didn't get purged from you build directory.

hth,
- martin


pgpaGnJq21bFC.pgp
Description: Digitale Signatur von OpenPGP

Re: Query on increasing virtual memory for java heap size issue

[Martin Hoeller]

Hi!

On 30 Jän 2018, Saisowjanya N wrote:

> Dear All
> I am facing java heap space issue.I want increase the heap size using vm 
> arguments through maven.
> 
> When searched in internet I found a solution that says to define 
> ${maven.projectBasedir}/.mvn/extensions.xml in our project
> 
> Could you please help on how to define the file 
> ${maven.projectBasedir}/.mvn/extensions.xml in our project 

You mean .mvn/jvm.config not .mvn/extensions.xml. See the documentation
here fore details:
https://maven.apache.org/docs/3.3.1/release-notes.html#JVM_and_Command_Line_Options

hth,
- martin


pgpv5rqI3pBpy.pgp
Description: Digitale Signatur von OpenPGP

Re: How to use global checkstyle.xml that have SuppressionsFilter included

[Martin Hoeller]

On 09 Mai 2017, Gayan Weerakutti wrote:

> So here in my case I want use remote checkstyle file located in 
> https://github.com/openmrs/openmrs-core/blob/master/checkstyle.xml?#L45 in 
> another project.
> 
> 
> In my project's pom I have config location set as 
> follows:
> 
> 
> 
>  https://github.com/openmrs/openmrs-core/blob/master/checkstyle.xml
> 
> 
> However checkstyle can't resolve checkstyle-suppressions.xml because of the 
> configuration included in the remote file:
> 
> 
> 
> 
> 
> So what would be the ideal solution to be alble to use that remote checkstyle 
> on other projects?

What about specifying the suprresion file also in your project:


  
https://github.com/openmrs/openmrs-core/blob/master/checkstyle.xml
  
  

https://github.com/openmrs/openmrs-core/blob/master/checkstyle-suppressions.xml
  


I don't know if this works, but you could give it a try.

hth,
- martin


pgpkAo4yxW5v4.pgp
Description: Digitale Signatur von OpenPGP

Re: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[Martin Hoeller]

Hi!

On Mon, 20 Feb 2017 16:32 "KARR, DAVID"  wrote:

> Although my issue is about configuring the "jacoco-maven-plugin", I
> think it's really more of a pure Maven configuration issue, as I
> don't think this situation is unique to JaCoCo.
> 
> I have a somewhat large multi-module project.  Each of the child
> modules has a parent pom that configures the "jacoco-maven-plugin" to
> do offline instrumentation (at present, all the modules having unit
> tests using PowerMock, which doesn't work with online
> instrumentation).
> 
> I've designed a change that I'll have to make in a few classes in
> each module that will allow the unit tests to use Mockito, and for
> JaCoCo to use online instrumentation.  I'll eventually fix all of
> them to work this way, but it will take a little while.  In the
> meantime, I just want to override the configuration in the "fixed"
> modules with online instrumentation and let the other modules use the
> default of offline instrumentation.
> 
> The simple-minded way to do this is just to define the same
> configuration using online instrumentation in each "fixed" module, so
> it will override the parent pom.  Copying that block to every "fixed"
> module is not a great idea.  I'd like a solution that requires less
> code duplication.


Just two weeks ago Tamás Cservenák pointed out on this list the
configuration-maven-plugin [1]. I haven't used it myself, but it sounds
like this plugin could help you saving some code duplication.

hth,
- martin

[1] https://github.com/cstamas/configuration-maven-plugin


pgpZ_uqmsITba.pgp
Description: Digitale Signatur von OpenPGP

Re: Building WAR files with/without EAR context

[Martin Hoeller]

On Fri, 18 Nov 2016 11:17:08 +0100 Stefan Seidel  wrote:

> you don't usually depend on EJBs in your WARs.

That's actually right. You depend on the API (interfaces) of the EJBs.
This is usually in separate JAR (but it is not required to be).

> You should depend on
> ejb- client. IIRC you'll have to explicitely configure your EJB
> project to create an ejb-client artifact.

You mean this:
http://maven.apache.org/plugins/maven-ejb-plugin/examples/generating-ejb-client.html

That's one possibility to separate interfaces and classes. But IMHO
this only sufficies very simple scenarios. I usually separate the
classes and interfaces by hand and have different modules for them.

- martin


pgpQF_XDm17wF.pgp
Description: Digitale Signatur von OpenPGP

Re: Building WAR files with/without EAR context

[Martin Hoeller]

On 17 Nov 2016, Clemens von Musil wrote:

> We pushed a very minimal example project to a public github repo located
> here:
> 
> https://github.com/kr1schan/mavenToy
> 
> The project consists of an ear, two war modules, one ejb module and one
> plain jar artifact.
> Both war modules depend on the ejbmodule as well as on the jar artifact.
> SkinnyWar is enabled and configured in all conscience.
> 
> After 'mvn clean package', the resulting ear shows correct handling of the
> jar dependency.
> The ejb dependency remains in both war files.

Good to have a minimal example showing the problem! I confirm that I can
reproduce the buggy (?) behavior.

Unfortunately I can reproduce it and can't see the error when looking
into it for 5 minutes. Don't have time for a close look right now, sorry.

- martin


pgpmDxkBhdffg.pgp
Description: Digitale Signatur von OpenPGP

Re: Building WAR files with/without EAR context

[Martin Hoeller]

On 16 Nov 2016, Clemens von Musil wrote:

> This is true for jar dependencies.
> 
> But if the war file depends on an artifact with type ejb
> (ejb), the skinnywar-option ignores this dependency and let it
> remain in war/lib.

This is not true in general, it works for me!
Did you declare the dependency correct with ejb in *all*
places (WAR and EAR, and maybe a parent POM)) where you reference it?

> And if there are two war files WAR1 and WAR2 depending on the same artifact
> with type ejb, the ear isn't deployable as the beans within the
> ejb-artifact resist in WAR1/lib _and_ WAR2/lib. The container tries to
> deploy beans from both loations and struggles as it cannot deploy the same
> bean twice.

This is a logical result from the above problem.

> We found a workaound. We define all dependencies without the type-tag to
> keep the skinnywar-option working. To avoid malicious packaging inside the
> EAR, we define all these dependencies as jarmodules with explicit deploy
> path and entry in the application.xml. Such a definition looks like
> 
> 
> groupid
> artifactid
> true
> /
> 
> 
> Ugly but working.

This shouldn't be necessary. I really think you have a configuration bug
and missed the ejb in some places.

- martin


pgpqa8E2V9Nlr.pgp
Description: Digitale Signatur von OpenPGP

Re: Building WAR files with/without EAR context

[Martin Hoeller]

On 14 Nov 2016, Clemens von Musil wrote:

> Hi again,
> 
> thanks a lot for your advice, Martin.
> 
> We spent a lot of time into skinny wars but stuck with ejb dependencies.
> 
> The EAR contains several WAR modules and these WAR modules share several
> EJB modules.
> Unfortunately, the skinny war option seems to ignore transitive EJB
> dependencies so that we get errors with duplicate beans on startup.

The skinnyWar-option should just remove JARs from the WAR that are also
defined in the POM of the EAR module. Nothing special about transitive
dependencies here I' guess.

Try this again:
https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html

If you list a dependency in the EAR, it should then be removed from the
WAR that is bundled with the EAR (this not the WAR installed in your
local repo!).

If this is not the case, there is either a bug, or you are doing
something wrong. But you would need to provide more details: POMs of the
WAR and the EAR and a listing of the relevant EAR and WAR contents.

hth,
- martin


pgpt83DaVhmrL.pgp
Description: Digitale Signatur von OpenPGP

Re: Building WAR files with/without EAR context

[Martin Hoeller]

Hi!

On 08 Nov 2016, Clemens von Musil wrote:

> I am working on a multimodule maven project consisting of several EJB, WAR
> and an EAR module. The EJB modules contain shared functionality.
> 
> To increase development speed, I want the WAR modules build in a way that
> allows me to bundle them into the EAR as well as deploy them standalone in
> my EE container.

Wrong approach! Build the WAR as you would need it in standalone-mode and
configure the maven-ear-plugin to make the WAR a skinny war.

Details can be found here:
https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html

hth,
- martin


pgp2_fx7oPWiR.pgp
Description: Digitale Signatur von OpenPGP

Re: Comparing specifying repositories in pom vs. settings.xml?

[Martin Hoeller]

On 17 Okt 2016, Manfred Moser wrote:

> If you really feel you need to control the source of where you download 
> components from within the source control system 
> I would still NOT use the repositories definition in the POM since that is 
> them transferred to the target repo on deployment (unless you use flatten).
> 
> Instead I would check in a specific settings.xml as part of the project... or 
> even multiple ones for different build scenarios.. 

You could even use the .mvn/ folder with a maven.config file in it, so
use this specific settings.xml without any other setup. See
https://maven.apache.org/docs/3.3.1/release-notes.html#JVM_and_Command_Line_Options
for details.

hth,
- martin


pgpXwqS7SWtqY.pgp
Description: Digitale Signatur von OpenPGP

[ANN] vdldoc-maven-plugin 1.0-beta-1 available

[Martin Hoeller]

Hi all!

I'm happy to announce the availability of the Vdldoc Maven Plugin
1.0-beta-1 on maven central.

The Vdldoc Maven Plugin uses OmniFaces Vdldoc [1] to generate
documentation for Facelet tags and JSF (composite) components. Basically
it's JavaDoc for JSF.

Documentation: https://matinh.github.io/vdldoc-maven-plugin/
Source Code: https://github.com/matinh/vdldoc-maven-plugin/

Enjoy,
- martin


[1] http://vdldoc.omnifaces.org/


pgp5MxGuYCoaZ.pgp
Description: Digitale Signatur von OpenPGP

Re: Use 2 pom.xml files with different names

[Martin Hoeller]

Hi!

Am Mon, 10 Aug 2015 19:23:51 +0300 schrieb Alex Ditu ditu.alexan...@gmail.com:

 I cannot test right now, but it can be tested very simple: in a simple
 project, rename pom.xml and run install/deploy, and see if it works.
 If it is ok, then is smth that I've done wrong. Else maybe it is the
 desired effect (wich I don't understand).

I created a simple quickstart project with

  mvn archetype:generate

moved the pom.xml to some-pom.xml and executed

  mvn -f some-pom.xml install

without any problems. The project was installed correctly in
~/.m2/repository:

  $ ls -1 ~/.m2/repository/test/quickstart/1.0-SNAPSHOT/
  _remote.repositories
  maven-metadata-local.xml
  quickstart-1.0-SNAPSHOT.jar
  quickstart-1.0-SNAPSHOT.pom

So something must be different in your setup.

hth,
- martin


signature.asc
Description: PGP signature

versions-maven-plugin not updating properties any more

[Martin Hoeller]

Hi all!

I have two multi-module projects where the first one is a dependency of
the second one. Usually before a release of the second one also the first
one is released and the second one has to update the dependency-version
which is set via a property.

For this update I use versions-maven-plugin (v2.1) to do the update:

  mvn -DincludeProperties=mylib.version versions:update-properties

This used to work, when the released version was for example 1.0-beta-13
and the new development version was 1.0-beta-14-SNAPSHOT.

After I changed the new development version to always be 1.0-SNAPSHOT the
update via versions-maven-plugin stopped working. I get debugging output
like state from somebody else on StackOverflow:
http://stackoverflow.com/questions/25034556/how-can-i-update-a-property-in-a-maven-pom

For me this means version 1.0-beta-13/14 are found but than it says
current winner is: null and leaves the version unchanged.

Could this be a bug or am I doing something wrong?

- martin


signature.asc
Description: PGP signature

Re: Bug? maven-ear-plugin 2.9.1 behaves different to 2.9

[Martin Hoeller]

Hi Karl Heinz!

On 26 Nov 2014, Karl Heinz Marbaise wrote:

 Hi Martin,
 
 first can you create a project which reproduces the problem...otherwise 
 it's really hard to drill down the issue...

I don't know if I can create such a project. I'll try and start with a
simple project as described in my original post. We'll see if this
suffices...

 Furthermore have you defined the dependencies in your ear module which 
 should be skinnyfied...

I just checked and I do have most of the dependencies listed in the EAR
but some are missing. I'll fix this and see if this changes anything.

 Does you ear module contain other dependencies which could have the jars 
 you don't like to have in your ear as a transitive dependency?

Sorry, I don't get you. I want JARs *to be* in the EAR and no to not be
in the EAR.

 Can you post your pom file ?

Well, the actual project has more than 150 modules without the
dependencies. I don't think posting the whole pom makes sense. I'll try
to create a sample project instead (could take me some time). If you just
want some m-ear-p configuration or the like, just let me know. I could of
course post this.

[...]
  I'd be happy to provide a sample project but I'm not sure how to
  provide this as it also seems to depend on the infrastructure.
 
 Hm...you say on one side it's a bug of maven-ear-plugin but here you say 
 different... ?...

As changing the version of the m-ear-p is enough to fix the problem I
really do think it's a bug in the ear plugin.

But the bug only triggers in situations that depend on the infrastructure.

Does this make more sens to you?

- martin


signature.asc
Description: PGP signature

Bug? maven-ear-plugin 2.9.1 behaves different to 2.9

[Martin Hoeller]

Hi!

I'm using the maven-ear-plugin to create an EAR with a skinny WAR. This
worked fine till I did an update from version 2.9 to version 2.9.1.

The actual problem is quite hard to explain, so I'll try and start with
an abstract and provide details below.

The problem is, the skinny WAR contains a lot more JARs than it should,
but not all that are in the original WAR artifact. So it seems the
m-ear-p does build a skinny WAR but the decisions what JARs to pack
into the WAR are wrong. Changing the used m-ear-p back to version 2.9
fixes the problem, so this is definitely a regression in v2.9.1.

The really strange thing is, this does not happen always! It only
happens when I build my project the first time a day and a
recent version of dependency of the project was not locally installed
but was obtained from our local nexus. So it seems version information
(or timestamps as all versions are SNAPSHOTs) of the dependencies
matters.

A concrete example to make this more clear:

* My Project E is the EAR.
* E depends on an artifact W, a WAR.
* E and W have a common dependency D which is also a project of mine.
* E, W and D are all built by a CI-server (jenkins) and SNAPSHOTs
  are deployed to nexus during the night.

In the WAR there is D.jar packaged in WEB-INF/lib.
In the EAR there is D.jar packaged in lib/ and the skinny WAR should no
longer contain D.jar.

With  m-ear-p 2.9 this worked as expected. With version 2.9.1 when I
build E with mvn clean install and D was not locally installed
earlier this day, the skinny WAR is not skinny. It contains D.jar!
Thus, D.jar is located twice in the EAR which is a bug.

As soon as I do a mvn clean install for D, the building of E
starts to work and the WAR is skinny again... till a nightly deploy
provides a newer SNAPSHOT of D.

Any ideas what could be wrong here?

I'd be happy to provide a sample project but I'm not sure how to
provide this as it also seems to depend on the infrastructure.

TIA,
- martin

PS: I reported a (maybe) related issue half a year ago without any
feedback. Not sure if this could provide some extra info:

http://maven.40175.n5.nabble.com/bug-in-maven-ear-plugin-with-skinny-war-td5792646.html


signature.asc
Description: PGP signature

Re: Testing Maven 3.2.3

[Martin Hoeller]

On 13 Aug 2014, Hilton Wichwski Silva wrote:

 Example:
 http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/

Just to let you know: there is already a plugin available to verify
signatures as described in this StackOverflow answer:
http://stackoverflow.com/questions/6565084/maven-verify-signatures-of-downloaded-pom-jar-files/25302527#25302527

hth,
- martin


signature.asc
Description: PGP signature

Re: Version in Mojo

[Martin Hoeller]

Am Wed, 14 May 2014 07:41:27 -0700 (PDT) schrieb DenisDasKind blto...@abv.bg:

 Hi,
 
 i'm new to maven, and now i have the following problem. I have a
 custom Mojo, and the Mojo should print the own version stored in the
 pom.xml of this mojo. And now i have trouble to get this version. I
 have tried the project.version, but this is always the version of the
 pom, that calls my Mojo. A easy way, will be when the version is
 hardcoded, but this is not the best way, becausae each time when the
 version is changed (release) i must change it manually.
 Is there a better way to get this version?

There are also some useful hints on StackOverflow:
http://stackoverflow.com/questions/2712970/how-to-get-maven-artifact-version-at-runtime/12571330

hth,
- martin


signature.asc
Description: PGP signature

bug in maven-ear-plugin with skinny war?

[Martin Hoeller]

Hi!

I see strange behavior when using the maven EAR plugin with the
skinnyWar [1] feature, which might be a bug.

Here is the (simplified) module-structure I have:

core
  +-- core-shared

web
  +-- backend
  +-- war

ee
  +-- ear

Usually all modules share the same version (let's say 1.0) number. My
ear module includes a skinny version of the war module, core-shared
and some other 3rd-party dependencies. This works fine.

However, when I update all modules to version 2.0-SNAPSHOT but keep the
dependency on the war in the ear to version 1.0, the skinny war is
no longer skinny. Instead the war 1.0 in the ear contains
core-shared 1.0 dependency but the ear contains core-shared
2.0-SNAPSHOT. Thus, the dependency is included twice with different
versions.

IMHO the EAR plugin doesn't respect artifact's version information
when removing JARs from the skinny war, but only removes JARs that
match exactly (including version string). I'd consider this a bug. Or
at least a missing feature in the EAR plugin.

What do others think? Should I create a JIRA entry?

thx,
- martin

[1] http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html


signature.asc
Description: PGP signature

OutOfMemoryError with maven-javadoc-plugin

[Martin Hoeller]

Hi!

I have a quite large multimodule project with 150 modules. When
executing mvn site the maven-javadoc-plugin is executed with default
configuration. After some time of execution it fails in aggregate goal
and I get a

  Exception in thread main java.lang.OutOfMemoryError: GC overhead limit 
exceeded

I know, I can adjust MAVEN_OPTS to give it more memory and I tried it with
MAVEN_OPTS=-Xmx1536m -Xms512m -XX:MaxPermSize=512m and with
MAVEN_OPTS=-Xmx1280m -Xms256m -XX:MaxPermSize=768m. Both just leading
to another OutOfMemoryError (but no GC overhead limit exceeded).

I'm currently using maven 3.1.1 and tested with m-javadoc-p 2.8 and 2.9.1
(no difference).

So my question is: does any body have some idea how to tweak parameters
to solve this issue?

My current workaround is to disable aggregation in reporting section as
described here [0]. But this is really just a workaround, no solution :(

thx for your help,
- martin

[0] 
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/selective-javadocs-report.html


signature.asc
Description: PGP signature

Re: OutOfMemoryError with maven-javadoc-plugin

[Martin Hoeller]

Hi Baptiste!

I tried it but it didn't change anything. Still OutOfMemoryError :(

-martin

On 28 Mär 2014, Baptiste Mathus wrote:

 Sorry, I haven't used javadoc for years now, but as javadoc is an external
 tool, I guess you should specify additionalJOption?
 http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalJOption
 
 Cheers
 
 
 2014-03-28 10:36 GMT+01:00 Martin Hoeller mar...@xss.co.at:
 
  Hi!
 
  I have a quite large multimodule project with 150 modules. When
  executing mvn site the maven-javadoc-plugin is executed with default
  configuration. After some time of execution it fails in aggregate goal
  and I get a
 
Exception in thread main java.lang.OutOfMemoryError: GC overhead limit
  exceeded
 
  I know, I can adjust MAVEN_OPTS to give it more memory and I tried it with
  MAVEN_OPTS=-Xmx1536m -Xms512m -XX:MaxPermSize=512m and with
  MAVEN_OPTS=-Xmx1280m -Xms256m -XX:MaxPermSize=768m. Both just leading
  to another OutOfMemoryError (but no GC overhead limit exceeded).
 
  I'm currently using maven 3.1.1 and tested with m-javadoc-p 2.8 and 2.9.1
  (no difference).
 
  So my question is: does any body have some idea how to tweak parameters
  to solve this issue?
 
  My current workaround is to disable aggregation in reporting section as
  described here [0]. But this is really just a workaround, no solution :(
 
  thx for your help,
  - martin
 
  [0]
  https://maven.apache.org/plugins/maven-javadoc-plugin/examples/selective-javadocs-report.html
 
 
 
 
 -- 
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor !


-- 
Martin Höller   | martin.hoel...@xss.co.at
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-40
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: OutOfMemoryError with maven-javadoc-plugin

[Martin Hoeller]

Yes I did. If I tried without -J I got some error.

On 28 Mär 2014, Baptiste Mathus wrote:

 Did you make sure you put -J-Xmx and not only -Xmx ?
 
 
 2014-03-28 12:24 GMT+01:00 Martin Hoeller mar...@xss.co.at:
 
  Hi Baptiste!
 
  I tried it but it didn't change anything. Still OutOfMemoryError :(
 
  -martin
 
  On 28 Mär 2014, Baptiste Mathus wrote:
 
   Sorry, I haven't used javadoc for years now, but as javadoc is an
  external
   tool, I guess you should specify additionalJOption?
  
  http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalJOption
  
   Cheers
  
  
   2014-03-28 10:36 GMT+01:00 Martin Hoeller mar...@xss.co.at:
  
Hi!
   
I have a quite large multimodule project with 150 modules. When
executing mvn site the maven-javadoc-plugin is executed with default
configuration. After some time of execution it fails in aggregate
  goal
and I get a
   
  Exception in thread main java.lang.OutOfMemoryError: GC overhead
  limit
exceeded
   
I know, I can adjust MAVEN_OPTS to give it more memory and I tried it
  with
MAVEN_OPTS=-Xmx1536m -Xms512m -XX:MaxPermSize=512m and with
MAVEN_OPTS=-Xmx1280m -Xms256m -XX:MaxPermSize=768m. Both just leading
to another OutOfMemoryError (but no GC overhead limit exceeded).
   
I'm currently using maven 3.1.1 and tested with m-javadoc-p 2.8 and
  2.9.1
(no difference).
   
So my question is: does any body have some idea how to tweak parameters
to solve this issue?
   
My current workaround is to disable aggregation in reporting section
  as
described here [0]. But this is really just a workaround, no solution
  :(
   
thx for your help,
- martin
   
[0]
   
  https://maven.apache.org/plugins/maven-javadoc-plugin/examples/selective-javadocs-report.html
   
  
  
  
   --
   Baptiste Batmat MATHUS - http://batmat.net
   Sauvez un arbre,
   Mangez un castor !
 
 
  --
  Martin Höller   | martin.hoel...@xss.co.at
  *x Software + Systeme   | http://www.xss.co.at/
  Karmarschgasse 51/2/20  | Tel: +43-1-6060114-40
  A-1100 Vienna, Austria  | Fax: +43-1-6060114-71
 
 
 
 
 -- 
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor !


-- 
Martin Höller   | martin.hoel...@xss.co.at
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-40
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: OutOfMemoryError with maven-javadoc-plugin

[Martin Hoeller]

Hi Ron!

On 28 Mär 2014, Ron Wheeler wrote:

 Have you tried increasing the JVM memory past
 
 MAVEN_OPTS=-Xmx1536m -Xms512m -XX:MaxPermSize=512m
 MAVEN_OPTS=-Xmx1280m -Xms256m -XX:MaxPermSize=768m
 
 You could try something extreme (-Xmx8g ) and see if that changes anything.

Well, I should have added, that it was working fine with -Xmx1024m
-Xms256m -XX:MaxPermSize=512m recently. Since then I did a minor
restructure of the project and updated maven from 2.2.1 to 3.1.1. So I
thought the required memory wouldn't be much more.

 -Xms512m is not very useful in this case and you can omit it or make it the 
 same as -XMXnnn.
 Make sure that you allow enough(???) space after you allocate MaxPermSize.
 
 MAVEN_OPTS=-Xmx8g -XX:MaxPermSize=768m
 
 
 Did you notice that it took longer to run out  of memory with the higher 
 settings?
 If not, then I may be barking up the wrong tree and you might have to 
 change JAVA_OPTS to affect the memory allocation.
 If it did, then you are heading in the right direction but have not gone 
 far enough yet.

I tried with 8GB and now it was running for more that 4 hours. Than I
canceld it because the machine was only swapping and progress was very
low. (There were only 8GB physical RAM available on the system.)

With 4GB I got the usual OOM error. Can't say if it ran longer. If it
did, it wasn't that much longer. About 15min or so.

The point is: with maven 2.2.1, m-javadoc-p 2.8 and only minor changes in
the project layout it was running fine with 1GB. Now it needs at least
more than 4GB. There must be something wrong.

Any more ideas?

- martin


signature.asc
Description: PGP signature

Re: OutOfMemoryError with maven-javadoc-plugin

[Martin Hoeller]

On 28 Mär 2014, Justin Georgeson wrote:

 The maven-javadoc-plugin has a maxmemory configuration parameter. In my 
 parent POM I set a default property docs.maxMemory and then configure 
 maven-javadoc-plugin with
 
 maxmemory${docs.maxMemory}/maxmemory
 
 So each team can override that default setting in their pom.xml if they have 
 an unusually large codebase, or set it really high on the command line for an 
 aggregate javadoc of the entire multi-project workspace.

I already experimented with the maxmemory option without success. I'll
try some more in combination with the other memory options.

thx,
- martin


signature.asc
Description: PGP signature

Re: Maven copies 3 jars in lib folder (skinny war) for no reason

[Martin Hoeller]

Hi!

This topic was just discussed yesterday:
http://maven.40175.n5.nabble.com/Are-skinny-WARs-still-recommended-td5786626.html

On 28 Feb 2014, poroto20 wrote:

 I have one EAR project and I am trying to have a skinny war. It seems to be
 working ok but for some reason it keeps copying 3 dependencies into war/lib
 folder, which are commons-logging-1.0.4.jar, commons-codec-1.4.jar and
 jboss-seam-2.2.1.Final.jar.

The only dependencies to these artifacts seem to come from the WAR. So
the m-ear-p needs not to extract them to the EAR.

 I the EAR's pom I added `skinnyWarstrue/skinnyWars`.

That's correct!

 I made sure I added
 exclusions for those three jars, or they are `scope=provided`. I also added
 `packagingExcludes**/*.jar/packagingExcludes` in the WAR's pom file.

You don't need to do anything in the WAR. The m-ear-p repackages the WAR,
so it's entirely the responsibility of the m-ear-p.

 I really can't understand maven's logic to create the war (or to copy those
 jars).

The m-ear-p tries to extract all JARs that are also referenced from
outside the WAR to the EARs lib folder, so they can be reused by other
modules in the EAR.

Artifacts that are only used by the WAR should remain in the WAR.

Artifacts that are JSF libraries (like RichFaces, OmniFaces, etc.) should
also stay in the WAR because otherwise JSF won't scan them for
initialization. See the link above for more details.

 1) When I run maven only for the WAR project, the WAR has no jars in /lib
 folder

Yes, but that's something completely different! The WAR will get
re-packages by the m-ear-p if you configure skinnyWars for the m-ear-p.

 2) But when I run maven for all the projects (including the EAR) it copies
 those 3 jars in the war file.
 
 What am I doing wrong? Why is different the WAR created with maven inside
 the WAR project then for all projects (including EAR)? Please help

hth,
- martin


signature.asc
Description: PGP signature

Are skinny WARs still recommended?

[Martin Hoeller]

Hi all!

Most webapplication developers will probably know the concept of skinny
WARs which is described here [0].

When I have a skinny WAR in an EAR everthing from WAR!WEB-INF/lib is
excluded and goes into the lib-folder of the EAR. Thus, it is in the WARs
classpath.

However, when I use JSF component libraries like RichFaces or OmniFaces
they contain classes that are annotated with various JSF annotations
(@FacesComponet, @FacesConverter, etc.). Unfortunately JSF only scans the
WAR and not JARs in the classpath of the WAR that are located in the EAR.
This is correct behaviour according to the JSF 2.0 specification
(JSR-314), section 11.5.1 [1].

So my question is: how can this problem be solved for skinny WARs? Or are
skinny WARs considered obsolete these days?

Many thanks in advance,
- martin

[0] http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem
[1] http://jcp.org/en/jsr/detail?id=314


signature.asc
Description: PGP signature

Re: Are skinny WARs still recommended?

[Martin Hoeller]

Hi Simon!

Thanks for your help...

On 27 Feb 2014, Simon Lessard wrote:

 Hi Martin,
 
 Your definition of the skinny WAR is very slightly off and that may or not
 solve your issue. A skinny WAR is not necessarily a WAR from which *all*
 WEB-INF/lib was stripped, but rather one where all of its dependencies that
 are shared by another module in the EAR gets stripped.

You are right: skinny WARs might still contain some JARs in WEB-INF/lib.

 For example, let say
 you have:
 
 WAR1 depends on artifact1 and artifact2
 WAR2 depends on artifact2 and artifact3
 EJB-JAR depends on artifact1
 
 Then the EAR's lib should contain artifact1 and artifact2, WAR1 should not
 contain any lib, WAR2 should still contain artifact3. Now, in your case, if
 your EAR contains 2 JSF application WARs, then your issue still stands and
 I cannot really see how you'll be able to get truly skinny WAR as indeed
 you must not remove the JSF related artifacts from the WARs. However, if
 your EAR is a single WAR and some EJB/MDB then the skinny WAR should work
 just fine (it's what we use here and it work fine, the web related
 libraries stay in the WAR and don'T get promoted to the EAR).

I have another concrete example with a single WAR where OmniFaces is a
dependency by the WAR and by some EJB JAR, both contained in the EAR. The
OmniFaces JAR goes in the EARs lib folder and thus OmniFaces ist not
fully usable without workarounds. See also my question on StackOverflow:
http://stackoverflow.com/questions/22046464/how-to-correctly-use-omnifaces-in-an-ear

So even with your definition of a skinny WAR the problem still exists.

Some more ideas?

- martin

PS: I know this is not really a maven problem but maven-war-plugin and
maven-ear-plugin both have support for skinny WARs so I was hoping to
find some help here.


signature.asc
Description: PGP signature

Re: Are skinny WARs still recommended?

[Martin Hoeller]

On 27 Feb 2014, Antonio Petrelli wrote:

 2014-02-27 17:05 GMT+01:00 Martin Hoeller mar...@xss.co.at:
 
  I have another concrete example with a single WAR where OmniFaces is a
  dependency by the WAR and by some EJB JAR, both contained in the EAR. The
  OmniFaces JAR goes in the EARs lib folder and thus OmniFaces ist not
  fully usable without workarounds. See also my question on StackOverflow:
 
  http://stackoverflow.com/questions/22046464/how-to-correctly-use-omnifaces-in-an-ear
 
 
 Hi,
 the real question is: why do you want to use a JSF-specific library inside
 an EJB?

OmniFaces is a JSF library but not UI component focused like RichFaces.
It hast some really nice classes like BeanManager that could be useful
outside a JSF application.

 I strongly suggest to avoid it.

Hm... have to rethink it. Maybe this is really the wrong approach.

thanks,
- martin


signature.asc
Description: PGP signature

Re: Are skinny WARs still recommended?

[Martin Hoeller]

On 27 Feb 2014, Antonio Petrelli wrote:

 2014-02-27 17:14 GMT+01:00 Martin Hoeller mar...@xss.co.at:
 
  On 27 Feb 2014, Antonio Petrelli wrote:
 
   2014-02-27 17:05 GMT+01:00 Martin Hoeller mar...@xss.co.at:
  
I have another concrete example with a single WAR where OmniFaces is a
dependency by the WAR and by some EJB JAR, both contained in the EAR.
  The
OmniFaces JAR goes in the EARs lib folder and thus OmniFaces ist not
fully usable without workarounds. See also my question on
  StackOverflow:
   
   
  http://stackoverflow.com/questions/22046464/how-to-correctly-use-omnifaces-in-an-ear
   
   
   Hi,
   the real question is: why do you want to use a JSF-specific library
  inside
   an EJB?
 
  OmniFaces is a JSF library but not UI component focused like RichFaces.
  It hast some really nice classes like BeanManager that could be useful
  outside a JSF application.
 
 
 If it's really BeanManager or few classes that you need, I suggest to use
 the Shade plugin, to create an artifact with one (or few) classes, possibly
 moved to another package:
 http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

I was already thinking of this :)

However, I felt like there would be something wrong with this approach, as
I usually just need to declare a dependency when I want to use a library.
Not repackage it and include the classes twice in the EAR.

Thanks anyway,
- martin


signature.asc
Description: PGP signature

Re: Are skinny WARs still recommended?

[Martin Hoeller]

On 27 Feb 2014, Simon Lessard wrote:


 From a pure JSF point of view, you could also add a
 WEB-INF/faces-config.xml file in your project that redefine all OmniFaces
 artifact that are annotated. It's a super poor man solution/ugly hack as
 you might have to alter the file with every OmniFaces releases, but would
 allow you to have the OmniFaces JAR in the EAR while still have everything
 it provides available.

Yes, already tried this and it is working. But as you said, it's a
super-poor-man-solution with pains everytime you have to update.

 I agree with Antonio's suggestion to ask for a
 library split within OmniFaces as a more future-proof solution.

I'll try this. Let's see what they say.

thx,
- martin


signature.asc
Description: PGP signature

Re: Are skinny WARs still recommended?

[Martin Hoeller]

On 27 Feb 2014, Mark Struberg wrote:

 JSF by default loads the resources from the local WAR classpath only. But you 
 can easily write your own ResourceResolver which picks the stuff from the 
 ClassPath as well.
 
 An example can be found here:
 http://ocpsoft.org/opensource/create-common-facelets-jar/
 See CustomResourceResolver.

Very big on the linked site is stated In JSF2, this process is no longer
required.. An we are talking about JSF2 here.

Beside this, (as far as I understood it) the ResourceResolver is just
responsible for resolving resources like images, CSS and the like at
application runtime. We are talking about registering component,
converters, etc. at application startup time here and I don't think the
ResourceResolver could be any help in this case.

thx anyway,
- martin


signature.asc
Description: PGP signature

Re: Best practices for Java EE 7 dependencies

[Martin Hoeller]

Hi!

Thanks for your answers so far.

Am Fri, 7 Feb 2014 11:17:22 -0600 schrieb Wayne Fay wayne...@gmail.com:

  Should I better specify the exact dependencies and investigate some
  more work in POM maintainance? What would this gain me?
 
 You answered your own question, congrats! :)

Well, if I got you right, you mean it won't gain me anything. Right?

But I just found out a first problem that arises with the use
javaee-api: mvn dependency:analyze reports used undeclared
dependencies :(

It's totally clear why it reports these: annotation classes like
@Stateless are in the javax.ejb-api JAR and javaee-api declares a
dependency to it but my actual module does not.

So using javaee-api instead of the finer grained POMs DOES CAUSE
problems. Or am I doing something wrong here?

many thanks,
- martin


signature.asc
Description: PGP signature

Best practices for Java EE 7 dependencies

[Martin Hoeller]

Hi!

I'm wondering what the best practices are for specifying Java EE 7
dependencies in my modules.

There is the so called BOM (bill of materials) POM: javax:javaee-api:7.0
which lists all API submodules required for JEE7. Specifying this in my
module as

  dependency
groupIdjavax/groupId
artifactIdjavaee-api/artifactId
version7.0/version
  /dependency

works and is the least work for me. However, this way I got all JEE APIs
on the CLASSPATH even if I just need a few of them. Further on, the
actual dependencies are now transitive which is (IMHO) not fully correct.
Should I better specify the exact dependencies and investigate some more
work in POM maintainance? What would this gain me?

What do you think?

- martin


signature.asc
Description: PGP signature

Default value for properties depending on active profile

[Martin Hoeller]

Hi!

Here is the short version of what I want: I've got a JEE6 webapp with a
web.xml file, where the context-parameter facelets.DEVELOPMENT should be
enabled in development mode but disabled for releases.

My idea to solve this problem is as follows:

1) Define the context parameter in web.xml like this

   context-param
  param-namefacelets.DEVELOPMENT/param-name
  param-value${devel.mode}/param-value
   /context-param

2) Configure the maven-resources-plugin to filter web.xml and replace
   ${devel.mode} with the actual value.

3) Make devel.mode a maven-property with it's value being 'true' for
   normal builds and 'false' for a release build.

My questions is, is this a recommended way or should I solve this task
differently?

If this is ok, how could I initialize devel.mode correctly? I was
thinking about a default initialization in the pom.xml and an alternative
initialization via the release-profile. My qualms about this approach
are, that profiles are considered evil for most use-cases.

Many thanks in advance,
- martin


signature.asc
Description: PGP signature

Re: Default value for properties depending on active profile

[Martin Hoeller]

On 18 Okt 2013, Adrien Rivard wrote:
 You should just override the context-param when deploying on the real
 production server.

What do you mean by override?

You don't want me to extract the released WAR artifact (which is actually
included in an EAR), modify the web.xml and repackage it. Do you?

- martin


signature.asc
Description: PGP signature

Re: Default value for properties depending on active profile

[Martin Hoeller]

On 18 Okt 2013, Adrien Rivard wrote:

 Most server allow you to externally override context-param without
 modifying the war

I can't find anything for JBoss 7, which is the application-server i use.
If this is not possible, your suggestion doesn't work for me :(

 (which would be even worst than using profiles IMO)

Fully ACK.

- martin


signature.asc
Description: PGP signature

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Martin Hoeller]

On 22 Mär 2013, Stephen Connolly wrote:
 On 22 March 2013 08:12, Martin Höller mar...@xss.co.at wrote:
 
  Hi!
 
  On 21 Mär 2013, Stephen Connolly wrote:
 
   I think mailing lists are not the best way to explain why different
   solutions are to be preferred when ranking against what is best for the
   Maven ecosystem as a whole.
  
   So I wrote a blog post to explain my views on what are good ways and what
   are bad ways.
  
  
  http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
 
  Really good post, but... ;-)
 
  There is one thing that is IMHO not clearly (enough) stated in your post:
  it is in general a bad idea to add repositories to your POMs [1].
 
  Section 2. Get the external jars into a public Maven repository adds an
  additional repository to the pom.xml. This is usually bad pratice and
  should be avoided. Brian Fox wrote a detailed blog post [1] about this.
 
  Maybe you could link to this post and mentione, that putting the
  additional repo in your settings.xml is an alternative.
 
 
 Well if you put them into your settings.xml, then those extra repositories
 are applied for *every single project that you build*
 
 If you put them in your pom.xml, then those extra repositories are only
 applied for that project and *every single project that lists that project
 as a transitive dependency*

Good point.

 Also putting them in your settings.xml means you cannot just checkout and
 build, putting them in your pom.xml allows most others to just checkout and
 build (except for those of us behind a corporate proxy with a mandated
 mirrorOf*/mirrorOf)

On the other hand putting them in pom.xml might bring you artifacts into
your build from this repo without one noticing they are not coming from
central.

But I have to admit, in the scenario described by your post the pom.xml
might be the better choice. However, a word of warning and a link to
Brian's post would not hurt and would hopefully further educate maven
users.

best regards,
- martin


signature.asc
Description: PGP signature

Re: Can not get a jar from maven central

[Martin Hoeller]

Hi!

Could it be MVNCENTRAL-252?
See also this thread some weeks ago:
http://maven.40175.n5.nabble.com/Broken-link-for-avalon-td5726894.html

- martin


On 05 Nov 2012, Brian Fox wrote:

 N oone has been blacklisted in a while. Can you give us the headers like
 shown here:
 
 
 $ curl -I
 http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
 HTTP/1.1http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jarHTTP/1.1
  200 OK
 Accept-Ranges: bytes
 Content-Type: application/java-archive
 Date: Thu, 25 Oct 2012 10:07:48 GMT
 Last-Modified: Thu, 15 Feb 2007 20:44:01 GMT
 Server: ECAcc (dfw/F489)
 X-Cache: HIT
 Content-Length: 33218
 
 
 
 Then we can go to the CDN and see what's up.
 
 
 On Mon, Nov 5, 2012 at 9:05 AM, eugene eugen.ra...@gmail.com wrote:
 
  Hello Ron,
 
  As a matter of fact we do have our own repo, nexus based.
 
  We have A LOT of projects that we have to mavenize, thus, yes I think
  that
  maven thinks we are doing something wrong. But then again, all that we do
  is
  get some jars from it, nothing else, nothing more, isn't maven suppose to
  do
  that in the first place? I'm confused.
 
  Ok, so how do we get out of the blacklist? Whom do we contact, etc?
 
  Thank You,
  Eugene.


signature.asc
Description: PGP signature

Re: Maven Central broken? (was: Broken link for avalon)

[Martin Hoeller]

On 17 Okt 2012, Anders Hammar wrote:

 https://issues.sonatype.org/browse/MVNCENTRAL

Thanks. Reported it as https://issues.sonatype.org/browse/MVNCENTRAL-252

 It works for me though (Sweden/Europe) so I guess it depends on which
 central mirror you're directed to.

Maybe. I'm located in Austria/Europe.

- martin


signature.asc
Description: PGP signature

Re: Maven Central broken? (was: Broken link for avalon)

[Martin Hoeller]

On 17 Okt 2012, Lyons, Roy wrote:

 Yet another reason to use a caching repository manager...  You never know
 when a repository out of your control can be on the fritz...

We are using nexus, but the artifacts in question are just not yet in the
cache.

- martin


signature.asc
Description: PGP signature

Re: putting context.xml into META-INF

[Martin Hoeller]

Hi!

First, if you start a new topic, please do this by writing a new mail and
not by replying to some other mail. This can be really annoying if you
use a proper MUA that sorts by thread!

On 25 Feb 2008, [EMAIL PROTECTED] wrote:

 i am using mvn package to create a war file of my project.
 However, I found out that my context.xml file, located under
 src/context/context.xml, is missing in the META-INF directory
 of the war file! Therefore, running my application fails! :-(

Try putting it in src/main/webapp/META-INF.

 I know there is a tomcat plugin that builds the war AND deploys
 the war to a tomcat server, but I would like to do this step by
 step - as a first step, I want to manually move the war file into
 my tomcat webapps directory, if that works, I want to try to
 automatically do this with the tomcat plugin.

I don't know the tomcat plugin, I use cargo to deploy to servlet
containers. But if you don't want to use the tomcat plugin, just do not
configure it in your pom. Nothing will get deployed by default.

 However, I found out that the tomcat plugin can be configured like that:
 groupIdorg.codehaus.mojo/groupId  
 artifactIdtomcat-maven-plugin/artifactId
 configuration
 modeboth/mode 
 contextFilesrc/context/context.xml/contextFile
 
 However, I didn't find anything similar for the maven war plugin.

Documentation for the m-war-p is here:
http://maven.apache.org/plugins/maven-war-plugin/

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: Separating the base from the installation not working

[Martin Hoeller]

On 19 Feb 2008, Martin Hoeller wrote:

 I'll go and file an issue with the updated documentation.

Added information from this thread to issue MRM-701 [0].

hth,
- martin

[0] http://jira.codehaus.org/browse/MRM-701
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Separating the base from the installation not working

[Martin Hoeller]

Hi!

I'm trying to install archiva 1.0.1 on Linux as a standalone application
as running in JBoss gives various errors.

The archiva admin guide for standalone installation [0] says

| However, the best way to use this installation technique is to separate
| the configuration from the installation to make it easy to upgrade to
| newer versions in the future.

I tried to follow these steps exactly as explained. However, it seems this
does not work at all.

First, there is no 'data'-directory as mentioned in step 2 (I ignored
this for now).

Second, as archiva should now hold it's data in the PLEXUS_BASE
directory, I thought it shouldn't need to write to the installation
directory (PLEXUS_HOME) which seems not to be true. If write access to
the PLEXUS_HOME directory is denied archiva startup fails. So I granted
write permissions to this directory.

Third, the user- and artifact- database seem to be created in the
installation base (PLEXUS_HOME) and not PLEXUS_BASE, as PLEXUS_HOME now
contains new directories data/archiva and data/users with lots of files
in it.

Has anybody successfully tried to perform a separation of installation
and data in archiva 1.0.1?

Any comments are welcome.

tia,
- martin

[0] http://maven.apache.org/archiva/docs/1.0.1/adminguide/standalone.html
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: Separating the base from the installation not working

[Martin Hoeller]

On 19 Feb 2008, Brett Porter wrote:

 The doc could well be a bit wrong in step 2 - please file a bug for that :)

Ok, done that: http://jira.codehaus.org/browse/MRM-701

 I do use it successfully with the following script to start it though:
 
 #!/bin/sh
 version=1.0.1
 PLEXUS_BASE=$HOME/Library/Application\ Support/Archiva
 /Applications/Archiva/apache-archiva-$version/bin/macosx-universal-32/run.sh
 $@

That's what I'd expect to work, but unfortunately it doesn't :-(
(I suppose the $@ should be on one line with the run.sh line)

 Maybe you were missing an export of PLEXUS_BASE before starting? (the
 above doesn't need it since it's all on one line, the env vars are
 passed to the second run script).

No, I did export PLEXUS_BASE and also tried it in a script like yours. No
success.

Here are exactly the steps i performed:

1) tar xzvf ~/downloads/apache-archiva-1.0.1-bin.tar.gz
2) mkdir -p archiva-data/logs
   (NOTE: when I do not create the 'logs' directory archiva throws an
   exception)
3) mv apache-archiva-1.0.1/conf archiva-data/
4) chmod ugo-w -R apache-archiva-1.0.1/
5) ./apache-archiva-1.0.1/bin/linux-x86-32/run.sh console

The result is:
  Running Archiva...
  wrapper  | ERROR: Could not write pid file ./archiva.pid: Permission denied

It tries to write the PID-File to bin/linux-x86-32/, not './'. If I allow
for writing there by doing

6) chmod a+w apache-archiva-1.0.1/bin/linux-x86-32/
7) ./apache-archiva-1.0.1/bin/linux-x86-32/run.sh console

The result is another exception:
Running Archiva...
wrapper  | -- Wrapper Started as Console
wrapper  | Launching a JVM...
jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
jvm 1|   Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.
jvm 1|
jvm 1| java.io.FileNotFoundException: 
[...]/apache-archiva-1.0.1/conf/classworlds.conf (No such file or directory)
jvm 1|  at java.io.FileInputStream.open(Native Method)
jvm 1|  at java.io.FileInputStream.init(FileInputStream.java:106)
jvm 1|  at java.io.FileInputStream.init(FileInputStream.java:66)
jvm 1|  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:385)
jvm 1|  at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
jvm 1|  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jvm 1|  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
jvm 1|  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
jvm 1|  at java.lang.reflect.Method.invoke(Method.java:585)
jvm 1|  at 
org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:240)
jvm 1|  at java.lang.Thread.run(Thread.java:595)
wrapper  | -- Wrapper Stopped

BTW, I'm running on Debian GNU/Linux, with java version 1.5.0_12.

Anyone knows whats the problem here?

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: Separating the base from the installation not working

[Martin Hoeller]

Hi Brett!

Thanks for you help so far.

On 19 Feb 2008, Brett Porter wrote:

 Ah, I see. You shouldn't move the original configuration (specifically
 the classworlds configuration). I just copy the 3 XML files to the new
 conf directory.

Ok, so this is an issue in the mentioned documentation which says Move
the conf  and data  directories. I'll file a JIRA issue for this as soon
as I see it confirmed.

 Also, you are write - the PID file is written to the installation
 (which is probably a bug - we should make sure that is addressed in
 MRM-688.

Well, even with the PID file writeable and the configuration copied
instead of moved, it's still throwing exceptions. The stacktrace I get is
as follows:

$ ./apache-archiva-1.0.1/bin/linux-x86-32/run.sh console
Running Archiva...
wrapper  | -- Wrapper Started as Console
wrapper  | Launching a JVM...
jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
jvm 1|   Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.
jvm 1|
jvm 1| [INFO] Loading on start [role,roleHint]: 
[org.codehaus.plexus.naming.Naming,dataSources]
jvm 1| [INFO] Loading on start [role,roleHint]: 
[org.codehaus.plexus.contextualizer.Contextualizer,jettyConfiguration]
jvm 1| [INFO] Services will be deployed in: 
'/home/martin/work/archiva/apache-archiva-1.0.1/services'.
jvm 1| [INFO] Applications will be deployed in: 
'/home/martin/work/archiva/apache-archiva-1.0.1/apps'.
jvm 1| [INFO] Service Supervisor is deploying 
plexus-appserver-service-jetty-2.0-alpha-8.
jvm 1| [ERROR] Error while deploying service 
plexus-appserver-service-jetty-2.0-alpha-8.sar.
jvm 1| org.codehaus.plexus.appserver.ApplicationServerException: Error 
executing service deployment id.
jvm 1|  at 
org.codehaus.plexus.appserver.service.deploy.DefaultServiceDeployer.deploy(DefaultServiceDeployer.java:91)
jvm 1|  at 
org.codehaus.plexus.appserver.service.deploy.DefaultServiceDeployer.deploy(DefaultServiceDeployer.java:65)
jvm 1|  at 
org.codehaus.plexus.appserver.lifecycle.phase.ServiceDeploymentPhase$1.onJarDiscovered(ServiceDeploymentPhase.java:45)
jvm 1|  at 
org.codehaus.plexus.appserver.supervisor.DefaultSupervisor.scanDirectory(DefaultSupervisor.java:100)
jvm 1|  at 
org.codehaus.plexus.appserver.supervisor.DefaultSupervisor.scan(DefaultSupervisor.java:73)
jvm 1|  at 
org.codehaus.plexus.appserver.lifecycle.phase.ServiceDeploymentPhase.execute(ServiceDeploymentPhase.java:59)
jvm 1|  at 
org.codehaus.plexus.appserver.DefaultApplicationServer.start(DefaultApplicationServer.java:218)
jvm 1|  at 
org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33)
jvm 1|  at 
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:128)
jvm 1|  at 
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:142)
jvm 1|  at 
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:132)
jvm 1|  at 
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:90)
jvm 1|  at 
org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
jvm 1|  at 
org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:69)
jvm 1|  at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:297)
jvm 1|  at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291)
jvm 1|  at 
org.codehaus.plexus.appserver.PlexusApplicationHost.start(PlexusApplicationHost.java:155)
jvm 1|  at 
org.codehaus.plexus.appserver.PlexusApplicationHost.start(PlexusApplicationHost.java:85)
jvm 1|  at 
org.codehaus.plexus.appserver.PlexusApplicationHost.main(PlexusApplicationHost.java:289)
jvm 1|  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jvm 1|  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
jvm 1|  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
jvm 1|  at java.lang.reflect.Method.invoke(Method.java:597)
jvm 1|  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
jvm 1|  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
jvm 1|  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
jvm 1|  at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
jvm 1|  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jvm 1|  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
jvm 1|  

Re: Separating the base from the installation not working

[Martin Hoeller]

On 19 Feb 2008, Brett Porter wrote:

 oops - you need to edit plexus.xml too.

Which one, a find -name plexus.xml gives me this:

./archiva-data/conf/plexus.xml
./apache-archiva-1.0.1/conf/plexus.xml
./apache-archiva-1.0.1/apps/archiva/conf/plexus.xml

I assume it's either the first or the second one.

 If you could file one bug that captures all the problems with this
 given document (preferably with a patch ;) it would be much
 appreciated.

Ok, I'll file one as soon as my archiva is running as it should :)

Many thanks to your Brett!

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: Separating the base from the installation not working

[Martin Hoeller]

On 19 Feb 2008, Brett Porter wrote:

 ${appserver.base} should work, but if not you can hardcode it

YES! Finally got it working! Many thanks again to you Brett!

I'll go and file an issue with the updated documentation.

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: deploying to archiva repository

[Martin Hoeller]

On 18 Feb 2008, Sunita Pahwa wrote:

 I am using archiva 1.0.1 standalone version. I am trying to deploy my
 artifact to archiva 'internal' repository using 'mvn: deploy'.
 1) I have done following changes to my artifact's POM:
 -added repository and snapshotRepository sections under
 distributionManagement element with appropriate id and url
 -added build
   extensions
 extension
   groupIdorg.apache.maven.wagon/groupId
   artifactIdwagon-webdav/artifactId
   version1.0-beta-2/version
 /extension
   /extensions
 /build
 
 
 2) In Maven's setting.xml, added one server configuration with archiva user
 name and password. User name is for administrator having 'repository
 manager' rights.

What is the id you are using for the server entry?

 On mvn:deploy, it gives following error:
 WARNING: No credentials available for the 'Repository Archiva Managed
 Internal Repository' authentication realm at localhost

The id under server in settings.xml must match the one from your
pom.xml file und distributionManagementrepository. It seems this does
not match in your case.

 I have followed all the steps specified at
 http://maven.apache.org/archiva/docs/1.0/userguide/deploy.html but it is not
 working.

Unfortunately this documentation is somewhat inconsistent regarding the
id's in the settings.xml and pom.xml file.

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: deploying to archiva repository

[Martin Hoeller]

Hi Wendy!

On 18 Feb 2008, Wendy Smoak wrote:

 On Feb 18, 2008 4:35 AM, Martin Hoeller [EMAIL PROTECTED] wrote:
  On 18 Feb 2008, Sunita Pahwa wrote:
   I have followed all the steps specified at
   http://maven.apache.org/archiva/docs/1.0/userguide/deploy.html but it is 
   not
   working.
 
  Unfortunately this documentation is somewhat inconsistent regarding the
  id's in the settings.xml and pom.xml file.
 
 Thanks, Martin.  I fixed that in the docs for the next version, which
 you can see at 
 http://maven.apache.org/archiva/docs/1.1-SNAPSHOT/userguide/deploy.html

I had a look and it is much clearer now. Thanks for fixing it.

 We've also just added a 'known issues and errata' page and linked to
 it from the downloads page.

Good idea!

 Please let us know if you see anything else that needs to be
 corrected.  (Preferably on the Archiva mailing lists or JIRA --
 http://maven.apache.org/archiva/mail-lists.html .)

Well, I already posted an issue on the archiva list [0], where following
the documentation brought me... nowhere. Unfortunately no response so
far. Maybe you can have a look.

thanks again,
- martin

[0] 
http://www.nabble.com/Separating-the-base-from-the-installation-not-working-to15542875s177.html
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: Separating the base from the installation not working

[Martin Hoeller]

On 19 Feb 2008, Martin Hoeller wrote:

 On 19 Feb 2008, Brett Porter wrote:
 
  oops - you need to edit plexus.xml too.
 
 Which one, a find -name plexus.xml gives me this:
 
 ./archiva-data/conf/plexus.xml
 ./apache-archiva-1.0.1/conf/plexus.xml
 ./apache-archiva-1.0.1/apps/archiva/conf/plexus.xml
 
 I assume it's either the first or the second one.

./archiva-data/conf/plexus.xml seems to be the right one. There is the
following that should probably be changed:

...
  property
nameurl/name

valuejdbc:derby:${plexus.home}/data/users/database;create=true/value
  /property
...
  property
nameurl/name

valuejdbc:derby:${plexus.home}/data/archiva/database;create=true/value
  /property

Changing ${plexus.home} to ${plexus.base} changed the location but not as
I wanted as plexus.base seems not to be defined. Can I use PLEXUS_BASE
somehow or do I have to hardcode the path?

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: [c1.1] mvn binary not found on path?

[Martin Hoeller]

On 29 Jan 2008, Mick Knutson wrote:

 I am logging in as the admin user and mvn is indeed on my $PATH and I can
 validate that running mvn from anywhere works fine.
 But the same user starts up continuum and I keep getting an error the mvn
 can't be found?
 
 Why is this happening?
 The build runs ok.

How can the build run if maven is not found?

Did you check the log files? What are they saying?

 But my emails are not getting sent out, and I can't add
 additional build definitions.

Emails are probably not sent out because continuum tries to execute maven
to get its version. If this is the case you get something like  this in
your logs: NotificationException: Error while generating mail contents.

 Every time I talk about the above 2 errors, this list tells me I need to fix
 this 1st. So I am trying to, but I have no idea what is broken. Everything
 looks as it should to me, unless continuum on Tomcat is changing my
 $PATH?

I'm pretty sure continuum doesn't tamper with your PATH. Are you running
on Windows or Linux? Try starting up continuum manually as the user you
want to and make sure maven is on your path right before starting
continuum. Do you still get the errors?

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

archiva.xml on JBoss

[Martin Hoeller]

Hi all!

As discussed in another thread [0], I deployed archiva successfully to
JBoss 4.2.2.GA. However, when configuring repositories archiva complains
that it cannot write configuration and a number of exceptions are thrown.

The reason seems to be that JBoss' home directory is (by intention) not
writable for archiva, and the directory ARCHIVA_BASE/conf, which is
actually JBOSS_HOME/conf which is actually /src/jboss/conf does not
exist. So archiva can't create the file archiva.xml which is required.

Is there an opportunity to change the location of archiva's configuration
file? Are there more files beside archiva.xml that will need write access?

thanks in advance,
- martin

[0] 
http://www.nabble.com/Trouble-deploying-Archiva-1.0-to-JBoss-4.2.2.GA-to15005490.html
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: A Hello World in ejb3

[Martin Hoeller]

On 27 Jan 2008, Angelo Chen wrote:

 I'm looking for a simple sample Maven project for ejb3,

Have a look at this:
http://maven.apache.org/plugins/maven-archetype-plugin/examples/j2ee-simple.html

It's not just EJB but a complete EAR, but it's a good starting point.

Also have a look at
www.michaelyuan.com/blog/2007/10/09/jboss-seam-project-setup-with-maven-—-part-2-ear-deployment/
(the page seems down at the moment)

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: A Hello World in ejb3

[Martin Hoeller]

On 28 Jan 2008, Angelo Chen wrote:

 Thanks but maven-archetype-j2ee-simple is not for ejb3, is there archetype
 for ejb3? thanks.

Unfortunately not that I know of and not in the list of archetypes [0].

However, you can use the j2ee archetype and just add this to your
maven-ejb-plugin definition in the build section:

  configuration
ejbVersion3.0/ejbVersion
  /configuration

Just as described in Maven - The Definitve Guide [1].

hth,
- martin

[0] http://docs.codehaus.org/display/MAVENUSER/Archetypes+List
[1] http://www.sonatype.com/book/j2ee.html
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Fw: deploying without deploying - how do I turn off deployment of pom(or anyother default maven goal in a phase)?

[Martin Hoeller]

I forgot to CC the list...

Begin forwarded message:

Date: Tue, 4 Dec 2007 14:16:10 +0100
From: Martin Hoeller [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: deploying without deploying - how do I turn off deployment of 
pom(or anyother default maven goal in a phase)?


Hi Michael!

[I CC'd maven-users again, maybe it's interesting for some others as well.]

 thanks for your mail - sorry to mail you directly, but I have already read 
 all the relevant documentation, and I can't see anyway of preventing a 
 plugin from executing.

Well, I didn't test it but had something like this in mind:

 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-deploy-plugin/artifactId
 executions
 /executions
   /plugin
 /plugins

Let us know if it works.

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: Default executions

[Martin Hoeller]

On 03 Dec 2007, lightbulb432 wrote:

 
 How can I find out the default plugin executions? For example, how would I
 know that maven-clean-plugin or maven-site-plugin isn't automatically in the
 build lifecycle (therefore requiring me to do a mvn clean or mvn site
 specifically or adding it as an execution in pom.xml)?

http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: [m2] Continuum error with ${scm.connection} type variables in scm declaration

[Martin Hoeller]

On 28 Nov 2007, Mick Knutson wrote:

 I have my scm as:
 
 scm
 connection${scm.connection}/connection
 developerConnection${scm.connection}/developerConnection
 url${scm.url}/url
 /scm

See this post for details:
http://www.nabble.com/-c-1.0-beta-4--Error-getting-continuum-to-pick-up-settings.xml-tf4893604s177.html#a14014979

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: deploying without deploying - how do I turn off deployment of pom (or anyother default maven goal in a phase)?

[Martin Hoeller]

On 03 Dec 2007, [EMAIL PROTECTED] wrote:

 How can I stop maven from deploying the pom.  Can't I disable the goal 
 somehow? 

This should be possible (not tested): just configure the
maven-deploy-plugin [0] not to execute in the deploy lifecycle.

See the POM Reference [1] and the Introduction to the Build Lifecycle [2]
for details.

hth,
- martin

[0] http://maven.apache.org/plugins/maven-deploy-plugin/
[1] http://maven.apache.org/pom.html
[2] 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

Re: maven ear building

[Martin Hoeller]

Hi!

On 28. October 2007 jdijkmeijer wrote:

 Hi i'm quite new to Maven, and I'm currently looking into some existing
 code/poms to genereate a ear project

Read the coresponding chapters in the really good books
Better Builds with Maven from DevZuZz [1] and Maven: The Definitive 
Guide from Sonatype [2].

 it uses icefaces together with seam 2.0. the icefaces jars and
 dependencies should go in the root of the ear as these are also used by
 the ejb-jar.

For Seam integration I recommend the blog [3] of Michael Yuan. His book on 
Seam is also quite good, although not maven specific!

hth,
- martin

[1] http://www.devzuz.com/web/guest/products/resources#BBWM
[2] http://www.sonatype.com/book/
[3] 
http://www.michaelyuan.com/blog/2007/10/02/jboss-seam-project-setup-with-maven/

-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: This is a digitally signed message part.

Re: Maven Release plugin

[Martin Hoeller]

On 29. October 2007 Mark Russell wrote:
 I am about to release my first maven plugin.  I was looking at the
 maven-release-plugin.  This seams to do what I want.  does it work with
 CVS?

Yes it does.

 If so where is the documentation for this? 

It uses maven's SCM infrastructure. See [1] for details.

 I did several web searches and the only thing I can find is SVN examples.

For CVS use a URL like this:
scm:cvs:pserver:user@server:repository-path:module

hth,
- martin

[1] http://maven.apache.org/scm/

-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: This is a digitally signed message part.

Re: Problem while doing installations in continuum

[Martin Hoeller]

On 16 Oct 2007, ichasco wrote:

 I am a starter with continuum and i have some silly questions. I have
 created a schedule that execute itself hourly. Now, I want to create an
 installations but... what is exactly an installation?

The concept of installations is new in continuum 1.1. Go read
http://maven.apache.org/continuum/guides/mini/guide-build-profile.html
for more information.

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: PGP signature

How to add menu entries to Project Information

[Martin Hoeller]

Hi all!

I've set up a simple site for a project following the documentation on 
maven.apache.org. I basically have a Welcome Page and the usual Project 
Documentation links with Project Information and Project Reports on 
the left side.

What I want to do is add another menu entry to the Project Information 
navigation menu. The new entry should be on the same level as Continuous 
Integration, Dependencies or Issue Tracking.

Does anybody know if this is possible and how to obtain this behaviour?

Many thanks in advance,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: This is a digitally signed message part.

Re: How to add menu entries to Project Information

[Martin Hoeller]

On 10. Oktober 2007 Manos Batsis wrote:
 
 I usually just add menu entries in site.xml.

Yes, this is what I found out quite easily. However, the link I want to add 
is a link for an enterprise content management system (www.nuxeo.org) and 
would fit to the other entries in Project Information.

 What you want however, is 
 to add another link in the menu generated by the info reports plugin
 [1], so you probably have to check it out more thoroughly to figure out
 a way to do this (for example extend it if this cant work as-is).

 [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/

Thanks for the link. However, it seems adding own entries is not supported 
at the moment. I'll probably just add the link in the site.xml as you 
suggested earlier.

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: This is a digitally signed message part.

Re: Example of setting up a maven 2 J2ee project

[Martin Hoeller]

Am Dienstag, 4. September 2007 schrieb Eric Wood:
 Folks:

 I'm new to maven and I'm looking for a good reference to how to set up a
 j2ee application using maven 2.0.  Are there and good documents or
 examples out there that I could use to get started?

See http://www.sonatype.com/book/j2ee.html

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


signature.asc
Description: This is a digitally signed message part.

Re: Writing portable CVS configuration using Maven 2

[Martin Hoeller]

Hi!

First, please stop hijacking somebody else's thread by replying to a mail 
and changing the subject! If you want to start a new topic, write a new 
email and DO NOT reply to another thread. Thanks!

Second, why do you repost somebody's questions answered months ago?  
Jerome Thibaud posted exactly the same question on 2007-04-25 with almost 
the same subject: Writing a portable CVS configuration using maven2. This 
question was perfectly answered by Emmanuel Venisse. (see 
http://mail-archives.apache.org/mod_mbox/maven-users/200704.mbox/[EMAIL 
PROTECTED])

regards,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


pgpageHqKt4go.pgp
Description: PGP signature

Re: Build schedule for only when subversion has changed

[Martin Hoeller]

Hi!
On Wednesday, 13. June 2007 15:27 Cameron Jones wrote:

 So, having a build triggered only by scm changes is currently not a
 feature. Cool, but would be good. Emmanuel - from what i understand
 from your post do you mean that continuum currently should not be
 building a scheduled build if there are no modifications in the
 repository? This isn't what i've been experiencing but is the
 behaviour i'm looking for. I'm using version 1.0.3, has anyone else
 seen this happen?

I'm using 1.0.3 and the behavior Emmanuel mentioned is exactly what's 
happening here:

If I have a build scheduled for every hour, the actual build only happens if 
some modifications were found compared to the last successful build (I'm 
using CVS as an SCM).

If nothing changed in CVS, no build is triggered.

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


pgpHZFk1G2IXd.pgp
Description: PGP signature

Re: an oveview of all the installed plugins and goals

[Martin Hoeller]

Hi!

On Wednesday, 16. May 2007 14:28 Gert-Jan Braas wrote:

 Now I'm using the axis2-aar maven plugin.
 As far as I can tell, it is installed.
 ==
 [EMAIL PROTECTED]:~/.m2/repository$ find . | grep aar
 ./org/apache/maven/plugins/maven-aar-plugin
 ./org/apache/maven/plugins/maven-aar-plugin/maven-metadata-central.xml
 ./org/apache/maven/plugins/maven-axis2-aar-plugin
 ./org/apache/maven/plugins/maven-axis2-aar-plugin/1.1.1
 ./org/apache/maven/plugins/maven-axis2-aar-plugin/1.1.1/axis2-aar-maven-plugin-1.1.1.jar
 ./org/apache/maven/plugins/maven-axis2-aar-plugin/maven-metadata-central.xml
[...]
 The plgin is installed by hand (copied to the plugin directory)
 and I have altered maven-metadata-central.xml with

  plugin
   nameMaven axis2-aar Plugin/name
   prefixaar/prefix
   artifactIdmaven-axis2-aar-plugin/artifactId
 /plugin

 What am I missing?

You specified the wrong name. The plugin is named axis2-aar-maven-plugin 
but you added it in your pom.xml as maven-axis2-aar-plugin. Fix your 
pom.xml.

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


pgpTtgxSkd4th.pgp
Description: PGP signature

Re: Default location of config files - Maven Standard Directroy Layo ut?

[Martin Hoeller]

Hi!

Sorry for the late reply.

On 26-03-2007 11:15 Doyle D.G. (Duncan) worte:

 Furthermore, where should one put configuration files which are needed
 for testing? There is no 'src/test/config' listed in the Maven Standard
 Directory Layout.

Put it in src/test/resources.

hth,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


pgpev2Sj4oGwd.pgp
Description: PGP signature

Re: [ANN] First release of Patchwork coverage maven plugin

[Martin Hoeller]

Hi!

Just wanted to try out the patchwork-maven-plugin but it fails with the
following exception (actually it doesn't fail, but maven says
Build Successful. However, I didn't get a report):

$ mvn patchwork:test
[...]
Error while defining at.co.xss.emcs.tg.dsp.EmcsDatasetProducer
java.lang.NoClassDefFoundError: de/laures/cewolf/DatasetProducer
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at 
oqube.bytes.loading.ByteArrayClassLoader.buildClass(ByteArrayClassLoader.java:76)
at 
oqube.bytes.loading.ByteArrayClassLoader.findClass(ByteArrayClassLoader.java:128)
at 
fr.lifl.utils.CompoundClassLoader.findClass(CompoundClassLoader.java:76)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at 
oqube.bytes.loading.ByteArrayClassLoader.buildClass(ByteArrayClassLoader.java:76)
at 
oqube.bytes.loading.ByteArrayClassLoader.findClass(ByteArrayClassLoader.java:128)
at 
fr.lifl.utils.CompoundClassLoader.findClass(CompoundClassLoader.java:76)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at 
oqube.bytes.loading.ByteArrayClassLoader.buildClass(ByteArrayClassLoader.java:76)
at 
oqube.bytes.loading.ByteArrayClassLoader.findClass(ByteArrayClassLoader.java:128)
at 
fr.lifl.utils.CompoundClassLoader.findClass(CompoundClassLoader.java:76)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
at java.lang.Class.getConstructor0(Class.java:2671)
at java.lang.Class.getConstructor(Class.java:1629)
at junit.framework.TestSuite.getTestConstructor(TestSuite.java:177)
at junit.framework.TestSuite.init(TestSuite.java:59)
at oqube.patchwork.test.JUnitRunner.runSuite(JUnitRunner.java:100)
at oqube.patchwork.TestRunner.test(TestRunner.java:350)
at oqube.patchwork.TestRunner.run(TestRunner.java:510)
at oqube.patchwork.maven.PatchworkMojo.execute(PatchworkMojo.java:184)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.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(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

The missing class de.laures.cewolf.DatasetProducer is an interface from
a third-party dependency which is defined with scope 'compile' 

handling of optional 3rd-party-dependencies in tests

[Martin Hoeller]

Hi all!

I've got a question regarding dependencies. Let me first explain my
project structure.

- I've got project A which is a web application (WAR).
- A depends on project B which is of type JAR.
- B depends on hibernate which has an optional dependency on ehcache.

My idea is if A wants to use hibernate's second level cache ehcache A has
to define a dependency on ehcache. To use ehcache also for tests in B, B
defines ehcache as a dependency of scope test.

Whenever I now run mvn test I get the following warings:

| Artifact net.sf.ehcache:ehcache:jar:1.2.3:test retains local scope 'test' 
overriding broader scope 'compile'
| given by a dependency. If this is not intended, modify or remove the local 
scope.

How can I get rid of this warning? Or am I doing something wrong?

tia,
- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


pgpWfD6erIDV3.pgp
Description: PGP signature

Re: [m2] handling of optional 3rd-party-dependencies in tests

[Martin Hoeller]

Hello Franz!

Thanks for your quick reply.

On 14. February 2007 13:08 franz see wrote:

 I'm guessing that happened while maven was building module B.

Yes, forgot to mention this.

 AFAIK, that's just a reminder that that jar is using the scope test
 only. I don't think it's anything to worry about ( not unless you did not
 specify that jar to be of scope test ).

Not exactly sure what you mean.
I did not specify B.jar in project A to be of scope test, it's of scope 
runtime (should it better be of scope compile?).

However, as this is nothing I need to worry about (that's what I expected), 
I would like this warning to go away. I don't want warnings if everything 
is fine. What am I missing?

- martin
-- 
Martin Höller   | [EMAIL PROTECTED]
*x Software + Systeme   | http://www.xss.co.at/
Karmarschgasse 51/2/20  | Tel: +43-1-6060114-30
A-1100 Vienna, Austria  | Fax: +43-1-6060114-71


pgpYOREQnJasl.pgp
Description: PGP signature