Re: How can I prevent SLF4J's infamous “multiple bindings” warning at build time for maven build?

[Nick Stolwijk]

You can ban duplicate classes with the enforcer plugin [1].

[1] http://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html

Hth,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Wed, Apr 11, 2018 at 10:39 AM Debraj Manna <subharaj.ma...@gmail.com>
wrote:

> I have seen a similar question being answered in stackoverflow
>
>
> https://stackoverflow.com/questions/25335497/how-can-i-prevent-slf4js-infamous-multiple-bindings-warning-at-build-time
>
> Is it possible achieve something like this via maven build also ?
>

How can I prevent SLF4J's infamous “multiple bindings” warning at build time for maven build?

[Debraj Manna]

I have seen a similar question being answered in stackoverflow

https://stackoverflow.com/questions/25335497/how-can-i-prevent-slf4js-infamous-multiple-bindings-warning-at-build-time

Is it possible achieve something like this via maven build also ?

Re: A maven plugin to add dynamically a repository at build time

[Nicolas Brasey]

Hi Yolan,

Thanks for your input.

Yes, what you proposed is what I use at the moment as a workaround. But I
wanted to hide the branch selection logic from the build runner.

I suppose there is no real solution to hook code in maven before even the
dependencies resolution? Is there another API besides the maven plugin
API which allows me for example to extend the default MavenArtifact
resolver?

Nicolas






On Tue, Apr 10, 2018 at 7:22 AM, Golan, Yaron <yg3...@intl.att.com> wrote:

> Hi,
>
> Here is my proposal...
>
> Inside your main/parent pom.xml, set the following:
>
> 
> ...
> 
> foo
> boo
> 
>
> 
> 
> ${repo.name}
> ${repo.url}
> 
> 
> ...
> 
>
>
> And your maven command should like:
> mvn  -Drepo.name=some.repo.name -Drepo.url=relevant.url
>
>
> What do you say?
>
> YG
>
>
>
>
> -Original Message-
> From: Nicolas Brasey [mailto:nicolas.bra...@gmail.com]
> Sent: Monday, April 09, 2018 20:41
> To: users@maven.apache.org
> Subject: A maven plugin to add dynamically a repository at build time
>
> Hi,
>
> In my continuous integration solution, I need to have a maven repository
> which is calculated based on the git branch name. For example, I have a
> naming convention which is used to calculate the maven repo URL, something
> similar to this:
>
> Branch name -> Git Repo URL:
> --- -
> develop -> https://urldefense.proofpoint.
> com/v2/url?u=http-3A__archiva_repositories_snapshot=DwIBaQ=LFYZ-o9_
> HUMeMTSQicvjIg=GYb_8qONFTPgVpTfZRT53aEptjaOm6sDrruaOwiowLQ=
> wYKDMhCmuL6gf7KPllHND78qrm6EwCIeSTQMt6cv268=
> YFvvW16iOsJQtkao0hwVmS33Rh07ba1sfucC1yHSwFI=
> feature/xxx -> https://urldefense.proofpoint.
> com/v2/url?u=http-3A__archiva_repositories_feature-2Dxxx=
> DwIBaQ=LFYZ-o9_HUMeMTSQicvjIg=GYb_8qONFTPgVpTfZRT53aEptjaOm6sDrr
> uaOwiowLQ=wYKDMhCmuL6gf7KPllHND78qrm6EwCIeSTQMt6cv268=
> tUqew2vcZMbgd3HbH8wWGoTp_v94pBrDATIHUCug8jw=
> staging/xxx -> https://urldefense.proofpoint.
> com/v2/url?u=http-3A__archiva_repositories_staging-2Dxxx=
> DwIBaQ=LFYZ-o9_HUMeMTSQicvjIg=GYb_8qONFTPgVpTfZRT53aEptjaOm6sDrr
> uaOwiowLQ=wYKDMhCmuL6gf7KPllHND78qrm6EwCIeSTQMt6cv268=
> KXqHxpLtHwoU86yY9ySm1QrSBtaoN7lsraCeF6DW9dw=
>
>
> I wrote a maven plugin that adds dynamically a repository in my project
> but unfortunately, my plugin is not invoked before maven performs the
> dependency resolution.
>
> I googled it and tried some workaround proposed (like putting my plugin in
> the pre-clean phase), but it still executes after the dependency resolution.
>
> You guys ever tried this?
>
> Thanks,
> Nicolas
>

RE: A maven plugin to add dynamically a repository at build time

[Golan, Yaron]

Hi,

Here is my proposal...

Inside your main/parent pom.xml, set the following:


...

foo
boo




${repo.name}
${repo.url}


...



And your maven command should like:
mvn  -Drepo.name=some.repo.name -Drepo.url=relevant.url


What do you say?

YG




-Original Message-
From: Nicolas Brasey [mailto:nicolas.bra...@gmail.com] 
Sent: Monday, April 09, 2018 20:41
To: users@maven.apache.org
Subject: A maven plugin to add dynamically a repository at build time

Hi,

In my continuous integration solution, I need to have a maven repository which 
is calculated based on the git branch name. For example, I have a naming 
convention which is used to calculate the maven repo URL, something similar to 
this:

Branch name -> Git Repo URL:
--- -
develop -> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__archiva_repositories_snapshot=DwIBaQ=LFYZ-o9_HUMeMTSQicvjIg=GYb_8qONFTPgVpTfZRT53aEptjaOm6sDrruaOwiowLQ=wYKDMhCmuL6gf7KPllHND78qrm6EwCIeSTQMt6cv268=YFvvW16iOsJQtkao0hwVmS33Rh07ba1sfucC1yHSwFI=
 
feature/xxx -> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__archiva_repositories_feature-2Dxxx=DwIBaQ=LFYZ-o9_HUMeMTSQicvjIg=GYb_8qONFTPgVpTfZRT53aEptjaOm6sDrruaOwiowLQ=wYKDMhCmuL6gf7KPllHND78qrm6EwCIeSTQMt6cv268=tUqew2vcZMbgd3HbH8wWGoTp_v94pBrDATIHUCug8jw=
 
staging/xxx -> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__archiva_repositories_staging-2Dxxx=DwIBaQ=LFYZ-o9_HUMeMTSQicvjIg=GYb_8qONFTPgVpTfZRT53aEptjaOm6sDrruaOwiowLQ=wYKDMhCmuL6gf7KPllHND78qrm6EwCIeSTQMt6cv268=KXqHxpLtHwoU86yY9ySm1QrSBtaoN7lsraCeF6DW9dw=
 


I wrote a maven plugin that adds dynamically a repository in my project but 
unfortunately, my plugin is not invoked before maven performs the dependency 
resolution.

I googled it and tried some workaround proposed (like putting my plugin in the 
pre-clean phase), but it still executes after the dependency resolution.

You guys ever tried this?

Thanks,
Nicolas

A maven plugin to add dynamically a repository at build time

[Nicolas Brasey]

Hi,

In my continuous integration solution, I need to have a maven repository
which is calculated based on the git branch name. For example, I have a
naming convention which is used to calculate the maven repo URL, something
similar to this:

Branch name -> Git Repo URL:
--- -
develop -> http://archiva/repositories/snapshot
feature/xxx -> http://archiva/repositories/feature-xxx
staging/xxx -> http://archiva/repositories/staging-xxx


I wrote a maven plugin that adds dynamically a repository in my project but
unfortunately, my plugin is not invoked before maven performs the
dependency resolution.

I googled it and tried some workaround proposed (like putting my plugin in
the pre-clean phase), but it still executes after the dependency resolution.

You guys ever tried this?

Thanks,
Nicolas

Re: Possible to alter project.distributionManagement.repository.url at build time?

[Dan Tran]

Hi Mirko,

I have something similar as well. I was hoping can do it as part of
release:repare release:perform to instrument dynamic stagingId for our
Artifactory deployment

Thanks

-D

On Tue, Jul 5, 2016 at 2:17 PM, Mirko Friedenhagen 
wrote:

> Hello Dan,
> we use a property in distributionManagement which has is set in
> settings.xml (may be overridden on the CLI), something like:
> ${distribution.snapshot.url}
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Tue, Jul 5, 2016 at 3:06 AM, Dan Tran  wrote:
> > quick prototype shows I can make changes to maven project, but deploy
> > plugin does not see my changes.
> >
> > so is not possible?
> >
> > Thanks
> >
> > -Dan
> >
> > On Mon, Jul 4, 2016 at 5:14 PM, Dan Tran  wrote:
> >
> >> Hi I have a need to push a key/value pair into release URL
> >>
> >> is maven project immutable once constructed?
> >>
> >> Thanks
> >>
> >> -Dan
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Possible to alter project.distributionManagement.repository.url at build time?

[Mirko Friedenhagen]

Hello Dan,
we use a property in distributionManagement which has is set in
settings.xml (may be overridden on the CLI), something like:
${distribution.snapshot.url}
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Jul 5, 2016 at 3:06 AM, Dan Tran  wrote:
> quick prototype shows I can make changes to maven project, but deploy
> plugin does not see my changes.
>
> so is not possible?
>
> Thanks
>
> -Dan
>
> On Mon, Jul 4, 2016 at 5:14 PM, Dan Tran  wrote:
>
>> Hi I have a need to push a key/value pair into release URL
>>
>> is maven project immutable once constructed?
>>
>> Thanks
>>
>> -Dan
>>

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

Re: Possible to alter project.distributionManagement.repository.url at build time?

[Dan Tran]

quick prototype shows I can make changes to maven project, but deploy
plugin does not see my changes.

so is not possible?

Thanks

-Dan

On Mon, Jul 4, 2016 at 5:14 PM, Dan Tran  wrote:

> Hi I have a need to push a key/value pair into release URL
>
> is maven project immutable once constructed?
>
> Thanks
>
> -Dan
>

Possible to alter project.distributionManagement.repository.url at build time?

[Dan Tran]

Hi I have a need to push a key/value pair into release URL

is maven project immutable once constructed?

Thanks

-Dan

Re: Improving project build time

[Kristian Rosenvold]

You should probably be looking into parallelizing your tests :) .

Either through using the parallel attribute of surefire or or
forkMode=perThread.

( see http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html)

forkMode=perThread is probably the easiest to get going with, but the
payoff is larger
with the parallel flag. You only need to watch out for singleton stutt
(tcp ports, files)
when trying to run parallel.

Kristian



2012/9/17 Hanmay Udgiri hanmayya.udg...@gmail.com:
 Hi All,

 We are Maven for building and deploying our projects.

 The total time taken for the project is around 32mins.

 We want to improve this time.
 Please suggest different ways of reducing the build time.

 The projects contains total 22 module.
 when we run the mvn clean and install without tests it takes around 1 min
 22 seconds.
 But when we run with Tests it takes around 32 mins.


 --
 Thanks and Regards
 Hanmayya Udgiri

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

Re: Improving project build time

[Barrie Treloar]

On Mon, Sep 17, 2012 at 5:26 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 You should probably be looking into parallelizing your tests :) .

Or looking at what your tests are doing.
32 minutes sounds like you are doing integration type testing and not
unit tests.

Pull the integration tests into their own module, which you include
via a profile (e.g. its), and get your continuous integration server
to run them for you.
The developers can then forget about them until they get emailed about
broken builds.

If they really want to run them, they can just include them via -Pits

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

Re: Improving project build time

[Clebert Suconic]

That's one thing I always thought that maven should have an explicit
spot for integration tests. We also had to create a separate profile.
Having them into a more standard place would make it cleaner IMO.

That's a feature request I know. But does it make sense?

Sent from my iPhone

On Sep 17, 2012, at 5:39 AM, Barrie Treloar baerr...@gmail.com wrote:

 On Mon, Sep 17, 2012 at 5:26 PM, Kristian Rosenvold
 kristian.rosenv...@gmail.com wrote:
 You should probably be looking into parallelizing your tests :) .

 Or looking at what your tests are doing.
 32 minutes sounds like you are doing integration type testing and not
 unit tests.

 Pull the integration tests into their own module, which you include
 via a profile (e.g. its), and get your continuous integration server
 to run them for you.
 The developers can then forget about them until they get emailed about
 broken builds.

 If they really want to run them, they can just include them via -Pits

 -
 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: Improving project build time

[Danny Thomas]

Use the Failsafe plugin, though a separate module is good practice too:

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

Danny

-Original Message-
From: Clebert Suconic [mailto:clebert.suco...@gmail.com]
Sent: 17 September 2012 14:05
To: Maven Users List
Subject: Re: Improving project build time

That's one thing I always thought that maven should have an explicit spot for 
integration tests. We also had to create a separate profile.
Having them into a more standard place would make it cleaner IMO.

That's a feature request I know. But does it make sense?

Sent from my iPhone

On Sep 17, 2012, at 5:39 AM, Barrie Treloar baerr...@gmail.com wrote:

 On Mon, Sep 17, 2012 at 5:26 PM, Kristian Rosenvold
 kristian.rosenv...@gmail.com wrote:
 You should probably be looking into parallelizing your tests :) .

 Or looking at what your tests are doing.
 32 minutes sounds like you are doing integration type testing and not
 unit tests.

 Pull the integration tests into their own module, which you include
 via a profile (e.g. its), and get your continuous integration server
 to run them for you.
 The developers can then forget about them until they get emailed about
 broken builds.

 If they really want to run them, they can just include them via -Pits

 -
 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


This email and any attachments may contain confidential and proprietary 
information of Blackboard that is for the sole use of the intended recipient. 
If you are not the intended recipient, disclosure, copying, re-distribution or 
other use of any of this information is strictly prohibited. Please immediately 
notify the sender and delete this transmission if you received this email in 
error.

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

Re: Improving project build time

[John Kramer]

I understand your point, and agree that I might be nice to have a bit more
of a standard place for integration tests.  However, one point that should
be mentioned is that there are frequently multiple levels of integration
tests (in container, out of container, ui, etc).  Thus it might not be so
simple to just have one spot for integration tests.

John Kramer
email: jkra...@mojiva.com
mobile: 314.435.2370
skype: kramer.mojiva
twitter: @KramerKnowsTech https://twitter.com/KramerKnowsTech
0xCAFEBABE0032







On 9/17/12 9:05 AM, Clebert Suconic clebert.suco...@gmail.com wrote:

That's one thing I always thought that maven should have an explicit
spot for integration tests. We also had to create a separate profile.
Having them into a more standard place would make it cleaner IMO.

That's a feature request I know. But does it make sense?

Sent from my iPhone

On Sep 17, 2012, at 5:39 AM, Barrie Treloar baerr...@gmail.com wrote:

 On Mon, Sep 17, 2012 at 5:26 PM, Kristian Rosenvold
 kristian.rosenv...@gmail.com wrote:
 You should probably be looking into parallelizing your tests :) .

 Or looking at what your tests are doing.
 32 minutes sounds like you are doing integration type testing and not
 unit tests.

 Pull the integration tests into their own module, which you include
 via a profile (e.g. its), and get your continuous integration server
 to run them for you.
 The developers can then forget about them until they get emailed about
 broken builds.

 If they really want to run them, they can just include them via -Pits

 -
 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: Improving project build time

[Hanmay Udgiri]

thx guys for your comments..
yes we have integration tests included in the build.
I have tried running them parallel but the tests are not atomic so are not
working as expected.
we have some DB call where we are using thread sleep,is there anything by
which this can be improved
Also we have any best practices for maven builds.

Thanks and Regards
Hanmayya

On Mon, Sep 17, 2012 at 6:48 PM, John Kramer jkra...@mojiva.com wrote:

 I understand your point, and agree that I might be nice to have a bit more
 of a standard place for integration tests.  However, one point that should
 be mentioned is that there are frequently multiple levels of integration
 tests (in container, out of container, ui, etc).  Thus it might not be so
 simple to just have one spot for integration tests.

 John Kramer
 email: jkra...@mojiva.com
 mobile: 314.435.2370
 skype: kramer.mojiva
 twitter: @KramerKnowsTech https://twitter.com/KramerKnowsTech
 0xCAFEBABE0032







 On 9/17/12 9:05 AM, Clebert Suconic clebert.suco...@gmail.com wrote:

 That's one thing I always thought that maven should have an explicit
 spot for integration tests. We also had to create a separate profile.
 Having them into a more standard place would make it cleaner IMO.
 
 That's a feature request I know. But does it make sense?
 
 Sent from my iPhone
 
 On Sep 17, 2012, at 5:39 AM, Barrie Treloar baerr...@gmail.com wrote:
 
  On Mon, Sep 17, 2012 at 5:26 PM, Kristian Rosenvold
  kristian.rosenv...@gmail.com wrote:
  You should probably be looking into parallelizing your tests :) .
 
  Or looking at what your tests are doing.
  32 minutes sounds like you are doing integration type testing and not
  unit tests.
 
  Pull the integration tests into their own module, which you include
  via a profile (e.g. its), and get your continuous integration server
  to run them for you.
  The developers can then forget about them until they get emailed about
  broken builds.
 
  If they really want to run them, they can just include them via -Pits
 
  -
  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




-- 
Thanks and Regards
Hanmayya Udgiri

Re: Improving project build time

[John Kramer]

I would suggest that you make sure that your tests are idempotent
(http://geekswithblogs.net/dthakur/archive/2004/11/19/15282.aspx) and
independent and deterministic.  This will not only allow you to run tests
in parallel, but it will also help maintainability a lot.

It is also a red flag that you need to cal thread.sleep in your tests.
Are you testing multithreaded processes?  If to, it is probably better to
use thread.wait and thread.notify.

John Kramer
email: jkra...@mojiva.com
mobile: 314.435.2370
skype: kramer.mojiva
twitter: @KramerKnowsTech https://twitter.com/KramerKnowsTech
0xCAFEBABE0032







On 9/17/12 10:17 AM, Hanmay Udgiri hanmayya.udg...@gmail.com wrote:

thx guys for your comments..
yes we have integration tests included in the build.
I have tried running them parallel but the tests are not atomic so are not
working as expected.
we have some DB call where we are using thread sleep,is there anything by
which this can be improved
Also we have any best practices for maven builds.

Thanks and Regards
Hanmayya

On Mon, Sep 17, 2012 at 6:48 PM, John Kramer jkra...@mojiva.com wrote:

 I understand your point, and agree that I might be nice to have a bit
more
 of a standard place for integration tests.  However, one point that
should
 be mentioned is that there are frequently multiple levels of integration
 tests (in container, out of container, ui, etc).  Thus it might not be
so
 simple to just have one spot for integration tests.

 John Kramer
 email: jkra...@mojiva.com
 mobile: 314.435.2370
 skype: kramer.mojiva
 twitter: @KramerKnowsTech https://twitter.com/KramerKnowsTech
 0xCAFEBABE0032







 On 9/17/12 9:05 AM, Clebert Suconic clebert.suco...@gmail.com wrote:

 That's one thing I always thought that maven should have an explicit
 spot for integration tests. We also had to create a separate profile.
 Having them into a more standard place would make it cleaner IMO.
 
 That's a feature request I know. But does it make sense?
 
 Sent from my iPhone
 
 On Sep 17, 2012, at 5:39 AM, Barrie Treloar baerr...@gmail.com wrote:
 
  On Mon, Sep 17, 2012 at 5:26 PM, Kristian Rosenvold
  kristian.rosenv...@gmail.com wrote:
  You should probably be looking into parallelizing your tests :) .
 
  Or looking at what your tests are doing.
  32 minutes sounds like you are doing integration type testing and not
  unit tests.
 
  Pull the integration tests into their own module, which you include
  via a profile (e.g. its), and get your continuous integration
server
  to run them for you.
  The developers can then forget about them until they get emailed
about
  broken builds.
 
  If they really want to run them, they can just include them via -Pits
 
  -
  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




-- 
Thanks and Regards
Hanmayya Udgiri


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

Re: Improving project build time

[Clebert Suconic]

Option one:

You could have one separate project for each integration layer?

I was just looking into something like, I just arrived in a project.. want
to run the integration tests... then I could just do:

cd /proper-integration-directory
mvn integration-tests
mvn tests:integration-tests



option 2:

mvn tests:module-name  (where module name would be the layer you mentioned)





Anyway: I understand there are other priorities so this will be a minor
thing. I was just proposing a standard way (from my user's POV).

Excessive build time using maven assembly plugin

[jredden]

Fellow developers,

Has anyone seen the behavior of revisiting of every object in the 
install/package process looking for EJBs and the like(?).  Is there a 
better plugin?  Missing attributes?  Code snippet:


plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
source${java-version}/source
target${java-version}/target
/configuration
/plugin

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.10/version
/plugin

plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
archive
manifest
mainClasscom.mycompany.service.notification.NotificationService/mainClass
/manifest
/archive
/configuration

executions
execution
idmake-assembly/id!-- this is used for inheritance merges --
phasepackage/phase!-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins

Re: Excessive build time using maven assembly plugin

[Wayne Fay]

 artifactIdmaven-compiler-plugin/artifactId
Missing plugin version (unless declared somewhere else?).

 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-surefire-plugin/artifactId
 version2.10/version
Old plugin version.

 artifactIdmaven-assembly-plugin/artifactId
Missing plugin version (declared elsewhere?).

Fix those issues and perhaps your problem will solve itself? Otherwise
post the stacktrace from your build at Gist and send us a link,
someone will review and offer suggestions.

Wayne

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

Re: help - how to reduce the build time using mvn and cargo

[Alex Lopez]

You could deploy in place or unpacked or something similar, there is 
more than one way to deploy or test your webapp without it having to be 
packed into the WAR, which is what takes most of the build time for us too.


Em 13-05-2011 01:42, Ron Wheeler escreveu:

On 12/05/2011 12:53 PM, javadaisy wrote:

Hi,

I am using maven 2.2.1 with cargo plugin to deploy into the local and
remote
host. It takes around 7 to 8 minutes to build and deploy the war. I would
like to reduce the time to 3 minutes or less than 3 minutes. can anybody
please tell me how to do that?.

I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat. It
didn't
work


How big is the WAR file?
There are physical limits to the speed at which disk drives work.

How long does it take on other machines? Is it only slow on some
workstations?

One of the most effective tricks is to segregate third party libraries
into sharable JARs that you only build once and deploy to the servlet
engine (Tomcat) once.
You set these as provided in the WAR file's POM and suddenly the build
creates a WAR that is 20 Mb smaller and builds 10 times faster.
Things like CXF (Web Services) add 20Mb to each WAR. If you make it
shareable and scope it as provided in the POM, the WAR drops to a few
tens of kilobytes that builds PDQ.

We have done this is 10+ cases to get common third-party and our own
utilities out of our 60+ WAR files that implement services and servlets.
- Spring, Hibernate, MySQL in one shared jar
- CXF
- JasperReports
- Apache Commons - lots of modules that everyone uses.
- our messaging/e-mail utility
- our facades that simplify our internal connections
- API and core functions that define the ORM and business processes

The WARs now contain only the code and resources that uniquely exist to
support the WAR's functionality.

It also eliminates the jar hell of conflicting versions of common
dependencies. Once you decide which version of commons-logging you want
to use, everyone gets it.

POM files get really small since they only refer to 10 dependencies or
less (typically 5 dependencies) to get all of the 90+ officially
sanctioned libraries.

Big help at run-time as well.

Ron


Thanks in advance.

--
View this message in context:
http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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



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

Re: help - how to reduce the build time using mvn and cargo

[Marc Rohlfs]

Java memory settings are not defined like system properties - You 
shouldn't use '-D'. Try this:

   set MAVEN_OPTS=-Xms=1024M -Xmx=1024M

This might not solve Your problem, but it should fix the memory 
reservation/allocation.


BTW: I wouldn't modify the mvn.bat. Just set the MAVEN_OPTS as an 
environment var.



On 12/05/11 18:53, javadaisy wrote:

I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It didn't
work


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

Re: help - how to reduce the build time using mvn and cargo

[javadaisy]

Bunch of thanks to all for sharing the info.  Yes my war is very big.  Its
size is almost 62MB.  It builds in 7 mins than other machines.  It uses 30
dependencies and xml resources.

--
View this message in context: 
http://maven-users.828.n2.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp6356451p6360977.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: help - how to reduce the build time using mvn and cargo

[Wayne Fay]

 Bunch of thanks to all for sharing the info.  Yes my war is very big.  Its
 size is almost 62MB.  It builds in 7 mins than other machines.  It uses 30
 dependencies and xml resources.

7 minutes is a long time just to build what is essentially a zip file.
Perhaps invest in some SSD hardware and perform your builds on
server-class machines rather than pokey laptops via a CI server like
Jenkins/Hudson or something along those lines.

Wayne

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

RE: help - how to reduce the build time using mvn and cargo

[EJ Ciramella]

Or, revisit what is going in there...

Are there images and files that the end user no longer can access?  How much 
cruft is in there exactly and how much can you yank out?

Are there dependencies that can be removed?

Are you saying the actual zipping process takes 7 min or the entire warfile 
build takes 7 min?  Could you break that apart and extract portions to a 
different build and just rely on dependencies?



-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Friday, May 13, 2011 4:30 PM
To: Maven Users List
Subject: Re: help - how to reduce the build time using mvn and cargo

 Bunch of thanks to all for sharing the info.  Yes my war is very big.  Its
 size is almost 62MB.  It builds in 7 mins than other machines.  It uses 30
 dependencies and xml resources.

7 minutes is a long time just to build what is essentially a zip file.
Perhaps invest in some SSD hardware and perform your builds on
server-class machines rather than pokey laptops via a CI server like
Jenkins/Hudson or something along those lines.

Wayne

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


CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

Re: help - how to reduce the build time using mvn and cargo

[Ron Wheeler]

Getting the 70 dependencies out of the build will yield the biggest ROI.

Ron

On 13/05/2011 4:29 PM, Wayne Fay wrote:

Bunch of thanks to all for sharing the info.  Yes my war is very big.  Its
size is almost 62MB.  It builds in 7 mins than other machines.  It uses 30
dependencies and xml resources.

7 minutes is a long time just to build what is essentially a zip file.
Perhaps invest in some SSD hardware and perform your builds on
server-class machines rather than pokey laptops via a CI server like
Jenkins/Hudson or something along those lines.

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

RE: help - how to reduce the build time using mvn and cargo

[EJ Ciramella]

Heh - I see 30 dependencies mentioned below, is this a trick answer?

(sorry, trolling as I wait for posts to my questions)

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Friday, May 13, 2011 5:08 PM
To: users@maven.apache.org
Subject: Re: help - how to reduce the build time using mvn and cargo

Getting the 70 dependencies out of the build will yield the biggest ROI.

Ron

On 13/05/2011 4:29 PM, Wayne Fay wrote:
 Bunch of thanks to all for sharing the info.  Yes my war is very big.  Its
 size is almost 62MB.  It builds in 7 mins than other machines.  It uses 30
 dependencies and xml resources.
 7 minutes is a long time just to build what is essentially a zip file.
 Perhaps invest in some SSD hardware and perform your builds on
 server-class machines rather than pokey laptops via a CI server like
 Jenkins/Hudson or something along those lines.

 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


CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

Re: help - how to reduce the build time using mvn and cargo

[Ron Wheeler]

By this time on a Friday 3s look like 7s.

We had to remove over 70 out of our build.
It made lots of things better.

Some dependencies such as CXF for Web services are huge and getting them 
as provided was a big help since we had a dozen or so webapps in our LMS 
portal that used web services.


 If 70 can be removed will the WAR file be a negative size and give you 
back disk space when you build it?


Ron

On 13/05/2011 5:10 PM, EJ Ciramella wrote:

Heh - I see 30 dependencies mentioned below, is this a trick answer?

(sorry, trolling as I wait for posts to my questions)

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Friday, May 13, 2011 5:08 PM
To: users@maven.apache.org
Subject: Re: help - how to reduce the build time using mvn and cargo

Getting the 70 dependencies out of the build will yield the biggest ROI.

Ron

On 13/05/2011 4:29 PM, Wayne Fay wrote:

Bunch of thanks to all for sharing the info.  Yes my war is very big.  Its
size is almost 62MB.  It builds in 7 mins than other machines.  It uses 30
dependencies and xml resources.

7 minutes is a long time just to build what is essentially a zip file.
Perhaps invest in some SSD hardware and perform your builds on
server-class machines rather than pokey laptops via a CI server like
Jenkins/Hudson or something along those lines.

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


CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.



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

Re: help - how to reduce the build time using mvn and cargo

[John Singleton]

In addition to trimming the war (definitely a good idea)...

In your first post, you mentioned mvn.bat - so I will assume you are in a
Windows environment.  Where is your ${user.home} located: local or remote?
I have seen at least one corporate environment where (for Sysadmin
convenience) home directories were kept on a central server.  This was not a
big deal to Word and PowerPoint users, who only download one file at a time,
but a huge hit to maven as people were constantly hitting .m2/repository
*ACROSS-THE-WIRE*.

On Fri, May 13, 2011 at 5:10 PM, EJ Ciramella ecirame...@casenetinc.comwrote:

 Heh - I see 30 dependencies mentioned below, is this a trick answer?

 (sorry, trolling as I wait for posts to my questions)

 -Original Message-
 From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
 Sent: Friday, May 13, 2011 5:08 PM
 To: users@maven.apache.org
 Subject: Re: help - how to reduce the build time using mvn and cargo

 Getting the 70 dependencies out of the build will yield the biggest ROI.

 Ron

 On 13/05/2011 4:29 PM, Wayne Fay wrote:
  Bunch of thanks to all for sharing the info.  Yes my war is very big.
  Its
  size is almost 62MB.  It builds in 7 mins than other machines.  It uses
 30
  dependencies and xml resources.
  7 minutes is a long time just to build what is essentially a zip file.
  Perhaps invest in some SSD hardware and perform your builds on
  server-class machines rather than pokey laptops via a CI server like
  Jenkins/Hudson or something along those lines.
 
  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


 CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within
 including any attachments is only for the recipient(s) to which it is
 intended and may contain confidential and/or privileged material. Any
 review, retransmission, dissemination or other use of; or taking of any
 action in reliance upon this information by persons or entities other than
 the intended recipient is prohibited. If you received this in error, please
 send the e-mail back by replying to the sender and permanently delete the
 entire message and its attachments from all computers and network systems
 involved in its receipt.

RE: help - how to reduce the build time using mvn and cargo

[EJ Ciramella]

100 points to Ron.

Ron touched on something here - not sure if you can look at any of the 
transitive dependencies you may be pulling in and see if you can exclude some 
of those as well.

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Friday, May 13, 2011 5:24 PM
To: users@maven.apache.org
Subject: Re: help - how to reduce the build time using mvn and cargo

By this time on a Friday 3s look like 7s.

We had to remove over 70 out of our build.
It made lots of things better.

Some dependencies such as CXF for Web services are huge and getting them
as provided was a big help since we had a dozen or so webapps in our LMS
portal that used web services.

  If 70 can be removed will the WAR file be a negative size and give you
back disk space when you build it?

Ron


CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

help - how to reduce the build time using mvn and cargo

[javadaisy]

Hi,

I am using maven 2.2.1 with cargo plugin to deploy into the local and remote
host.  It takes around 7 to 8 minutes to build and deploy the war.  I would
like to reduce the time to 3 minutes or less than 3 minutes.  can anybody
please tell me how to do that?.

I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It didn't
work

Thanks in advance.

--
View this message in context: 
http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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: help - how to reduce the build time using mvn and cargo

[Anders Hammar]

Seriously, what kind of answer are you expecting to this question? There
isn't any magic configuration like -DreduceBuildTime=true.

/Anders

On Thu, May 12, 2011 at 18:53, javadaisy javada...@gmail.com wrote:

 Hi,

 I am using maven 2.2.1 with cargo plugin to deploy into the local and
 remote
 host.  It takes around 7 to 8 minutes to build and deploy the war.  I would
 like to reduce the time to 3 minutes or less than 3 minutes.  can anybody
 please tell me how to do that?.

 I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It
 didn't
 work

 Thanks in advance.

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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: help - how to reduce the build time using mvn and cargo

[Martin Gainty]

-DGetPaidForSomeoneElseDoingMyJobForMe=true

Only in Amerika!
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Thu, 12 May 2011 19:18:48 +0200
 Subject: Re: help - how to reduce the build time using mvn and cargo
 From: and...@hammar.net
 To: users@maven.apache.org
 
 Seriously, what kind of answer are you expecting to this question? There
 isn't any magic configuration like -DreduceBuildTime=true.
 
 /Anders
 
 On Thu, May 12, 2011 at 18:53, javadaisy javada...@gmail.com wrote:
 
  Hi,
 
  I am using maven 2.2.1 with cargo plugin to deploy into the local and
  remote
  host.  It takes around 7 to 8 minutes to build and deploy the war.  I would
  like to reduce the time to 3 minutes or less than 3 minutes.  can anybody
  please tell me how to do that?.
 
  I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It
  didn't
  work
 
  Thanks in advance.
 
  --
  View this message in context:
  http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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: help - how to reduce the build time using mvn and cargo

[John Singleton]

Well, the first step would be determining exactly where your build is
spending its time - compiling, building the war, deploying the war (locally
and/or remotely)?  If your current build output doesn't give enough
information, try mvn -X for more verbose output.  Then you will have a
better idea where to look for improvement.  I doubt that the maven memory
footprint is the source of your speed issues.

On Thu, May 12, 2011 at 12:53 PM, javadaisy javada...@gmail.com wrote:

 Hi,

 I am using maven 2.2.1 with cargo plugin to deploy into the local and
 remote
 host.  It takes around 7 to 8 minutes to build and deploy the war.  I would
 like to reduce the time to 3 minutes or less than 3 minutes.  can anybody
 please tell me how to do that?.

 I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It
 didn't
 work

 Thanks in advance.

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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: help - how to reduce the build time using mvn and cargo

[EJ Ciramella]

I giggled at the first few replies to this thread, but now I'm curious - when 
you're finished building, and maven presents the summary output, which modules 
are taking the longest time and what exactly are they doing?


 Hi,

 I am using maven 2.2.1 with cargo plugin to deploy into the local and
 remote
 host.  It takes around 7 to 8 minutes to build and deploy the war.  I would
 like to reduce the time to 3 minutes or less than 3 minutes.  can anybody
 please tell me how to do that?.

 I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It
 didn't
 work

 Thanks in advance.

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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



CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

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

Re: help - how to reduce the build time using mvn and cargo

[javadaisy]

Thanks for pointing me to the right direction.  For clean and compile it
takes around 1Min and it takes around 3 1/2 mins for packaging the war file.  

--
View this message in context: 
http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4391561.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: help - how to reduce the build time using mvn and cargo

[Ron Wheeler]

On 12/05/2011 12:53 PM, javadaisy wrote:

Hi,

I am using maven 2.2.1 with cargo plugin to deploy into the local and remote
host.  It takes around 7 to 8 minutes to build and deploy the war.  I would
like to reduce the time to 3 minutes or less than 3 minutes.  can anybody
please tell me how to do that?.

I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat.  It didn't
work


How big is the WAR file?
There are physical limits to the speed at which disk drives work.

How long does it take on other machines? Is it only slow on some 
workstations?


One of the most effective tricks is to segregate third party libraries 
into sharable JARs that you only build once and deploy to the servlet 
engine (Tomcat) once.
You set these as provided in the WAR file's POM  and suddenly the 
build creates a WAR that is 20 Mb smaller and builds 10 times faster.
Things like CXF (Web Services) add 20Mb to each WAR. If you make it 
shareable and scope it as provided in the POM, the WAR drops to a few 
tens of kilobytes that builds PDQ.


We have done this is 10+ cases to get common third-party and our own 
utilities out of our 60+ WAR files that implement services and servlets.

- Spring, Hibernate, MySQL in one shared jar
- CXF
- JasperReports
- Apache Commons - lots of modules that everyone uses.
- our messaging/e-mail utility
- our facades that simplify our internal connections
- API and core functions that define the ORM and business processes

The WARs now contain only the code and resources that uniquely exist to  
support the WAR's functionality.


It also eliminates the jar hell of conflicting versions of common 
dependencies. Once you decide which version of commons-logging you want 
to use, everyone gets it.


POM files get really small since they only refer to 10 dependencies or 
less (typically 5 dependencies)  to get all of the 90+ officially 
sanctioned libraries.


Big help at run-time as well.

Ron


Thanks in advance.

--
View this message in context: 
http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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

Jar Signing eats up build time

[fgfggf fgfggf]

We have a legacy project that is pretty heinous in terms of build time and
this is severely affecting delivery times.  There are many pieces of
refactoring to break this down into a more manageable build, that need to be
done, but one quick win is to sort out the signing of dependencies and
transient dependencies.

There’s three modules where this occurs, and on a clean install it will sign
spring, etc. once, then move onto the next webstart application and sign
many of the same jars again. Ie. noddy-app-webstart signs all of spring,
then shoddy-app-webstart signs all of spring again.  This is also wasteful
as the cert does not expire for several years.

I can think of a few things to solve this but they greatly increase
management of the build, for example, deploying the artifacts signed to a
maven repo would be one approach and then only pulling in the classified
version.  However, this makes adding in new dependencies a pain and the
build less portable.   It will also take a lot of time upfront to sign and
then deploy the classified versions (unless there’s a plug-in that can be
run against the project to take the depedendencies, sign them and then
deploy them classified).

Using profiles to disable signing can also be done for development builds,
but this makes the dev builds inconsistent to the live builds and there’s
still the long time it takes to do a live build.

Are there other solutions to this problem?

Auto Generate Text File at Build Time

[dpark]

How do I go about auto generating a text file during my build? (ignored by
CVS)
Is there a plugin for this?

Thanks,

DP
-- 
View this message in context: 
http://www.nabble.com/Auto-Generate-Text-File-at-Build-Time-tp26097319p26097319.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: Auto Generate Text File at Build Time

[Edelson, Justin]

Generated files should go in a subdirectory of the target directory,
which should be in .cvsignore (and is automatically ignored goals which
use Maven SCM, IIRC).

There are a variety of code generation plugins around. Most of these are
built around specific types of generation (e.g. javacc, hibernate), but
there are generic ones like the xslt plugin at mojo.codehaus.org. You
can also use the Groovy or JRuby plugins to accomplish this.

Justin

-Original Message-
From: dpark [mailto:dp...@exchangesolutions.com] 
Sent: Wednesday, October 28, 2009 12:02 PM
To: users@maven.apache.org
Subject: Auto Generate Text File at Build Time


How do I go about auto generating a text file during my build? (ignored
by
CVS)
Is there a plugin for this?

Thanks,

DP
--
View this message in context:
http://www.nabble.com/Auto-Generate-Text-File-at-Build-Time-tp26097319p2
6097319.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: Auto Generate Text File at Build Time

[Michael Remijan]

I think one thing you'll need to do is add a .cvsignore file in the directory 
which the file gets generated and add the name of the file to .cvsignore.  That 
way synchronizing with CVS won't bother with the file.  





From: dpark dp...@exchangesolutions.com
To: users@maven.apache.org
Sent: Wed, October 28, 2009 11:01:44 AM
Subject: Auto Generate Text File at Build Time


How do I go about auto generating a text file during my build? (ignored by
CVS)
Is there a plugin for this?

Thanks,

DP
-- 
View this message in context: 
http://www.nabble.com/Auto-Generate-Text-File-at-Build-Time-tp26097319p26097319.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

Is it possible to use a build time property for resource filtering?

[Torben S. Giesselmann]

Hi there,

I am setting a system property timestamp in the early stage of my build
by executing a Groovy script. I'd like to use that property later during
resource filtering. Nice idea, but doesn't work, the property is ignored.

My resource file looks like this:

application.timestamp=${timestamp}


Here's how I set the system property:

build

!-- ENABLE RESOURCE FILTERING --
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources

plugins
  plugin
groupIdorg.codehaus.groovy.maven/groupId
artifactIdgmaven-plugin/artifactId
version1.0-rc-4/version
executions
  !-- GENERATE TIMESTAMP --
  execution
idgenerate-timestamp/id
phasevalidate/phase
goals
  goalexecute/goal
/goals
configuration
  sourceimport java.text.SimpleDateFormat;
System.setProperty(timestamp, new
SimpleDateFormat(-MM-dd HH:mm).format(new
Date()))/source
/configuration
  /execution

  !-- TEST TIMESTAMP --
  execution
idprint-timestamp/id
phasevalidate/phase
goals
  goalexecute/goal
/goals
configuration
  sourceprintln Timestamp:  +
System.getProperty(timestamp)/source
/configuration
  /execution
/executions
  /plugin
/plugins
/build


If you execute this, you'll notice that the property can be read correctly
in the execution print-timestamp. But still, it gets ignored during
resource filtering.

Am I missing something here? Is it impossible to set new properties at
build time and have those filtered? Thanks in advance!

Best regards,
- Torben


-- 
Torben S. Giesselmann
tsg-sw...@foogoo.net

A clear conscience is usually the sign of a bad memory.


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

RE: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Brian E. Fox]

Nothing immediate pops into my head, but what if you could hook your CI system 
to monitor these external xsds and use that to trigger the build?

The only way to stop the build currently is via the enforcer plugin, you could 
make a custom rule...but it would be seen to the CI as a build failure.

-Original Message-
From: les.hazlew...@anjinllc.com [mailto:les.hazlew...@anjinllc.com] On Behalf 
Of Les Hazlewood
Sent: Wednesday, February 25, 2009 5:56 PM
To: users@maven.apache.org
Subject: Conditional plugin execution based on build time behavior - Maven 
profiles not sufficient?

Hi folks,

Here's what I'm trying to achieve:

I have a build that must run every 5 minutes or so in a Continuous
Integration server.  It must do this because it downloads information that
exists outside of a Maven artifact repository or any build environment and
must regularly check to see if information has changed.  If the information
source has changed in any way, my Maven build must create a new SNAPSHOT
.jar to reflect the change.

If the information doesn't change, a new .jar should never be created or
deployed to the repository.  This is to avoid uploading a new snapshot .jar
every 5 minutes to the repository, and consequently having developers all
download this snapshot as a dependency every time they build (yuck).

Is there a way to pre-emptively stop a build in order to prevent the .jar
from being created/installed/deployed?  I don't want to fail the build,
because this case is not a failure - the build would have correctly stopped
short the lifecycle specifically because the .jar should not be created.

This behavior would exclude standard Maven profiles as a solution as I
understand them because they're only activated based on some condition when
the build starts.  The knowledge of if a build should be 'short circuited'
would only be available after this plugin finished executing.

--
Now, here's my very specific use case of why I'd like to do this (but should
probably work generically as described above), in case you're curious:

My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files representing
these .xsd files, creates a .jar file and deploys this .jar to a maven
repository.  Other applications consume this 'Java XSD stubs' .jar to call
web services and are quite happy, but they should automatically be updated
if the .XSD contracts change, so they can eagerly adapt to these points of
change, in true Continuous Integration fashion.

But I only want the .jar to be created and deployed to the maven repository
if one or more of the downloaded .xsd files are different compared to the
last time the build was executed.  If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen

Everything is working except for the part where I pre-emptively exit the
build, but without Failing the build.

Anyone have any ideas?

Thanks SO much for feedback!

Cheers,

Les

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Wendy Smoak]

On Wed, Feb 25, 2009 at 3:56 PM, Les Hazlewood l...@hazlewood.com wrote:

 I have a build that must run every 5 minutes or so in a Continuous
 Integration server.  It must do this because it downloads information that
 exists outside of a Maven artifact repository or any build environment and
 must regularly check to see if information has changed.  If the information
 source has changed in any way, my Maven build must create a new SNAPSHOT
 .jar to reflect the change.

 If the information doesn't change, a new .jar should never be created or
 deployed to the repository.  This is to avoid uploading a new snapshot .jar
 every 5 minutes to the repository, and consequently having developers all
 download this snapshot as a dependency every time they build (yuck).

How about having something outside the build process do the
monitoring, and kick off a build only when it sees a change?  Your CI
server probably has a way to force a build with a program or script.

You could still run the monitoring process in the build server if
that's important, it would just be a separate build.  The full project
build wouldn't happen on a schedule, but only when requested.

-- 
Wendy

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

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Jason van Zyl]

Not sure if this works in 2.x (it should, I know it works in 3.x) but  
I'll make an enforcer rule, or small plugin in the validate phase,  
which will detect the changed. Based on the outcome set the skip  
deploy option programmatically. Not the most efficient as the build  
will still happen but the JAR will not get deployed and the build  
won't fail.


On 25-Feb-09, at 2:56 PM, Les Hazlewood wrote:


Hi folks,

Here's what I'm trying to achieve:

I have a build that must run every 5 minutes or so in a Continuous
Integration server.  It must do this because it downloads  
information that
exists outside of a Maven artifact repository or any build  
environment and
must regularly check to see if information has changed.  If the  
information
source has changed in any way, my Maven build must create a new  
SNAPSHOT

.jar to reflect the change.

If the information doesn't change, a new .jar should never be  
created or
deployed to the repository.  This is to avoid uploading a new  
snapshot .jar
every 5 minutes to the repository, and consequently having  
developers all

download this snapshot as a dependency every time they build (yuck).

Is there a way to pre-emptively stop a build in order to prevent  
the .jar
from being created/installed/deployed?  I don't want to fail the  
build,
because this case is not a failure - the build would have correctly  
stopped
short the lifecycle specifically because the .jar should not be  
created.


This behavior would exclude standard Maven profiles as a solution as I
understand them because they're only activated based on some  
condition when
the build starts.  The knowledge of if a build should be 'short  
circuited'

would only be available after this plugin finished executing.

--
Now, here's my very specific use case of why I'd like to do this  
(but should

probably work generically as described above), in case you're curious:

My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files  
representing

these .xsd files, creates a .jar file and deploys this .jar to a maven
repository.  Other applications consume this 'Java XSD stubs' .jar  
to call
web services and are quite happy, but they should automatically be  
updated
if the .XSD contracts change, so they can eagerly adapt to these  
points of

change, in true Continuous Integration fashion.

But I only want the .jar to be created and deployed to the maven  
repository
if one or more of the downloaded .xsd files are different compared  
to the

last time the build was executed.  If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen

Everything is working except for the part where I pre-emptively exit  
the

build, but without Failing the build.

Anyone have any ideas?

Thanks SO much for feedback!

Cheers,

Les


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--

Simplex sigillum veri. (Simplicity is the seal of truth.)


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

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Les Hazlewood]

I _just_ saw a maven.deploy.skip property that the existing 2.4 deploy
plugin will check.  I'm perfectly fine with doing what you suggest Jason,
thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).

But, that property can be set programmatically via another plugin?

Maybe something like the following?

/**
 * @parameter expression=${project}
 */
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
  final Properties projectProperties = mavenProject.getProperties();
  projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}

Will that work?

I'm not aware of when property binding occurs - i.e. if their values can be
changed by plugins or if they're permanently set before the lifecycle starts
after reading the pom.

Thanks for any clarification - I think I'm close!

Les

On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl jvan...@sonatype.comwrote:

 Not sure if this works in 2.x (it should, I know it works in 3.x) but I'll
 make an enforcer rule, or small plugin in the validate phase, which will
 detect the changed. Based on the outcome set the skip deploy option
 programmatically. Not the most efficient as the build will still happen but
 the JAR will not get deployed and the build won't fail.


 On 25-Feb-09, at 2:56 PM, Les Hazlewood wrote:

  Hi folks,

 Here's what I'm trying to achieve:

 I have a build that must run every 5 minutes or so in a Continuous
 Integration server.  It must do this because it downloads information that
 exists outside of a Maven artifact repository or any build environment and
 must regularly check to see if information has changed.  If the
 information
 source has changed in any way, my Maven build must create a new SNAPSHOT
 .jar to reflect the change.

 If the information doesn't change, a new .jar should never be created or
 deployed to the repository.  This is to avoid uploading a new snapshot
 .jar
 every 5 minutes to the repository, and consequently having developers all
 download this snapshot as a dependency every time they build (yuck).

 Is there a way to pre-emptively stop a build in order to prevent the .jar
 from being created/installed/deployed?  I don't want to fail the build,
 because this case is not a failure - the build would have correctly
 stopped
 short the lifecycle specifically because the .jar should not be created.

 This behavior would exclude standard Maven profiles as a solution as I
 understand them because they're only activated based on some condition
 when
 the build starts.  The knowledge of if a build should be 'short circuited'
 would only be available after this plugin finished executing.

 --
 Now, here's my very specific use case of why I'd like to do this (but
 should
 probably work generically as described above), in case you're curious:

 My plugin downloads .xsd files from well-known locations (not maven
 repositories), auto-generates .java (and then .class) files representing
 these .xsd files, creates a .jar file and deploys this .jar to a maven
 repository.  Other applications consume this 'Java XSD stubs' .jar to call
 web services and are quite happy, but they should automatically be updated
 if the .XSD contracts change, so they can eagerly adapt to these points of
 change, in true Continuous Integration fashion.

 But I only want the .jar to be created and deployed to the maven
 repository
 if one or more of the downloaded .xsd files are different compared to the
 last time the build was executed.  If the files don't change between
 5-minute cycles (verified by downloading them and comparing to the
 previously retrieved files), nothing should happen

 Everything is working except for the part where I pre-emptively exit the
 build, but without Failing the build.

 Anyone have any ideas?

 Thanks SO much for feedback!

 Cheers,

 Les


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 --

 Simplex sigillum veri. (Simplicity is the seal of truth.)



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

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Les Hazlewood]

Hi Wendy,

Thanks very much for the feedback, I certainly appreciate it.

Yes, our CI server definitely supports executing a script.  We could just
take our logic, throw it in a groovy script, and if the .xsd files have
changed, have that groovy script just kick off the maven build.

I wanted to avoid this if possible - currently everything in our CI server
is a nice standard Maven build.  I want to avoid these kinds of permutations
to avoid confusion:  CI and even Maven are extremely new concepts at my
company and anything to avoid the perception of complexity is a good thing
:)

Jason's suggestion sounds promising - can you confirm if that property can
be set dynamically by another plugin?

Thanks,

Les

On Thu, Feb 26, 2009 at 9:55 AM, Wendy Smoak wsm...@gmail.com wrote:

 On Wed, Feb 25, 2009 at 3:56 PM, Les Hazlewood l...@hazlewood.com wrote:

  I have a build that must run every 5 minutes or so in a Continuous
  Integration server.  It must do this because it downloads information
 that
  exists outside of a Maven artifact repository or any build environment
 and
  must regularly check to see if information has changed.  If the
 information
  source has changed in any way, my Maven build must create a new SNAPSHOT
  .jar to reflect the change.
 
  If the information doesn't change, a new .jar should never be created or
  deployed to the repository.  This is to avoid uploading a new snapshot
 .jar
  every 5 minutes to the repository, and consequently having developers all
  download this snapshot as a dependency every time they build (yuck).

 How about having something outside the build process do the
 monitoring, and kick off a build only when it sees a change?  Your CI
 server probably has a way to force a build with a program or script.

 You could still run the monitoring process in the build server if
 that's important, it would just be a separate build.  The full project
 build wouldn't happen on a schedule, but only when requested.

 --
 Wendy

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

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Jason van Zyl]

All works fine, but you need to use version 2.4 of the deploy plugin.

Full working example is here:

http://people.apache.org/~jvanzyl/les.tgz

There's a plugin and a project that uses the plugin. Build/install the  
plugin, then mvn clean deploy the test project and you'll see it  
doesn't deploy.


On 26-Feb-09, at 7:59 AM, Les Hazlewood wrote:

I _just_ saw a maven.deploy.skip property that the existing 2.4  
deploy
plugin will check.  I'm perfectly fine with doing what you suggest  
Jason,

thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).

But, that property can be set programmatically via another plugin?

Maybe something like the following?

/**
* @parameter expression=${project}
*/
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
 final Properties projectProperties = mavenProject.getProperties();
 projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}

Will that work?

I'm not aware of when property binding occurs - i.e. if their values  
can be
changed by plugins or if they're permanently set before the  
lifecycle starts

after reading the pom.

Thanks for any clarification - I think I'm close!

Les

On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl  
jvan...@sonatype.comwrote:


Not sure if this works in 2.x (it should, I know it works in 3.x)  
but I'll
make an enforcer rule, or small plugin in the validate phase, which  
will

detect the changed. Based on the outcome set the skip deploy option
programmatically. Not the most efficient as the build will still  
happen but

the JAR will not get deployed and the build won't fail.


On 25-Feb-09, at 2:56 PM, Les Hazlewood wrote:

Hi folks,


Here's what I'm trying to achieve:

I have a build that must run every 5 minutes or so in a Continuous
Integration server.  It must do this because it downloads  
information that
exists outside of a Maven artifact repository or any build  
environment and

must regularly check to see if information has changed.  If the
information
source has changed in any way, my Maven build must create a new  
SNAPSHOT

.jar to reflect the change.

If the information doesn't change, a new .jar should never be  
created or
deployed to the repository.  This is to avoid uploading a new  
snapshot

.jar
every 5 minutes to the repository, and consequently having  
developers all

download this snapshot as a dependency every time they build (yuck).

Is there a way to pre-emptively stop a build in order to prevent  
the .jar
from being created/installed/deployed?  I don't want to fail the  
build,

because this case is not a failure - the build would have correctly
stopped
short the lifecycle specifically because the .jar should not be  
created.


This behavior would exclude standard Maven profiles as a solution  
as I
understand them because they're only activated based on some  
condition

when
the build starts.  The knowledge of if a build should be 'short  
circuited'

would only be available after this plugin finished executing.

--
Now, here's my very specific use case of why I'd like to do this  
(but

should
probably work generically as described above), in case you're  
curious:


My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files  
representing
these .xsd files, creates a .jar file and deploys this .jar to a  
maven
repository.  Other applications consume this 'Java XSD stubs' .jar  
to call
web services and are quite happy, but they should automatically be  
updated
if the .XSD contracts change, so they can eagerly adapt to these  
points of

change, in true Continuous Integration fashion.

But I only want the .jar to be created and deployed to the maven
repository
if one or more of the downloaded .xsd files are different compared  
to the

last time the build was executed.  If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen

Everything is working except for the part where I pre-emptively  
exit the

build, but without Failing the build.

Anyone have any ideas?

Thanks SO much for feedback!

Cheers,

Les



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--

Simplex sigillum veri. (Simplicity is the seal of truth.)



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




Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--

You are never dedicated to something you have complete 

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Jason van Zyl]

All works fine, but you need to use version 2.4 of the deploy plugin.

Full working example is here:

http://people.apache.org/~jvanzyl/les.tgz

There's a plugin and a project that uses the plugin. Build/install the  
plugin, then mvn clean deploy the test project and you'll see it  
doesn't deploy.


On 26-Feb-09, at 7:59 AM, Les Hazlewood wrote:

I _just_ saw a maven.deploy.skip property that the existing 2.4  
deploy
plugin will check.  I'm perfectly fine with doing what you suggest  
Jason,

thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).

But, that property can be set programmatically via another plugin?

Maybe something like the following?

/**
* @parameter expression=${project}
*/
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
final Properties projectProperties = mavenProject.getProperties();
projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}

Will that work?

I'm not aware of when property binding occurs - i.e. if their values  
can be
changed by plugins or if they're permanently set before the  
lifecycle starts

after reading the pom.

Thanks for any clarification - I think I'm close!

Les

On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl  
jvan...@sonatype.comwrote:


Not sure if this works in 2.x (it should, I know it works in 3.x)  
but I'll
make an enforcer rule, or small plugin in the validate phase, which  
will

detect the changed. Based on the outcome set the skip deploy option
programmatically. Not the most efficient as the build will still  
happen but

the JAR will not get deployed and the build won't fail.


On 25-Feb-09, at 2:56 PM, Les Hazlewood wrote:

Hi folks,


Here's what I'm trying to achieve:

I have a build that must run every 5 minutes or so in a Continuous
Integration server.  It must do this because it downloads  
information that
exists outside of a Maven artifact repository or any build  
environment and

must regularly check to see if information has changed.  If the
information
source has changed in any way, my Maven build must create a new  
SNAPSHOT

.jar to reflect the change.

If the information doesn't change, a new .jar should never be  
created or
deployed to the repository.  This is to avoid uploading a new  
snapshot

.jar
every 5 minutes to the repository, and consequently having  
developers all

download this snapshot as a dependency every time they build (yuck).

Is there a way to pre-emptively stop a build in order to prevent  
the .jar
from being created/installed/deployed?  I don't want to fail the  
build,

because this case is not a failure - the build would have correctly
stopped
short the lifecycle specifically because the .jar should not be  
created.


This behavior would exclude standard Maven profiles as a solution  
as I
understand them because they're only activated based on some  
condition

when
the build starts.  The knowledge of if a build should be 'short  
circuited'

would only be available after this plugin finished executing.

--
Now, here's my very specific use case of why I'd like to do this  
(but

should
probably work generically as described above), in case you're  
curious:


My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files  
representing
these .xsd files, creates a .jar file and deploys this .jar to a  
maven
repository.  Other applications consume this 'Java XSD stubs' .jar  
to call
web services and are quite happy, but they should automatically be  
updated
if the .XSD contracts change, so they can eagerly adapt to these  
points of

change, in true Continuous Integration fashion.

But I only want the .jar to be created and deployed to the maven
repository
if one or more of the downloaded .xsd files are different compared  
to the

last time the build was executed.  If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen

Everything is working except for the part where I pre-emptively  
exit the

build, but without Failing the build.

Anyone have any ideas?

Thanks SO much for feedback!

Cheers,

Les



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--

Simplex sigillum veri. (Simplicity is the seal of truth.)



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




Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--

You are never dedicated to something you have complete 

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Les Hazlewood]

Beautiful - I just tested with 2.4 and it works wonderfully.  Thanks to all
who contributed to this thread!

Cheers,

Les

On Thu, Feb 26, 2009 at 11:48 AM, Jason van Zyl jvan...@sonatype.comwrote:

 All works fine, but you need to use version 2.4 of the deploy plugin.

 Full working example is here:

 http://people.apache.org/~jvanzyl/les.tgzhttp://people.apache.org/%7Ejvanzyl/les.tgz

 There's a plugin and a project that uses the plugin. Build/install the
 plugin, then mvn clean deploy the test project and you'll see it doesn't
 deploy.


 On 26-Feb-09, at 7:59 AM, Les Hazlewood wrote:

  I _just_ saw a maven.deploy.skip property that the existing 2.4 deploy
 plugin will check.  I'm perfectly fine with doing what you suggest Jason,
 thanks very much for the recommendation (I don't care about the minor
 inefficiency in this case).

 But, that property can be set programmatically via another plugin?

 Maybe something like the following?

 /**
 * @parameter expression=${project}
 */
 private MavenProject mavenProject;
 ...
 public void execute() {
 boolean shouldSkip = //determined in some way
 if ( shouldSkip ) {
  final Properties projectProperties = mavenProject.getProperties();
  projectProperties.put( maven.deploy.skip, Boolean.TRUE);
 }
 ...
 }

 Will that work?

 I'm not aware of when property binding occurs - i.e. if their values can
 be
 changed by plugins or if they're permanently set before the lifecycle
 starts
 after reading the pom.

 Thanks for any clarification - I think I'm close!

 Les

 On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl jvan...@sonatype.com
 wrote:

  Not sure if this works in 2.x (it should, I know it works in 3.x) but
 I'll
 make an enforcer rule, or small plugin in the validate phase, which will
 detect the changed. Based on the outcome set the skip deploy option
 programmatically. Not the most efficient as the build will still happen
 but
 the JAR will not get deployed and the build won't fail.


 On 25-Feb-09, at 2:56 PM, Les Hazlewood wrote:

 Hi folks,


 Here's what I'm trying to achieve:

 I have a build that must run every 5 minutes or so in a Continuous
 Integration server.  It must do this because it downloads information
 that
 exists outside of a Maven artifact repository or any build environment
 and
 must regularly check to see if information has changed.  If the
 information
 source has changed in any way, my Maven build must create a new SNAPSHOT
 .jar to reflect the change.

 If the information doesn't change, a new .jar should never be created or
 deployed to the repository.  This is to avoid uploading a new snapshot
 .jar
 every 5 minutes to the repository, and consequently having developers
 all
 download this snapshot as a dependency every time they build (yuck).

 Is there a way to pre-emptively stop a build in order to prevent the
 .jar
 from being created/installed/deployed?  I don't want to fail the build,
 because this case is not a failure - the build would have correctly
 stopped
 short the lifecycle specifically because the .jar should not be created.

 This behavior would exclude standard Maven profiles as a solution as I
 understand them because they're only activated based on some condition
 when
 the build starts.  The knowledge of if a build should be 'short
 circuited'
 would only be available after this plugin finished executing.

 --
 Now, here's my very specific use case of why I'd like to do this (but
 should
 probably work generically as described above), in case you're curious:

 My plugin downloads .xsd files from well-known locations (not maven
 repositories), auto-generates .java (and then .class) files representing
 these .xsd files, creates a .jar file and deploys this .jar to a maven
 repository.  Other applications consume this 'Java XSD stubs' .jar to
 call
 web services and are quite happy, but they should automatically be
 updated
 if the .XSD contracts change, so they can eagerly adapt to these points
 of
 change, in true Continuous Integration fashion.

 But I only want the .jar to be created and deployed to the maven
 repository
 if one or more of the downloaded .xsd files are different compared to
 the
 last time the build was executed.  If the files don't change between
 5-minute cycles (verified by downloading them and comparing to the
 previously retrieved files), nothing should happen

 Everything is working except for the part where I pre-emptively exit the
 build, but without Failing the build.

 Anyone have any ideas?

 Thanks SO much for feedback!

 Cheers,

 Les


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 --

 Simplex sigillum veri. (Simplicity is the seal of truth.)



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

Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Les Hazlewood]

Hi folks,

Here's what I'm trying to achieve:

I have a build that must run every 5 minutes or so in a Continuous
Integration server.  It must do this because it downloads information that
exists outside of a Maven artifact repository or any build environment and
must regularly check to see if information has changed.  If the information
source has changed in any way, my Maven build must create a new SNAPSHOT
.jar to reflect the change.

If the information doesn't change, a new .jar should never be created or
deployed to the repository.  This is to avoid uploading a new snapshot .jar
every 5 minutes to the repository, and consequently having developers all
download this snapshot as a dependency every time they build (yuck).

Is there a way to pre-emptively stop a build in order to prevent the .jar
from being created/installed/deployed?  I don't want to fail the build,
because this case is not a failure - the build would have correctly stopped
short the lifecycle specifically because the .jar should not be created.

This behavior would exclude standard Maven profiles as a solution as I
understand them because they're only activated based on some condition when
the build starts.  The knowledge of if a build should be 'short circuited'
would only be available after this plugin finished executing.

--
Now, here's my very specific use case of why I'd like to do this (but should
probably work generically as described above), in case you're curious:

My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files representing
these .xsd files, creates a .jar file and deploys this .jar to a maven
repository.  Other applications consume this 'Java XSD stubs' .jar to call
web services and are quite happy, but they should automatically be updated
if the .XSD contracts change, so they can eagerly adapt to these points of
change, in true Continuous Integration fashion.

But I only want the .jar to be created and deployed to the maven repository
if one or more of the downloaded .xsd files are different compared to the
last time the build was executed.  If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen

Everything is working except for the part where I pre-emptively exit the
build, but without Failing the build.

Anyone have any ideas?

Thanks SO much for feedback!

Cheers,

Les

Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?

[Brett Porter]

I can see a few options.

The best solution is to find some way to get your CI server to detect  
the XSD changes as a trigger for the build instead.


From a Maven point of a view, you might be looking at building a  
conditional deploy plugin. Extending the current one and providing  
limited (if any) arguments should not make this a difficult task - and  
the plugin itself would check if it needs to deploy, then call back to  
the original deploy plugin using Java code.


A more generic alternative might be to enhance the deploy plugin to  
(optionally) not deploy anything if the checksum matches the previous  
snapshot.


A slightly different approach if you don't want to muck with the  
deploy plugin would be a plugin that is run standalone, checks for the  
updated XSD, and if found runs the build up to the given phase (by re- 
running Maven, basically in the same way as the reactor plugin).


Hope this helps!

- Brett

On 26/02/2009, at 9:56 AM, Les Hazlewood wrote:


Hi folks,

Here's what I'm trying to achieve:

I have a build that must run every 5 minutes or so in a Continuous
Integration server.  It must do this because it downloads  
information that
exists outside of a Maven artifact repository or any build  
environment and
must regularly check to see if information has changed.  If the  
information
source has changed in any way, my Maven build must create a new  
SNAPSHOT

.jar to reflect the change.

If the information doesn't change, a new .jar should never be  
created or
deployed to the repository.  This is to avoid uploading a new  
snapshot .jar
every 5 minutes to the repository, and consequently having  
developers all

download this snapshot as a dependency every time they build (yuck).

Is there a way to pre-emptively stop a build in order to prevent  
the .jar
from being created/installed/deployed?  I don't want to fail the  
build,
because this case is not a failure - the build would have correctly  
stopped
short the lifecycle specifically because the .jar should not be  
created.


This behavior would exclude standard Maven profiles as a solution as I
understand them because they're only activated based on some  
condition when
the build starts.  The knowledge of if a build should be 'short  
circuited'

would only be available after this plugin finished executing.

--
Now, here's my very specific use case of why I'd like to do this  
(but should

probably work generically as described above), in case you're curious:

My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files  
representing

these .xsd files, creates a .jar file and deploys this .jar to a maven
repository.  Other applications consume this 'Java XSD stubs' .jar  
to call
web services and are quite happy, but they should automatically be  
updated
if the .XSD contracts change, so they can eagerly adapt to these  
points of

change, in true Continuous Integration fashion.

But I only want the .jar to be created and deployed to the maven  
repository
if one or more of the downloaded .xsd files are different compared  
to the

last time the build was executed.  If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen

Everything is working except for the part where I pre-emptively exit  
the

build, but without Failing the build.

Anyone have any ideas?

Thanks SO much for feedback!

Cheers,

Les


--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


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

How to copy the resource files into my packaged folder in the build time?

[sean.chen(陈思淼)]

I define my own pakcaging type just like ear but have some customer file
type process.but sometimes, the project have some resources outside the
project.
I should copy that resources to that, in ant, i just use copy tag it
works.
but in maven, how can i copy the file to the folder? Is the antrun plugin
can do this kind of things?

Is there a standard way to provide build time properties to an application?

[Brewster, Richard]

The general idea is to create a properties file and package it in the
jar or war on the classpath, so it can be read at runtime.

Thanks,

Richard Brewster
Senior Associate
Perrin Quarles Associates
[EMAIL PROTECTED]
(434) 817-2640

Re: Is there a standard way to provide build time properties to an application?

[Manuel EVENO]

You mean dynamically create the properties file before packaging ?

On Fri, Jul 25, 2008 at 4:05 PM, Brewster, Richard
[EMAIL PROTECTED]wrote:

 The general idea is to create a properties file and package it in the
 jar or war on the classpath, so it can be read at runtime.

 Thanks,

 Richard Brewster
 Senior Associate
 Perrin Quarles Associates
 [EMAIL PROTECTED]
 (434) 817-2640

Re: Maven plugins that can check for hardcoded (un-externalized) strings at build time? (i18n)

[Rémy Sanlaville]

Hi,

I don't think so but it will be a useful plugin.

Rémy

Maven plugins that can check for hardcoded (un-externalized) strings at build time? (i18n)

[jonathanyu]

For internationalization purposes, are there any Maven plugins that would
check during build time for strings that aren't externalized to a resource
(.property) file?

For example, if I have code like this:

System.out.println(hello); //$NON-NLS-1$
System.out.println(world);

is there a maven tool that can alert me, perhaps in a report, that world
is not externalized to a property file AND isn't marks with a special marker
like //$NON-NLS-1$?  The special marker could also be /* NOI18N */.

Anything would help.  Thanks.


Jonathan
-- 
View this message in context: 
http://www.nabble.com/Maven-plugins-that-can-check-for-hardcoded-%28un-externalized%29-strings-at-build-time--%28i18n%29-tp15173563s177p15173563.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: how can I to use build time in pom files

[Rex Huang]

yes, this is work, but I don't know why it can't transfer this value via
properties.

Rex

On Jan 21, 2008 7:17 PM, Mick Knutson [EMAIL PROTECTED] wrote:

 actually, why can't you just add ${buildNumber} to your Versions.txt ???


 On Jan 21, 2008 10:17 AM, Mick Knutson [EMAIL PROTECTED] wrote:

  Add this to your filter.properties:
 
  BUILDTIME=${buildNumber}
 
 
 
  On Jan 21, 2008 9:10 AM, Rex Huang [EMAIL PROTECTED] wrote:
 
   yah, use buildnumber-maven-plugin may be better.
   one strange thing is I can't use ${buildNumber} in filter,
   when I want to replace $BUILDTIME in the resource file.
   such as:
   in pom.xml
  properties
  BUILDTIME${buildNumber}/BUILDTIME
  /properties
  
resource
  directorysrc/main/resources/directory
  filteringtrue/filtering
  includes
  includeVersion.txt/include
  /includes
/resource
  
   in Version.txt
   build-time= ${BUILDTIME}
  
 
 
 
  --
  Thanks,
  Mick Knutson
 
  http://www.baselogic.com
  http://www.blincmagazine.com
  http://www.djmick.com
  http://www.myspace.com/mickknutson
  http://www.myspace.com/BLiNCMagazine
  http://tahoe.baselogic.com
  ---




 --
 Thanks,
 Mick Knutson

 http://www.baselogic.com
 http://www.blincmagazine.com
 http://www.djmick.com
 http://www.myspace.com/mickknutson
 http://www.myspace.com/BLiNCMagazine
 http://tahoe.baselogic.com
 ---

Re: how can I to use build time in pom files

[Rex Huang]

I found information of maven-buildnumber-plugin here:
http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html
it's works!

Rex

On Jan 18, 2008 3:33 PM, Mark Eramo [EMAIL PROTECTED] wrote:

 Rex,
   Have a look at the Maven build number plugin. It may be able to do
 what you need.

 *http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html*

 Regards,
 Mark


 Rex Huang wrote:
  Does maven has build time property, which I can use in pom files
  my-property${build time}my-property
 
  BR//Rex
 
 

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

RE: how can I to use build time in pom files

[nicklist]

The newer version of this plugin is found here:

http://mojo.codehaus.org/buildnumber-maven-plugin/

And the artifacts can also be found on central:

http://mvnrepository.com/artifact/org.codehaus.mojo/buildnumber-maven-plugin

Hth,

Nick Stolwijk


-Original Message-
From: Rex Huang [mailto:[EMAIL PROTECTED]
Sent: Mon 1/21/2008 5:02 PM
To: Maven Users List
Subject: Re: how can I to use build time in pom files
 
I found information of maven-buildnumber-plugin here:
http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html
it's works!

Rex

On Jan 18, 2008 3:33 PM, Mark Eramo [EMAIL PROTECTED] wrote:

 Rex,
   Have a look at the Maven build number plugin. It may be able to do
 what you need.

 *http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html*

 Regards,
 Mark


 Rex Huang wrote:
  Does maven has build time property, which I can use in pom files
  my-property${build time}my-property
 
  BR//Rex
 
 

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

Re: how can I to use build time in pom files

[Mick Knutson]

!-- ===--
!-- Build Number Plugin --
!-- ===--
!--
This mojo is designed to get a unique build number for each
time you build your project. So while your version may
remain
constant at 1.0-SNAPSHOT for many iterations until release,
you
will have a build number that can uniquely identify each
build
during that time. The build number is obtained from scm, and
in
particular, at this time, from svn. You can then place that
build number in metadata, which can be accessed from your
app,
if desired.

The mojo also has a couple of extra functions to ensure you
get
the proper build number. First, your local repository is
checked to make sure it is up to date. Second, your local
repository is automatically updated, so that you get the
latest
build number. Both these functions can be suppressed, if
desired.

Optionally, you can configure this mojo to produce a
revision
based on a timestamp, or on a sequence, without requiring
any
interaction with an SCM system. Note that currently, the
only
supported SCM is subversion.

http://mojo.codehaus.org/buildnumber-maven-plugin/
--
!-- ===--
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuildnumber-maven-plugin/artifactId
version1.0-beta-1-SNAPSHOT/version
executions
execution
phasevalidate/phase
goals
goalcreate/goal
/goals
/execution
/executions
configuration
doCheckfalse/doCheck
doUpdatefalse/doUpdate
format{0,date,-MM-dd HH:mm:ss}/format
items
itemtimestamp/item
/items
/configuration
/plugin

Re: how can I to use build time in pom files

[Rex Huang]

yah, use buildnumber-maven-plugin may be better.
one strange thing is I can't use ${buildNumber} in filter,
when I want to replace $BUILDTIME in the resource file.
such as:
in pom.xml
properties
BUILDTIME${buildNumber}/BUILDTIME
/properties

  resource
directorysrc/main/resources/directory
filteringtrue/filtering
includes
includeVersion.txt/include
/includes
  /resource

in Version.txt
build-time= ${BUILDTIME}

Re: how can I to use build time in pom files

[Mick Knutson]

Add this to your filter.properties:

BUILDTIME=${buildNumber}


On Jan 21, 2008 9:10 AM, Rex Huang [EMAIL PROTECTED] wrote:

 yah, use buildnumber-maven-plugin may be better.
 one strange thing is I can't use ${buildNumber} in filter,
 when I want to replace $BUILDTIME in the resource file.
 such as:
 in pom.xml
properties
BUILDTIME${buildNumber}/BUILDTIME
/properties

  resource
directorysrc/main/resources/directory
filteringtrue/filtering
includes
includeVersion.txt/include
/includes
  /resource

 in Version.txt
 build-time= ${BUILDTIME}




-- 
Thanks,
Mick Knutson

http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/BLiNCMagazine
http://tahoe.baselogic.com
---

Re: how can I to use build time in pom files

[Mick Knutson]

actually, why can't you just add ${buildNumber} to your Versions.txt ???


On Jan 21, 2008 10:17 AM, Mick Knutson [EMAIL PROTECTED] wrote:

 Add this to your filter.properties:

 BUILDTIME=${buildNumber}



 On Jan 21, 2008 9:10 AM, Rex Huang [EMAIL PROTECTED] wrote:

  yah, use buildnumber-maven-plugin may be better.
  one strange thing is I can't use ${buildNumber} in filter,
  when I want to replace $BUILDTIME in the resource file.
  such as:
  in pom.xml
 properties
 BUILDTIME${buildNumber}/BUILDTIME
 /properties
 
   resource
 directorysrc/main/resources/directory
 filteringtrue/filtering
 includes
 includeVersion.txt/include
 /includes
   /resource
 
  in Version.txt
  build-time= ${BUILDTIME}
 



 --
 Thanks,
 Mick Knutson

 http://www.baselogic.com
 http://www.blincmagazine.com
 http://www.djmick.com
 http://www.myspace.com/mickknutson
 http://www.myspace.com/BLiNCMagazine
 http://tahoe.baselogic.com
 ---




-- 
Thanks,
Mick Knutson

http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/BLiNCMagazine
http://tahoe.baselogic.com
---

Re: how can I to use build time in pom files

[Mark Eramo]

Rex,
  Have a look at the Maven build number plugin. It may be able to do 
what you need.


*http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html*

Regards,
Mark


Rex Huang wrote:

Does maven has build time property, which I can use in pom files
my-property${build time}my-property

BR//Rex

  


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

Re: how can I to use build time in pom files

[amit kumar]

You can use buildnumber-maven-plugin, for this but i was able to have
date+time... tried only time format but it wasn't running. If this solves
your purpose lemme know, I will share the relevant portion of my pom.

On Jan 18, 2008 7:58 PM, Rex Huang [EMAIL PROTECTED] wrote:

 Does maven has build time property, which I can use in pom files
 my-property${build time}my-property

 BR//Rex

how can I to use build time in pom files

[Rex Huang]

Does maven has build time property, which I can use in pom files
my-property${build time}my-property

BR//Rex

Build time resolution of properties files

[Ian Petzer]

Hi,

I'm trying to build a WAR which includes a properties file at build
time. This properties file will vary according to the environment that
it is being built for. (dev, test, prod). This would ideally be added
during something like the process-resources stage, so that I can point
my eclipse project at various environments.

I've tried adding profiles to the project which specify an additional
resource area where the property file can be pulled from. ie
(src/main/properties/dev and src/main/properties/test).

This works fine the first time I build my war and the correct
properties file for the profile is included. However when I try to do
it again with a different profile, the properties file is not
replaced. Instead the properties file (from the previous build) is
incorporated into the build.

The only way to get it to work properly every time is to run mvn clean
every time.

At the moment, I've figured out another way where I use the ant runner
to copy the desired properties file into src/main/resources.

Is there a better way for me to do this.

ps: The properties files all have the same name, but thats necessary
as the application picking them up has this name hard-coded into its
config.

Thanks,
Ian

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

enforcing plugin writting guidelines at build time

[Jerome Lacoste]

On 3/15/07, Jerome Lacoste [EMAIL PROTECTED] wrote:


Hi,

further care must be taken when writing plugins considering that maven can
be embedded. Maven sort of acts as a container for code. And maven itself
can be embedded.




This isn't limited to embedding. As I said Kaare yesterday, maven plugin
developers all make the same mistake. They don't make the plugin
multi-module ready, they forget to use the proxy configuration, etc...

I believe these recurring problems can be detected programatically and
prevented. AOP can help.

So it's just an idea. Sorry I don't have time to code it now. Maybe someone
will take on it.

Maybe a candidate for http://wiki.apache.org/general/SummerOfCode2007 ??

Jerome

generating an admin jsp at build time

[Jeff Mutonho]

I would like to create a sort of administration jsp that gets bundled
into my application war during build time.The administration jsp would
probably  look like this :


HTML
BODY
This application was build on  %= new java.util.Date() %
/BODY
/HTML

but instead of new java.util.Date()  , it would have the build-date.

Any suggestion on how to achieve this?







Jeff  Mutonho
Cape Town
South Africa

GoogleTalk : ejbengine
Skype: ejbengine
Registered Linux user number 366042

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

Re: generating an admin jsp at build time

[David Delbecq]

HTML
BODY
This application was build on  @@SomeBuildDateProperty@@
/BODY
/HTML

And use the ant filtering rules to replace content between @@ (see ant docs)


Jeff Mutonho a écrit :
 I would like to create a sort of administration jsp that gets bundled
 into my application war during build time.The administration jsp would
 probably  look like this :


 HTML
 BODY
 This application was build on  %= new java.util.Date() %
 /BODY
 /HTML

 but instead of new java.util.Date()  , it would have the build-date.

 Any suggestion on how to achieve this?







 Jeff  Mutonho
 Cape Town
 South Africa

 GoogleTalk : ejbengine
 Skype: ejbengine
 Registered Linux user number 366042

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



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

Re: generating an admin jsp at build time

[Jeff Mutonho]

On 12/1/06, David Delbecq [EMAIL PROTECTED] wrote:

HTML
BODY
This application was build on  @@SomeBuildDateProperty@@
/BODY
/HTML

And use the ant filtering rules to replace content between @@ (see ant docs)



Thanx David.Ended up being this simple :

  tstamp prefix=build
format property=date pattern=EEE MMM d,  hh:mm:ss z
locale=en /
   /tstamp
filterset id=maven.build.filter begintoken=@ endtoken=@
filter token=BUILD_DATE value=${build.date} /
  /filterset
  copy todir=WebContent filtering=true overwrite=true
 fileset dir=.
  include name=**/mavenadmin.jsp/
/fileset
filterset refid=maven.build.filter /
 /copy

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

Re: Modifying a web application's web.xml at build time

[Carlos A. Carnero Delgado]

On 10/29/06, Wendy Smoak [EMAIL PROTECTED] wrote:

... That is, the auth filter is different in the live environment,
when running the integration tests, and when running
'local' on my workstation.


That's nice, but I think it will not help me. Your method, using
properties, can change which servlet to use. I'd like to turn it on or
off.

Thanks a lot,
Carlos.
--
nick grah windows just crashed again, unstable crap.
yukito Windows isn't unstable, it's just spontaneous.

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

Modifying a web application's web.xml at build time

[Carlos A. Carnero Delgado]

Hello,

using Maven the last couple of weeks with the Jetty plugin has
provided our team with a huge productivity boost. We use the
UrlRewrite servlet[1] in order to generate pretty URLs (from a
Spring-backed application.) Currently, during development, this
UrlRewrite servlet (which is loaded using a filter tag in web.xml)
is disabled using comments.

Is there a way of modifying the web.xml at build time using Maven
profiles? Are profiles the solution?

I think that the ideal solution would involve maintaining a single
web.xml that could be modified at build time.

Best regards,
Carlos.
--
nick grah windows just crashed again, unstable crap.
yukito Windows isn't unstable, it's just spontaneous.

[1] http://tuckey.org/urlrewrite/

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

Re: Modifying a web application's web.xml at build time

[Wendy Smoak]

On 10/29/06, Carlos A. Carnero Delgado [EMAIL PROTECTED] wrote:


Is there a way of modifying the web.xml at build time using Maven
profiles? Are profiles the solution?

I think that the ideal solution would involve maintaining a single
web.xml that could be modified at build time.


Sure.  I do this with profiles such as 'env-live' 'env-test' and
'env-local'.  That is, the auth filter is different in the live
environment, when running the integration tests, and when running
'local' on my workstation.

  filter-mapping
 filter-name${auth.filter.name}/filter-name
 url-pattern*.do/url-pattern
  /filter-mapping

For example,

  profile
 idenv-local/id
 activation
property
   nameenv/name
   valuelocal/value
/property
 /activation
 properties
auth.filter.namelocalhostFilter/auth.filter.name
 /properties
  /profile

Here's what the plugin config looks like.  I put web.xml in a separate
directory so I could filter it and nothing else.  This may not be
necessary anymore, I think I started doing it with an earlier verison
of the war plugin.  Adjust as necessary. :)

plugin
artifactIdmaven-war-plugin/artifactId
configuration
webResources
webResource

directory${basedir}/src/main/webapp-filtered/directory
filteringtrue/filtering
includes
include**/*.xml/include
/includes
/webResource
/webResources
/configuration
/plugin

I think I had problems trying to filter in the !-- and -- for
comments, but then I realized that rather than trying to comment
various things in and out, I should just filter in the name of the
filter I wanted.

--
Wendy

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

Re: Modifying a web application's web.xml at build time

[向秦贤]

Hi,

There has a good example, jboss-messaging, which use replace stratedgy.
If you wanna check it out, after downloaded a new version, try to see that
file:
${jboss-messaging}/util/release-admin.xml.

Regards,

xy

2006/10/30, Carlos A. Carnero Delgado [EMAIL PROTECTED]:


Hello,

using Maven the last couple of weeks with the Jetty plugin has
provided our team with a huge productivity boost. We use the
UrlRewrite servlet[1] in order to generate pretty URLs (from a
Spring-backed application.) Currently, during development, this
UrlRewrite servlet (which is loaded using a filter tag in web.xml)
is disabled using comments.

Is there a way of modifying the web.xml at build time using Maven
profiles? Are profiles the solution?

I think that the ideal solution would involve maintaining a single
web.xml that could be modified at build time.

Best regards,
Carlos.
--
nick grah windows just crashed again, unstable crap.
yukito Windows isn't unstable, it's just spontaneous.

[1] http://tuckey.org/urlrewrite/

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





--
向秦贤

Re: Modifying a web application's web.xml at build time

[向秦贤]

Hi,

Maybe doing conditional subtasks in your case is good idea.
And refering to this segment mentioned before has no bad effect.:)
which use replaceregexp, with in ant, should available in m2.

there are two codes as follows, one in firefox. and one in text.

Regards,

Qinxian

!-- slim down jboss-service.xml --
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/jboss-
service.xml flags=s
regexp pattern=(\x3cmbean
code=\x22org.jboss.management.j2ee.LocalJBossServerDomain\x22.*jboss:service=CorbaORB\x3c/attribute\x3e[
\t\n\r]*\x3c/mbean\x3e)/
substitution expression=/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/jboss-
service.xml flags=s
regexp pattern=(\x3cmbean
code=\x22org.jboss.util.property.jmx.SystemPropertyClassValue\x22.*
org.jboss.system.JBossRMIClassLoader\x3c/attribute\x3e[
\t\n\r]*\x3c/mbean\x3e)/
substitution expression=/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/jboss-
service.xml flags=s
regexp pattern=(\x3cmbean
code=\x22org.jboss.web.WebService\x22.*\x3cdepends
optional-attribute-name=\x22ThreadPool\x22[
\t\n\r]*proxy-type=\x22attribute\x22\x3ejboss.system:service=ThreadPool\x3c/depends\x3e[
\t\n\r]*\x3c/mbean\x3e)/
substitution expression=/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/jboss-
service.xml flags=s
regexp pattern=(\x3cmbean
code=\x22org.jboss.tm.usertx.server.ClientUserTransactionService\x22.*\x3cdepends\x3ejboss:service=invoker,type=jrmp\x3c/depends\x3e[
\t\n\r]*\x3c/mbean\x3e[ \t\n\r]*\x3c/depends\x3e[ \t\n\r]*\x3c/mbean\x3e)/
substitution expression=/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/jboss-
service.xml flags=s
regexp pattern=(\x3cmbean
code=\x22org.jboss.invocation.pooled.server.PooledInvoker\x22.*\x3cdepends
optional-attribute-name=\x22TransactionManagerService\x22\x3ejboss:service=TransactionManager\x3c/depends\x3e[
\t\n\r]*\x3c/mbean\x3e)/
substitution expression=/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/jboss-
service.xml flags=s
regexp pattern=(\x3cmbean
code=\x22org.jboss.ejb.plugins.cmp.jdbc.metadata.MetaDataLibrary\x22.*name=\x22jboss.jdbc:service=metadata\x22/\x3e)/
substitution expression=/
/replaceregexp
!-- customize login-config.xml --
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/login-
config.xml flags=s
regexp pattern=(\x3cpolicy\x3e)/
substitution expression=\1 application-policy name =
messaging  authenticationlogin-module code = 
org.jboss.security.auth.spi.UsersRolesLoginModule flag =
required   module-option name =
unauthenticatedIdentityguest/module-option  module-option name
= usersPropertiesmessaging-users.properties/module-option
module-option name =
rolesPropertiesmessaging-roles.properties/module-option
/login-module/authentication/application-policy/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/login-
config.xml flags=s
regexp pattern=(\x3cpolicy\x3e)/
substitution expression=\1 application-policy name =
messaging  authenticationlogin-module code = 
org.jboss.security.auth.spi.UsersRolesLoginModule flag =
required   module-option name =
unauthenticatedIdentityguest/module-option  module-option name
= usersPropertiesmessaging-users.properties/module-option
module-option name =
rolesPropertiesmessaging-roles.properties/module-option
/login-module/authentication/application-policy/
/replaceregexp
−
   replaceregexp file=${jboss.home}/server/${config.name}/conf/login-
config.xml flags=s
regexp pattern=(\x3capplication-policy name = \x22jbossmq\x22\x3e.*FROM
JMS_ROLES WHERE USERID=.\x3c/module-option\x3e[
\t\n\r]*\x3c/login-module\x3e[ \t\n\r]*\x3c/authentication\x3e[
\t\n\r]*\x3c/application-policy\x3e)/
substitution expression=/


in text:
target name=create-standalone-server-config depends=validate-jboss,
validate-messaging-artifact
  description=Creates a standalone Messaging server configuration
based on a default JBoss instance

 echo message=Creating Standalone Messaging configuration '${
config.name}' for ${jboss.home} based on ${messaging.artifact.name}/

 mkdir dir=${jboss.home}/server/${config.name}/conf/
 mkdir dir=${jboss.home}/server/${config.name}/lib/
 mkdir dir=${jboss.home}/server/${config.name}/deploy/

 copy todir=${jboss.home}/server/${config.name}/conf
fileset dir=${jboss.home}/server/default/conf
   include name=jboss-service.xml/
   include name=jndi.properties/
   include name=log4j.xml/
   include name=login-config.xml/
   include name=props/**/
   include name=xmdesc/**/
/fileset
 /copy

 copy todir=${jboss.home}/server/${config.name}/deploy
fileset dir=${jboss.home}/server/default/deploy
   include name=hsqldb-ds.xml/
   include name=jboss-local-jdbc.rar/
   

Re: Build time classpath using my java plugin

[Trygve Laugstøl]

TimHedger wrote:

OK, so now I'm using the exec-plugin instead of my own code - great.
But I've lost the control I had over when the exec step happened.

I am using the plugin to generate SOAP wrappers for some Java code using
glue (themindelectric).  This step involves running a Java class with
certain parameters and it creates various xml files and a directory
structure, ready for packing into a war for distribution.

My problem is this is happening every time I compile using maven.  I've lost
any control over checking whether source is stale and thus the soap/exec
step if nothing's changed since my last build.

How can I get this control with the exec plugin?


You can't, the exec plugin does not have that kind of knowledge.

I think the best way for you would be to write your own glue plugin that 
just calls the main() method of the application after setting the system 
properties.


--
Trygve


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

Re: Build time classpath using my java plugin

[TimHedger]

OK, so now I'm using the exec-plugin instead of my own code - great.
But I've lost the control I had over when the exec step happened.

I am using the plugin to generate SOAP wrappers for some Java code using
glue (themindelectric).  This step involves running a Java class with
certain parameters and it creates various xml files and a directory
structure, ready for packing into a war for distribution.

My problem is this is happening every time I compile using maven.  I've lost
any control over checking whether source is stale and thus the soap/exec
step if nothing's changed since my last build.

How can I get this control with the exec plugin?
-- 
View this message in context: 
http://www.nabble.com/Build-time-classpath-using-my-java-plugin-tf1914923.html#a5292877
Sent from the Maven - Users forum at Nabble.com.


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

Re: Build time classpath using my java plugin

[TimHedger]

You're right - I did some unnecessary work!  (I took my approach from the
idlj plugin, that basically puts some wrapper stuff around running the main
method on a Java class - I guess that was done that way for convenience
rather than needing lots of config in the pom).

Anyway, I've dumped my plugin (less code has to be better) and am now using
the exec-maven-plugin.  And I can get it to do exactly what I need stand
alone - by invoking it explicitly:

mvn exec:java

will run the necessary Java class with all my arguments.

But I want to attach this step to a phase so it is nicely included in my
build cycle.  So I took the approach I have taken with other pugins, but it
doesn't seem to work here.

Specifics - this is the plugin section of my pom.xml:
  build
plugins
  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
  execution
idglue-processing/id
phasecompile/phase
goals
  goalexec/goal
/goals
  /execution
/executions
configuration
  debugtrue/debug
  executablejava/executable
  mainClasselectric.application.tools.NewApp/mainClass
  arguments
argument-Delectric.apphome=target/glue/argument
argument-Delectric.home=/apps/product/glue/argument
argument-h/argument
argumentVentureVaRService/argument
  /arguments
/configuration
  /plugin
/plugins
  /build

Here I've tried to attach the exec:java goal to the compile phase.

When I invoke mvn exec:java, I get what I expect:

: mvn exec:java
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'exec'.
[INFO]

[INFO] Building Maven Quick Start Archetype
[INFO]task-segment: [exec:java]
[INFO]

[INFO] Preparing exec:java
[INFO] No goals needed for project - skipping
[INFO] [exec:java]
[DEPLOYMENT] creating application directory at
/home/hedgert/maven/venvar/target/glue/VentureVaRService
[DEPLOYMENT] copying application files from /apps/product/glue/common
[DEPLOYMENT] adding application configuration URLs to config.xml
[DEPLOYMENT] saving application configuration file
[DEPLOYMENT] application has been successfully created
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 8 seconds
[INFO] Finished at: Tue Jul 11 18:47:37 BST 2006
[INFO] Final Memory: 3M/8M
[INFO]


(The DEPLOYMENT lines are the correct output from the Java class I'm
running, and this output shows it has taken the arguments I defined in the
pom).

But if I try to use the compile phase instead:

: mvn compile
[INFO] Scanning for projects...
[INFO] ---
[INFO] Building Maven Quick Start Archetype
[INFO]task-segment: [compile]
[INFO] ---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [exec:exec {execution: glue-processing}]
[INFO] Usage: java [-options] class [args...]
[INFO](to execute a class)
[INFO]or  java -jar [-options] jarfile [args...]
[INFO](to execute a jar file)
[INFO]
[INFO] where options include:
[INFO] -d32
[INFO]   use a 32-bit data model if available
[INFO] -d64
[INFO]   use a 64-bit data model if available
(etc etc)

In this case it seems to have invoked the plugin, but it has ignored all my
arguments and simply run Java with no parameters.  And yet the pom.xml file
is unchanged between these two runs.

So given the first one (mvn exec:java) works, I guess I'm doing something
wrong with the way I'm trying to attach the plugin goal to the compile phase
of the build.

Can someone point out my mistake?
-- 
View this message in context: 
http://www.nabble.com/Build-time-classpath-using-my-java-plugin-tf1914923.html#a5274398
Sent from the Maven - Users forum at Nabble.com.


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

Re: Build time classpath using my java plugin

[Tim Kettler]

replace goalexec/goal with goaljava/goal

TimHedger schrieb:

You're right - I did some unnecessary work!  (I took my approach from the
idlj plugin, that basically puts some wrapper stuff around running the main
method on a Java class - I guess that was done that way for convenience
rather than needing lots of config in the pom).

Anyway, I've dumped my plugin (less code has to be better) and am now using
the exec-maven-plugin.  And I can get it to do exactly what I need stand
alone - by invoking it explicitly:

mvn exec:java

will run the necessary Java class with all my arguments.

But I want to attach this step to a phase so it is nicely included in my
build cycle.  So I took the approach I have taken with other pugins, but it
doesn't seem to work here.

Specifics - this is the plugin section of my pom.xml:
  build
plugins
  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
  execution
idglue-processing/id
phasecompile/phase
goals
  goalexec/goal
/goals
  /execution
/executions
configuration
  debugtrue/debug
  executablejava/executable
  mainClasselectric.application.tools.NewApp/mainClass
  arguments
argument-Delectric.apphome=target/glue/argument
argument-Delectric.home=/apps/product/glue/argument
argument-h/argument
argumentVentureVaRService/argument
  /arguments
/configuration
  /plugin
/plugins
  /build

Here I've tried to attach the exec:java goal to the compile phase.

When I invoke mvn exec:java, I get what I expect:

: mvn exec:java
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'exec'.
[INFO]

[INFO] Building Maven Quick Start Archetype
[INFO]task-segment: [exec:java]
[INFO]

[INFO] Preparing exec:java
[INFO] No goals needed for project - skipping
[INFO] [exec:java]
[DEPLOYMENT] creating application directory at
/home/hedgert/maven/venvar/target/glue/VentureVaRService
[DEPLOYMENT] copying application files from /apps/product/glue/common
[DEPLOYMENT] adding application configuration URLs to config.xml
[DEPLOYMENT] saving application configuration file
[DEPLOYMENT] application has been successfully created
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 8 seconds
[INFO] Finished at: Tue Jul 11 18:47:37 BST 2006
[INFO] Final Memory: 3M/8M
[INFO]


(The DEPLOYMENT lines are the correct output from the Java class I'm
running, and this output shows it has taken the arguments I defined in the
pom).

But if I try to use the compile phase instead:

: mvn compile
[INFO] Scanning for projects...
[INFO] ---
[INFO] Building Maven Quick Start Archetype
[INFO]task-segment: [compile]
[INFO] ---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [exec:exec {execution: glue-processing}]
[INFO] Usage: java [-options] class [args...]
[INFO](to execute a class)
[INFO]or  java -jar [-options] jarfile [args...]
[INFO](to execute a jar file)
[INFO]
[INFO] where options include:
[INFO] -d32
[INFO]   use a 32-bit data model if available
[INFO] -d64
[INFO]   use a 64-bit data model if available
(etc etc)

In this case it seems to have invoked the plugin, but it has ignored all my
arguments and simply run Java with no parameters.  And yet the pom.xml file
is unchanged between these two runs.

So given the first one (mvn exec:java) works, I guess I'm doing something
wrong with the way I'm trying to attach the plugin goal to the compile phase
of the build.

Can someone point out my mistake?



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

Re: Build time classpath using my java plugin

[TimHedger]

Doh!  (Thank you)
-- 
View this message in context: 
http://www.nabble.com/Build-time-classpath-using-my-java-plugin-tf1914923.html#a5281234
Sent from the Maven - Users forum at Nabble.com.


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

Re: Build time classpath using my java plugin

[Trygve Laugstøl]

TimHedger wrote:

I've written a plugin (in Java) that explicitly invokes the main method of a
Java class directly from within the jvm that maven is already running.  My
plugin is behaving/configured as I expect, but I have a classpath problem
when control switches from my plugin code to the main method of the Java
class it invokes.


Seems like you have implemented the exec-maven-plugin [1].


I use the following method to print the classpath before I invoke the main
method on my target class:
project.getCompileClasspathElements();

(where project is MavenProject)

And I get the list of jars I expect, including:
/home/hedgert/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar

which is the copy of javax.servlet that I have in my local maven repository. 
Great - so far so good.


I invoke the main method of my target class and the code runs and then falls
over with a:
java.lang.NoClassDefFoundError: javax/servlet/ServletException

If I check the contents of my servlet-api-2.4.jar:
: jar -tf
/home/hedgert/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
|grep ServletException
javax/servlet/ServletException.class

The missing class is indeed in the jar that is on the classpath.

So presumably the classpath I'm getting back from:
project.getCompileClasspathElements();

is not actually the classpath in operation when I invoke the main method on
my class from within a running JVM.

So my question is: maven has nicely worked out the classpath I need (using
the dependencies in my pom.xml file for my target project, rather than my
plugin), how do I get this classpath be active in the running JVM?


You don't. The classpath that the plugin is running in contains all 
dependencies of the plugin, not the project. If you want to do something 
with the project's classpath you will have to create a classloader from 
the list you're referring to.


[1]: http://mojo.codehaus.org/exec-maven-plugin/

--
Trygve

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

Build time classpath using my java plugin

[TimHedger]

I've written a plugin (in Java) that explicitly invokes the main method of a
Java class directly from within the jvm that maven is already running.  My
plugin is behaving/configured as I expect, but I have a classpath problem
when control switches from my plugin code to the main method of the Java
class it invokes.

I use the following method to print the classpath before I invoke the main
method on my target class:
project.getCompileClasspathElements();

(where project is MavenProject)

And I get the list of jars I expect, including:
/home/hedgert/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar

which is the copy of javax.servlet that I have in my local maven repository. 
Great - so far so good.

I invoke the main method of my target class and the code runs and then falls
over with a:
java.lang.NoClassDefFoundError: javax/servlet/ServletException

If I check the contents of my servlet-api-2.4.jar:
: jar -tf
/home/hedgert/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
|grep ServletException
javax/servlet/ServletException.class

The missing class is indeed in the jar that is on the classpath.

So presumably the classpath I'm getting back from:
project.getCompileClasspathElements();

is not actually the classpath in operation when I invoke the main method on
my class from within a running JVM.

So my question is: maven has nicely worked out the classpath I need (using
the dependencies in my pom.xml file for my target project, rather than my
plugin), how do I get this classpath be active in the running JVM?
-- 
View this message in context: 
http://www.nabble.com/Build-time-classpath-using-my-java-plugin-tf1914923.html#a5242414
Sent from the Maven - Users forum at Nabble.com.


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

[m2]How to reduce Build Time in Maven 2.0.3

[narayan dhumale]

artifactIdmaven-ear-plugin/artifactId
configuration

defaultJavaBundleDirlib//defaultJavaBundleDir
/configuration
/plugin
/plugins
  /build
/project



Problem Defination:-
In order order build web-1.0 i need dependecies like person-ejb-service 
etc.(which u can see in the pom given below.. web-1.0 WAR file).I have to build 
the whole project everytime i have to see changes in web-1.0.
Can anybody shortcut to this procedure so that my build time can b  reduced??? 

The pom of web-1.0 is looks like this
project xmlns=http://maven.apache.org/POM/4.0.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;
parent
groupIdxxx/groupId
artifactIdG2/artifactId
version1.0/version
/parent

modelVersion4.0.0/modelVersion
groupId/groupId
artifactIdweb/artifactId
packagingwar/packaging
version1.0/version
nameOmniVision Web Component/name
dependencies
dependency
groupIdxx/groupId
artifactIdutil/artifactId
version1.0/version
/dependency
dependency
groupIdxx/groupId
artifactIdparticipant-ejb-service/artifactId
version1.0/version
/dependency
dependency
groupIdxxx/groupId
artifactIdperson-ejb-service/artifactId
version1.0/version
/dependency
dependency
groupId/groupId
artifactIdplan-ejb-service/artifactId
version1.0/version
/dependency
dependency
groupIdjavax.j2ee/groupId
artifactIdj2ee/artifactId
version1.4/version
scopeprovided/scope
/dependency
dependency
groupIdstruts/groupId
artifactIdstruts/artifactId
version1.2.8/version
/dependency
dependency
groupIdxxx/groupId
artifactIdterminology-ejb-service/artifactId
version1.0/version
/dependency
/dependencies
build
resources
resource
directorysrc/main/resources/directory
/resource
/resources
/build
/project



Waiting for your replies.

Re: Adding Build Time to Projects Summary Page

[Richard C. L. Li]

Not possible even by altering the Summary.vm template?

Emmanuel Venisse wrote:

No, it isn't possible. File an issue for this feature.

Emmanuel

Richard C. L. Li a écrit :

Hi,

Is there any way to add a column of the ending date and time of the 
latest build in the project summary page?


Thanks,
Richard Li

Re: Adding Build Time to Projects Summary Page

[Emmanuel Venisse]

you can but you'll need to readd it in continuum-web.jar because this file is always unpack at each 
restart.


$date.format('medium',$latestBuild.endTime)

Emmanuel

Richard C. L. Li a écrit :

Not possible even by altering the Summary.vm template?

Emmanuel Venisse wrote:


No, it isn't possible. File an issue for this feature.

Emmanuel

Richard C. L. Li a écrit :


Hi,

Is there any way to add a column of the ending date and time of the 
latest build in the project summary page?


Thanks,
Richard Li

Re: Adding Build Time to Projects Summary Page

[Emmanuel Venisse]

No, it isn't possible. File an issue for this feature.

Emmanuel

Richard C. L. Li a écrit :

Hi,

Is there any way to add a column of the ending date and time of the 
latest build in the project summary page?


Thanks,
Richard Li

Adding Build Time to Projects Summary Page

[Richard C. L. Li]

Hi,

Is there any way to add a column of the ending date and time of the 
latest build in the project summary page?


Thanks,
Richard Li

speed up build time

[thorsten maus]

hi there ..

we are developing an application using the multiproject plugin ...

i would be interested in your ways to speed up the build process ...

1. is it possible to execute only parts of a multiproject
2. how do i tell maven not to compile all sources over and over again ???
--
Thorsten Maus ( IT Architect )
[EMAIL PROTECTED]
mobile: +49-173-644-1988
www.pirack.com
it's teamwork
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

build time

[thorsten maus]

hi guys ..

im actually having a multiproject with 4 subproject ...

for each subproject the ejbdoclet as well as the hibernatedoclet ist 
working .. although not needed for each ...

the altogether build time is about 4-5 minutes 

is there any way to speed the build process up ???



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

Re: build time

[Kevin Hagel]

http://ant.apache.org/manual/CoreTasks/uptodate.html
I use ant's uptodate to see if I need to rebuild anything in 
particular.  When our project was in its early days there wasn't so much 
to build and it seemed like overkill, but after a while when things 
really bloated it made a big difference

thorsten maus wrote:

hi guys ..

im actually having a multiproject with 4 subproject ...

for each subproject the ejbdoclet as well as the hibernatedoclet ist 
working .. although not needed for each ...

the altogether build time is about 4-5 minutes 

is there any way to speed the build process up ???



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

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