Re: maven-release-plugin

2011-01-27 Thread milewc

Thanks for your helpful answer!

The solution works fine:


REM Dependency-Snapshot-Versions are replaced by the corresponding release
version (e.g. 0.4.0-SNAPSHOT -- 0.4.0)
call mvn versions:use-releases
call svn commit

REM Release Prepare and install to local repository
call mvn -B release:prepare -Dtag=0.4.0 -DdevelopmentVersion=0.5.0-SNAPSHOT
-DreleaseVersion=0.4.0 -DpreparationGoals=clean install

REM Dependency-Release-Versions are replaced by the newest Snapshot-Version
call mvn versions:use-latest-snapshots
call svn commit

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-update-dependency-snapshots-to-versions-in-batch-mode-tp3351425p3359398.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: A Maven archetype that helps packaging Solr as a standalone application embedded in Apache Tomcat

2011-01-27 Thread Simone Tripodi
Hi Paul,
thanks a lot for your feedbacks, much more than appreciated! :)

Going through your comments:

 * Yes it also packs a Solr webepp, it is needed to embed it in
Tomcat. Do you think it could be a useful feature having also webapp
.war as output? if it helps, I'm open to add it as well.

 * src/main/webapp and src/main/resources are ignored because I didn't
use the war plugin, everything is configured in the assembly
descriptor ATM. As a workaround, you can add resources on src/solr/*
subdirectory and it will be included in the webapp; when the war
plugin will be plugged (previous comment), that issue should be
solved.

Can you tell me a little more about the velocity contrib, please? In
the multicore, I'd like the solr.xml will be generated during the
build-time analyzing the dependencies but I didn't figure out how to
do it. Many thanks in advance!

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Jan 27, 2011 at 9:49 AM, Paul Libbrecht p...@hoplahup.net wrote:
 Simone,

 It's good that you did so! I had found this three days ago while googling.
 And I am starting to make sense of it. It works well.

 Two little comments:

 - you are saying that it packages a standalone multicore and a standalone 
 app. But it actually also packs a webapp.
  At first, I had rejected using that option because of the standalone output. 
 I think a  webapp is more usable. Just a matter of formulation

 - I have found how to configure my schema and config, could add the velocity 
 contrib to it, but I haven't yet found out how to add further resources. Both 
 src/main/webapp and src/main/resources are ignored.

 Help for the latter would be nice.

 paul


 Le 27 janv. 2011 à 07:58, Simone Tripodi a écrit :

 Hi all guys,
 this short mail just to make the Maven/Solr communities aware that we
 published an Apache Maven archetype[1] (that we lazily called
 'solr-packager' :P) that helps Apache Solr developers creating
 complete standalone Solr-based applications, embedded in Apache
 Tomcat, with few operations.
 We started developing it internally to reduce and help the `ops`
 tasks, since it has been useful we hope it could be also for you, so
 decided to publish it as oss.
 Questions, feedbacks, constructive criticisms, ideas... are more than
 welcome, if interested visit the github[2] page.
 Have a nice day, all the best
 Simo

 [1] http://sourcesense.github.com/solr-packager/
 [2] https://github.com/sourcesense/solr-packager

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/



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



maven-archiver merge policy on manifest file

2011-01-27 Thread Julien CARSIQUE
Hello,

The maven-archiver documentation says:
 The content of your own manifest file will be merged with the entries 
generated by Maven Archiver. If you specify an
entry in your own manifest file it will override the value generated by Maven 
Archiver. 

In our case, we need the entries in our own manifest file being overridden with 
those generated by Maven Archiver.

We ask Maven to fill the MANIFEST at build time:
  configuration
archive
  
manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile
  manifestEntries

Bundle-Version${eclipseVersion}-t${buildNumber}/Bundle-Version
  /manifestEntries
/archive
  /configuration
On the other side, we have to set a default Eclipse compliant value in the 
source manifest file (the reason comes from
Eclipse which requires a MANIFEST.MF with a Bundle-Version in source code in 
order to be able to load the module as an
OSGI plugin).
But, after Maven build, it would be better to get the true/dynamic version in 
the produced jar instead of the
hard-coded version set in the source file.

Is it possible to invert this behavior and make the value generated by Maven 
Archiver override existing entries in our
own manifest file ?

Thanks,

-- 
Julien Carsique, Nuxeo (Paris, France)
www.nuxeo.com - The Open Source ECM Platform - www.nuxeo.org
Nuxeo ECM Stack - The Java EE, scalable, standard-based ECM Platform



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



Re: A Maven archetype that helps packaging Solr as a standalone application embedded in Apache Tomcat

2011-01-27 Thread Paul Libbrecht

Le 27 janv. 2011 à 12:42, Simone Tripodi a écrit :
 thanks a lot for your feedbacks, much more than appreciated! :)

Good time sync. I need it right now.

 * Yes it also packs a Solr webepp, it is needed to embed it in
 Tomcat. Do you think it could be a useful feature having also webapp
 .war as output? if it helps, I'm open to add it as well.

I feel so.
Or at least say that it's a side production even if it's not an individual goal.

 * src/main/webapp and src/main/resources are ignored because I didn't
 use the war plugin, everything is configured in the assembly
 descriptor ATM. As a workaround, you can add resources on src/solr/*
 subdirectory and it will be included in the webapp;

But only in WEB-INF/classes... that doesn't seem right to be served as a static 
resource (I'm looking at css or js files).

 when the war plugin will be plugged (previous comment), that issue should be
 solved.

Any time estimate?

 Can you tell me a little more about the velocity contrib, please?

I added the dependency.
I copied in src/main/solr/commons the velocity config files.

I note that I had to deactivate the query-elevation which seems to expect a 
solr-home.

 In the multicore, I'd like the solr.xml will be generated during the
 build-time analyzing the dependencies but I didn't figure out how to
 do it. Many thanks in advance!

I should also say. At first I tried the multicore one and it failed on me... 
not too sure why but it did not have sufficient output.

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



Re: A Maven archetype that helps packaging Solr as a standalone application embedded in Apache Tomcat

2011-01-27 Thread Paul Libbrecht

Le 27 janv. 2011 à 12:42, Simone Tripodi a écrit :
 thanks a lot for your feedbacks, much more than appreciated! :)

One more anomaly I find: the license is in the output of the pom.xml.
I think this should not be the case.
*my* license should be there, not the license of the archetype. Or?

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



Re: Why is Maven allowing cycles?

2011-01-27 Thread Phillip Hellewell
Doesn't anyone know if Maven is supposed to give you an error when
there is a cycle?

If the answer is yes, then I need to figure out what I'm missing.

If the answer is no, then I'll write a plugin to detect cycles and
give an error.  I've already got a plugin that detects a version clash
(same artifact in the tree twice with different versions), so I could
just add cycle detection to that one.  It will probably be as simple
as checking for myself in the tree of dependencies.

Phillip

On Mon, Jan 24, 2011 at 3:56 PM, Phillip Hellewell ssh...@gmail.com wrote:
 I don't know if I've lost my mind or what, but Maven is not giving me
 an error when I have cyclic dependencies.

 I just tried a simple two projects A and B that depend on each other,
 and Maven gives me no errors when resolving dependencies.

 You can clearly see the cycle when running mvn dependency:tree.

 C:\mycomps2\compamvn dependency:tree
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building compa
 [INFO]    task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] [dependency:tree {execution: default-cli}]
 [INFO] mygroup:compa:pom:1.0.0
 [INFO] \- mygroup:compb:zip:vc-all:1.0.0:compile
 [INFO]    \- mygroup:compa:zip:vc-all:1.0.0:compile
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 second
 [INFO] Finished at: Mon Jan 24 15:00:16 MST 2011
 [INFO] Final Memory: 19M/483M
 [INFO] 
 

 Am I losing my mind?  What's going on?  Does it have something to do
 with the fact that I am using the assembly plugin with zip
 classifer?

 Phillip


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



Re: A Maven archetype that helps packaging Solr as a standalone application embedded in Apache Tomcat

2011-01-27 Thread Simone Tripodi
Hi Paul,
sorry I'm late but I've been in the middle of a conf call :( On which
IRC server the #solr channel is? I'll reach you ASAP.
Thanks a lot!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Jan 27, 2011 at 4:00 PM, Paul Libbrecht p...@hoplahup.net wrote:

 Le 27 janv. 2011 à 12:42, Simone Tripodi a écrit :
 thanks a lot for your feedbacks, much more than appreciated! :)

 One more anomaly I find: the license is in the output of the pom.xml.
 I think this should not be the case.
 *my* license should be there, not the license of the archetype. Or?

 paul

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



Nexus settings.xml best practice

2011-01-27 Thread David Hoffer
What's the best way to configure Nexus to override the default 'central'
repository and pluginRepository when I want this to be configured via a
'nexus' profile in settings.xml so I can have multiple profiles...each
pointing to a different maven proxy, i.e. nexus, artifactory, etc.

The online docs
http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.htmlsay
to create a nexus mirror (and a profile), but that is unacceptable
because then it's global...I can't choose a different profile to get maven
to point to it's maven proxy.  With this suggested approach I have to
comment out the mirror each time I want to use a non-nexus profile/etc.
When I put the full nexus URL in the profile's repository/pluginRepository
configuration and don't use the mirror, nexus can't proxy all artifacts...no
idea why.  The mirror, as suggested in the online docs, does allow nexus to
proxy all but then breaks the use of profiles here.


RE: Keeping the executable bit on shell scripts when testing

2011-01-27 Thread Haszlakiewicz, Eric
-Original Message-
From: Oliver Schrenk [mailto:oliver.schr...@gmail.com]

It's a good idea but not suitable for my case. If I'm calling sh, the real
script would be an argument.In my case this would break the test cases for
my command line argument validation tool.

cat  aa.sh EOF
#!/bin/sh
echo 0:$0
echo 1:$1
EOF
 chmod +x aa.sh
 ./aa.sh
0:./aa.sh
1:
 ./aa.sh a
0:./aa.sh
1:a
 sh ./aa.sh a
0:./aa.sh
1:a

That looks exactly the same to me.  What kind of shell are you using that 
breaks this?

eric


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



Best Practices: Deploying large releases into Maven Central

2011-01-27 Thread cowwoc

Hi,

Do artifacts ever expire on the Maven Central Repository? Is there a size
limit to how big each artifact can be? I ask because some artifacts can get
very big and I am concerned that this may cause problems down the line.

I'll give you a simple example. My library depends on the Boost C++ library.
Boost starts out with 241MB of sources (75MB compressed). When you compile
it, you end up with 2.78GB of binaries (200MB compressed) per
compiler/platform combination (i.e. Visual Studio 2010, Windows, 32-bit).
You then have to multiply that number by the number of platforms you want to
support.

On the one hand, I don't want users building Boost themselves because it is
a very painful and lengthy process. On the other hand, I get the feeling
that uploading GB of artifacts per release is not the right way to go ;)

My library only depends on a very small subset of of Boost so technically
speaking I could upload just that subset (at a cost of approximately 10MB
per platform). I am concerned about what will happen long-term. What happens
if more people begin using Boost and each one uploads the subset that they
depend on...?

See http://sourceforge.net/projects/boost/files/boost-binaries/1.44.0/ for
an example of how Boost modules can be split up. As you can see, individual
modules are quite small.

A similar topic has come up before:
http://maven.40175.n5.nabble.com/Best-practice-re-releasing-large-assembly-artifacts-td3250739.html
but in my case I am not trying to deploy assemblies into central. I am
trying to deploy individual artifacts that happen to be very large.

Let me know what you think.

Thanks,
Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Best-Practices-Deploying-large-releases-into-Maven-Central-tp3360249p3360249.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



@parameter alias does not seem to work

2011-01-27 Thread cowwoc

Hi,

Did I misunderstand how @parameter alias is supposed to work, or is this a
legitimate bug?

My plugin contains:

/**
 * The environment variables.
 *
 * @parameter alias=environment
 * @required
 */
@SuppressWarnings(UWF_UNWRITTEN_FIELD)
private MapString, String environmentVariables;

The referencing POM contains:

configuration
  environment
FOObar/FOO
  /environment
/configuration

This fails, as does:

configuration
  environmentVariables
FOObar/FOO
  /environmentVariables
/configuration

but if I remove alias from the plugin and use the second POM variation
then it works. What am I doing wrong?

Thanks,
Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/parameter-alias-does-not-seem-to-work-tp3360329p3360329.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



Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

2011-01-27 Thread Evgeny Goldin
Hi,

I see a different behavior in Maven 2.2.1 and Maven 3.0.2.

Suppose I have

properties
propertyDirdir/propertyDir
/properties

Later, it is used in expression to configure some plugin:

configuration
targetPathpl-290-4/${propertyDir}/1/targetPath
...
/configuration

*Before* this configuration is running, yet another plugin overrides
${propertyDir}
to another value by calling
mavenProject.getProperties().setProperty( propertyDir, dirdir )

Now, in Maven 2 configuration above will see new value and resolve to 
pl-290-4/*dirdir*/1 but in Maven 3
it will see an old one and resolve to pl-290-4/*dir*/1. As if Maven 2
interpolates ${propertyDir} dynamically
but Maven 3 does so statically so even having ${propertyDir} updated at
run-time the value of expression where
it is involved stays the same.

Here is the POM http://goo.gl/K3rkS and if I uncomment line
29http://goo.gl/JYcsX expression
in line 143 http://goo.gl/HEKzq will create a directory that will fail an
assert in
line 195 http://goo.gl/YExqW in Maven 3.0.2 but not in Maven 2.2.1. The
value is overridden in line 62 http://goo.gl/0wFZs.

What do you say the correct behavior is?  Is it Maven 3 bug or feature?
Appreciate your help!


Best regards,
Evgeny
evgeny-goldin.com


Re: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

2011-01-27 Thread lukewpatterson

I seem to remember it always being static.  I remember trying that scenario
in Maven 2 and it always remained the same as what was present in
help:effective-pom.  i.e. if it shows up in effective-pom, your plugin can't
change it
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-tp3360336p3360344.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: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

2011-01-27 Thread Evgeny Goldin

But it can be perfectly changed in Maven 2 and I use it a lot. It's just that
in Maven 3 the expression doesn't reflect the change out of sudden. 

-
Best regards,
Evgeny
http://evgeny-goldin.com/

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-tp3360336p3360350.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: @parameter alias does not seem to work

2011-01-27 Thread cowwoc


cowwoc wrote:
 
 Hi,
 
 Did I misunderstand how @parameter alias is supposed to work, or is this a
 legitimate bug?
 
 My plugin contains:
 
   /**
* The environment variables.
*
* @parameter alias=environment
* @required
*/
   @SuppressWarnings(UWF_UNWRITTEN_FIELD)
   private MapString, String environmentVariables;
 
 The referencing POM contains:
 
 configuration
   environment
 FOObar/FOO
   /environment
 /configuration
 
 This fails, as does:
 
 configuration
   environmentVariables
 FOObar/FOO
   /environmentVariables
 /configuration
 
 but if I remove alias from the plugin and use the second POM variation
 then it works. What am I doing wrong?
 
 Thanks,
 Gili
 


I think this is a bug. Aliasing seems to work for simple types (String) but
not for Map. Can someone please confirm this on their end?

Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/parameter-alias-does-not-seem-to-work-tp3360329p3360359.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: Why is Maven allowing cycles?

2011-01-27 Thread Ron Wheeler

On 27/01/2011 10:11 AM, Phillip Hellewell wrote:

Doesn't anyone know if Maven is supposed to give you an error when
there is a cycle?

If the answer is yes, then I need to figure out what I'm missing.

If the answer is no, then I'll write a plugin to detect cycles and
give an error.  I've already got a plugin that detects a version clash
(same artifact in the tree twice with different versions), so I could
just add cycle detection to that one.  It will probably be as simple
as checking for myself in the tree of dependencies.

Phillip

On Mon, Jan 24, 2011 at 3:56 PM, Phillip Hellewellssh...@gmail.com  wrote:

I don't know if I've lost my mind or what, but Maven is not giving me
an error when I have cyclic dependencies.

I just tried a simple two projects A and B that depend on each other,
and Maven gives me no errors when resolving dependencies.

You can clearly see the cycle when running mvn dependency:tree.

C:\mycomps2\compamvn dependency:tree
[INFO] Scanning for projects...
[INFO] 
[INFO] Building compa
[INFO]task-segment: [dependency:tree]
[INFO] 
[INFO] [dependency:tree {execution: default-cli}]
[INFO] mygroup:compa:pom:1.0.0
[INFO] \- mygroup:compb:zip:vc-all:1.0.0:compile
[INFO]\- mygroup:compa:zip:vc-all:1.0.0:compile
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 1 second
[INFO] Finished at: Mon Jan 24 15:00:16 MST 2011
[INFO] Final Memory: 19M/483M
[INFO] 

Am I losing my mind?  What's going on?  Does it have something to do
with the fact that I am using the assembly plugin with zip
classifer?

Phillip


Does this matter?
Is more than 1 copy of mygroup:compa:zip:vc-all:1.0.0 being included.

It seems silly to make something dependent on itself and I can't imagine how 
your would build it in the first place withyout getting an error.

But for mygroup:compa:pom:1.0.0, it will get 1  mygroup:compa:zip:vc-all:1.0.0 
and that is what it needs.

I am missing the harm that this does since it will get detected earlier in the 
process.


Ron



-
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



maven-plugin-testing-harness with Maven 3

2011-01-27 Thread oliver
Hi,

I'm working at a Maven plugin for OOo which uses 
maven-plugin-testing-harness-1.2 for testing. With Maven-2 it works fine but 
with Maven-3 I'll get a

java.lang.IllegalAccessError: tried to access field 
org.codehaus.plexus.PlexusTestCase.container from class 
org.apache.maven.plugin.testing.AbstractMojoTestCase
at 
org.apache.maven.plugin.testing.AbstractMojoTestCase.validateContainerStatus(AbstractMojoTestCase.java:447)
at 
org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:178)
at 
org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:127)
 ...

as error message during testing. Is there a chance to get the tests work also 
with Maven-3? 

regards,
Oliver


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



Re: maven-plugin-testing-harness with Maven 3

2011-01-27 Thread Olivier Lamy
Hello,
With maven3, you have to use

dependency
  groupIdorg.apache.maven.plugin-testing/groupId
  artifactIdmaven-plugin-testing-harness/artifactId
  version2.0-alpha-1/version
  scopetest/scope
/dependency



2011/1/27 oliver oliver.bo...@gmail.com:
 Hi,

 I'm working at a Maven plugin for OOo which uses 
 maven-plugin-testing-harness-1.2 for testing. With Maven-2 it works fine but 
 with Maven-3 I'll get a

 java.lang.IllegalAccessError: tried to access field 
 org.codehaus.plexus.PlexusTestCase.container from class 
 org.apache.maven.plugin.testing.AbstractMojoTestCase
        at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.validateContainerStatus(AbstractMojoTestCase.java:447)
        at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:178)
        at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:127)
  ...

 as error message during testing. Is there a chance to get the tests work also 
 with Maven-3?

 regards,
 Oliver


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





-- 
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

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



Re: maven-plugin-testing-harness with Maven 3

2011-01-27 Thread oliver
but then I have the problem that it does not work with Maven-2. One of our 
build server uses Maven-3 and the other Maven-2. I guess this can be handled by 
a profile section. Or is there another (better) way to do this?

regards,
Oliver


Am 27.01.2011 um 22:41 schrieb Olivier Lamy:

 Hello,
 With maven3, you have to use
 
dependency
  groupIdorg.apache.maven.plugin-testing/groupId
  artifactIdmaven-plugin-testing-harness/artifactId
  version2.0-alpha-1/version
  scopetest/scope
/dependency
 
 
 
 2011/1/27 oliver oliver.bo...@gmail.com:
 Hi,
 
 I'm working at a Maven plugin for OOo which uses 
 maven-plugin-testing-harness-1.2 for testing. With Maven-2 it works fine but 
 with Maven-3 I'll get a
 
 java.lang.IllegalAccessError: tried to access field 
 org.codehaus.plexus.PlexusTestCase.container from class 
 org.apache.maven.plugin.testing.AbstractMojoTestCase
at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.validateContainerStatus(AbstractMojoTestCase.java:447)
at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:178)
at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:127)
  ...
 
 as error message during testing. Is there a chance to get the tests work 
 also with Maven-3?
 
 regards,
 Oliver
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 
 -- 
 Olivier Lamy
 http://twitter.com/olamy
 http://www.linkedin.com/in/olamy
 
 -
 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: maven-plugin-testing-harness with Maven 3

2011-01-27 Thread Olivier Lamy
yup use a profile section (as for the site plugin)

2011/1/27 oliver oliver.bo...@gmail.com:
 but then I have the problem that it does not work with Maven-2. One of our 
 build server uses Maven-3 and the other Maven-2. I guess this can be handled 
 by a profile section. Or is there another (better) way to do this?

 regards,
 Oliver


 Am 27.01.2011 um 22:41 schrieb Olivier Lamy:

 Hello,
 With maven3, you have to use

    dependency
      groupIdorg.apache.maven.plugin-testing/groupId
      artifactIdmaven-plugin-testing-harness/artifactId
      version2.0-alpha-1/version
      scopetest/scope
    /dependency



 2011/1/27 oliver oliver.bo...@gmail.com:
 Hi,

 I'm working at a Maven plugin for OOo which uses 
 maven-plugin-testing-harness-1.2 for testing. With Maven-2 it works fine 
 but with Maven-3 I'll get a

 java.lang.IllegalAccessError: tried to access field 
 org.codehaus.plexus.PlexusTestCase.container from class 
 org.apache.maven.plugin.testing.AbstractMojoTestCase
        at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.validateContainerStatus(AbstractMojoTestCase.java:447)
        at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:178)
        at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:127)
  ...

 as error message during testing. Is there a chance to get the tests work 
 also with Maven-3?

 regards,
 Oliver


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





 --
 Olivier Lamy
 http://twitter.com/olamy
 http://www.linkedin.com/in/olamy

 -
 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





-- 
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

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



Re: Keeping the executable bit on shell scripts when testing

2011-01-27 Thread Oliver Schrenk
No. That works fine. Its the application logic that get's in the way. Maybe I 
find a workaround using `sh` but it'll be a few days I have time to work on it 
again.

Thanks.

Best regards
Oliver

PS Throwing a crazy idea out there: Java7 rewrite for Maven using JSR203 
accessing POSIX file permissions

 

Am 27.01.2011 um 19:42 schrieb Haszlakiewicz, Eric:

 -Original Message-
 From: Oliver Schrenk [mailto:oliver.schr...@gmail.com]
 
 It's a good idea but not suitable for my case. If I'm calling sh, the real
 script would be an argument.In my case this would break the test cases for
 my command line argument validation tool.
 
 cat  aa.sh EOF
 #!/bin/sh
 echo 0:$0
 echo 1:$1
 EOF
 chmod +x aa.sh
 ./aa.sh
 0:./aa.sh
 1:
 ./aa.sh a
 0:./aa.sh
 1:a
 sh ./aa.sh a
 0:./aa.sh
 1:a
 
 That looks exactly the same to me.  What kind of shell are you using that 
 breaks this?
 
 eric
 
 
 -
 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