Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Martin Eigenbrodt]

Hello Trevor,

contrary to some responses here I don't think your issues is SCM/Version
Control issue. This is not your fault.
Your issue is missing "soft" or dynamic version support in maven.
Actually the responses propose some workarounds:

1.Manual:
> An easy solution is: When Alice prepares the release, she says "Hey
> Bob, I'm doing a release of Foo".
This is obviously not a solution if ther is not just foo but foo1, foo2 to
fo10 and AppA to AppZ.

2. Custom scripts
>We use a little script
>that invokes the version plugin and checks in the pom.xml if versions were
>updated. Hudson runs the update script nightly.
This looks like a working solution. However a "native" Maven Solution would
be better.

3. innhouse parent pom workaround
>Use an inhouse global POM that is used as parent everywhere and define the
>versions used there in a depMgmt section.
How can you make sure you always use the latest version of the parent POM?
This changes the problem
from updating the reference to foo into updating the reference to the
parent.

I'm new to maven and have used ant & ivy before. With ivy you're able to
design AppA an AppB so they will always pick
up the latest version of foo. However a released artifact can still contain
information about the exact version used to build the artifact.
I'm really missing this feature in maven. An if I look at your post and the
proposed workarounds I think others are missing it a well, maybe they just
don't know...
I've already posted about this isse before, but there has not been any
response yet:
http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html

Best regards,

Martin

2009/3/26 Martin Gainty 

>
> The only way to accomplish this is called version control
> but since you do not want to use version control ..
>
> how do you achieve intelligent merging *on the same component codebase*
> without version control
> ?
> Martin
> __
> Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> This message is confidential and may be privileged. If you are not the
> intended recipient, we kindly ask you to  please inform the sender. Any
> unauthorised dissemination or copying hereof is prohibited. This message
> serves for information purposes only and shall not have any legally binding
> effect. Given that e-mails can easily be subject to manipulation, we can not
> accept any liability for the content provided.
>
>
>
>
>
>
> > Subject: RE: Possible problem when multiple developers depend on SNAPSHOT
> versions
> > Date: Wed, 25 Mar 2009 22:18:53 -0400
> > From: justin.edel...@mtvstaff.com
> > To: users@maven.apache.org
> >
> > +10
> >
> > 
> >
> > From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com]
> > Sent: Wed 3/25/2009 5:49 PM
> > To: Maven Users List
> > Subject: Re: Possible problem when multiple developers depend on SNAPSHOT
> versions
> >
> >
> >
> > With all due respect to others' responses, the scenario described
> > below is not due to misuse or lack of version control. Indeed, the
> > scenario below clearly describes version control *working as
> > designed*.
> >
> > Bob finds himself unwittingly building snapshots of 2.2, while his
> > project continues to depend on snapshots of 2.1, so he doesn't see his
> > own changes. The problem, however, is neither source control nor
> > maven: it's lack of communication.
> >
> > Something like cutting a release needs to be coordinated among the
> > developers working on a component. Alice and Bob need to talk to each
> > other about library Foo, particularly with respect to cutting a
> > release. There's no way around this.
> >
> > // ben
> >
> > On Wed, Mar 25, 2009 at 20:10, Trevor Harmon  wrote:
> > > Consider this scenario:
> > >
> > > Alice and Bob are working independently on two different applications,
> AppA
> > > and AppB. Both applications depend on an in-house shared library, Foo,
> that
> > > Alice and Bob are working on together. They have both checked out Foo's
> > > trunk and are regularly committing changes to it.
> > >
> > > Because Foo is undergoing heavy development, AppA and AppB depend on
> Foo
> > > 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA
> needs
> > > some of the features scheduled for Foo 2.2, so she decides to perform a
> > > release of Foo 2.1 and does the usual release procedure:
> > >
> > > 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into
> the
> > > trunk
> > > 2) Deploys Foo 2.1 to the comp

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Stephen Connolly]

2009/3/26 Martin Eigenbrodt 

> Hello Trevor,
>
> contrary to some responses here I don't think your issues is SCM/Version
> Control issue. This is not your fault.
> Your issue is missing "soft" or dynamic version support in maven.
> Actually the responses propose some workarounds:
>
> 1.Manual:
> > An easy solution is: When Alice prepares the release, she says "Hey
> > Bob, I'm doing a release of Foo".
> This is obviously not a solution if ther is not just foo but foo1, foo2 to
> fo10 and AppA to AppZ.
>
> 2. Custom scripts
> >We use a little script
> >that invokes the version plugin and checks in the pom.xml if versions were
> >updated. Hudson runs the update script nightly.
> This looks like a working solution. However a "native" Maven Solution would
> be better.


eh... how is invoking a maven plugin not a "native" maven solution


>
>
> 3. innhouse parent pom workaround
> >Use an inhouse global POM that is used as parent everywhere and define the
> >versions used there in a depMgmt section.
> How can you make sure you always use the latest version of the parent POM?
> This changes the problem
> from updating the reference to foo into updating the reference to the
> parent.


mvn versions:update-parent

presto-chango you now have the latest deployed parent


>
>
> I'm new to maven and have used ant & ivy before. With ivy you're able to
> design AppA an AppB so they will always pick
> up the latest version of foo. However a released artifact can still contain
> information about the exact version used to build the artifact.
> I'm really missing this feature in maven. An if I look at your post and the
> proposed workarounds I think others are missing it a well, maybe they just
> don't know...
> I've already posted about this isse before, but there has not been any
> response yet:
>
> http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html
>
> Best regards,
>
> Martin
>
> 2009/3/26 Martin Gainty 
>
> >
> > The only way to accomplish this is called version control
> > but since you do not want to use version control ..
> >
> > how do you achieve intelligent merging *on the same component codebase*
> > without version control
> > ?
> > Martin
> > __
> > Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality
> note
> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte
> > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> > dient lediglich dem Austausch von Informationen und entfaltet keine
> > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > This message is confidential and may be privileged. If you are not the
> > intended recipient, we kindly ask you to  please inform the sender. Any
> > unauthorised dissemination or copying hereof is prohibited. This message
> > serves for information purposes only and shall not have any legally
> binding
> > effect. Given that e-mails can easily be subject to manipulation, we can
> not
> > accept any liability for the content provided.
> >
> >
> >
> >
> >
> >
> > > Subject: RE: Possible problem when multiple developers depend on
> SNAPSHOT
> > versions
> > > Date: Wed, 25 Mar 2009 22:18:53 -0400
> > > From: justin.edel...@mtvstaff.com
> > > To: users@maven.apache.org
> > >
> > > +10
> > >
> > > 
> > >
> > > From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com]
> > > Sent: Wed 3/25/2009 5:49 PM
> > > To: Maven Users List
> > > Subject: Re: Possible problem when multiple developers depend on
> SNAPSHOT
> > versions
> > >
> > >
> > >
> > > With all due respect to others' responses, the scenario described
> > > below is not due to misuse or lack of version control. Indeed, the
> > > scenario below clearly describes version control *working as
> > > designed*.
> > >
> > > Bob finds himself unwittingly building snapshots of 2.2, while his
> > > project continues to depend on snapshots of 2.1, so he doesn't see his
> > > own changes. The problem, however, is neither source control nor
> > > maven: it's lack of communication.
> > >
> > > Something like cutting a release needs to be coordinated among the
> > > developers working on a component. Alice and Bob need to talk to each
> > > other about library Foo, particularly with respect to cutting a
> > > release. There's no way around this.
> > >
> > > // ben
> > >
> > > On Wed, Mar 25, 2009 at 20:10, Trevor Harmon 
> wrote:
> > > > Consider this scenario:
> > > >
> > > > Alice and Bob are working independently on two different
> applications,
> > AppA
> > > > and AppB. Both applications depend on an in-house shared library,
> Foo,
> > that
> > > > Alice and Bob are working on together. They have both checked out
> Foo's
> > > > trunk and are regularly committing changes to it.
> > > >

Re: Test built jar

[andy petrella]

ping ^^

andy petrella a écrit :

Hi All,

I trying to have some IT tests (or look-like) on my jar file only. I 
was thinking that the phase verify will give me that chance but not.


Here is my problem.

I have a jar where some directory has to be parsed on a file pattern 
=> I use the JarFile class, then parse it to retrieve what I need 
(some XML files).


This code must be tested (a lot !) but I can figure out how to have my 
tests' classpath running on the generated test and not on 
target/classses.
(a maven -X shows me that target/classes are used while my It test are 
executed using the surfire conf in the verify phase)


Ideas someone ?

Thanks a lot.

ap

-
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: Possible problem when multiple developers depend on SNAPSHOT versions

[Martin Eigenbrodt]

>
> >
> > 2. Custom scripts
> > >We use a little script
> > >that invokes the version plugin and checks in the pom.xml if versions
> were
> > >updated. Hudson runs the update script nightly.
> > This looks like a working solution. However a "native" Maven Solution
> would
> > be better.
>
>
> eh... how is invoking a maven plugin not a "native" maven solution
>

The Plugin is "native". "A little script invoking the version plugin" is not
native since you need that script and make sure it is invoked before every
build.  (Or at least nightly ..)

//Martin Eigenbrodt


>
>
> >
> >
> > 3. innhouse parent pom workaround
> > >Use an inhouse global POM that is used as parent everywhere and define
> the
> > >versions used there in a depMgmt section.
> > How can you make sure you always use the latest version of the parent
> POM?
> > This changes the problem
> > from updating the reference to foo into updating the reference to the
> > parent.
>
>
> mvn versions:update-parent
>
> presto-chango you now have the latest deployed parent
>

I know this, but again it is a manual solution. If you want AppB (I'm using
the originall posters example) to stay up to date you have
to make sure versions:update-parent is called before every build and you
have your pom changed each time and so need a scm checkin.
This is a complicated workaround for the missing feature:

foo
LATEST



>
> >
> >
> > I'm new to maven and have used ant & ivy before. With ivy you're able to
> > design AppA an AppB so they will always pick
> > up the latest version of foo. However a released artifact can still
> contain
> > information about the exact version used to build the artifact.
> > I'm really missing this feature in maven. An if I look at your post and
> the
> > proposed workarounds I think others are missing it a well, maybe they
> just
> > don't know...
> > I've already posted about this isse before, but there has not been any
> > response yet:
> >
> >
> http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html
> >
> > Best regards,
> >
> > Martin
> >
> > 2009/3/26 Martin Gainty 
> >
> > >
> > > The only way to accomplish this is called version control
> > > but since you do not want to use version control ..
> > >
> > > how do you achieve intelligent merging *on the same component codebase*
> > > without version control
> > > ?
> > > Martin
> > > __
> > > Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality
> > note
> > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> > unbefugte
> > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
> Nachricht
> > > dient lediglich dem Austausch von Informationen und entfaltet keine
> > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > > This message is confidential and may be privileged. If you are not the
> > > intended recipient, we kindly ask you to  please inform the sender. Any
> > > unauthorised dissemination or copying hereof is prohibited. This
> message
> > > serves for information purposes only and shall not have any legally
> > binding
> > > effect. Given that e-mails can easily be subject to manipulation, we
> can
> > not
> > > accept any liability for the content provided.
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Subject: RE: Possible problem when multiple developers depend on
> > SNAPSHOT
> > > versions
> > > > Date: Wed, 25 Mar 2009 22:18:53 -0400
> > > > From: justin.edel...@mtvstaff.com
> > > > To: users@maven.apache.org
> > > >
> > > > +10
> > > >
> > > > 
> > > >
> > > > From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com]
> > > > Sent: Wed 3/25/2009 5:49 PM
> > > > To: Maven Users List
> > > > Subject: Re: Possible problem when multiple developers depend on
> > SNAPSHOT
> > > versions
> > > >
> > > >
> > > >
> > > > With all due respect to others' responses, the scenario described
> > > > below is not due to misuse or lack of version control. Indeed, the
> > > > scenario below clearly describes version control *working as
> > > > designed*.
> > > >
> > > > Bob finds himself unwittingly building snapshots of 2.2, while his
> > > > project continues to depend on snapshots of 2.1, so he doesn't see
> his
> > > > own changes. The problem, however, is neither source control nor
> > > > maven: it's lack of communication.
> > > >
> > > > Something like cutting a release needs to be coordinated among the
> > > > developers working on a component. Alice and Bob need to talk to each
> > > > other about library Foo, particularly with respect to cutting a
> > > > release. There's no way around this.
> > > >
> > > > // ben
> > > >
> > > > On Wed, Mar 25, 2009 at 20:10, Trevor Harmon 
> > wrote:
> > > > > Consider this scenario:
> > > > >
> > > > > Alice an

Re: How to integrate xhtml files into a maven generated site?

[feensturm]

Hi


Lukas Theussl wrote:
> 
>> This doesn't work with doxia-1.0, it's fixed in doxia-1.1 which is not 
>> used yet by the site plugin. There is a snapshot of the site plugin 
>> (version 2.1-SNAPSHOT) that uses doxia 1.1 but it requires maven 2.1 
> 
> 

I tried maven 2.1 and doxia 1.1 and get this exception:


Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site': Unable to load
the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site' in the
plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class is
missing:
org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext
org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext

Did I miss something

regards Pascal






-- 
View this message in context: 
http://www.nabble.com/How-to-integrate-xhtml-files-into-a-maven-generated-site--tp22601841p22717300.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: How to perform a deploy only

[B Smith-Mannschott]

On Thu, Mar 26, 2009 at 03:17, Jim McCaskey  wrote:
> Hello all,
>
> I have several components all built from a top level pom.  This works great 
> for accelerating users to be able to build a lot of stuff quickly but is 
> giving me some fits when trying to deploy.  Up to this point I have been 
> using deploy:deploy-file to get built components into our local repository 
> after a full build is successful, but this is labor intensive.

My Guess: It sounds like you're describing a multi-module build where
the "top-level" pom naming the modules to be built is also parent to
the sub-modules. You want to deploy just the top-level pom, so others
can build against it. Correct? You don't want to deploy all the
sub-modules each time you do this because they may not be in a stable
state.

(1) Have you considered "mvn --non-recursive deploy"?
(2) You do realize that the pom that defines the modules does not have
to be the same as the common parent pom, yes?



// ben

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

Re: How to integrate xhtml files into a maven generated site?

[Lukas Theussl]

As I said, you can't use site-plugin-2.0-beta-7 (btw latest version is 2.0) with 
doxia 1.1. Try version 2.1-SNAPSHOT.


HTH,
-Lukas


feensturm wrote:

Hi


Lukas Theussl wrote:
This doesn't work with doxia-1.0, it's fixed in doxia-1.1 which is not 
used yet by the site plugin. There is a snapshot of the site plugin 
(version 2.1-SNAPSHOT) that uses doxia 1.1 but it requires maven 2.1 




I tried maven 2.1 and doxia 1.1 and get this exception:


Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site': Unable to load
the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site' in the
plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class is
missing:
org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext
org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext

Did I miss something

regards Pascal








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

Re: Test built jar

[Wayne Fay]

> ping ^^

I think no one replied because your message does not make any sense
(to me at least). Can you try re-writing the email and focus on what
you have, what you need, and how you think Maven can help get you from
A to B? Also mention what you've tried and why that didn't work or was
insufficient.

Wayne

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

Re: Exclude resources during jar generation

[Wayne Fay]

> When I generate jar from A project, I would like to exclude these resources
> (containing in src/main/resources) from my jar. For the moment, I haven't
> found a solution.

Make project D which is just the assembly, and don't put any files in
D/src/main/resources, just let D be your assembly project. (This
assumes I understood your email, which may not be a correct
assumption.)

Wayne

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

maven-release-plugin: branch goal does not take same properties as prepare goal

[Ringo De Smet]

Hello,

I am trying to automate the branching for a few hundred Maven
projects. The automation of creating a release works great using the
-DreleaseVersion and -DdevelopmentVersion properties using the prepare
goal. The documentation of the branch goals states this: "The branch
goal can use the same properties used by the prepare goal for
specifying the versions to be used." It seems that I can't use the
version properties from the release goal, but that I should specify
these:

project.[rel|dev].org.myCompany:projectA

However, these properties contain project specific information, which
means that I can't use the multi-module approach to automate the
branching for all my projects at once. Our versioning strategy always
takes the same major/minor number and branch name for modules going
together in a release.

Am I missing something? Any hints on how to get around this?

Ringo

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

Re: maven-release-plugin, svn 1.5 issue and dependencies

[Olivier Lamy]

Hi,
The vote (maven-scm and maven-release-plugin) has started 2 days ago.
(vote thread : [1])
I'm currently waiting the end of the release process to push artifacts
on the central repo (the end for me is today 11H55 PM Paris Time )
BTW you can try with the staged artifacts.

HTH,
--
Olivier
[1] 
http://www.nabble.com/-VOTE--Release-Maven-Scm-1.2-and-maven-release-plugin-2.0-beta-9-tt22671100.html

2009/3/26 Stevo Slavić :
> Hello maven users,
>
> In maven-release-plugin recently an important issue (
> http://jira.codehaus.org/browse/MRELEASE-375 ) has been resolved. Without
> this fix, release plug-in can not be used on a multi-module project (with
> svn 1.5.0+ client) - dunno about others, but I rarely work on a single
> module project, and even more rarely use release plugin on a single module
> project. Eager to test the fix, I tried to use 2.0-beta-9-SNAPSHOT version
> of the plugin. Just as note to other, for it to be used, I had to add
> http://repository.apache.org/snapshots as both dependency repository
> (because release plugin depends on
> maven-release-manager:2.0-beta-9-SNAPSHOT) and as plugin repository.
>
> Because of fix importance, are there any plans to release 2.0-beta-9 any
> time soon?
>
> Regards,
> Stevo.
>

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

maven-release-plugin, svn 1.5 issue and dependencies

[Stevo Slavić]

Hello maven users,

In maven-release-plugin recently an important issue (
http://jira.codehaus.org/browse/MRELEASE-375 ) has been resolved. Without
this fix, release plug-in can not be used on a multi-module project (with
svn 1.5.0+ client) - dunno about others, but I rarely work on a single
module project, and even more rarely use release plugin on a single module
project. Eager to test the fix, I tried to use 2.0-beta-9-SNAPSHOT version
of the plugin. Just as note to other, for it to be used, I had to add
http://repository.apache.org/snapshots as both dependency repository
(because release plugin depends on
maven-release-manager:2.0-beta-9-SNAPSHOT) and as plugin repository.

Because of fix importance, are there any plans to release 2.0-beta-9 any
time soon?

Regards,
Stevo.

Re: maven-release-plugin, svn 1.5 issue and dependencies

[Stevo Slavić]

Great! Thanks for quick reply!

2009/3/26 Olivier Lamy 

> Hi,
> The vote (maven-scm and maven-release-plugin) has started 2 days ago.
> (vote thread : [1])
> I'm currently waiting the end of the release process to push artifacts
> on the central repo (the end for me is today 11H55 PM Paris Time )
> BTW you can try with the staged artifacts.
>
> HTH,
> --
> Olivier
> [1]
> http://www.nabble.com/-VOTE--Release-Maven-Scm-1.2-and-maven-release-plugin-2.0-beta-9-tt22671100.html
>
> 2009/3/26 Stevo Slavić :
> > Hello maven users,
> >
> > In maven-release-plugin recently an important issue (
> > http://jira.codehaus.org/browse/MRELEASE-375 ) has been resolved.
> Without
> > this fix, release plug-in can not be used on a multi-module project (with
> > svn 1.5.0+ client) - dunno about others, but I rarely work on a single
> > module project, and even more rarely use release plugin on a single
> module
> > project. Eager to test the fix, I tried to use 2.0-beta-9-SNAPSHOT
> version
> > of the plugin. Just as note to other, for it to be used, I had to add
> > http://repository.apache.org/snapshots as both dependency repository
> > (because release plugin depends on
> > maven-release-manager:2.0-beta-9-SNAPSHOT) and as plugin repository.
> >
> > Because of fix importance, are there any plans to release 2.0-beta-9 any
> > time soon?
> >
> > Regards,
> > Stevo.
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Test built jar

[andy petrella]

ok :)

What I need is to be able to test the behavior of my code when the jar 
is attached to the classpath instead of the classes folder.
Because, I have a code that parse the content of the jar where it stands 
to find xml files or use getResourceAsStream to get the folder.


So the code checks if the context is jar or not, then execute the 
corresponding code. The code using getResourceAsStream is well tested 
but the other cannot because surefire adds the folder target/classes to 
the classpath rather than (in my case) the built jar.


Sorry if it wasn't clear, or still not clear.

If it doesn't make sense, what can I do (other than : created a project 
having a dependency on the to-be-tested project...)


Thanks

ap


Wayne Fay a écrit :

ping ^^



I think no one replied because your message does not make any sense
(to me at least). Can you try re-writing the email and focus on what
you have, what you need, and how you think Maven can help get you from
A to B? Also mention what you've tried and why that didn't work or was
insufficient.

Wayne

-
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

Code coverage reports & Activating profile if (site) plug-in is run

[Stevo Slavić]

Hello maven users,

Is there a way to activate a profile based on plug-in being run? I'm trying
to find a workaround for issue present in both free open source code
coverage maven report options, cobertura and emma (if there are more, please
let me know). AFAIK, both, to produce report, run code instrumentalization,
execute test phase in lifecycle separate from default, and then generate
output. Problem is that test phase is so to speak hardcoded, so surefire
execution configured to run in integration-test phase doesn't get run and
coverage data will apear to be lower than what they actually are.

Typicaly I use TestNG for tests, and it's test groups feature, separating
tests in at least "unit", and "integration" and/or "functional" test groups.
Then I configure surefire to run "unit" tests in "test" phase, and all the
others in "integration-test" phase. If profile could be activated based on
plug-in being run, workaround would be to create a profile, activeted on
e.g. site plug-in being run, and in that profile surefire could be
configured to contain only one default execution on test phase but would
include all the tests.

IMO, best solution would be to have following (in cobertura case,
longstanding) issues fixed ( http://jira.codehaus.org/browse/MCOBERTURA-86 ,
http://jira.codehaus.org/browse/MOJO-1299 )

Regards,
Stevo.

Re: XHTML to PDF with doxia-maven-plugin, ignore some tags

[niamande]

I can't remove the anchor because my xhtml is generated from an existing html
(used by others applications, so i can't modify it).
Thanks for your response, i'll developped my own tool to remove specifics
xhtml tags.



Lukas Theussl-3 wrote:
> 
> 
> Not sure I understand but if you don't want an anchor, why not just remove
> it?
> 
> Anyway, you can't tell a parser to ignore one tag and not the other.
> 
> HTH,
> -Lukas
> 
> 
> niamande wrote:
>> I've got a xhtml with an anchor before a section : 
>> ..l txt1 
>> ..
>> 
>> How indicate to doxia plugin to ignore this anchor ? I don't want that it
>> appears in the generated pdf.
>> Thanks !
> 
> 

-- 
View this message in context: 
http://www.nabble.com/XHTML-to-PDF-with-doxia-maven-plugin%2C-ignore-some-tags-tp22702451p22718534.html
Sent from the Doxia - Users mailing list archive at Nabble.com.

Maven extra sources and eclipse

[Jean-Marc Vanel]

Hi all

 We have a projet (
http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml
) using a parser generator , for which we have extra Java sources, not
for building with the application.

We generate the eclipse configuration with Maven, but I found no way
to specify these extra Java sources so that they appear in the eclipse
configuration.

Thanks for any hint
-- 
Jean-Marc Vanel
Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/

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

Maven dependency for JAI?

[Angelo Chen]

Hi,

is there a maven dependency for  Java Advanced Imaging projects? thanks.
-- 
View this message in context: 
http://www.nabble.com/Maven-dependency-for-JAI--tp22719872p22719872.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: setting surefire reports directory

[Norbert S.]

Hi,
thank you for your answers. Reinhards infos solve exactly my problem.

Of course I knew the luntbuild-property "artifactsDir". But I missed
the solution from Reinhard how I simply integrate this property in the
pom.xml
without forcing the user to set the artifactsDir at every call or integrate
a default-artifactsDir in every profile!

Norbert


-- 
View this message in context: 
http://www.nabble.com/setting-surefire-reports-directory-tp22702724p22720009.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: [Vote] findbugs-maven-plugin v 2.0 release

[Pablo Saavedra]

+1

2009/3/26 Garvin LeClaire 

> The Maven Findbugs team would like to release Maven Findbugs Plugin version
> 2.0
>
> This plugin allows the developer to run Findbugs analysis against a Maven
> project and produce site output in HTML to match other site reports.  There
> are option to produce other XML outputs which are used by other plugins.
>
> Issues fixed in this release:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&fixfor=14335&pid=11701&status=6&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC
>
>
> More information can be found at the plugin site:
> http://mojo.codehaus.org/findbugs-maven-plugin/
>
>
> Issues Can be registered in JIRA at:
> http://jira.codehaus.org/browse/MFINDBUGS
>
>
> More information on FindBugs
> http://findbugs.sourceforge.net/index.html
>
>
>
> You can test the Maven Findbugs Plugin in your own project by adding the
> following dependency:
>
> 
> org.codehaus.mojo
> findbugs-maven-plugin
> 2.0-SNAPSHOT
> 
>
>
>
> *NOTE*  Version 2.0 and greater of the Maven Findbugs plugin will require
> Maven to be run with a minimum of Java 5.  This is consistent with Findbugs
> requirement for their versions of 1.3.X and greater.
>
>
>
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
>
> Regards,
>
>
>
> Garvin LeClaire
> garvin.lecla...@gmail.com
>
>

Apache maven snapshots repository root links are invalid

[Stevo Slavić]

Hello maven users,

Links on http://repository.apache.org/snapshots are invalid, they are
missing "snapshots" part. This is error only in the root of the repository,
once in some directory e.g. "http://repository.apache.org/snapshots/org";,
links work well. It seems to be some sort of (nexus) configuration issue.

Regards,
Stevo.

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Stephen Connolly]

2009/3/26 Martin Eigenbrodt 

> >
> > >
> > > 2. Custom scripts
> > > >We use a little script
> > > >that invokes the version plugin and checks in the pom.xml if versions
> > were
> > > >updated. Hudson runs the update script nightly.
> > > This looks like a working solution. However a "native" Maven Solution
> > would
> > > be better.
> >
> >
> > eh... how is invoking a maven plugin not a "native" maven solution
> >
>
> The Plugin is "native". "A little script invoking the version plugin" is
> not
> native since you need that script and make sure it is invoked before every
> build.  (Or at least nightly ..)
>
> //Martin Eigenbrodt
>
>
> >
> >
> > >
> > >
> > > 3. innhouse parent pom workaround
> > > >Use an inhouse global POM that is used as parent everywhere and define
> > the
> > > >versions used there in a depMgmt section.
> > > How can you make sure you always use the latest version of the parent
> > POM?
> > > This changes the problem
> > > from updating the reference to foo into updating the reference to the
> > > parent.
> >
> >
> > mvn versions:update-parent
> >
> > presto-chango you now have the latest deployed parent
> >
>
> I know this, but again it is a manual solution. If you want AppB (I'm using
> the originall posters example) to stay up to date you have
> to make sure versions:update-parent is called before every build and you
> have your pom changed each time and so need a scm checkin.
> This is a complicated workaround for the missing feature:
> 
>foo
>LATEST
> 


And that prevents your build from being reproducible...

note that AFAIK is nothing stopping you from using a range


  [1.0,2.0-!)


(Of course you'd face the same issues as LATEST)


>
>
> >
> > >
> > >
> > > I'm new to maven and have used ant & ivy before. With ivy you're able
> to
> > > design AppA an AppB so they will always pick
> > > up the latest version of foo. However a released artifact can still
> > contain
> > > information about the exact version used to build the artifact.
> > > I'm really missing this feature in maven. An if I look at your post and
> > the
> > > proposed workarounds I think others are missing it a well, maybe they
> > just
> > > don't know...
> > > I've already posted about this isse before, but there has not been any
> > > response yet:
> > >
> > >
> >
> http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html
> > >
> > > Best regards,
> > >
> > > Martin
> > >
> > > 2009/3/26 Martin Gainty 
> > >
> > > >
> > > > The only way to accomplish this is called version control
> > > > but since you do not want to use version control ..
> > > >
> > > > how do you achieve intelligent merging *on the same component
> codebase*
> > > > without version control
> > > > ?
> > > > Martin
> > > > __
> > > > Verzicht und Vertraulichkeitanmerkung / Disclaimer and
> confidentiality
> > > note
> > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> > > unbefugte
> > > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
> > Nachricht
> > > > dient lediglich dem Austausch von Informationen und entfaltet keine
> > > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
> von
> > > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > > > This message is confidential and may be privileged. If you are not
> the
> > > > intended recipient, we kindly ask you to  please inform the sender.
> Any
> > > > unauthorised dissemination or copying hereof is prohibited. This
> > message
> > > > serves for information purposes only and shall not have any legally
> > > binding
> > > > effect. Given that e-mails can easily be subject to manipulation, we
> > can
> > > not
> > > > accept any liability for the content provided.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Subject: RE: Possible problem when multiple developers depend on
> > > SNAPSHOT
> > > > versions
> > > > > Date: Wed, 25 Mar 2009 22:18:53 -0400
> > > > > From: justin.edel...@mtvstaff.com
> > > > > To: users@maven.apache.org
> > > > >
> > > > > +10
> > > > >
> > > > > 
> > > > >
> > > > > From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com]
> > > > > Sent: Wed 3/25/2009 5:49 PM
> > > > > To: Maven Users List
> > > > > Subject: Re: Possible problem when multiple developers depend on
> > > SNAPSHOT
> > > > versions
> > > > >
> > > > >
> > > > >
> > > > > With all due respect to others' responses, the scenario described
> > > > > below is not due to misuse or lack of version control. Indeed, the
> > > > > scenario below clearly describes version control *working as
> > > > > designed*.
> > > > >
> > > > > Bob finds himself unwittingly building snapshots of 2.2, while his
> > > > > project continues to depend on snapshots of 2.1, so he doesn't see
> > his
> > > > > own changes. The problem, howeve

Re: How to integrate xhtml files into a maven generated site?

[feensturm]

Ok, I mixed up with the answer from Marco Huber


Marco Huber wrote:
> 
> 
> So I wait for maven 2.1 until I can add my documentation to the project
> :-( 
> 

But with the Snapshot I get the same exception:

Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site': Unable to
load the mojo 'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site'
in the plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class
is missing:
org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext
org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext

regards Pascal

-- 
View this message in context: 
http://www.nabble.com/How-to-integrate-xhtml-files-into-a-maven-generated-site--tp22601841p22721345.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: Maven extra sources and eclipse

[Markku Saarela]

Hi,

You can use build-helper plugin and its goal add-source.

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

rgds,

Markku

Jean-Marc Vanel wrote:

Hi all

 We have a projet (
http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml
) using a parser generator , for which we have extra Java sources, not
for building with the application.

We generate the eclipse configuration with Maven, but I found no way
to specify these extra Java sources so that they appear in the eclipse
configuration.

Thanks for any hint
  



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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Martin Eigenbrodt]

>> 
>>foo
>>LATEST
>> 
>And that prevents your build from being reproducible...

Not If you combine dynamic version ranges with replacement during deploy
and release the builds remain reproducable. They are in
fact even more reproducable than now.

Example: You trunk would contain:

  latest


a tag in svn or a resolved pom within a jar/war/ whatever should
automatically have the used version written in:

  1.2.3


If you then stop using SNAPSHOT versions an have your CI Server produces a
new version for every Build each single build becomes
reproducable which is even more than you have now.
In my opinion that is what on should aim for. The only difference between a
CI build and a release is that a release has been tested and marked as
"good". So each CI build is a potential release and as such should be
reproducable.


> 
>  [1.0,2.0-!)
> 

I've tried that and it doesn't work. Theres even an ticket for that one:
http://jira.codehaus.org/browse/MNG-2199
There are in fact more tickets about using latest version and dynamic
version replacement (or replacing properties)

Re: How to perform a deploy only

[Stefan Seidel]

I don't really see the problem here.
mvn clean install && mvn deploy:deploy

I'm sure there is an equivalent if you're building under Windows.

Stefan

On Wed, 25 Mar 2009 21:37:29 -0500
Jim McCaskey  wrote:

> I have a whole bunch of components that are mostly interrelated but 
> consumable individually by downstream builds.  If I run deploy it basically 
> starts deploying as it goes, so if a downstream component breaks for some 
> reason then I am left with half of the components updated in the maven repo 
> and half not.  That's not really what we want.
> 
> So ideally, we would run a build/test, make sure it all gets through 
> completely, then deploy the resulting artifacts.
> 
> -Jim
> 
> -Original Message-
> From: Brian E. Fox [mailto:bri...@reply.infinity.nu] 
> Sent: Wednesday, March 25, 2009 9:20 PM
> To: Maven Users List
> Subject: RE: How to perform a deploy only
> 
> This really isn't a supported use case. Deploy is a phase and by
> definition all earlier phases run before the one you've asked for. Why
> would you not want to build before you deploy?
> 
> -Original Message-
> From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] 
> Sent: Wednesday, March 25, 2009 10:17 PM
> To: 'users@maven.apache.org'
> Subject: How to perform a deploy only
> 
> Hello all,
> 
> I have several components all built from a top level pom.  This works
> great for accelerating users to be able to build a lot of stuff quickly
> but is giving me some fits when trying to deploy.  Up to this point I
> have been using deploy:deploy-file to get built components into our
> local repository after a full build is successful, but this is labor
> intensive.
> 
> I would like to be able to run some variation of "mvn deploy" from the
> top level.  I have figured out how to skip things using the FAQ here:
> 
> http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip
> 
> But I do NOT want it to do anything other than deploy.  I have googled
> for this but have not turned up anything useful.  I was surprised that
> the documentation does not suggest how to do this.  This is the correct
> deploy documentation I think.
> 
> http://maven.apache.org/plugins/maven-deploy-plugin/
> 
> Anyway, any help would be appreciated.
> 
> Thanks!
> 
> -Jim
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-- 
Mit freundlichen Grüßen,

Stefan Seidel
Software-Entwickler

VUB Printmedia GmbH
Chopinstraße 4, 04103 Leipzig
tel.+49 (341) 9 60 50 93
fax.+49 (341) 9 60 50 92
mail.   ssei...@vub.de 
web.www.vub.de

VUB Printmedia GmbH
HRB Köln 24015
GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf

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

[ANN] Apache Continuum 1.3.2 (Beta) Released

[Marica Tan]

The Apache Continuum team is pleased to announce the release of Apache
Continuum 1.3.2 (Beta).

Apache Continuum is an enterprise-ready continuous integration server
with features such as automated builds, release management, role-based
security, and integration with popular build tools and source control
management systems.

The latest release can be downloaded from:
http://continuum.apache.org/download.html

~ The Apache Continuum Team

Re: How to integrate xhtml files into a maven generated site?

[Lukas Theussl]

Where did you get the snapshot from? Are you using the new snapshot repo 
http://repository.apache.org/snapshots ? (not the old one at people.apache.org).


If that's not it please attach the full stack trace.

cheers,
-Lukas


feensturm wrote:

Ok, I mixed up with the answer from Marco Huber


Marco Huber wrote:


So I wait for maven 2.1 until I can add my documentation to the project
:-( 



But with the Snapshot I get the same exception:

Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site': Unable to
load the mojo 'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site'
in the plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class
is missing:
org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext
org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext

regards Pascal



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

RE: How to perform a deploy only

[Todd Thiessen]

Brian.

I think what Jim is asking for is very reasonable. You just did a full
install of your multi-module project to ensure they all pass and work as
you expect to avoid encoutering those errors when doing a deploy and
only having 1/2 your projects up on your nexus repo. This isn't as
important for cutting new releases, since there is the release plugin,
but for deploying snapshots it would be nice to ensure all projects pass
all tests before deploying any of them. So running a mvn install, then a
mvn deployOnly work flow I think is very reasonable.

---
Todd Thiessen
 

> -Original Message-
> From: Brian E. Fox [mailto:bri...@reply.infinity.nu] 
> Sent: Wednesday, March 25, 2009 10:20 PM
> To: Maven Users List
> Subject: RE: How to perform a deploy only
> 
> This really isn't a supported use case. Deploy is a phase and 
> by definition all earlier phases run before the one you've 
> asked for. Why would you not want to build before you deploy?
> 
> -Original Message-
> From: Jim McCaskey [mailto:jim.mccas...@pervasive.com]
> Sent: Wednesday, March 25, 2009 10:17 PM
> To: 'users@maven.apache.org'
> Subject: How to perform a deploy only
> 
> Hello all,
> 
> I have several components all built from a top level pom.  
> This works great for accelerating users to be able to build a 
> lot of stuff quickly but is giving me some fits when trying 
> to deploy.  Up to this point I have been using 
> deploy:deploy-file to get built components into our local 
> repository after a full build is successful, but this is 
> labor intensive.
> 
> I would like to be able to run some variation of "mvn deploy" 
> from the top level.  I have figured out how to skip things 
> using the FAQ here:
> 
> http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip
> 
> But I do NOT want it to do anything other than deploy.  I 
> have googled for this but have not turned up anything useful. 
>  I was surprised that the documentation does not suggest how 
> to do this.  This is the correct deploy documentation I think.
> 
> http://maven.apache.org/plugins/maven-deploy-plugin/
> 
> Anyway, any help would be appreciated.
> 
> Thanks!
> 
> -Jim
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

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

Re: How to integrate xhtml files into a maven generated site?

[Manos Batsis]

Sorry if this is out of context, haven't followed the thread. For now 
the best way AFAIK is to just add (X)HTML files in src/site/resources 
and link as appropriate.


hth,

Manos

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

ejb manifest -- strip version numbers of dependencies

[Michael Hüttermann]

Hello,

I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
..  the message is "Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1". How can I cut off the
version numbers? Thank you !!



org.apache.maven.plugins
maven-ejb-plugin

  2.1
  false
  

true
custom
${artifact.artifactId}

  

  



Michael

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

RE: How to perform a deploy only

[Jim McCaskey]

Stephen,

Ah, this sounds like a very promising work around.  I was unaware of the 
maven-stage-plugin.  Short of a method to do it with deploy directly this may 
work.

Thanks for the suggestion!

-Jim

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Thursday, March 26, 2009 1:13 AM
To: Maven Users List
Subject: Re: How to perform a deploy only

Well you could stage them yourself

You need a staging repository... I see no reason why this cannot be file
based

You then need to do some scripting and use the maven-stage-plugin (
http://maven.apache.org/plugins/maven-stage-plugin/index.html) to copy the
contents of the staging repository to the real repository.

I normally have the distribution repository defined by a property in
settings.xml... so that you can just run

mvn deploy -Ddistribution.url=file:///staging-repo

and then run an ant script that does the mvn stage:copy for you

-Stephen

2009/3/26 Jim McCaskey 

> Thanks for the suggestion.  I have been trying to avoid using repository
> managers for a number of reasons that are beyond the scope of this thread.
>  I may have to break down eventually...
>
> I'm surprised no one has needed this sort of feature, or maybe they have
> and that's why Nexus has the features that it does.  I was hoping to find a
> Maven native (whatever native means in a highly pluggable architecture) way
> to do this that would not take much additional work.
>
> mvn -DdoNothingButDeploy=true deploy
>
> That would be about perfect.  :)
>
> Would this even be consider for an enhancement request if I opened it?
>  Perhaps I am the only one interested in such a thing.
>
> Thanks!
>
> -Jim
>
> -Original Message-
> From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com]
> Sent: Wednesday, March 25, 2009 9:55 PM
> To: Maven Users List
> Subject: RE: How to perform a deploy only
>
> Brian can pitch his own stuff far better than I can, but this kind of
> transactional deployment can be done with Nexus' Staging feature.
>
> I realized after I sent my deploy:deploy suggestion that it probably
> wouldn't work without running at least the package phase, sorry to give you
> bad info. I'm reasonably confident with some light hacking you could write a
> plugin that essentially faked the build, but if the below is your use case
> and you can afford Nexus Pro, it's probably a better solution.
>
> Justin
>
>
> 
>
> From: Jim McCaskey [mailto:jim.mccas...@pervasive.com]
> Sent: Wed 3/25/2009 10:37 PM
> To: 'Maven Users List'
> Subject: RE: How to perform a deploy only
>
>
>
> I have a whole bunch of components that are mostly interrelated but
> consumable individually by downstream builds.  If I run deploy it basically
> starts deploying as it goes, so if a downstream component breaks for some
> reason then I am left with half of the components updated in the maven repo
> and half not.  That's not really what we want.
>
> So ideally, we would run a build/test, make sure it all gets through
> completely, then deploy the resulting artifacts.
>
> -Jim
>
> -Original Message-
> From: Brian E. Fox [mailto:bri...@reply.infinity.nu]
> Sent: Wednesday, March 25, 2009 9:20 PM
> To: Maven Users List
> Subject: RE: How to perform a deploy only
>
> This really isn't a supported use case. Deploy is a phase and by
> definition all earlier phases run before the one you've asked for. Why
> would you not want to build before you deploy?
>
> -Original Message-
> From: Jim McCaskey [mailto:jim.mccas...@pervasive.com]
> Sent: Wednesday, March 25, 2009 10:17 PM
> To: 'users@maven.apache.org'
> Subject: How to perform a deploy only
>
> Hello all,
>
> I have several components all built from a top level pom.  This works
> great for accelerating users to be able to build a lot of stuff quickly
> but is giving me some fits when trying to deploy.  Up to this point I
> have been using deploy:deploy-file to get built components into our
> local repository after a full build is successful, but this is labor
> intensive.
>
> I would like to be able to run some variation of "mvn deploy" from the
> top level.  I have figured out how to skip things using the FAQ here:
>
> http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip
>
> But I do NOT want it to do anything other than deploy.  I have googled
> for this but have not turned up anything useful.  I was surprised that
> the documentation does not suggest how to do this.  This is the correct
> deploy documentation I think.
>
> http://maven.apache.org/plugins/maven-deploy-plugin/
>
> Anyway, any help would be appreciated.
>
> Thanks!
>
> -Jim
>
>
> -
> 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..

Re: hibernate byte code instrumentation

[fachhoch]

I did not understand this, please explain  what should I change  in pom to do
this ?


here is my jetty maven plugin
  
org.mortbay.jetty
maven-jetty-plugin
6.1.12.rc4

   

  commons-logging
  commons-logging
  1.0.4
  jar


  log4j
  log4j
  1.2.14
  jar

   

  

here is my maven ant run plugin

  
maven-antrun-plugin
1.3

  

  


  


  

  

  

  

please tell me what should I do to my pom  to acheieve what you said .


Stephen Connolly-2 wrote:
> 
> attach the execution to the process-classes phase
> 
> 2009/3/26 fachhoch 
> 
>>
>> I am using maven-ant-run plugin to call  hibernate byte code
>> insturmentation
>> , i also have maven jetty plugin , every  time i run jetty plugin   first
>> all modified java files  gets complied and then test cases and finally
>> deployed , but this ant-run plugin  for hibernate byte code
>> instrumentation
>> does not get called , please tell me   how to call hibernate byte code
>> automatically ?
>> --
>> View this message in context:
>> http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22714675.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
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22722678.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

multi-module pom: "do something after build"?

[Kristian Rink]

Folks;

maybe a strange question: At the moment I am dealing with a project
containing several 's to be built, including a couple of
.jar and a couple of .war artifacts. In order to have the .war artifacts
(.war) deployable to an application server, I want to configure
my project to, after everything has been built, have all these .war files
($project/target/.war) copied to an arbitrary folder somewhere in
my file system (say, an "autodeploy" one).

Is there a straightforward way getting this done?
TIA and all the best,
Kristian


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

Re: [Vote] findbugs-maven-plugin v 2.0 release

[TM]

-1

Background: According to http://jira.codehaus.org/browse/MFINDBUGS-66, the
plugin integrates Findbugs version 1.3.6. Meanwhile, version 1.3.8 was
released. I suggest to catch up with that release before releasing the
plugin.

-- Thorsten







Garvin LeClaire-2 wrote:
> 
> The Maven Findbugs team would like to release Maven Findbugs Plugin 
> version 2.0
> 
> This plugin allows the developer to run Findbugs analysis against a 
> Maven project and produce site output in HTML to match other site 
> reports.  There are option to produce other XML outputs which are used 
> by other plugins.
> 
> Issues fixed in this release:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&fixfor=14335&pid=11701&status=6&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC
> 
> 
> More information can be found at the plugin site:
> http://mojo.codehaus.org/findbugs-maven-plugin/
> 
> 
> Issues Can be registered in JIRA at:
> http://jira.codehaus.org/browse/MFINDBUGS
> 
> 
> More information on FindBugs
> http://findbugs.sourceforge.net/index.html
> 
> 
> 
> You can test the Maven Findbugs Plugin in your own project by adding the 
> following dependency:
> 
> 
> org.codehaus.mojo
> findbugs-maven-plugin
> 2.0-SNAPSHOT
> 
> 
> 
> 
> *NOTE*  Version 2.0 and greater of the Maven Findbugs plugin will 
> require Maven to be run with a minimum of Java 5.  This is consistent 
> with Findbugs requirement for their versions of 1.3.X and greater.
> 
> 
> 
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -- 
> 
> Regards,
> 
> 
> 
> Garvin LeClaire
> garvin.lecla...@gmail.com
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-Vote--findbugs-maven-plugin-v-2.0--release-tp22715803p22723449.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: How to integrate xhtml files into a maven generated site?

[Lukas Theussl]

This will just copy the xhtml file as a resource, so you can link it statically. 
With Doxia 1.1 you can have the xhtml source file processed by the site renderer, 
so it gets really integrated in the site, with navigation, menus, etc.


-Lukas


Manos Batsis wrote:


Sorry if this is out of context, haven't followed the thread. For now 
the best way AFAIK is to just add (X)HTML files in src/site/resources 
and link as appropriate.


hth,

Manos

-
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 Stage Plugin issue

[Jim McCaskey]

Hello all,

I am attempting to use the Maven stage plugin and running into a break.  I have 
tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using 
the only stage plugin available which appears to be 1.0-alpha-1.  My guess is 
I'm doing something wrong, but for the life of me I can't see what.

Here is the command I am executing (I'm on windows FWIW):

mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 
-Dversion=9.2.0-16 stage:copy

Here is the error:

[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] org.apache.maven.wagon.providers.file.FileWagon
[INFO] 
[INFO] Trace
java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon
at 
org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
at 
org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)

I found this bug in Jira that is somewhat similar but is marked as closed/fixed:

http://jira.codehaus.org/browse/MNG-3581

I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists.

According to this bug:

http://jira.codehaus.org/browse/MSTAGE-3

Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly 
probably because I don't know where to look.

Was this tool not intended to be used on a local file systems?

Thanks!

-Jim



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

Re: Test built jar

[Wayne Fay]

> If it doesn't make sense, what can I do (other than : created a project
> having a dependency on the to-be-tested project...)

This sounds like the most sane and "standard" solution to the problem,
given what you've said above. Or you could try binding an execution of
m-jar-p to a phase earlier than package and before test, and then
monkey with the Surefire parameters to it tests the jar instead of
target/classes. But this sounds very non-standard and I'm not positive
it would even work.

Wayne

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

RE: multi-module pom: "do something after build"?

[Will Hoover]

http://maven.apache.org/plugins/maven-invoker-plugin/examples/post-build-scr
ipt.html 

-Original Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Kristian Rink
Sent: Thursday, March 26, 2009 10:38 AM
To: users@maven.apache.org
Subject: multi-module pom: "do something after build"?

Folks;

maybe a strange question: At the moment I am dealing with a project
containing several 's to be built, including a couple of
.jar and a couple of .war artifacts. In order to have the .war artifacts
(.war) deployable to an application server, I want to configure
my project to, after everything has been built, have all these .war files
($project/target/.war) copied to an arbitrary folder somewhere in
my file system (say, an "autodeploy" one).

Is there a straightforward way getting this done?
TIA and all the best,
Kristian


-
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: Possible problem when multiple developers depend on SNAPSHOT versions

[Trevor Harmon]

On Mar 25, 2009, at 10:26 PM, Martin Gainty wrote:


The only way to accomplish this is called version control


I thought it was clear in the first paragraph that version control is  
involved:


"They have both checked out Foo's trunk and are regularly committing  
changes to it."


There are several other indications as well, such as the description  
of Alice tagging the code base and Bob updating his working copy.


To be absolutely clear, Alice and Bob are both using version control.  
All code, including AppA, AppB, and Foo are managed in a source code  
repository.


But I don't think this improves the situation in any way. As Ben  
noted, the scenario shows version control working as designed.



but since you do not want to use version control ..


Why do you think this?

Trevor


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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Trevor Harmon]

On Mar 25, 2009, at 3:26 PM, Martin Gainty wrote:

someone is assigned mainline of code and someone-else assigned a  
branch

(this happens when core is heavily customised for a customer's needs
where the user-specific mods will be integrated by merge-branch  
later on)


This does not solve Bob's problem. Assume that Bob is working on a  
branch of Foo. At some point he will A) merge the trunk's changes into  
his branch, or B) merge the branch into the trunk and then switch to  
the trunk. If this happens after Alice increments Foo's trunk to 2.2- 
SNAPSHOT, the problem will occur.


Trevor


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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Trevor Harmon]

On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote:

Bob should work on a branch. IMHO if any work is taking a long time  
and
you can't commit it to trunk in a timely manner, then do that work  
on a
branch so you can commit often and still take specific control over  
when

Alice's changes get merged to Bob's branch so he can test the merge
thoroughly before putting his changes in trunk.


This does not solve Bob's problem. Let's say he's committing to his  
branch, and then at some point he merges Alice's changes to the trunk  
into his branch. He then performs thorough testing of this new code  
and encounters no problems. But of course he won't have any problems  
testing the new Foo 2.2-SNAPSHOT because AppB is still still using the  
old code from Foo 2.1-SNAPSHOT. Until he realizes that Foo's version  
has changed, and he updates AppB accordingly, branching, merging, and  
testing won't help him.


Trevor


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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Trevor Harmon]

On Mar 25, 2009, at 5:28 PM, Brian E. Fox wrote:


Do we assume that bob is unable to see that the version he currently
works on and compiles, tests, installs and maybe deploys has
2.2-snapshot written all over it?


Yes. Maven generates a lot of output to the console, and it's easy to  
ignore all the text that scrolls by. Even if the output were minimal,  
Bob is updating and rebuilding his working copy of Foo several times a  
day. He's not in the habit of examining the build output closely, at  
least not when the build succeeds, as in this scenario. Sure, he might  
notice the version change eventually, but perhaps not before he wastes  
a couple of hours debugging the problem.


Also, consider that Foo may not be the only shared library that Bob's  
AppB depends on. There could be Bar, Bat, Baz, Xyzzy, and Thud as  
well. These libraries might be under active development too, and their  
versions may change periodically. With all these version numbers  
floating around, even if Bob notices that Foo is 2.2-SNAPSHOT today,  
he might have simply forgotten that it was 2.1-SNAPSHOT yesterday.


Trevor


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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Trevor Harmon]

On Mar 25, 2009, at 5:07 PM, Sean Hennessy wrote:

Evidence to the contrary that Bob and Alice are working  
independently is they share development on single artifact Foo.


They're working independently on AppA and AppB, but they're sharing  
the work of developing Foo.


Ensure Alice and Bob communicate daily on the development plan,  
schedule and status.


Yes, that is true. Alice should have told Bob that she released Foo  
2.1, and that development on the trunk is now at version 2.2-SNAPSHOT,  
and that Bob should update his AppB to depend on this new version.  
That would have definitely solved Bob's problem.


But the side-effect is that whenever there's a new release of a  
dependency, emails must be sent and POM files must be updated. For  
Alice's and Bob's simple scenario, that's not a big deal. But consider  
a real-world scenario with many developers and perhaps dozens of  
interwoven dependencies. The stream of new releases causes a flurry of  
communication and lots of POM editing, especially if the development  
teams are following a "release early, release often" kind of strategy.  
The overhead is not scalable, especially in the face of human error.  
(An email could be forgotten, or a POM file could be updated with the  
wrong version number.)


In fact, all this overhead encourages developers to *avoid* releasing  
new versions of dependencies. They want to work with X-SNAPSHOT for as  
long as possible simply to avoid the extra work of putting out a new  
version, even if it's just an internal release.  (This is precisely  
the problem we're facing in my team and is what prompted the original  
post.) Of course, staying with a SNAPSHOT release for extended periods  
complicates regression testing and other quality assurance tasks.


Trevor


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

Getting Assembly and Jar signer plugins to work together well

[Peter Aarestad]

I'm trying to build a simple WebStart jar for deployment, and I've  
found that the Assembly plugin's capability of building an uber-jar  
with dependencies will work fine for our needs. I need to sign it  
since the app requires all permissions, but I'm having a little  
trouble getting the jar signer to work the way I want it to. It is  
signing the initial application code's jar before it is handled by  
Assembly to create the jar-with-dependencies jar. What I want it to do  
is wait until the assembly plugin assembles the big jar, and then sign  
that instead. Any suggestions on how I would go about doing that?


-peter

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

RE: Possible problem when multiple developers depend on SNAPSHOT versions

[Todd Thiessen]

I don't think so. When Bob merges the trunk to branch he will have both
Alice's changes and his.  When he does an install, the 2.2-SNAPSHOT
version will contain both his and Alices changes for all modules.

---
Todd Thiessen
 

> -Original Message-
> From: Trevor Harmon [mailto:tre...@vocaro.com] 
> Sent: Thursday, March 26, 2009 12:39 PM
> To: Maven Users List
> Subject: Re: Possible problem when multiple developers depend 
> on SNAPSHOT versions
> 
> On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote:
> 
> > Bob should work on a branch. IMHO if any work is taking a long time 
> > and you can't commit it to trunk in a timely manner, then 
> do that work 
> > on a branch so you can commit often and still take specific control 
> > over when Alice's changes get merged to Bob's branch so he can test 
> > the merge thoroughly before putting his changes in trunk.
> 
> This does not solve Bob's problem. Let's say he's committing 
> to his branch, and then at some point he merges Alice's 
> changes to the trunk into his branch. He then performs 
> thorough testing of this new code and encounters no problems. 
> But of course he won't have any problems testing the new Foo 
> 2.2-SNAPSHOT because AppB is still still using the old code 
> from Foo 2.1-SNAPSHOT. Until he realizes that Foo's version 
> has changed, and he updates AppB accordingly, branching, 
> merging, and testing won't help him.
> 
> Trevor
> 
> 
> -
> 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 Stage Plugin issue

[Dan Tran]

try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
It has a port of maven-stage-plugin with lots of fixes.

-D

On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
 wrote:
> Hello all,
>
> I am attempting to use the Maven stage plugin and running into a break.  I 
> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also 
> using the only stage plugin available which appears to be 1.0-alpha-1.  My 
> guess is I'm doing something wrong, but for the life of me I can't see what.
>
> Here is the command I am executing (I'm on windows FWIW):
>
> mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 
> -Dversion=9.2.0-16 stage:copy
>
> Here is the error:
>
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org.apache.maven.wagon.providers.file.FileWagon
> [INFO] 
> 
> [INFO] Trace
> java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon
>        at 
> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
>        at 
> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
>        at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>        at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
>        at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
>
> I found this bug in Jira that is somewhat similar but is marked as 
> closed/fixed:
>
> http://jira.codehaus.org/browse/MNG-3581
>
> I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists.
>
> According to this bug:
>
> http://jira.codehaus.org/browse/MSTAGE-3
>
> Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly 
> probably because I don't know where to look.
>
> Was this tool not intended to be used on a local file systems?
>
> Thanks!
>
> -Jim
>
>
>
> -
> 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: Possible problem when multiple developers depend on SNAPSHOT versions

[Todd Thiessen]

Yes he does need to know that the release has changed. This is something
you would need to be aware of when you do the merge.

---
Todd Thiessen
 

> -Original Message-
> From: Thiessen, Todd (BVW:9T16) 
> Sent: Thursday, March 26, 2009 12:53 PM
> To: Maven Users List
> Subject: RE: Possible problem when multiple developers depend 
> on SNAPSHOT versions
> 
> I don't think so. When Bob merges the trunk to branch he will 
> have both Alice's changes and his.  When he does an install, 
> the 2.2-SNAPSHOT version will contain both his and Alices 
> changes for all modules.
> 
> ---
> Todd Thiessen
>  
> 
> > -Original Message-
> > From: Trevor Harmon [mailto:tre...@vocaro.com]
> > Sent: Thursday, March 26, 2009 12:39 PM
> > To: Maven Users List
> > Subject: Re: Possible problem when multiple developers depend on 
> > SNAPSHOT versions
> > 
> > On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote:
> > 
> > > Bob should work on a branch. IMHO if any work is taking a 
> long time 
> > > and you can't commit it to trunk in a timely manner, then
> > do that work
> > > on a branch so you can commit often and still take 
> specific control 
> > > over when Alice's changes get merged to Bob's branch so 
> he can test 
> > > the merge thoroughly before putting his changes in trunk.
> > 
> > This does not solve Bob's problem. Let's say he's committing to his 
> > branch, and then at some point he merges Alice's changes to 
> the trunk 
> > into his branch. He then performs thorough testing of this new code 
> > and encounters no problems.
> > But of course he won't have any problems testing the new Foo 
> > 2.2-SNAPSHOT because AppB is still still using the old code 
> from Foo 
> > 2.1-SNAPSHOT. Until he realizes that Foo's version has 
> changed, and he 
> > updates AppB accordingly, branching, merging, and testing 
> won't help 
> > him.
> > 
> > Trevor
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

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

Re: hibernate byte code instrumentation

[Rusty Wright]

Try this:

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html


fachhoch wrote:

I did not understand this, please explain  what should I change  in pom to do
this ?


here is my jetty maven plugin
  
org.mortbay.jetty
maven-jetty-plugin
6.1.12.rc4

   

  commons-logging
  commons-logging
  1.0.4
  jar


  log4j
  log4j
  1.2.14
  jar

   

  

here is my maven ant run plugin

  
maven-antrun-plugin
1.3

  

  


  


  

  

  

  

please tell me what should I do to my pom  to acheieve what you said .


Stephen Connolly-2 wrote:

attach the execution to the process-classes phase

2009/3/26 fachhoch 


I am using maven-ant-run plugin to call  hibernate byte code
insturmentation
, i also have maven jetty plugin , every  time i run jetty plugin   first
all modified java files  gets complied and then test cases and finally
deployed , but this ant-run plugin  for hibernate byte code
instrumentation
does not get called , please tell me   how to call hibernate byte code
automatically ?
--
View this message in context:
http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22714675.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








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

RE: Maven Stage Plugin issue

[Jim McCaskey]

Hi Dan,

Thanks a lot for the response.  I took a look at it and it definitely seems 
more full featured than the staging plugin, but I'm still having trouble with 
it.  If I formulate a command like this:

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://E:\dir\staging-repo 
-Dwagon.target=file://E:\dir\staging-repo1

I get this error:

[ERROR] BUILD ERROR
[INFO] 
[INFO] Error during performing repository copy

Embedded error: The filename, directory name, or volume label syntax is 
incorrect

Did I miss understand the input parameters?

I'm assuming that you are referring to this version of wagon-maven-plugin.

http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1

I found what appears to be an older Apache MyFaces project by the same 
artifactId.

-Jim

-Original Message-
From: Dan Tran [mailto:dant...@gmail.com] 
Sent: Thursday, March 26, 2009 11:54 AM
To: Maven Users List
Subject: Re: Maven Stage Plugin issue

try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
It has a port of maven-stage-plugin with lots of fixes.

-D

On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
 wrote:
> Hello all,
>
> I am attempting to use the Maven stage plugin and running into a break.  I 
> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also 
> using the only stage plugin available which appears to be 1.0-alpha-1.  My 
> guess is I'm doing something wrong, but for the life of me I can't see what.
>
> Here is the command I am executing (I'm on windows FWIW):
>
> mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 
> -Dversion=9.2.0-16 stage:copy
>
> Here is the error:
>
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org.apache.maven.wagon.providers.file.FileWagon
> [INFO] 
> 
> [INFO] Trace
> java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon
>        at 
> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
>        at 
> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
>        at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>        at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
>        at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
>
> I found this bug in Jira that is somewhat similar but is marked as 
> closed/fixed:
>
> http://jira.codehaus.org/browse/MNG-3581
>
> I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists.
>
> According to this bug:
>
> http://jira.codehaus.org/browse/MSTAGE-3
>
> Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly 
> probably because I don't know where to look.
>
> Was this tool not intended to be used on a local file systems?
>
> Thanks!
>
> -Jim
>
>
>
> -
> 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 Stage Plugin issue

[Dan Tran]

try file:///e:/dir/staging-repo

-D

On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey
 wrote:
> Hi Dan,
>
> Thanks a lot for the response.  I took a look at it and it definitely seems 
> more full featured than the staging plugin, but I'm still having trouble with 
> it.  If I formulate a command like this:
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://E:\dir\staging-repo 
> -Dwagon.target=file://E:\dir\staging-repo1
>
> I get this error:
>
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error during performing repository copy
>
> Embedded error: The filename, directory name, or volume label syntax is 
> incorrect
>
> Did I miss understand the input parameters?
>
> I'm assuming that you are referring to this version of wagon-maven-plugin.
>
> http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
> http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1
>
> I found what appears to be an older Apache MyFaces project by the same 
> artifactId.
>
> -Jim
>
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Thursday, March 26, 2009 11:54 AM
> To: Maven Users List
> Subject: Re: Maven Stage Plugin issue
>
> try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
> It has a port of maven-stage-plugin with lots of fixes.
>
> -D
>
> On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
>  wrote:
>> Hello all,
>>
>> I am attempting to use the Maven stage plugin and running into a break.  I 
>> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also 
>> using the only stage plugin available which appears to be 1.0-alpha-1.  My 
>> guess is I'm doing something wrong, but for the life of me I can't see what.
>>
>> Here is the command I am executing (I'm on windows FWIW):
>>
>> mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 
>> -Dversion=9.2.0-16 stage:copy
>>
>> Here is the error:
>>
>> [INFO] 
>> 
>> [ERROR] FATAL ERROR
>> [INFO] 
>> 
>> [INFO] org.apache.maven.wagon.providers.file.FileWagon
>> [INFO] 
>> 
>> [INFO] Trace
>> java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon
>>        at 
>> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
>>        at 
>> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
>>        at 
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>>        at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
>>        at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
>>
>> I found this bug in Jira that is somewhat similar but is marked as 
>> closed/fixed:
>>
>> http://jira.codehaus.org/browse/MNG-3581
>>
>> I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists.
>>
>> According to this bug:
>>
>> http://jira.codehaus.org/browse/MSTAGE-3
>>
>> Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly 
>> probably because I don't know where to look.
>>
>> Was this tool not intended to be used on a local file systems?
>>
>> Thanks!
>>
>> -Jim
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>

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

Re: Maven Stage Plugin issue

[Dan Tran]

yes myface has this plugin too to serve what they need

On Thu, Mar 26, 2009 at 11:31 AM, Dan Tran  wrote:
> try file:///e:/dir/staging-repo
>
> -D
>
> On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey
>  wrote:
>> Hi Dan,
>>
>> Thanks a lot for the response.  I took a look at it and it definitely seems 
>> more full featured than the staging plugin, but I'm still having trouble 
>> with it.  If I formulate a command like this:
>>
>> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
>> -Dwagon.source=file://E:\dir\staging-repo 
>> -Dwagon.target=file://E:\dir\staging-repo1
>>
>> I get this error:
>>
>> [ERROR] BUILD ERROR
>> [INFO] 
>> 
>> [INFO] Error during performing repository copy
>>
>> Embedded error: The filename, directory name, or volume label syntax is 
>> incorrect
>>
>> Did I miss understand the input parameters?
>>
>> I'm assuming that you are referring to this version of wagon-maven-plugin.
>>
>> http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
>> http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1
>>
>> I found what appears to be an older Apache MyFaces project by the same 
>> artifactId.
>>
>> -Jim
>>
>> -Original Message-
>> From: Dan Tran [mailto:dant...@gmail.com]
>> Sent: Thursday, March 26, 2009 11:54 AM
>> To: Maven Users List
>> Subject: Re: Maven Stage Plugin issue
>>
>> try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
>> It has a port of maven-stage-plugin with lots of fixes.
>>
>> -D
>>
>> On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
>>  wrote:
>>> Hello all,
>>>
>>> I am attempting to use the Maven stage plugin and running into a break.  I 
>>> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm 
>>> also using the only stage plugin available which appears to be 1.0-alpha-1. 
>>>  My guess is I'm doing something wrong, but for the life of me I can't see 
>>> what.
>>>
>>> Here is the command I am executing (I'm on windows FWIW):
>>>
>>> mvn -Dsource=file://E:\dir\staging-repo 
>>> -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy
>>>
>>> Here is the error:
>>>
>>> [INFO] 
>>> 
>>> [ERROR] FATAL ERROR
>>> [INFO] 
>>> 
>>> [INFO] org.apache.maven.wagon.providers.file.FileWagon
>>> [INFO] 
>>> 
>>> [INFO] Trace
>>> java.lang.ClassCastException: 
>>> org.apache.maven.wagon.providers.file.FileWagon
>>>        at 
>>> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
>>>        at 
>>> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
>>>        at 
>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>>>        at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
>>>        at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
>>>
>>> I found this bug in Jira that is somewhat similar but is marked as 
>>> closed/fixed:
>>>
>>> http://jira.codehaus.org/browse/MNG-3581
>>>
>>> I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists.
>>>
>>> According to this bug:
>>>
>>> http://jira.codehaus.org/browse/MSTAGE-3
>>>
>>> Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly 
>>> probably because I don't know where to look.
>>>
>>> Was this tool not intended to be used on a local file systems?
>>>
>>> Thanks!
>>>
>>> -Jim
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>

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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[Trevor Harmon]

On Mar 26, 2009, at 12:52 PM, Todd Thiessen wrote:

I don't think so. When Bob merges the trunk to branch he will have  
both

Alice's changes and his.  When he does an install, the 2.2-SNAPSHOT
version will contain both his and Alices changes for all modules.


Yes, but AppB will still reference Foo 2.1-SNAPSHOT. Therein lies the  
problem.


Trevor


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

RE: Maven Stage Plugin issue

[Jim McCaskey]

Hi Dan,

Thanks again for the response.  I tried a few variations on that theme:

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file:///e:/dir/staging-repo 
-Dwagon.target=file:///e:/dir/staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:/dir/staging-repo 
-Dwagon.target=file://e:/dir/staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file:///e:\\dir\\staging-repo 
-Dwagon.target=file:///e:\\dir\\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:\\dir\\staging-repo 
-Dwagon.target=file://e:\\dir\\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file:///e:\dir\staging-repo 
-Dwagon.target=file:///e:\dir\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:\dir\staging-repo 
-Dwagon.target=file://e:\dir\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://./staging-repo -Dwagon.target=file://./staging-repo1


They all give me the same error message:

[ERROR] BUILD ERROR
[INFO] 
[INFO] Error during performing repository copy

Embedded error: The filename, directory name, or volume label syntax is 
incorrect

-Jim

-Original Message-
From: Dan Tran [mailto:dant...@gmail.com] 
Sent: Thursday, March 26, 2009 1:32 PM
To: Maven Users List
Subject: Re: Maven Stage Plugin issue

try file:///e:/dir/staging-repo

-D

On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey
 wrote:
> Hi Dan,
>
> Thanks a lot for the response.  I took a look at it and it definitely seems 
> more full featured than the staging plugin, but I'm still having trouble with 
> it.  If I formulate a command like this:
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://E:\dir\staging-repo 
> -Dwagon.target=file://E:\dir\staging-repo1
>
> I get this error:
>
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error during performing repository copy
>
> Embedded error: The filename, directory name, or volume label syntax is 
> incorrect
>
> Did I miss understand the input parameters?
>
> I'm assuming that you are referring to this version of wagon-maven-plugin.
>
> http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
> http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1
>
> I found what appears to be an older Apache MyFaces project by the same 
> artifactId.
>
> -Jim
>
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Thursday, March 26, 2009 11:54 AM
> To: Maven Users List
> Subject: Re: Maven Stage Plugin issue
>
> try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
> It has a port of maven-stage-plugin with lots of fixes.
>
> -D
>
> On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
>  wrote:
>> Hello all,
>>
>> I am attempting to use the Maven stage plugin and running into a break.  I 
>> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also 
>> using the only stage plugin available which appears to be 1.0-alpha-1.  My 
>> guess is I'm doing something wrong, but for the life of me I can't see what.
>>
>> Here is the command I am executing (I'm on windows FWIW):
>>
>> mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 
>> -Dversion=9.2.0-16 stage:copy
>>
>> Here is the error:
>>
>> [INFO] 
>> 
>> [ERROR] FATAL ERROR
>> [INFO] 
>> 
>> [INFO] org.apache.maven.wagon.providers.file.FileWagon
>> [INFO] 
>> 
>> [INFO] Trace
>> java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon
>>        at 
>> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
>>        at 
>> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
>>        at 
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>>        at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
>>        at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
>>
>> I found this bug in Jira that is somewhat similar but is marked as 
>> closed/fixed:
>>
>> http://jira.codehaus.org/browse/MNG-3581
>>
>> I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists.
>>
>> According to this bug:
>>
>> http://jira.codehaus.org/browse/MSTAGE-3
>>
>> Some fix

RE: Maven Stage Plugin issue

[Jim McCaskey]

All,

I finally got it.  I was missing the temp directory -Djava.io.tmpdir=target.  

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:\dir\staging-repo 
-Dwagon.target=file://e:\dir\staging-repo1  -Djava.io.tmpdir=target

Needing that is not listed here:

http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html

But it is in the usage example here:

http://mojo.codehaus.org/wagon-maven-plugin/usage.html

Thanks for all the help!

-Jim

-Original Message-
From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] 
Sent: Thursday, March 26, 2009 1:49 PM
To: 'Maven Users List'
Subject: RE: Maven Stage Plugin issue

Hi Dan,

Thanks again for the response.  I tried a few variations on that theme:

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file:///e:/dir/staging-repo 
-Dwagon.target=file:///e:/dir/staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:/dir/staging-repo 
-Dwagon.target=file://e:/dir/staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file:///e:\\dir\\staging-repo 
-Dwagon.target=file:///e:\\dir\\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:\\dir\\staging-repo 
-Dwagon.target=file://e:\\dir\\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file:///e:\dir\staging-repo 
-Dwagon.target=file:///e:\dir\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://e:\dir\staging-repo 
-Dwagon.target=file://e:\dir\staging-repo1

mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
-Dwagon.source=file://./staging-repo -Dwagon.target=file://./staging-repo1


They all give me the same error message:

[ERROR] BUILD ERROR
[INFO] 
[INFO] Error during performing repository copy

Embedded error: The filename, directory name, or volume label syntax is 
incorrect

-Jim

-Original Message-
From: Dan Tran [mailto:dant...@gmail.com] 
Sent: Thursday, March 26, 2009 1:32 PM
To: Maven Users List
Subject: Re: Maven Stage Plugin issue

try file:///e:/dir/staging-repo

-D

On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey
 wrote:
> Hi Dan,
>
> Thanks a lot for the response.  I took a look at it and it definitely seems 
> more full featured than the staging plugin, but I'm still having trouble with 
> it.  If I formulate a command like this:
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://E:\dir\staging-repo 
> -Dwagon.target=file://E:\dir\staging-repo1
>
> I get this error:
>
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error during performing repository copy
>
> Embedded error: The filename, directory name, or volume label syntax is 
> incorrect
>
> Did I miss understand the input parameters?
>
> I'm assuming that you are referring to this version of wagon-maven-plugin.
>
> http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
> http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1
>
> I found what appears to be an older Apache MyFaces project by the same 
> artifactId.
>
> -Jim
>
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Thursday, March 26, 2009 11:54 AM
> To: Maven Users List
> Subject: Re: Maven Stage Plugin issue
>
> try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
> It has a port of maven-stage-plugin with lots of fixes.
>
> -D
>
> On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
>  wrote:
>> Hello all,
>>
>> I am attempting to use the Maven stage plugin and running into a break.  I 
>> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also 
>> using the only stage plugin available which appears to be 1.0-alpha-1.  My 
>> guess is I'm doing something wrong, but for the life of me I can't see what.
>>
>> Here is the command I am executing (I'm on windows FWIW):
>>
>> mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 
>> -Dversion=9.2.0-16 stage:copy
>>
>> Here is the error:
>>
>> [INFO] 
>> 
>> [ERROR] FATAL ERROR
>> [INFO] 
>> 
>> [INFO] org.apache.maven.wagon.providers.file.FileWagon
>> [INFO] 
>> 
>> [INFO] Trace
>> java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon
>>        at 
>> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
>>        at 
>> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(C

Maven release plugin issue- Error code 401

[huser]

Hi,

I am running maven perform and get the following error.

I am the Nexus Administrator and I have commented out  in
settings.xml in my local repo. What could be wrong here ? I want to use the
release plugin only for deployments.

[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Error deploying artifact: Failed to transfer file:
http://fpsvn00
1.na.coglobal.com:8081/nexus/content/repositories/releases/com/co/maven/co-m
aven/1.0/co-maven-1.0.pom. Return code is: 401

Thanks,
-- 
View this message in context: 
http://www.nabble.com/Maven-release-plugin-issue--Error-code-401-tp22729480p22729480.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: Possible problem when multiple developers depend on SNAPSHOT versions

[Todd Thiessen]

> 
> Yes, but AppB will still reference Foo 2.1-SNAPSHOT. Therein 
> lies the problem.
> 
> Trevor

I guess I don't see that as a problem. Bob wants to merge in the latest
version from trunk. If the version has been upped since Bob made his
branch, he would need to know that. That is just the nature of versions.
Its kind of like saying you want to use the latest version of log4j, get
that version into your local repository but then forget to reference it
in your pom.

He could always get the latest version by not specifying any version but
again this is usually frowned upon since it kind of negates all the
benefits of having versions in the first place ;-).

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

Re: Maven release plugin issue- Error code 401

[Wayne Fay]

>        [INFO] Error deploying artifact: Failed to transfer file:
> http://fpsvn00
> 1.na.coglobal.com:8081/nexus/content/repositories/releases/com/co/maven/co-m
> aven/1.0/co-maven-1.0.pom. Return code is: 401

HTTP Error 401 is... Unauthorized, right? Solve that, and deploy will
proceed. Check filesystem permissions etc.

Wayne

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

Re: Maven Stage Plugin issue

[Dan Tran]

glad it works out for you

-Dan


On Thu, Mar 26, 2009 at 12:16 PM, Jim McCaskey
 wrote:
> All,
>
> I finally got it.  I was missing the temp directory -Djava.io.tmpdir=target.
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://e:\dir\staging-repo 
> -Dwagon.target=file://e:\dir\staging-repo1  -Djava.io.tmpdir=target
>
> Needing that is not listed here:
>
> http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
>
> But it is in the usage example here:
>
> http://mojo.codehaus.org/wagon-maven-plugin/usage.html
>
> Thanks for all the help!
>
> -Jim
>
> -Original Message-
> From: Jim McCaskey [mailto:jim.mccas...@pervasive.com]
> Sent: Thursday, March 26, 2009 1:49 PM
> To: 'Maven Users List'
> Subject: RE: Maven Stage Plugin issue
>
> Hi Dan,
>
> Thanks again for the response.  I tried a few variations on that theme:
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file:///e:/dir/staging-repo 
> -Dwagon.target=file:///e:/dir/staging-repo1
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://e:/dir/staging-repo 
> -Dwagon.target=file://e:/dir/staging-repo1
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file:///e:\\dir\\staging-repo 
> -Dwagon.target=file:///e:\\dir\\staging-repo1
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://e:\\dir\\staging-repo 
> -Dwagon.target=file://e:\\dir\\staging-repo1
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file:///e:\dir\staging-repo 
> -Dwagon.target=file:///e:\dir\staging-repo1
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://e:\dir\staging-repo 
> -Dwagon.target=file://e:\dir\staging-repo1
>
> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
> -Dwagon.source=file://./staging-repo -Dwagon.target=file://./staging-repo1
>
>
> They all give me the same error message:
>
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error during performing repository copy
>
> Embedded error: The filename, directory name, or volume label syntax is 
> incorrect
>
> -Jim
>
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Thursday, March 26, 2009 1:32 PM
> To: Maven Users List
> Subject: Re: Maven Stage Plugin issue
>
> try file:///e:/dir/staging-repo
>
> -D
>
> On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey
>  wrote:
>> Hi Dan,
>>
>> Thanks a lot for the response.  I took a look at it and it definitely seems 
>> more full featured than the staging plugin, but I'm still having trouble 
>> with it.  If I formulate a command like this:
>>
>> mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos 
>> -Dwagon.source=file://E:\dir\staging-repo 
>> -Dwagon.target=file://E:\dir\staging-repo1
>>
>> I get this error:
>>
>> [ERROR] BUILD ERROR
>> [INFO] 
>> 
>> [INFO] Error during performing repository copy
>>
>> Embedded error: The filename, directory name, or volume label syntax is 
>> incorrect
>>
>> Did I miss understand the input parameters?
>>
>> I'm assuming that you are referring to this version of wagon-maven-plugin.
>>
>> http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html
>> http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1
>>
>> I found what appears to be an older Apache MyFaces project by the same 
>> artifactId.
>>
>> -Jim
>>
>> -Original Message-
>> From: Dan Tran [mailto:dant...@gmail.com]
>> Sent: Thursday, March 26, 2009 11:54 AM
>> To: Maven Users List
>> Subject: Re: Maven Stage Plugin issue
>>
>> try wagon-maven-plugin with maven 2.1.0 to see it works out for you.
>> It has a port of maven-stage-plugin with lots of fixes.
>>
>> -D
>>
>> On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey
>>  wrote:
>>> Hello all,
>>>
>>> I am attempting to use the Maven stage plugin and running into a break.  I 
>>> have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm 
>>> also using the only stage plugin available which appears to be 1.0-alpha-1. 
>>>  My guess is I'm doing something wrong, but for the life of me I can't see 
>>> what.
>>>
>>> Here is the command I am executing (I'm on windows FWIW):
>>>
>>> mvn -Dsource=file://E:\dir\staging-repo 
>>> -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy
>>>
>>> Here is the error:
>>>
>>> [INFO] 
>>> 
>>> [ERROR] FATAL ERROR
>>> [INFO] 
>>> 
>>> [INFO] org.apache.maven.wagon.providers.file.FileWagon
>>> [INFO] 
>>> --

SCM requires that command line svn be used?

[Chris]

I'm trying to configure my pom to use an . We use Subversion. When 
I run it, I get the error "'svn' is not recognized as an internal or 
external command, operable program or batch file.". I take it this means 
that svn.exe needs to be on the path, and the plugin is shelling out to 
access it.


This is obviously flaky and error prone. In Ant, I can use SvnAnt to 
access svn directly, using java alone.


Is it possible to configure Maven to use one of the svn-java libraries 
instead of the command line client?



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

Re: SCM requires that command line svn be used?

[Olivier Lamy]

Hi,
It's possible with the javasvn implementation. This has been moved
recently from the asf repository due to license issue.
Now it's here : http://code.google.com/p/maven-scm-provider-svnjava/
It will be released after the maven-scm release.

HTH,
--
Olivier

2009/3/26 Chris :
> I'm trying to configure my pom to use an . We use Subversion. When I
> run it, I get the error "'svn' is not recognized as an internal or external
> command, operable program or batch file.". I take it this means that svn.exe
> needs to be on the path, and the plugin is shelling out to access it.
>
> This is obviously flaky and error prone. In Ant, I can use SvnAnt to access
> svn directly, using java alone.
>
> Is it possible to configure Maven to use one of the svn-java libraries
> instead of the command line client?
>
>
> -
> 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-surefire-plugin: run unit tests from classes in a jar, not a directory

[Anshul Jaiswal]

Thanks for your replies, Brett and Stephen!

I was able to use the @RunWith with a Suite subclass that would search for
unit tests within jars in the classpath. However, the problem with that
approach is that all the unit tests run within the same JVM. Whereas we want
all the unit tests to be forked, pretty much like forkMode=always.

Looking through the code, it appears to me that I can write my own subclass
of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override
its locateTestSets() method (actually I just want to override collectTests()
but that is private) to be able to implement my own test discovery
algorithm.

However, it's not clear to me how I can get surefire plugin to use my
subclass instead of the Junit one. I guess I may have to create my own
surefire-provider? I guess I can do that by starting with (or extending) the
junit4 provider. Lets say I do that how, is there a way to get surefire to
use my provider instead of junit 4.

Cheers,
Anshul



On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal wrote:

> Folks,
>
> The surefire plugin currently supports automatically searching for unit
> testing classes from a directory.
>
> I was wondering if there is way for it to search for unit tests from a set
> of jar files instead of a directory. ie., a mechanism where I can specify a
> regex pattern for the package and/or class name and it can search through
> all the jars in the 'test' scope for classes matching that pattern and run
> them.
>
> Thanks in advance!
> Anshul
>

Re: [maven-eclipse-plugin] and .aj AspectJ files.

[Barrie Treloar]

Added http://jira.codehaus.org/browse/MECLIPSE-538.

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

Re: [Vote] findbugs-maven-plugin v 2.0 release

[Arnaud HERITIER]

1.3.8 isn't in the central repo :
http://repo1.maven.org/maven2/com/google/code/findbugs/findbugs/

Arnaud


On Thu, Mar 26, 2009 at 3:43 PM, TM  wrote:

>
> -1
>
> Background: According to http://jira.codehaus.org/browse/MFINDBUGS-66, the
> plugin integrates Findbugs version 1.3.6. Meanwhile, version 1.3.8 was
> released. I suggest to catch up with that release before releasing the
> plugin.
>
> -- Thorsten
>
>
>
>
>
>
>
> Garvin LeClaire-2 wrote:
> >
> > The Maven Findbugs team would like to release Maven Findbugs Plugin
> > version 2.0
> >
> > This plugin allows the developer to run Findbugs analysis against a
> > Maven project and produce site output in HTML to match other site
> > reports.  There are option to produce other XML outputs which are used
> > by other plugins.
> >
> > Issues fixed in this release:
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&fixfor=14335&pid=11701&status=6&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC
> >
> >
> > More information can be found at the plugin site:
> > http://mojo.codehaus.org/findbugs-maven-plugin/
> >
> >
> > Issues Can be registered in JIRA at:
> > http://jira.codehaus.org/browse/MFINDBUGS
> >
> >
> > More information on FindBugs
> > http://findbugs.sourceforge.net/index.html
> >
> >
> >
> > You can test the Maven Findbugs Plugin in your own project by adding the
> > following dependency:
> >
> > 
> > org.codehaus.mojo
> > findbugs-maven-plugin
> > 2.0-SNAPSHOT
> > 
> >
> >
> >
> > *NOTE*  Version 2.0 and greater of the Maven Findbugs plugin will
> > require Maven to be run with a minimum of Java 5.  This is consistent
> > with Findbugs requirement for their versions of 1.3.X and greater.
> >
> >
> >
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > --
> >
> > Regards,
> >
> >
> >
> > Garvin LeClaire
> > garvin.lecla...@gmail.com
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-Vote--findbugs-maven-plugin-v-2.0--release-tp22715803p22723449.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
>
>


-- 
Arnaud

Re: Maven extra sources and eclipse

[ksangani]

Did you write maven plugin to generate sources under target/generate-sources?
If so you can maven plugin api to add these extra source directories to
project.


Jean-Marc Vanel-2 wrote:
> 
> Hi all
> 
>  We have a projet (
> http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml
> ) using a parser generator , for which we have extra Java sources, not
> for building with the application.
> 
> We generate the eclipse configuration with Maven, but I found no way
> to specify these extra Java sources so that they appear in the eclipse
> configuration.
> 
> Thanks for any hint
> -- 
> Jean-Marc Vanel
> Consulting, services, training,
> Rule-based programming, Semantic Web
> http://jmvanel.free.fr/
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Maven-extra-sources-and-eclipse-tp22719773p22733515.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

Ideal File Placement

[Sammy]

Hello,

In a multi-module maven project, a webapp module has java, resources 
and WEB-INF folders. In which folder should jsp, css, web.xml, spring 
XML configurations and other files go?


--
Thank you,
Sammy



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

RE: Ideal File Placement

[Martin Gainty]

are you building a war or an ear
if ear which AppServer will you deploy to?

?
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
This message is confidential and may be privileged. If you are not the intended 
recipient, we kindly ask you to  please inform the sender. Any unauthorised 
dissemination or copying hereof is prohibited. This message serves for 
information purposes only and shall not have any legally binding effect. Given 
that e-mails can easily be subject to manipulation, we can not accept any 
liability for the content provided.





 

> To: users@maven.apache.org
> From: pico...@gmail.com
> Subject: Ideal File Placement
> Date: Fri, 27 Mar 2009 01:57:35 +0200
> 
> Hello,
> 
> In a multi-module maven project, a webapp module has java, resources 
> and WEB-INF folders. In which folder should jsp, css, web.xml, spring 
> XML configurations and other files go?
> 
> -- 
> Thank you,
> Sammy
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

_
Internet Explorer 8 – Get your Hotmail Accelerated.  Download free!
http://clk.atdmt.com/MRT/go/141323790/direct/01/

Grandparent classes not found at compile time

[Trinition]

I'm confused about why transitive provided dependencies shouldn't be included
at compile time.

I have a project, "myapp-web", which defines a custom Servlet, MyServlet. 
MyServlet extends a BaseServlet from "framework".  BaseServlet extends a
Servlet class from "thirdparty", ThirdPartyServlet.  ThirdPartyServlet in
turn implements the third party's CacheableServlet interface among other
things.

myapp-web: MyServlet
framework: BaseServlet
thirdparty: ThidrdPartyServlet, CacheableServlet, etc.

So myapp's pom declares a compile-time dependency on framework, and
framework declares a provided dependency on thirdparty.  This is because the
thirdparty jar is available at runtime in my container, thus I don't want to
ever include it transitively for packaging.

So when myapp-web compiles, it needs the definition of BaseServlet.class
which it finds in its compile time dependency of "framework".  However, it
seems to not know about the definitions of BaseServelt's parent class
(MyServlet's grandparent class), ThirdPartyServlet.  I get compile-time
errors like these:

MyServlet.java:[199,20] cannot find symbol
symbol  : variable this
location: class com.myapp.MyServlet

MyServlet.java:[201,24] cannot find symbol
symbol  : variable super
location: class com.myapp.MyServlet

Because MyServlet extends BaseServlet which extends ThirdPartyServlet,
doesn't the compile NEED to know about all classes in the hierarchy in order
to compile?  Thus, I would think anything that was available at compile time
during the building of BaseServlet COULD BE a compile-time dependency to
dependents of "framework" (such as "myapp-web").

So why does Maven NOT include provided dependencies transitively at compile
time?

This is presently blocking me.  My workaround is to explicitly add
"thirdparty" as a provided dependency to "myapp-web" so that the
ThirdPartyServlet and CacheableServlet definitions will be available at
compile time.  But this is the very thing that transitive dependencies
solves for COMPILE dependencies (which are really COMPILED and PACKAGED). 
Why not solve it for TRANSITIVE dependencies (whcich are COMPILED but NOT
PACKAGED).
-- 
View this message in context: 
http://www.nabble.com/Grandparent-classes-not-found-at-compile-time-tp22733894p22733894.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: [maven-eclipse-plugin] and .aj AspectJ files.

[Barrie Treloar]

Can you confirm that
  src/main/aspect
should be
  including="**/*.java|**/*.aj"
instead of just
  including="**/*.aj"

Thanks

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

Re: [maven-eclipse-plugin] and .aj AspectJ files.

[Barrie Treloar]

On Fri, Mar 27, 2009 at 12:19 PM, Barrie Treloar  wrote:
> Can you confirm that
>  src/main/aspect
> should be
>  including="**/*.java|**/*.aj"
> instead of just
>  including="**/*.aj"
>
> Thanks
>

Ok after googling, I can find more than one project that has java
files in src/main/aspect.
Will go with that.

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

RE: Apache maven snapshots repository root links are invalid

[Brian E. Fox]

Thanks for pointing this out. It's actually a misconfig in the proxy rewrite 
rules. The /snapshots is actually a proxy of 
http://repository.apache.org/content/groups/snapshots and it looks like the 
reverse proxy rules are bunging up the url. I'll have to polish my rewrite-fu 
to get them worked out.

-Original Message-
From: Stevo Slavić [mailto:ssla...@gmail.com] 
Sent: Thursday, March 26, 2009 6:59 AM
To: Maven Users List
Subject: Apache maven snapshots repository root links are invalid

Hello maven users,

Links on http://repository.apache.org/snapshots are invalid, they are
missing "snapshots" part. This is error only in the root of the repository,
once in some directory e.g. "http://repository.apache.org/snapshots/org";,
links work well. It seems to be some sort of (nexus) configuration issue.

Regards,
Stevo.

RE: How to perform a deploy only

[Brian E. Fox]

Running the full lifecycle is a fundamental of Maven, so this type of
feature request is unlikely to gain traction. You should rather look at
your build configuration to solve the problem, or as mentioned use a
repo man that can help you out.

-Original Message-
From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] 
Sent: Wednesday, March 25, 2009 11:26 PM
To: 'Maven Users List'
Subject: RE: How to perform a deploy only

Thanks for the suggestion.  I have been trying to avoid using repository
managers for a number of reasons that are beyond the scope of this
thread.  I may have to break down eventually...

I'm surprised no one has needed this sort of feature, or maybe they have
and that's why Nexus has the features that it does.  I was hoping to
find a Maven native (whatever native means in a highly pluggable
architecture) way to do this that would not take much additional work.

mvn -DdoNothingButDeploy=true deploy

That would be about perfect.  :)  

Would this even be consider for an enhancement request if I opened it?
Perhaps I am the only one interested in such a thing.

Thanks!

-Jim

-Original Message-
From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] 
Sent: Wednesday, March 25, 2009 9:55 PM
To: Maven Users List
Subject: RE: How to perform a deploy only

Brian can pitch his own stuff far better than I can, but this kind of
transactional deployment can be done with Nexus' Staging feature.
 
I realized after I sent my deploy:deploy suggestion that it probably
wouldn't work without running at least the package phase, sorry to give
you bad info. I'm reasonably confident with some light hacking you could
write a plugin that essentially faked the build, but if the below is
your use case and you can afford Nexus Pro, it's probably a better
solution.

Justin
 



From: Jim McCaskey [mailto:jim.mccas...@pervasive.com]
Sent: Wed 3/25/2009 10:37 PM
To: 'Maven Users List'
Subject: RE: How to perform a deploy only



I have a whole bunch of components that are mostly interrelated but
consumable individually by downstream builds.  If I run deploy it
basically starts deploying as it goes, so if a downstream component
breaks for some reason then I am left with half of the components
updated in the maven repo and half not.  That's not really what we want.

So ideally, we would run a build/test, make sure it all gets through
completely, then deploy the resulting artifacts.

-Jim

-Original Message-
From: Brian E. Fox [mailto:bri...@reply.infinity.nu]
Sent: Wednesday, March 25, 2009 9:20 PM
To: Maven Users List
Subject: RE: How to perform a deploy only

This really isn't a supported use case. Deploy is a phase and by
definition all earlier phases run before the one you've asked for. Why
would you not want to build before you deploy?

-Original Message-
From: Jim McCaskey [mailto:jim.mccas...@pervasive.com]
Sent: Wednesday, March 25, 2009 10:17 PM
To: 'users@maven.apache.org'
Subject: How to perform a deploy only

Hello all,

I have several components all built from a top level pom.  This works
great for accelerating users to be able to build a lot of stuff quickly
but is giving me some fits when trying to deploy.  Up to this point I
have been using deploy:deploy-file to get built components into our
local repository after a full build is successful, but this is labor
intensive.

I would like to be able to run some variation of "mvn deploy" from the
top level.  I have figured out how to skip things using the FAQ here:

http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip

But I do NOT want it to do anything other than deploy.  I have googled
for this but have not turned up anything useful.  I was surprised that
the documentation does not suggest how to do this.  This is the correct
deploy documentation I think.

http://maven.apache.org/plugins/maven-deploy-plugin/

Anyway, any help would be appreciated.

Thanks!

-Jim


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


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




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





-
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-eclipse-plugin] and .aj AspectJ files.

[Barrie Treloar]

On Fri, Mar 27, 2009 at 12:23 PM, Barrie Treloar  wrote:
> On Fri, Mar 27, 2009 at 12:19 PM, Barrie Treloar  wrote:
>> Can you confirm that
>>  src/main/aspect
>> should be
>>  including="**/*.java|**/*.aj"
>> instead of just
>>  including="**/*.aj"
>>
>> Thanks
>>
>
> Ok after googling, I can find more than one project that has java
> files in src/main/aspect.
> Will go with that.
>

http://jira.codehaus.org/browse/MECLIPSE-538 closed.

Patched on trunk.

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

Re: Ideal File Placement

[Rusty Wright]

For a tomcat app I put them in

src/main/webapp/WEB-INF (web.xml and spring config)
src/main/webapp/WEB-INF/views (with spring's view resolver configured to use 
this)
src/main/webapp/images
src/main/webapp/css

Whatever is in

src/main/resources

will end up in

tomcat/webapps//WEB-INF/classes

which puts it on the classpath.


Sammy wrote:

Hello,

In a multi-module maven project, a webapp module has java, resources and 
WEB-INF folders. In which folder should jsp, css, web.xml, spring XML 
configurations and other files go?




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

Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory

[Anshul Jaiswal]

I was able to get this to work by modifying the sure-fire plugin source. I
updated AbstractDirectoryTestSuite.collectTests() to be protected. And I
over-rode that method in JUnit4DirectoryTestSuite to list all the jars from
the class path and search for unit tests within them adding the discovered
unit tests to the list of collected tests. It does seem to work.

I guess, if SurefirePlugin, exposed the name of junit4DirectoryTestSuite as
a parameter, like it exposes the testNG and junit artifact names. I would
have been able to accomplish this without needing any changes to the plugin
codebase.

In case it's useful for folks, here is the background on why I'm wanting to
do this.

I'm using this mechanism to be able to create patch projects/artifacts for
artifacts that only include the source for classes that are updated for that
patch. These patch projects designate the project/artifact being patched as
a parent. The patch project only contains the sources and unit tests for
functionality that has been modified / added in the patch. The jar generated
by these projects only have the patched classes and I can apply this patch
by placing this jar ahead of the actual artifact's jar, in the classpath, in
an installation.

Along with running the unit tests that I have created for the patch, I do
want to be able to run all the unit tests for the project/artifact being
patched, so that I can verify that the entire project continues to work, as
expected, with the changes. Through this mechanism I have that ability.
Ofcourse, the artifact being patched has to export it's to the maven
repository, so that the patch project can depend on it, but that's easy.

Cheers,
Anshul

On Thu, Mar 26, 2009 at 1:57 PM, Anshul Jaiswal wrote:

> Thanks for your replies, Brett and Stephen!
>
> I was able to use the @RunWith with a Suite subclass that would search for
> unit tests within jars in the classpath. However, the problem with that
> approach is that all the unit tests run within the same JVM. Whereas we want
> all the unit tests to be forked, pretty much like forkMode=always.
>
> Looking through the code, it appears to me that I can write my own subclass
> of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override
> its locateTestSets() method (actually I just want to override collectTests()
> but that is private) to be able to implement my own test discovery
> algorithm.
>
> However, it's not clear to me how I can get surefire plugin to use my
> subclass instead of the Junit one. I guess I may have to create my own
> surefire-provider? I guess I can do that by starting with (or extending) the
> junit4 provider. Lets say I do that how, is there a way to get surefire to
> use my provider instead of junit 4.
>
> Cheers,
> Anshul
>
>
>
>
> On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal 
> wrote:
>
>> Folks,
>>
>> The surefire plugin currently supports automatically searching for unit
>> testing classes from a directory.
>>
>> I was wondering if there is way for it to search for unit tests from a set
>> of jar files instead of a directory. ie., a mechanism where I can specify a
>> regex pattern for the package and/or class name and it can search through
>> all the jars in the 'test' scope for classes matching that pattern and run
>> them.
>>
>> Thanks in advance!
>> Anshul
>>
>
>