Re: [VOTE] Require Java 17 for Maven 4

[Stephane Nicoll]

+1 (non binding)

On Wed, Feb 28, 2024 at 8:31 AM Benjamin Marwell 
wrote:

> Hi Maven Devs/Users/Committers and PMC members!
>
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
>
> This is a procedural majority vote [1*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> Please also notice:
> * Maven 3 will stay at Java 8 no matter what.
> * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> on the release date).
>   This is not part of this vote.
> * The linked PR is not part of this vote (this is not a code vote).
>   But you may take a look at it to understand the intended change.
>
> PR: https://github.com/apache/maven/pull/1430
>
> Maven-Parent will not be raised with this vote, the other PR is not
> part of this vote.
>
> Please refrain from starting discussions in this thread, but do
> include a reasoning on downvotes and feel free to start a new
> discussion on the mailing list, or comment on the existing ones.
>
> ---
>
> Vote open for 72 hours:
>
> [ ] +1 (set JDK17 min version for Maven 4.x)
> [ ] +0
> [ ] -1 (please include reasoning)
>
> ---
>
> - Ben
>
> [1*]: https://www.apache.org/foundation/voting.html
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephane Nicoll]

You're welcome Curtis, thanks for the discussion! If you want to see a live
example of this build structure check Spring-boot on GitHub.

Cheers,
S.

On Wednesday, 24 August 2016, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Christian & Stephane,
>
> Christian Schulte wrote:
> > It has never been possible to override a property in the BOM from the
> > imorting POM.
>
> Thanks Christian, I stand corrected!
>
> So it is a consequence of the fact that my projects' managed dependency
> versions previously came in through inheritance, but now (with the new
> Maven 3.4.0 behavior) the imported versions always take precedence.
>
> Stephane Nicoll wrote (in a different thread):
> > Your parent would become a parent for pluginsManagement and all the
> > dependencyManagement would move to a separate BOM that you would
> > manage the same way as the two others. In Spring Boot we have done
> > both actually (because we don't have the same requirement that you
> > explain here). "spring-boot-dependencies" is the bom and
> > "spring-boot-parent" is the parent pom. The latter extends from the
> > former. If you use the parent you get everything. If you don't,
> > there's still a separate pom that you can use as a BOM.
>
> Thanks Stephane for this—together with Christian's comment above, it makes
> me realize that we will need to use that scheme for our updated POM
> structure as well: our pom-base will need to extend our BOM as you say. And
> the BOM will need to manage _all_ component versions directly, not via
> composition using imports, or else it will not be possible to override
> version properties in downstream consumers to change dependency versions.
>
> Or perhaps that behavior is not so important... but if we stop supporting
> it, our community will need some time to get used to it.
>
> In general, thanks to you both for investing so much time in this
> discussion.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Wed, Aug 24, 2016 at 12:15 PM, Christian Schulte <c...@schulte.it
> <javascript:_e(%7B%7D,'cvml','c...@schulte.it');>> wrote:
>
>> Am 24.08.2016 um 19:05 schrieb Curtis Rueden:
>> > One nuance I do not discuss is how importing a BOM under the new scheme
>> now
>> > resolves all version properties, such that overriding them in the
>> consuming
>> > POM has no effect anymore. I still feel this is a bug (or at least
>> > undesired quality) of the new approach.
>>
>> It has never been possible to override a property in the BOM from the
>> imorting POM.
>>
>> Regards,
>> --
>> Christian
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> <javascript:_e(%7B%7D,'cvml','users-unsubscr...@maven.apache.org');>
>> For additional commands, e-mail: users-h...@maven.apache.org
>> <javascript:_e(%7B%7D,'cvml','users-h...@maven.apache.org');>
>>
>>
>

-- 
Sent from my phone

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Thu, Aug 18, 2016 at 5:24 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Stephane,
>
>
> In fact, nowhere does it talk about what happens when dependencyManagement
> comes in through both the parent and through imports. It does say, however:
>

I agree that both the doc and the code are missing a piece. I am not
blaming you (or anyone, we did it too!) for creating such project structure
:)


>
> I'm not arguing that "I am right and you are wrong" here—I'm saying that
> the docs make no promises and there is room for doubt here.


Fully agree.



> I am just looking for a solution which will keep everyone's projects
> working as intended while also letting us move Maven forward the way it
> should. It sounds like Christian's proposal to bump the POM model version
> to 4.1.0 may be the way to go.


Sounds good to me!

Cheers,
S.




> Maybe that is a discussion for the dev list?
>
> Regards,
> Curtis
>
> [1]
> https://maven.apache.org/guides/introduction/introduction-to-dependency-
> mechanism.html#Importing_Dependencies
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Thu, Aug 18, 2016 at 3:04 AM, Stephane Nicoll <
> stephane.nic...@gmail.com>
> wrote:
>
> > On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden <ctrue...@wisc.edu>
> wrote:
> >
> > > Hi Stephane,
> > >
> > > Apologies up front for my long reply here. I divided into sections to
> > help
> > > break things up.
> > >
> > >
> > > *== Expected behavior? Or a defect? ==*
> > >
> > > > if you expect the parent to override something you've defined
> > > > in the child, that's not the expected behaviour at all.
> > >
> > > It certainly _has_ been the expected behavior in my community for the
> > past
> > > 5 years. Here is a simplified rundown:
> > >
> > > - pom-base is the parent POM for everything, locking down plugin
> > versions,
> > > and managing common dependency versions.
> > > - pom-whiz extends pom-base to manage dependency versions of "whiz"
> > > components.
> > > - pom-bang extends pom-base to manage dependency versions of "bang"
> > > components.
> > > - Whiz-based projects extend pom-whiz to gain dependency management of
> > all
> > > base and whiz components.
> > > - Bang-based projects extend pom-bang to gain dependency management of
> > all
> > > base and bang components.
> > > - Hybrid projects extend pom-base, and import both pom-whiz and
> pom-bang,
> > > to gain dependency management of all base, whiz and bang components.
> > >
> > > In this scenario, because we use "release early, release often" style
> > > development where components are released individually, it is untenable
> > for
> > > the pom-base version to be totally aligned between the most recent
> > > pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do
> > not
> > > want to force releases of bang, and vice versa, just to keep all
> pom-base
> > > versions consistent.
> > >
> >
> > OK, after more coffee I finally managed to get my head around your
> project.
> > The problem is that "pom-whiz" extends from "pom-base". You have a
> scenario
> > where a "whiz" project extends from "pom-base" and then import
> "pom-whiz".
> > Said "pom-whiz", via inheritance, "imports" "pom-base" again.
> >
> > Independently on the issue described in this thread, this setup is broken
> > IMO. I already said we spent a lot of time in Spring land to tune our
> BOMs
> > and one rule of thumb was that you should _never ever_ provide dependency
> > management for something that you're not managing yourself. You should
> let
> > the component responsible for it drive it.
> >
> > Let's take an example in Spring land: Spring Boot is the base for
> > application development: it brings Spring Framework and dependency
> > management for a bunch of third parties. Spring Cloud is built on top of
> > Spring Boot.
> >
> > Initially, the Spring Cloud BOM was (indirectly) importing dependency
> > management from some components managed by Spring Boot. Here's the setup:
> > you have a Spring Boot project (with the spring boot parent that provides
> > you all that's required to bui

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

e issue above, there still seems to be a bug in property
> overrides, as illustrated by my earlier gist:
>
>https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
>
> Here we see that with Maven 3.4.0, setting the imagej.version property to
> 2.0.0-rc-49 in the  section of the project POM has no effect on
> the final resolved version of the associated net.imagej:imagej component.
> Whereas with Maven 3.3.9, setting that property does modify the resolved
> dependency version.
>
> We all agree that this is a bug, right? If this behavior is not changed, I
> expect it will be the source of frequent bug reports once 3.4.0 is
> released.
>
>
> *== Build reproducibility ==*
>
> One of the beautiful things about Maven is that it tries so hard to foster
> reproducible builds, despite the fact that it draws heavily from the
> Internet as needed when building. Releases are immutable, you can pin all
> used plugins to specific releases, etc., so that when you build your
> project five years later, the same thing is produced as was originally. But
> this change in how dependency versions are computed breaks backwards
> compatibility in the Maven core itself -- something which (as of this
> writing) cannot be pinned via the POM. I can understand the desire for such
> core changes between major release versions -- 1.x to 2.x was a big
> overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this
> change is happening in a minor version increment.
>
> I do understand that SemVer only promises backwards compatibility of
> intended behavior, not _all_ behavior. But I think this case is a very gray
> area. The old behavior allowed to have a single POM which acts as a parent
> _and_ a BOM -- with the new behavior, this will no longer be practical (see
> above).
>
>
> *== How to avoid this scenario in the future? ==*
>
> I can see that I'm fighting a losing battle here. My community can
> certainly cut new releases of all our components which are tweaked to work
> properly with Maven 3.4.0. But I am very concerned about the precedent
> here: at any point in the future, complex builds which used to work might
> stop doing so, even without a major version increment, due to future
> changes in the logic of core Maven.
>
> It would be ideal if in the future (something for Maven 4?), as much of
> this logic as possible could be pushed out of core and into plugins, so
> that they can be pinned in the POM, to promote better build
> reproducibility.
>
> If you actually made it through this whole thing: thank you for reading.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Tue, Aug 16, 2016 at 1:12 PM, Stephane Nicoll <
> stephane.nic...@gmail.com>
> wrote:
>
> > Hello Curtis,
> >
> > I have no opinion on your project (To be honest, I haven't looked in
> > details yet, quite a large setup) but if you expect the parent to
> override
> > something you've defined in the child, that's not the expected behaviour
> at
> > all. That's still a problem for you though, I am not denying that.
> >
> > Of course, if the issue you're having is some sort of different
> regression,
> > we should fix it for sure.
> >
> > Thanks,
> > S.
> >
> > On Mon, Aug 15, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu>
> wrote:
> >
> > > Hi Stephane,
> > >
> > > Why can't we have the best of both worlds? Backwards compatibility, but
> > > with a "stop sucking" flag which enables the new better behavior?
> > >
> > > As I said previously, unless the previous behavior is preserved, all of
> > my
> > > communy's existing releases (hundreds of projects, thousands of tags)
> > will
> > > no longer build as intended at time of release.
> > >
> > > It could be as simple as the required minimum maven version being set
> to
> > > 3.4 to trigger the new behavior.
> > >
> > > Regards,
> > > Curtis
> > >
> > > On Aug 15, 2016 2:21 PM, "Stephane Nicoll" <stephane.nic...@gmail.com>
> > > wrote:
> > >
> > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <c...@schulte.it>
> > > wrote:
> > > >
> > > > > Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > > > > > reviewing things. So current state of this is: "That's the
> > behaviour
> > > > > > requested a

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Wed, Aug 17, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Christian & Stephane,
>
> Thanks for your replies.
>
> Christian Schulte wrote:
> > I am thinking about introducing model version "4.1.0" in Maven 3.4.
>
> I like this idea. Thanks for putting it forward!
>
> One question: for POM hierarchies with mixed model versions -- a 4.0.0 POM
> which imports or extends a 4.1.0 POM or vice versa -- do you foresee any
> complications?
>
> Stephane Nicoll wrote:
> > Assume "foo" is managed by "pom-base". The minute you want to override
> > the version of "foo", your bom import scenario falls appart.
>
> Why? You simply override the value of foo.version in your POM properties.
> This worked in Maven 3.3, but is currently broken in 3.4.0-SNAPSHOT. My
> understanding is that this is a bug distinct from the parent-vs-BOM
> versioning issue. No?
>

I was trying to show the inconsistency. If you have foo in a bom it doesn't
work but if you override the dependency manually (or override the version
for foo in properties) it works.

If we can't no longer override a version from the parent using a property
that's really bad because Spring Boot does that a lot. Is there a link to
an issue so that I can try on other projects?

Thanks!
S.


>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Tue, Aug 16, 2016 at 9:57 PM, Christian Schulte <c...@schulte.it> wrote:
>
> > Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> > > On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> > >
> > >> There is an easy way to solve this. Maven validates the model version
> in
> > >> the POM to match "4.0.0". Based on that version, Maven can decide how
> to
> > >> behave. I am thinking about introducing model version "4.1.0" in Maven
> > >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> > >
> > > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a
> > long time ago when we were doing the Google Hangouts discussions about a
> > mental separation of build/deploy POM.
> >
> > Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
> > with Maven < 3.4. Tools parsing the POMs themselves (not using
> > maven-model-builder) would need to support that as well.
> >
> > >
> > > If deployed as 4.1.0 then you'd be forcing all consumers of that
> > dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ),
> but
> > that might hurt any consuming applications like Sonar, Jenkins, or other
> > build tools.
> > >
> >
> > That's the drawback I am seeing as well. It's the same syntax with
> > different semantics. That's why Maven < 3.4 would need to abort.
> > Everything < 3.4 cannot provide the behaviour for that model version and
> > thus must not e.g. silently ignore XML elements leading to e.g.
> > different dependency trees when used with >= 3.4. It's a question of how
> > to progress Maven core when it comes to changes in behaviour making
> > sense. "Has always been that way -> must not change." Means we can never
> > change anything and must provide new features for changing things (e.g.
> > keep the import scope the way it always has been and introduce an
> > include scope with the new behaviour and document the import scope is
> > considered deprecated). It's not always possible to introduce a change
> > as a new feature. We recently discussed the addition of some kind of
> > feature toggles or knobs. That won't work, in my opinion, because Maven
> > would behave differently based on command line options. It's not
> > possible to deploy a POM to central whose correct/intended behaviour
> > depends on a specical command line option in use. I see no other way to
> > incrementing the model version for such things. Maven needs to know how
> > to behave solely based on what is in the POM. Nothing syntax related.
> >
> > Regards,
> > --
> > Christian
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

 overrides? ==*
>
> Setting aside the issue above, there still seems to be a bug in property
> overrides, as illustrated by my earlier gist:
>
>https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
>
> Here we see that with Maven 3.4.0, setting the imagej.version property to
> 2.0.0-rc-49 in the  section of the project POM has no effect on
> the final resolved version of the associated net.imagej:imagej component.
> Whereas with Maven 3.3.9, setting that property does modify the resolved
> dependency version.
>
> We all agree that this is a bug, right? If this behavior is not changed, I
> expect it will be the source of frequent bug reports once 3.4.0 is
> released.
>
>
> *== Build reproducibility ==*
>
> One of the beautiful things about Maven is that it tries so hard to foster
> reproducible builds, despite the fact that it draws heavily from the
> Internet as needed when building. Releases are immutable, you can pin all
> used plugins to specific releases, etc., so that when you build your
> project five years later, the same thing is produced as was originally. But
> this change in how dependency versions are computed breaks backwards
> compatibility in the Maven core itself -- something which (as of this
> writing) cannot be pinned via the POM. I can understand the desire for such
> core changes between major release versions -- 1.x to 2.x was a big
> overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this
> change is happening in a minor version increment.
>
> I do understand that SemVer only promises backwards compatibility of
> intended behavior, not _all_ behavior. But I think this case is a very gray
> area. The old behavior allowed to have a single POM which acts as a parent
> _and_ a BOM -- with the new behavior, this will no longer be practical (see
> above).
>
>
> *== How to avoid this scenario in the future? ==*
>
> I can see that I'm fighting a losing battle here. My community can
> certainly cut new releases of all our components which are tweaked to work
> properly with Maven 3.4.0. But I am very concerned about the precedent
> here: at any point in the future, complex builds which used to work might
> stop doing so, even without a major version increment, due to future
> changes in the logic of core Maven.
>
> It would be ideal if in the future (something for Maven 4?), as much of
> this logic as possible could be pushed out of core and into plugins, so
> that they can be pinned in the POM, to promote better build
> reproducibility.
>
> If you actually made it through this whole thing: thank you for reading.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Tue, Aug 16, 2016 at 1:12 PM, Stephane Nicoll <
> stephane.nic...@gmail.com>
> wrote:
>
> > Hello Curtis,
> >
> > I have no opinion on your project (To be honest, I haven't looked in
> > details yet, quite a large setup) but if you expect the parent to
> override
> > something you've defined in the child, that's not the expected behaviour
> at
> > all. That's still a problem for you though, I am not denying that.
> >
> > Of course, if the issue you're having is some sort of different
> regression,
> > we should fix it for sure.
> >
> > Thanks,
> > S.
> >
> > On Mon, Aug 15, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu>
> wrote:
> >
> > > Hi Stephane,
> > >
> > > Why can't we have the best of both worlds? Backwards compatibility, but
> > > with a "stop sucking" flag which enables the new better behavior?
> > >
> > > As I said previously, unless the previous behavior is preserved, all of
> > my
> > > communy's existing releases (hundreds of projects, thousands of tags)
> > will
> > > no longer build as intended at time of release.
> > >
> > > It could be as simple as the required minimum maven version being set
> to
> > > 3.4 to trigger the new behavior.
> > >
> > > Regards,
> > > Curtis
> > >
> > > On Aug 15, 2016 2:21 PM, "Stephane Nicoll" <stephane.nic...@gmail.com>
> > > wrote:
> > >
> > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <c...@schulte.it>
> > > wrote:
> > > >
> > > > > Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > > > > > reviewing things. So current state of this is: "That's the
> > beh

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

Hello Curtis,

I have no opinion on your project (To be honest, I haven't looked in
details yet, quite a large setup) but if you expect the parent to override
something you've defined in the child, that's not the expected behaviour at
all. That's still a problem for you though, I am not denying that.

Of course, if the issue you're having is some sort of different regression,
we should fix it for sure.

Thanks,
S.

On Mon, Aug 15, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Stephane,
>
> Why can't we have the best of both worlds? Backwards compatibility, but
> with a "stop sucking" flag which enables the new better behavior?
>
> As I said previously, unless the previous behavior is preserved, all of my
> communy's existing releases (hundreds of projects, thousands of tags) will
> no longer build as intended at time of release.
>
> It could be as simple as the required minimum maven version being set to
> 3.4 to trigger the new behavior.
>
> Regards,
> Curtis
>
> On Aug 15, 2016 2:21 PM, "Stephane Nicoll" <stephane.nic...@gmail.com>
> wrote:
>
> > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <c...@schulte.it>
> wrote:
> >
> > > Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > > > reviewing things. So current state of this is: "That's the behaviour
> > > > requested and tested during commiting to MNG-5971. Cannot override
> > > > properties? Really requested behaviour? Maybe incorrect. Need to look
> > at
> > > > it again. There was a reason it got implemented the way it is."
> > >
> > > The current behaviour is on purpose.
> > >
> > > 1. Read POM.
> > > 2. Recursivley read all parent POMs.
> > > 3. Include (import) dependency declarations top-down at each level.
> > > 4. Apply inheritance processing.
> > >
> > > There is no way to use an overridden property value when importing the
> > > depdency declarations because the import happens before inheritance
> > > processing. Benefit is the imported dependency declarations will be
> > > available to inheritance processing that way.
> > >
> >
> > I agree and I need to draw the attention to the opposite problem (even if
> > it was already explained here).
> >
> > The spring ecosystem heavily uses BOMs to define the versions for Spring
> > related modules. We have those for the framework, spring data, spring
> boot
> > and cloud. I took us quite some time to get those BOMs right and this
> > effort lead to the creation of MNG-5971.
> >
> > For those asking for a revert, please consider that without it, the BOM
> > feature is pretty much useless (in the sense it does not enforce
> anything).
> > When you have a dependency management section in a project, you want to
> > make sure that those versions are going to be used in child projects (and
> > you do so by not specifying any version at all). In a given child project
> > you can deviate from that rule by overriding the dependency management
> for
> > particular module(s). But it wasn't working with a BOM until now.
> >
> > So, something you couldn't do by importing a BOM is actually working by
> > copy/pasting the content of the BOM in the project! I understand that
> this
> > may feel a regression for those who were relying on the current behaviour
> > but I think the current status is much more consistent.
> >
> > Cheers,
> > S.
> >
> >
> > >
> > > Regards,
> > > --
> > > Christian
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte  wrote:

> Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > reviewing things. So current state of this is: "That's the behaviour
> > requested and tested during commiting to MNG-5971. Cannot override
> > properties? Really requested behaviour? Maybe incorrect. Need to look at
> > it again. There was a reason it got implemented the way it is."
>
> The current behaviour is on purpose.
>
> 1. Read POM.
> 2. Recursivley read all parent POMs.
> 3. Include (import) dependency declarations top-down at each level.
> 4. Apply inheritance processing.
>
> There is no way to use an overridden property value when importing the
> depdency declarations because the import happens before inheritance
> processing. Benefit is the imported dependency declarations will be
> available to inheritance processing that way.
>

I agree and I need to draw the attention to the opposite problem (even if
it was already explained here).

The spring ecosystem heavily uses BOMs to define the versions for Spring
related modules. We have those for the framework, spring data, spring boot
and cloud. I took us quite some time to get those BOMs right and this
effort lead to the creation of MNG-5971.

For those asking for a revert, please consider that without it, the BOM
feature is pretty much useless (in the sense it does not enforce anything).
When you have a dependency management section in a project, you want to
make sure that those versions are going to be used in child projects (and
you do so by not specifying any version at all). In a given child project
you can deviate from that rule by overriding the dependency management for
particular module(s). But it wasn't working with a BOM until now.

So, something you couldn't do by importing a BOM is actually working by
copy/pasting the content of the BOM in the project! I understand that this
may feel a regression for those who were relying on the current behaviour
but I think the current status is much more consistent.

Cheers,
S.


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

[ANN] Animal Sniffer 1.14 Released

[Stephane Nicoll]

Hi,

The Mojo team is pleased to announce the release of Animal Sniffer version 1.14.

Animal Sniffer provides tools to assist verifying that classes
compiled with a newer JDK/API are compatible with an older JDK/API.

The following tools are provided by animal sniffer:

* A command line tool to dump the class file version number
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer/index.html).
This helps you track down the offending jar file when you see
UnsupportedClassVersionError.

* A set of ANT tasks
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/index.html
)
for verifying that your classes comply with an API signature as well
as tasks for creating API signatures from a JDK, or a collection or
jar and class files, or a collection of other API signature files, or
combination of these elements.

* A rule for use in the maven-enforcer-plugin
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-enforcer-rule/index.html
)
for verifying that your classes comply with an API signature .

* A maven plugin
(http://mojo.codehaus.org/animal-sniffer-maven-plugin/index.html) for
verifying that your classes comply with an API signature as well as
for creating API signatures from a JDK, or the current module's
classes, or the current module's dependencies, or a collection of
other API signature files, or combination of these elements.

The artifacts have are available from the Maven Central repository.


Release Notes - Mojo's Animal Sniffer - Version 1.14

** Bug
* [MANIMALSNIFFER-49] - Support covariant return types
* [MANIMALSNIFFER-53] - Documentation error : checking dependency classes

** Improvement
* [MANIMALSNIFFER-50] - Apply plugin Annotations (instead of
current doclet tags)


** Task
* [MANIMALSNIFFER-51] - Upgrade ASM to 5.0.3

The Mojo Team.

Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl

[Stephane Nicoll]

On Mon, Dec 15, 2014 at 2:15 PM, Gary Gregory garydgreg...@gmail.com
wrote:

 As cute as Shutgun might seem, for some unspecified definition of
 cute, I am sick of hearing about any kind of gun...

 http://www.chicagotribune.com/news/nationworld/chi-school-shootings-sandy-hook-20141211-story.html


Same here. B



 Gary

 On Mon, Dec 15, 2014 at 7:30 AM, Jeroen Hoek jer...@lable.org wrote:
 
  B
 
  2014-12-15 12:41 GMT+01:00 Martin Grigorov mgrigo...@apache.org:
   B
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Mon, Dec 15, 2014 at 12:39 PM, Stephen Connolly 
   stephen.alan.conno...@gmail.com wrote:
  
   A
  
   On 15 December 2014 at 10:39, Stephen Connolly 
   stephen.alan.conno...@gmail.com wrote:
   
After the run-off round, we are left with two names standing.
   
This second vote will be a straight and simple majority wins.
   
The vote will be open for at least 72 hours (with the potential of
 an
extension until I send a message saying that the polls are closed)
   
There will be no discussion in this thread, we have talked it all
  enough
already. If you want to discuss something, please use a different
  thread.
   
Vote:
   
[A]: Shotgun
[B]: The Maven Owl
   
Thank you very much for your time
   
-Stephen
   
  
 
 
 
  --
  Vriendelijke groeten,
 
  Jeroen Hoek
 
  Lable
  ✉ jer...@lable.org
  ℡ 088 44 20 202
 
  http://lable.org
  KvK № 55984037
  BTW № NL8519.32.411.B.01
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Run-off for mascot's name

[Stephane Nicoll]

B E

On Tue Dec 09 2014 at 11:52:59 AM Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 H, E, K

 On 9 December 2014 at 10:52, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  This is a run-off vote to select the top two options for our new mascot's
  name.
 
  The entries with the highest number of votes will be selected for the
  final round. If there is only one entry with the highest number of votes
  then the entries with the second highest number of votes will also be
  included in the final round.
 
  The vote will be open for 72 hours.
 
  The entries are as follows:
 
  A. Abraham
  B. Boo
  C. Darth Mowl
  D. Jacob
  E. Kaboom
  F. Moses
  G. Rap
  H. Shotgun
  K. The Maven Owl
  L. Ty
 
  It is not clear whether all of the above suggestions were completely
  serious, but I have included them anyway for this first round.
 
  Please respond with at most your top three in order of preference. I may
  not use second or third preferences if we get a sufficient number of
 votes,
  but in the case of a small poll the additional preferences will help.
 
  In the event of repeated votes from an individual, only the last cast
 vote
  as determined by me will count.
 
  Any other discussion should happen in a separate thread.
 
  Thanks
 
  -Stephen
 

Re: Welcome Karl Heinz Marbaise to the Maven PMC

[Stephane Nicoll]

Congrats Karl!


On Tue, Aug 26, 2014 at 7:41 AM, Barrie Treloar baerr...@gmail.com wrote:

 I'm pleased to announce that the Maven PMC has voted to add Karl to the
 Maven PMC.

 Welcome, Karl.

[ANN] Animal Sniffer version 1.11 Released

[Stephane Nicoll]

Hi,

The Mojo team is pleased to announce the release of Animal Sniffer version 1.11.

This release permits the use of custom annotations in lieu of
@IgnoreJRERequirement

Animal Sniffer provides tools to assist verifying that classes
compiled with a newer JDK/API are compatible with an older JDK/API.

The following tools are provided by animal sniffer:

* A command line tool to dump the class file version number
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer/index.html).
This helps you track down the offending jar file when you see
UnsupportedClassVersionError.

* A set of ANT tasks
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/index.html)
for verifying that your classes comply with an API signature as well
as tasks for creating API signatures from a JDK, or a collection or
jar and class files, or a collection of other API signature files, or
combination of these elements.

* A rule for use in the maven-enforcer-plugin
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-enforcer-rule/index.html)
for verifying that your classes comply with an API signature .

* A maven plugin
(http://mojo.codehaus.org/animal-sniffer-maven-plugin/index.html) for
verifying that your classes comply with an API signature as well as
for creating API signatures from a JDK, or the current module's
classes, or the current module's dependencies, or a collection of
other API signature files, or combination of these elements.

The artifacts are available from the Maven Central repository.

Release Notes - Mojo Animal Sniffer - Version 1.11

** Improvement
* [MANIMALSNIFFER-41] - Define a custom annotation instead of
relying on @IgnoreJRERequirement
Enjoy,

The Mojo Team.

Re: maven-ear-plugin silently overrides libraries

[Stephane Nicoll]

I confirm that the use case you mention is supposed to work transparently.
This most likely looks like a bug.

Thanks for reporting this.

S.


On Fri, Feb 7, 2014 at 3:21 PM, Reto Hablützel ret...@rethab.ch wrote:

 Hi there,

 I built an ear using the maven-ear-plugin (version 2.6).

 The ear is configured such that it includes two libraries into the lib
 folder, both with the same artifactId as well as the same version, but a
 different groupId. Now if I simply call 'mvn package' only the first one is
 included, but no warning whatsoever appears. Only once I turn on debugging
 (mvn --debug package), I see one subtle message:
 [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date
 at [lib/bar-1.0.jar]

 Wouldn't it make sense to either include the groupId in the filename or at
 least make a check (that includes the groupId) beforehand if there are any
 conflicts?

 Cheers,
 Reto

Re: dependency management across projects

[Stephane Nicoll]

On Mon, Feb 3, 2014 at 8:21 AM, Anders Hammar and...@hammar.net wrote:

 I believe so, yes. The key thing in my solution is the BOM. And the BOM
 will keep the appropriate version of the the sub-products together.


Right!


 There is no automatic solution for this that I know of. I suppose that
 tolls could be created, but keep in mind that in the end, for backward
 compatibility reason SP2 has to use 1.8.0 is normally a human decision.


It is. The tool I aim to create is more report-based. Something that would
gather the dependencies on each sub-projects and report inconsistencies: a
dependency unknown to the product has been added or removed, etc.

Thanks for brainstorming this with me. It feels that we're indeed lacking
for a standard solution for this in the Maven land. Will look into that and
report here my progress

S.



 /Anders


 
  Creating manually the first BOM for P v1.0.0 isn't a problem: i've
 created
  a set of tools that I am happy to share once they are fully ready. But
  maintaining that BOM in the long run is more of a challenge (because we
  can't force the sub-projects to use those versions so we have to monitor
  what happens in each sub-project to take the appropriate version at the
  product level).
 
  Thanks again for the feedback!
 
  S.
 
 
  
   /Anders
  
  
   
   


 There is also the possibility of creating a grouping pom, which
  lists
all
 artifacts as dependencies. You would then declare a dependency to
  that
 grouping pom and get all deps magically sucked in. However, this is
  not
 really the Maven way in my opinion as you wouldn't specify your
   direct
 deps bu sort of relly on transitive deps. There are some fans of
 this
 approach though here on this list.


  2. Build configs that *force* each sub-project to run with the
 list
   of
  dependencies for the project (to ensure all tests pass, etc).
 This
  is
to
 be
  used alongside the regular build job for validation purpose
 

 Maybe some enforcer rule?

   
Like I said, this is to be used alongside the regular build job. So
 my
   SP4
1.2.0-SNAPSHOT is building with a set of dependencies on its own and
 I
   want
to validate that with the dependencies of the target release for P,
 it
  is
also working just fine. It may just be the same ideally or slightly
different (or not slightly at all which requires an explicit
  validation).
   
So I need to be able to swap those versions for validation purposes
 and
   run
the build with that.
   
S.
   
   
   

 /Anders


 
  I started to look at this and my first trial was to generate a
  report
 with
  all the dependencies of each project and build a consolidated
  report
 that I
  can match against the candidates. This would help manage the
 first
   goal
 as
  if a dependency gets added, removed or updated, the global
  dependencyManagement has to be impacted manually (do we upgrade
 or
   not,
  etc).
 
  For the second part, it's not easy to force a dependency change
 in
Maven,
  especially if the version has been specified at the project
 level.
 
  Thanks for reading that far. If you have any idea or know any
 organisation
  that tried to implement that, I'd be interested
 
  Thanks!
  S.
 

   
  
 

Re: dependency management across projects

[Stephane Nicoll]

Thanks for the feedback. This looks like something that the
versions-maven-plugin could do. There's something similar that is
advertised by the plugin documentation but it's not implemented. I'll have
a look to that too.

Thanks!
S.


On Mon, Feb 3, 2014 at 6:39 PM, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi everyone,

   The very point I am trying to make here is
   how do you manage that manual BOM on a daily basis.
 
  There is no automatic solution for this that I know of.

 Maybe not exactly what you are looking for, but sort of similar:

 My group uses a script [1] to automatically bump the version of our parent
 POM [2].

 In that parent POM, we declare many version properties, plugin
 configuration in pluginManagement, etc., and we like to keep all our
 projects across various Git repositories using the newest available version
 of the parent, to minimize version clashes when mixing and matching
 libraries.

 We set up a parameterized Jenkins job [3] to run the parent bump for us,
 which provides checkboxes for all the downstream projects so the bump can
 be controlled individually.

 It's not perfect but it does save a lot of manual maintenance.

 Regards,
 Curtis

 [1]

 https://github.com/scijava/scijava-scripts/blob/a0fc8006741e0216c74c82866fd1bb1a7d364d55/bump-pom-scijava.sh
 [2]

 https://github.com/scijava/pom-scijava/blob/0de0676f7731b98baa89379dc8b92f8b26a5d086/pom.xml
 [3] http://jenkins.imagej.net/view/SciJava/job/Bump-POM-SciJava/


 On Mon, Feb 3, 2014 at 1:21 AM, Anders Hammar and...@hammar.net wrote:

  
The release of the BOM would be that release of a single coherent
  unit
then. It would specify the (marketing) version of the platform P.
For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1),
  v1.4.3
   of
SP2, etc.
  
   Isn't it what I just write in my original post? (without mentioning the
   BOM)
  
 
  I believe so, yes. The key thing in my solution is the BOM. And the BOM
  will keep the appropriate version of the the sub-products together.
 
 
 
   The very point I am trying to make here is
   how do you manage that manual BOM on a daily basis. Each sub-project
  has
   its own release cycle and we cannot force the versions it has to use
 for
  a
   specific branch. For instance, the product might state that the
  dependency
   D should be 2.2.0 (because that's the latest or the one that people
   generally use) but for backward compatibility reason SP2 has to use
  1.8.0.
  
 
  There is no automatic solution for this that I know of. I suppose that
  tolls could be created, but keep in mind that in the end, for backward
  compatibility reason SP2 has to use 1.8.0 is normally a human decision.
 
  /Anders
 
 
  
   Creating manually the first BOM for P v1.0.0 isn't a problem: i've
  created
   a set of tools that I am happy to share once they are fully ready. But
   maintaining that BOM in the long run is more of a challenge (because we
   can't force the sub-projects to use those versions so we have to
 monitor
   what happens in each sub-project to take the appropriate version at the
   product level).
  
   Thanks again for the feedback!
  
   S.
  
  
   
/Anders
   
   


 
 
  There is also the possibility of creating a grouping pom, which
   lists
 all
  artifacts as dependencies. You would then declare a dependency to
   that
  grouping pom and get all deps magically sucked in. However, this
 is
   not
  really the Maven way in my opinion as you wouldn't specify your
direct
  deps bu sort of relly on transitive deps. There are some fans of
  this
  approach though here on this list.
 
 
   2. Build configs that *force* each sub-project to run with the
  list
of
   dependencies for the project (to ensure all tests pass, etc).
  This
   is
 to
  be
   used alongside the regular build job for validation purpose
  
 
  Maybe some enforcer rule?
 

 Like I said, this is to be used alongside the regular build job. So
  my
SP4
 1.2.0-SNAPSHOT is building with a set of dependencies on its own
 and
  I
want
 to validate that with the dependencies of the target release for P,
  it
   is
 also working just fine. It may just be the same ideally or slightly
 different (or not slightly at all which requires an explicit
   validation).

 So I need to be able to swap those versions for validation purposes
  and
run
 the build with that.

 S.



 
  /Anders
 
 
  
   I started to look at this and my first trial was to generate a
   report
  with
   all the dependencies of each project and build a consolidated
   report
  that I
   can match against the candidates. This would help manage the
  first
goal
  as
   if a dependency gets added, removed or updated, the global
   dependencyManagement has to be impacted manually (do we upgrade

Re: dependency management across projects

[Stephane Nicoll]

On Fri, Jan 31, 2014 at 1:16 PM, Anders Hammar and...@hammar.net wrote:

 The release of the BOM would be that release of a single coherent unit
 then. It would specify the (marketing) version of the platform P.
 For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of
 SP2, etc.


Isn't it what I just write in my original post? (without mentioning the BOM)



 Creating the BOM would be a manual work I think, as you want to make sure
 that exactly the correct versions are included (might not be the latest
 releases).


Yes, this is already what I do. The very point I am trying to make here is
how do you manage that manual BOM on a daily basis. Each sub-project has
its own release cycle and we cannot force the versions it has to use for a
specific branch. For instance, the product might state that the dependency
D should be 2.2.0 (because that's the latest or the one that people
generally use) but for backward compatibility reason SP2 has to use 1.8.0.

Creating manually the first BOM for P v1.0.0 isn't a problem: i've created
a set of tools that I am happy to share once they are fully ready. But
maintaining that BOM in the long run is more of a challenge (because we
can't force the sub-projects to use those versions so we have to monitor
what happens in each sub-project to take the appropriate version at the
product level).

Thanks again for the feedback!

S.



 /Anders


 
 
  
  
   There is also the possibility of creating a grouping pom, which lists
  all
   artifacts as dependencies. You would then declare a dependency to that
   grouping pom and get all deps magically sucked in. However, this is not
   really the Maven way in my opinion as you wouldn't specify your
 direct
   deps bu sort of relly on transitive deps. There are some fans of this
   approach though here on this list.
  
  
2. Build configs that *force* each sub-project to run with the list
 of
dependencies for the project (to ensure all tests pass, etc). This is
  to
   be
used alongside the regular build job for validation purpose
   
  
   Maybe some enforcer rule?
  
 
  Like I said, this is to be used alongside the regular build job. So my
 SP4
  1.2.0-SNAPSHOT is building with a set of dependencies on its own and I
 want
  to validate that with the dependencies of the target release for P, it is
  also working just fine. It may just be the same ideally or slightly
  different (or not slightly at all which requires an explicit validation).
 
  So I need to be able to swap those versions for validation purposes and
 run
  the build with that.
 
  S.
 
 
 
  
   /Anders
  
  
   
I started to look at this and my first trial was to generate a report
   with
all the dependencies of each project and build a consolidated report
   that I
can match against the candidates. This would help manage the first
 goal
   as
if a dependency gets added, removed or updated, the global
dependencyManagement has to be impacted manually (do we upgrade or
 not,
etc).
   
For the second part, it's not easy to force a dependency change in
  Maven,
especially if the version has been specified at the project level.
   
Thanks for reading that far. If you have any idea or know any
   organisation
that tried to implement that, I'd be interested
   
Thanks!
S.
   
  
 

Maven process stuck on MacOS with Java8

[Stephane Nicoll]

On Fri, Jan 31, 2014 at 8:45 PM, Mark Derricutt
m...@talios.comjavascript:_e(%7B%7D,'cvml','m...@talios.com');
 wrote:

 That's the terminal, not the shell ( bash, zsh, fish, csh etc. ).


Yes, right. I am just using the default (bash). I also invoked the same
command from the plain Terminal application and I have the same issue.

Martijn, I've just tried with 127, same issue.

The problem is that I can't generate a thread dump

jstack 47707

47707: Unable to open socket file: target process not responding or HotSpot
VM not loaded

The -F option can be used when the target process is not responding

Using -F does not really help either.

S.


 I was also using iTerm when I had my issue, and now I think about it -
 since the last beta update/release I've not seen the issue again, but I
 also changed laptops so can't recall if its only on the new install I've
 not had the issue.

 I suspect they're not the same issue tho...  maybe.


 On 1 Feb 2014, at 0:05, Stephane Nicoll wrote:

  Mark,

 I am using iTerm2 (1.0.0.20130622)

 S.


 On Fri, Jan 31, 2014 at 11:56 AM, Mark Derricutt 
 m...@talios.comjavascript:_e(%7B%7D,'cvml','m...@talios.com');
 wrote:

  You're not by any chance using fish as your shell are you?

 For awhile some strange bug in fish ( at least on my old machine, along
 with a combination of prompt settings ) would hang on the termination
 of
 processes, more often than not maven but also others.  Something about it
 being stuck reading a char from stdin or something - only it wasn't time
 related, sometimes resizes/splitting the terminal would kick it back into
 gear.


 On 31 Jan 2014, at 23:12, Stephane Nicoll wrote:

 I am definitely impatient because looking at that closer, the shell is
 not

 stuck but it takes several seconds to give back hand. Sometimes it's ok,
 sometimes is 5 sec or so.


 -
 To unsubscribe, e-mail: 
 users-unsubscr...@maven.apache.orgjavascript:_e(%7B%7D,'cvml','users-unsubscr...@maven.apache.org');
 For additional commands, e-mail: 
 users-h...@maven.apache.orgjavascript:_e(%7B%7D,'cvml','users-h...@maven.apache.org');



 -
 To unsubscribe, e-mail: 
 users-unsubscr...@maven.apache.orgjavascript:_e(%7B%7D,'cvml','users-unsubscr...@maven.apache.org');
 For additional commands, e-mail: 
 users-h...@maven.apache.orgjavascript:_e(%7B%7D,'cvml','users-h...@maven.apache.org');




-- 
Sent from my phone

Re: Maven process stuck on MacOS with Java8

[Stephane Nicoll]

On Thu, Jan 30, 2014 at 12:20 PM, Mark Derricutt m...@talios.com wrote:

 Can't say I've seen that with any of the 1.8 builds I've been trailing,
 either the official dev builds or the ones I'm compiling up myself...

 Have you tried looking at a thread dump and seeing where in Maven it's
 hanging?


I am definitely impatient because looking at that closer, the shell is not
stuck but it takes several seconds to give back hand. Sometimes it's ok,
sometimes is 5 sec or so.

S.



 Mark


 On 31 Jan 2014, at 0:13, Stephane Nicoll wrote:

  Hi,

 Has anybody else noticed an issue with Java8 running Maven?

 I am using 1.8.0-ea-b124 and a maven command does not complete properly.
 It
 does not matter which plugin or phase is invoked, the process is stuck at
 the end and I have to ctrl-Z to go back to the shell.

 Switching back to Java 1.7 fixes the problem for me.

 Any idea?

 Thanks,
 S.


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

dependency management across projects

[Stephane Nicoll]

Hi,

I was wondering if anyone knows or has experience with a system that would
track and consolidate dependencies on a project composed of several
sub-projects.

Assume a project P with 10 sub-projects (SP1...SP10). Each of those
sub-projects are located in its own space and have its own lifecycle
(release versioning, etc). But ultimately, the project P needs to be
released as a set of coherent *tested* dependencies. For various reasons,
some sub-projects have to keep different dependencies of the target for
backward compatibility reason.

There are two deliverables to this:

1. Provide a single/coherent dependencyManagement section so that users
using P do not have to care about the different versions of the
sub-projects: they use P and all the required dependencies are pulled
automatically
2. Build configs that *force* each sub-project to run with the list of
dependencies for the project (to ensure all tests pass, etc). This is to be
used alongside the regular build job for validation purpose

I started to look at this and my first trial was to generate a report with
all the dependencies of each project and build a consolidated report that I
can match against the candidates. This would help manage the first goal as
if a dependency gets added, removed or updated, the global
dependencyManagement has to be impacted manually (do we upgrade or not,
etc).

For the second part, it's not easy to force a dependency change in Maven,
especially if the version has been specified at the project level.

Thanks for reading that far. If you have any idea or know any organisation
that tried to implement that, I'd be interested

Thanks!
S.

Re: Maven process stuck on MacOS with Java8

[Stephane Nicoll]

Mark,

I am using iTerm2 (1.0.0.20130622)

S.


On Fri, Jan 31, 2014 at 11:56 AM, Mark Derricutt m...@talios.com wrote:

 You're not by any chance using fish as your shell are you?

 For awhile some strange bug in fish ( at least on my old machine, along
 with a combination of prompt settings ) would hang on the termination of
 processes, more often than not maven but also others.  Something about it
 being stuck reading a char from stdin or something - only it wasn't time
 related, sometimes resizes/splitting the terminal would kick it back into
 gear.


 On 31 Jan 2014, at 23:12, Stephane Nicoll wrote:

  I am definitely impatient because looking at that closer, the shell is not
 stuck but it takes several seconds to give back hand. Sometimes it's ok,
 sometimes is 5 sec or so.


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

Re: dependency management across projects

[Stephane Nicoll]

Thanks for the response.

On Fri, Jan 31, 2014 at 11:33 AM, Anders Hammar and...@hammar.net wrote:

 
  1. Provide a single/coherent dependencyManagement section so that users
  using P do not have to care about the different versions of the
  sub-projects: they use P and all the required dependencies are pulled
  automatically
 

 Some confusion here. You're talking about depMgmt and then say that the
 required deps should be pulled in autoamtically. That will not happen. You
 still need to specify the deps you have.


Yes, but not the versions. The users will have to add the dependency they
want to use, yes. The point here is that they don't have to care about the
versions (but I do, which is why I need some tooling)



 In any case, this is ok if you want to stay on the Maven way. This
 depMgmt could be handled/provided in a separate pom which is then included
 in those projects that want to use the platform/product. Sometimes this is
 called a BOM (Bill of Material). JBoss provides such a BOM for their app
 server for example. A quick Google gave this page talking about that:
 http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms



BOM is exactly what I want to do, yes. What may not be clear in my original
post is that I am looking at this problem as the release manager of P who
wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want
to have an overview of where the different sub-projects stands with regards
to the target for P.

Assume that each sub-project has its own release cycle (and is released as
a project on its own actually) and at some point those different projects
have to be released as a single coherent unit.




 There is also the possibility of creating a grouping pom, which lists all
 artifacts as dependencies. You would then declare a dependency to that
 grouping pom and get all deps magically sucked in. However, this is not
 really the Maven way in my opinion as you wouldn't specify your direct
 deps bu sort of relly on transitive deps. There are some fans of this
 approach though here on this list.


  2. Build configs that *force* each sub-project to run with the list of
  dependencies for the project (to ensure all tests pass, etc). This is to
 be
  used alongside the regular build job for validation purpose
 

 Maybe some enforcer rule?


Like I said, this is to be used alongside the regular build job. So my SP4
1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want
to validate that with the dependencies of the target release for P, it is
also working just fine. It may just be the same ideally or slightly
different (or not slightly at all which requires an explicit validation).

So I need to be able to swap those versions for validation purposes and run
the build with that.

S.




 /Anders


 
  I started to look at this and my first trial was to generate a report
 with
  all the dependencies of each project and build a consolidated report
 that I
  can match against the candidates. This would help manage the first goal
 as
  if a dependency gets added, removed or updated, the global
  dependencyManagement has to be impacted manually (do we upgrade or not,
  etc).
 
  For the second part, it's not easy to force a dependency change in Maven,
  especially if the version has been specified at the project level.
 
  Thanks for reading that far. If you have any idea or know any
 organisation
  that tried to implement that, I'd be interested
 
  Thanks!
  S.
 

Checking dependencyManagement content

[Stephane Nicoll]

Hi,

As far as I know, there is no plugin out there that validates the content
of the dependencyManagement section. There are more and more people using
the so-called Bill of materials out there and having such a goal would be
nice to make sure that the dependencies listed there are valid (still
exists, proper type, etc)

Anybody knows if such initiative exists?

Thanks,
S.

Maven process stuck on MacOS with Java8

[Stephane Nicoll]

Hi,

Has anybody else noticed an issue with Java8 running Maven?

I am using 1.8.0-ea-b124 and a maven command does not complete properly. It
does not matter which plugin or phase is invoked, the process is stuck at
the end and I have to ctrl-Z to go back to the shell.

Switching back to Java 1.7 fixes the problem for me.

Any idea?

Thanks,
S.

Re: [VOTE] Retire Maven One Plugin

[Stephane Nicoll]

+1

S.


On Sat, Jul 20, 2013 at 11:13 AM, Dennis Lundberg denn...@apache.orgwrote:

 Hi,

 Now that we have Maven 1 at End-Of-Life, I think it's time to retire
 Maven One Plugin as well. It has been almost six years since the last
 release. I therefor propose that we retire maven-one-plugin.

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

 If this vote is successful I will make one final release of the
 plugin, making it clear on the plugin site that it has been retired.
 After that the source code will be moved into the retired area in
 Subversion.

 The process for retiring a plugin is described here, and is being improved:
 http://maven.apache.org/developers/retirement-plan-plugins.html

 The vote is open for 72 hours.

 [ ] +1 Yes, it's about time
 [ ] -1 No, because...

 --
 Dennis Lundberg

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

Re: Welcome Andreas Gudian as a maven committer !

[Stephane Nicoll]

Good stuff. Welcome!


On Fri, Feb 22, 2013 at 10:28 PM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 I'd like to welcome Andreas Gudian as our latest committer!

 Andreas has been working mostly on surefire, where he has been doing some
 great stuff.
 Gaining the commit bit now means he can work on anything he prefers,
 something I truly believe will make maven an even more interesting place to
 be.

 He lives on the Central Eurpean Time zone, increasing the euro-dominance of
 the maven project ;)

 Welcome !

 Kristian

[ANN] Maven EAR Plugin 2.8 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven EAR
Plugin, version 2.8

The plugin generates a JavaEE Enterprise Archive (EAR) file.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-ear-plugin/artifactId
  version2.8/version
/plugin


Release Notes - Maven 2.x Ear Plugin - Version 2.8

** Bug
* [MEAR-147] - wrong DOCTPYE in jboss-app.xml for 4.2
* [MEAR-151] - Allow empty library-directory element in application.xml

** Improvement
* [MEAR-141] - No way to configure generate env-entry elements in
generated application.xml
* [MEAR-145] - Add Maven version used to Created-By entry in manifest
* [MEAR-146] - Expose parameter to not write library-directory
element in application.xml

** New Feature
* [MEAR-150] - Support new 'no-version-for-ejb' file name mapping


** Task
* [MEAR-152] - use maven-plugin-tools' java 5 annotations


Enjoy,

-The Maven team

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

Re: [SOLVED] maven-ear-plugin is not including jarModule into application.xml

[Stephane Nicoll]

mvn help:effective-pom is your friend here.

S.

On Thu, Aug 23, 2012 at 5:20 PM, Stuart Stephen
stuart.step...@tracegroup.com wrote:
 I worked it out. I was being an idiot as usual. User error.

 Strangely it was producing the EAR file pretty much correctly, even though my 
 plugin wasn't configured properly.

 I replaced...

 groupIdmaven-ear-plugin/groupId
 artifactIdmaven-ear-plugin/artifactId
 with...

 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-ear-plugin/artifactId
 Then changed...

 includeLibInApplicationXmltrue/includeLibInApplicationXml
 to...

 includeInApplicationXmltrue/includeInApplicationXml

 Suddenly it did what I asked. Clever that.

 -Original Message-
 From: Stuart Stephen [mailto:stuart.step...@tracegroup.com]
 Sent: 23 August 2012 16:01
 To: users@maven.apache.org
 Subject: maven-ear-plugin is not including jarModule into application.xml

 Hi,

 [This question is also on StackOverflow: 
 http://stackoverflow.com/questions/12093346/maven-ear-plugin-is-not-including-jarmodule-into-application-xml]

 I've been following the example on the maven-ear-plugin site that [shows how 
 to add third-party libraries to the generated application.xml][1]. However, 
 it does not appear to be working as I expected. Similarly the web module 
 [contextRoot][2] is being ignored.

 According to the [documentation][3] what I am trying to do should be entirely 
 possible.

 The context root of a Web module might be customized using the contextRoot 
 parameter.
 Please note that third party libraries (i.e. JarModule) are not included in 
 the generated application.xml (only ejb-client should be included in a java 
 entry). However, a jar dependency could be included in the generated 
 application.xml by specifying the includeInApplicationXml flag.

 I have the following output when it executes the build in my application.xml.

 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE application PUBLIC
 -//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN
 http://java.sun.com/dtd/application_1_3.dtd;
 application
   display-nameMyApp.EAR/display-name
   module
 ejbMyApp.jar/ejb
   /module
   module
 web
   web-uriMyApp.war/web-uri
   context-root/MyApp.Web/context-root
 /web
   /module
 /application

 From the following maven configuraton (pom.xml).
 ...
 modelVersion4.0.0/modelVersion
 groupIdcom.blah/groupId
 artifactIdMyApp.EAR/artifactId
 version1.0/version
 packagingear/packaging

 build
 plugins
 plugin
 groupIdmaven-ear-plugin/groupId
 artifactIdmaven-ear-plugin/artifactId
 version2.7/version
 configuration
 applicationNameMyApp/applicationName
 modules
 ejbModule
 groupIdcom.blah/groupId
 artifactIdMyApp.EJB/artifactId
 /ejbModule
 webModule
 groupIdcom.blah/groupId
 artifactIdMyApp.Web/artifactId
 contextRootMyApp/contextRoot
 /webModule
 jarModule
 groupIdorg.slf4j/groupId
 artifactIdslf4j-simple/artifactId
 
 includeLibInApplicationXmltrue/includeLibInApplicationXml
 /jarModule
 /modules
 archive
 manifestEntries
 
 WebLogic-Application-Version${weblogic.version}/WebLogic-Application-Version
 /manifestEntries
 /archive
 /configuration
 /plugin
 /plugins
 /build

 dependencies
 !-- web and ejb modules --
 dependency
 groupIdcom.blah/groupId
 artifactIdMyApp.EJB/artifactId
 version1.0/version
 typeejb/type
 /dependency
 dependency
 groupIdcom.blah/groupId
 artifactIdMyApp.Web/artifactId
 version1.0/version
 typewar/type
 /dependency
 /dependencies
 ...

 It is immediately obvious that the application.xml is not being generated as 
 I intended.
 1. The contextRoot supplied is not correct in the application.xml, instead 
 the default name of MyApp.Web is output instead of the specified MyApp.
 2. The org.slf4j jarModule specified is missing entirely from the 
 application.xml.
 What am I doing wrong?
 Debug from Maven is shown below.

 [DEBUG] 
 ---
 [DEBUG] Goal:  
 org.apache.maven.plugins:maven-ear-plugin:2.4.2:generate-application-xml 
 (default-generate-application-xml)
 [DEBUG] Style: Regular
 [DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8? configuration
   description${project.description}/description
   displayName${project.artifactId}/displayName
   encoding default-value=UTF-8/
   
 

[ANN] Maven Resources Plugin 2.6 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven Resources
Plugin, version 2.6

The Resources Plugin handles the copying of project resources to the
output directory.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-resources-plugin/artifactId
  version2.6/version
/plugin


Release Notes - Maven 2.x Resources Plugin - Version 2.6


** Bug
* [MRESOURCES-111] - escapeWindowsPath doesn't work when applying properties
* [MRESOURCES-131] - Maven resources plugin does not honour
maven.test.skip  flag
* [MRESOURCES-141] - Filtering doesn't work when there is an odd
number of @ in the resource
* [MRESOURCES-166] - Escaping on a line suppresses filtering for
the rest of the token/line

** Improvement
* [MRESOURCES-140] - Plugin shows always '[debug] execute
contextualize' despite the logging level
* [MRESOURCES-148] - Turn Off '@' Escape Filtering
* [MRESOURCES-161] - Some incorrect HTML in the description of the
delimiters parameter

** Task
* [MRESOURCES-139] - misspelling in documentation: /inclues
* [MRESOURCES-167] - use new maven plugins annotations.


Enjoy,

-The Maven team

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

[ANN] Maven Filtering 1.1 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven
Filtering, version 1.1

These Plexus components have been built from the filtering process/code
in Maven Resources Plugin. The goal is to provide a shared component for
all plugins that needs to filter resources.

http://maven.apache.org/shared/maven-filtering/

You should specify the version in your project's configuration:

plugin
  groupIdorg.apache.maven.shared/groupId
  artifactIdmaven-filtering/artifactId
  version1.1/version
/plugin


Release Notes - Maven Shared Components - Version maven-filtering-1.1

** Bug
* [MSHARED-195] - maven-filtering incorrect states a dependency to
maven-monitor
* [MSHARED-215] - maven-filtering brings in JUnit as transitive dependency
* [MSHARED-228] -
MultiDelimiterInterpolatorFilterReaderLineEnding() does not filter
after a token is escaped


Enjoy,

-The Maven team

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

[ANN] Maven Script Interpreter 1.1 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven
Script Interpreter, version 1.1

This component provides some utilities to interpret/execute some
scripts for various implementations: groovy or beanshell.

http://maven.apache.org/shared/maven-script-interpreter/

You should specify the version in your project's configuration:

plugin
  groupIdorg.apache.maven.shared/groupId
  artifactIdmaven-script-interpreter/artifactId
  version1.1/version
/plugin


Release Notes - Maven Shared Components - Version maven-script-interpreter-1.1

** Improvement
* [MSHARED-229] - log relative script path when available instead
of full path
* [MSHARED-231] - upgrade groovy version used to 2.0.1

** Task
* [MSHARED-230] - use plexus java 5 annotations instead of
old-style javadoc annotations


Enjoy,

-The Maven team

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

[ANN] Maven Invoker Plugin 1.7 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven Invoker
Plugin, version 1.7

The Invoker Plugin is used to run a set of Maven projects. The plugin
can determine whether each project execution is successful, and
optionally can verify the output generated from a given project
execution.

This plugin is in particular handy to perform integration tests for
other Maven plugins. The Invoker Plugin can be employed to run a set
of test projects that have been designed to assert certain features of
the plugin under test.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-invoker-plugin/artifactId
  version1.7/version
/plugin


Release Notes - Maven 2.x Invoker Plugin - Version 1.7

** Improvement
* [MINVOKER-135] - log relative script path instead of full script
path for pre-/post-build scripts
* [MINVOKER-136] - upgrade groovy version used to 2.0.1

** Task
* [MINVOKER-134] - use maven-plugin-tools' java 5 annotations


Enjoy,

-The Maven team

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

[ANN] Maven Source Plugin 2.2 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven Source
Plugin, version 2.2

This plugin is used to create jar of the project source files.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-source-plugin/artifactId
  version2.2/version
/plugin

Release Notes - Maven 2.x Source Plugin - Version 2.2


** Bug
* [MSOURCES-30] - Should not output INFO message when maven is run
in quiet mode
* [MSOURCES-45] - Test Source Jar has wrong name.
* [MSOURCES-60] - Use new annotations api

** Improvement
* [MSOURCES-23] - test-jar misses sources from generate-test-sources phase
* [MSOURCES-51] - Disable source plugin in derived pom
* [MSOURCES-53] - defaultManifestFile should not be readonly
* [MSOURCES-61] - Reduce the logging level of the message
indicated the resource has already been added to the archive

** New Feature
* [MSOURCES-48] - Including sources in project dependencies
* [MSOURCES-50] - Add optional 'classifier' for source artifact
* [MSOURCES-55] - Add a skip configuration to source plugin
* [MSOURCES-56] - Parameter to skip the generation of the sources jar

Enjoy,

-The Maven team

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

Re: EAR project produces application.xml, but EJB module is missing

[Stephane Nicoll]

On Tue, Mar 6, 2012 at 6:24 PM, Markus KARG mar...@headcrashing.eu wrote:

 What do you mean with maps to?


An EJB is a .jar file. If you don't specify any type, jar is the default
and since they share the same extension, Maven is able to resolve the
dependency. One improvement would be to look at the pom file and realize
the packaging is set to ejb and issue a warning in this case.

Feel free to open a Jira for this.

Thanks,
S.



  -Original Message-
  From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
  Sent: Sonntag, 4. März 2012 13:01
  To: Maven Users List
  Subject: Re: EAR project produces application.xml, but EJB module is
  missing
 
  Because ejb type maps to jar extension
 
  On Sunday, 4 March 2012, Markus KARG mar...@headcrashing.eu wrote:
   You are right, when adding typeejb/type it is working! I missed
   the
  fact
   that maven coordinates include the packaging, while the default
   packaging
  is
   typejar/type. The odd thing is that dependency resolution is
   working without that. So it actually seems, module resolution is
   working correctly while dependency resolution ignores type.
  
   Thanks a lot!
   Markus
  
   -Original Message-
   From: Stephen Coy [mailto:st...@resolvesw.com]
   Sent: Sonntag, 4. März 2012 09:44
   To: Maven Users List
   Subject: Re: EAR project produces application.xml, but EJB module is
   missing
  
   The number one reason I've had this problem in the past is
  forgetting
   to specify:
  
 typeejb/type
  
   in the dependency declarations for EJB jars.
  
  
   On 04/03/2012, at 2:33 AM, Markus KARG wrote:
  
Maven 3.0.4 is producing application.xml containing module
entries for some dependencies (RAR modules), but which is missing
module entries for other dependencies (EJB modules). This is
weird as the
   pom
more or less is empty. It just contains the dependencies (RAR
modules and EJB modules) and Java EE version (6). So I assume one
cannot do wrong. Is that a bug in Maven or what the heck is the
trick to get
   module entries for EJB modules?
   
  
  
   
  -
   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: jboss-app.xml Auto Generated from MAVEN EAR plugin

[Stephane Nicoll]

On Fri, Feb 3, 2012 at 6:44 PM, Daivish Shah daivish.s...@gmail.com wrote:


 Do we have any guideline or any link from where i can read which all Jboss
 TAG supported by MAVE EAR plugin ?

 Thanks.


In the doc (see JBoss support):
http://maven.apache.org/plugins/maven-ear-plugin/usage.html

S.







 On Thu, Feb 2, 2012 at 10:31 PM, Stephen Coy st...@resolvesw.com wrote:

 
  On 03/02/2012, at 4:42 AM, Daivish Shah wrote:
 
   Hi Wayne,
  
   org.springframework.beans.factory.BeanCreationException: Error
   creating bean with name 'TestEjbHandlerImpl': Invocation of init
   method failed; nested exception is java.lang.LinkageError: loader
   constraint violation: loader (instance of
   org/jboss/web/tomcat/service/WebCtxLoader$ENCLoader) previously
   initiated loading for a different type with name
   javax/xml/namespace/QName
  
  
 
  The whole JBoss 5 deployment descriptor is almost a red herring. In fact
  it exposes a clue as to what the real problem is.
 
  The problem you have here is that your application has included at least
  one of the (many) XML utilities out there that contains it's own version
 of
  javax.xml.namespace.QName. The reason for this is largely historical as
  it's generally a result of forward migration of code from Java 1.3/1.4
  environments.
 
  Early xmlbeans is one such example. Old releases of Apache Axis is
 another
  source of these kinds of problems.
 
  Cheers,
 
  Steve C
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

[ANN] Maven EAR Plugin 2.6 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven EAR
Plugin, version 2.6

This version brings mainly detection of application client archive
managed by the recent maven-arc-plugin [1]

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-ear-plugin/artifactId
  version2.6/version
/plugin


Release Notes - Maven 2.x Ear Plugin - Version 2.6

** Bug
* [MEAR-139] - earSourceDirectory named in documentation as
earSourcesDirectory

** New Feature
* [MEAR-40] - Autodetect Client Application modules and EJB3 modules.
* [MEAR-137] - Support for JEE Application Clients

Enjoy,

-The Maven team

[1] http://maven.apache.org/plugins/maven-acr-plugin/

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

[ANN] Maven ACR Plugin 1.0 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven ACR
Plugin, version 1.0

The Maven ACR (Application Client aRchive) is a new plugin in the
JavaEE spectrum meant to deal with the JavaEE application client
packaging type. A new app-client packaging type is provided with
this plugin and an integration with the EAR plugin is foreseen[1] short term

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

You should specify the version in your project's plugin configuration
and enable the plugin's extensions as the new app-client packaging
type is not yet detected by Maven automatically:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-acr-plugin/artifactId
  version1.0/version
  extensionstrue/extensions
/plugin


Release Notes - Maven ACR Plugin - Version 1.0

** Improvement
* [MACR-2] - Initial documentation

** New Feature
* [MACR-1] - Initial version of the plugin


Enjoy,

-The Maven team

[1] http://jira.codehaus.org/browse/MEAR-137

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

Re: maven 3.0.1 pulling in transient dependencies of a provided dependency as compile-scoped

[Stephane Nicoll]

Aren't these coming from another dependencies. If you flip the maven
version on the exact same project, do you get any difference?

S.

On Mon, Dec 27, 2010 at 12:31 PM, radai radai.rosenbl...@gmail.com wrote:
 i have a maven project that contains the following dependency:

 dependency
    groupIdorg.jboss.ejb3/groupId
    artifactIdjboss-ejb3-core/artifactId
    version1.6.3/version
    scopeprovided/scope
 /dependency

 this is part of a module that produces an ear artifact. according to the
 maven dependency scope doc (
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html)
 the transient dependencies of a provided-scoped dependency are either
 scoped as provided or not treated at all. and yet in my case im seeing
 this as part of the build (produced with -X):

 [DEBUG] com.emc.illuminator:illuminator-ear:ear:6.0-SNAPSHOT
 [DEBUG]    ...some direct dependencies edited out for brevity's sake...
 [DEBUG]    org.jboss.ejb3:jboss-ejb3-core:jar:1.6.3:provided
 [DEBUG]       javassist:javassist:jar:3.7.1.GA:compile
 [DEBUG]       org.hibernate:hibernate-core:jar:3.3.1.GA:provided
 [DEBUG]          antlr:antlr:jar:2.7.6:provided
 [DEBUG]          dom4j:dom4j:jar:1.6.1:compile

 notice that javassist and dom4j are upgraded to compile-scoped, and they
 are also packaged as part of the ear. these are not the only artifacts
 upgraded.
 this project builds just fine with maven 2. before i start adding a lot of
 exclusions, what am i missing here ?

 thanks in advance for any help/ideas/comments/clues,

   radai.


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

[ANN] Maven EAR Plugin 2.5 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven EAR
Plugin, version 2.5

This new release brings additional compatibility with Java EE 6,
automatic id generation for modules and a few bug fixes.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-ear-plugin/artifactId
  version2.5/version
/plugin

Release Notes - Maven 2.x Ear Plugin - Version 2.5

** Bug
* [MEAR-116] - different build results from single module build
and from reactor build
* [MEAR-130] - maven build hangs when earSourceDirectory is set to /
* [MEAR-131] - Default value for earSourceDirectory param missing
* [MEAR-134] - no library-directory in application.xml if version is 6

** Improvement
* [MEAR-35] - Generate id for modules in application.xml
* [MEAR-98] - Add an implementation of FileNameMapping that allows
to remove version of artefact in the ear.
* [MEAR-128] - Support for application-name and
initialize-in-order (Java EE 6)
* [MEAR-132] - State default value for generateApplicationXml

** Task
* [MEAR-135] - Rationalize the management of the JavaEE version in
a dedicated class


Enjoy,

-The Maven team

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

Re: maven-ear-plugin 2.5-SNAPSHOT has been unstable lately

[Stephane Nicoll]

Without a closer look to your setup, it's hard to tell. There's nothing
special in this plugin that should lead to this particular error.

Releasing 2.5 is on my todo list for quite some time now, I was mostly
waiting from user's feedback. What are you using in 2.5 specifically?

S.

On Wed, Jan 12, 2011 at 11:12 AM, Viggo Navarsete viggo.navars...@gmail.com
 wrote:

 Hi,

 I'm using maven-ear-plugin 2.5-SNAPSHOT, and for the past week or so, we've
 had problems downloading it from Maven, output is this:

 Downloading:
 http://mavenrepo.pd.tracetracker.com:9998/repo/org/apache/maven/plugins/maven-ear-plugin/2.5-SNAPSHOT/maven-ear-plugin-2.5-20110111.075142-136.pom
 7K downloaded
 Downloading:
 http://mavenrepo.pd.tracetracker.com:9998/repo/org/apache/maven/plugins/maven-ear-plugin/2.5-SNAPSHOT/maven-ear-plugin-2.5-20110111.075142-136.jar
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Failed to resolve artifact.

 GroupId: org.apache.maven.plugins
 ArtifactId: maven-ear-plugin
 Version: 2.5-20110111.075142-136

 Reason: Unable to locate resource in repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-ear-plugin -Dversion=2.5-20110111.075142-136
 -Dpackaging=maven-plugin -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file
 there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-ear-plugin -Dversion=2.5-20110111.075142-136
 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
 -DrepositoryId=[id]



  
 org.apache.maven.plugins:maven-ear-plugin:maven-plugin:2.5-20110111.075142-136

 from the specified remote repositories:
  marplemirror (http://mavenrepo.pd.tracetracker.com:9998/repo)



 We have artifactory which cache all external dependencies for us, and it
 seems that sometimes when we delete maven-ear-plugin 2.5-SNAPSHOT from our
 repo it works, but then a few days later it stops working again. Is this a
 problem with the metadata for this plugin, or something else?

 Another question: When will you release a stable version (2.5) of the
 maven-ear-plugin? I assume that would also help preventing this from
 happening in the first place.

 Best regards,
 Viggo Navarsete

Re: Maven 3.0 and m-war-p 2.1: Duplicate entries in generated WAR?

[Stephane Nicoll]

You probably got affected by http://jira.codehaus.org/browse/MWAR-235

S.

On Wed, Oct 20, 2010 at 8:45 PM, Thorsten Heit th...@gmx.de wrote:

 Hi,

 I have a multi-module project structure that basically produces an EAR and
 some other artifacts:

 root
 +- pom.xml
 |
 +- module-common
 |  + pom.xml
 |  \ ...
 |
 +- module-war
 |  + pom.xml
 |  \ ...
 |
 +- module-ear
 |  + pom.xml
 |  \ ...
 |
 ...

 The project fully uses standard Maven directory layout, and there are some
 inter-module dependencies:
 - module-war depends on module-common
 - module-ear depends on module-war
 - each module has a parent entry to reference the project root

 The war module's web.xml (src/main/webapp/WEB-INF/web-xml) is automatically
 filtered when building the war so that Maven replaces display name and
 description with the values from my pom:

 web.xml:

 ?xml version=1.0 encoding=UTF-8?

 web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
id=WebApp_ID

display-name${project.name}/display-name
description${project.description} ${project.version}/description
...
 /web-app


 From the war module's pom.xml:

 ...
 packagingwar/packaging
 ...
 build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-beta-1/version
configuration

  filteringDeploymentDescriptorstrue/filteringDeploymentDescriptors
/configuration
/plugin
/plugins
 /build
 ...

 Everything quite basic, and all according to the docs on
 http://maven.apache.org/plugins/maven-war-plugin/faq.html.

 As long as I'm using m-war-p 2.1-beta-1, everything works fine. With
 m-war-p 2.1 the WAR suddenly contains duplicate web.xml entries in the
 WEB-INF folder so that the ear module can't be packaged successfully.

 Am I doing something wrong? Or is this a bug (feature)?


 Environment:
 - Maven 3.0
 - JDK 1.6.0_22
 - Windows XP


 Regards

 Thorsten

Re: Dependancy failure when building ear file

[Stephane Nicoll]

It should work but your project's version should be something like
1.0-SNAPSHOT, not 1.0.

That being said, it could be a thing as simple as a typo so posting your
project somewhere would help.

S.

On Fri, Sep 17, 2010 at 11:46 PM, Jon Paynter kittl...@gmail.com wrote:

 Hi -- ive been tasked with looking to see if maven will work to replace our
 current ant build.

 Since our company makes extensive use of j2ee and OC4J components, that was
 one of the first thigns I tackled after getting some basic modules to
 compile.

 In keeping with our existing ant build structure I setup the following tree
 structure:
 OC4J pom.xml
 |
 |--- OC4J.ear
 |
 |--- OC4J.rar
 |
 |--- OC4J.war

 The ear is setup with a dependancy on the war file.
 If goto the top level folder and run:  mvn compile -- all is fine. no
 errors.

 but when I goto the top level folder and run:  mvn package
 I get an error when building the ear file saying it cant find the war file:

 [ERROR] Failed to execute goal on project OC4J.ear: Could not resolve
 dependencies for project cdrive:OC4J.ear:ear:1.0: The following artifacts
 could not be resolved: cdrive:OC4J.war:war:1.0: Failure to find
 cdrive:OC4J.war:war:1.0 in http://repo1.maven.org/maven2 was cached in the
 local repository. Resolution will not be reattempted until the update
 interval of central has elapsed or updates are forced. - [Help 1]


 I started this endevor using maven 2.2.1 but I had the same problems with
 ear generation.  searching led me to a post back from 2007 where somebody
 had the exact same problem, but there was no resolution posted.  I was
 hoping maven 3.0 would fix the issue, but it just gives different error
 messages.


 So my questions are as follows:

 1) Is there a better way to do this?  -- if so it needs to scale well, the
 project has about 20 OC4J components.
 2) if not, how do I fix the dependancies so this will work?
 3) if neither... will this be fixed in maven 3.0?

Re: Ear plugin issue

[Stephane Nicoll]

On Thu, Aug 26, 2010 at 7:36 PM, nishant@hsbcib.com wrote:

 Just that unable to find clientModule


That's just not enough. Provide the output of mvn dependency:list and the
log of your build (mvn package  output.log)







 Stephane Nicoll stephane.nic...@gmail.com
 Aug 26 2010 18:35

 Mail Size: 10664

 Please respond to
 Maven Users List users@maven.apache.org


 To
 Maven Users List users@maven.apache.org
 cc

 Subject
 Re: Ear plugin issue

  Entity
   HSBC Bank plc - HBEU



 What error message do you get exactly? ClientModules is not a dependency
 of
 the project or something else?

 S.

 On Thu, Aug 26, 2010 at 4:20 PM, nishant@hsbcib.com wrote:

  It seems the attachments are not allowed. I have included the ear pom
  below..
 
 
 

 **
  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/xsd/maven-4.0.0.xsd;
   modelVersion4.0.0/modelVersion
   parent
 artifactIdProjectX/artifactId
 groupIdroot/groupId
 version1.0/version
   /parent
   groupIdroot.ProjectX/groupId
   artifactIdEarAssembler/artifactId
   version1.0/version
   nameEarAssembler/name
   packagingear/packaging
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-ear-plugin/artifactId
 version2.4.2/version
 configuration
   modules
 jarModule
   groupIdroot.ProjectX/groupId
   artifactIdClientModules/artifactId
 /jarModule
   /modules
   archive
 manifest
   addClasspathtrue/addClasspath
 /manifest
   /archive
 /configuration
   /plugin
 /plugins
   /build
   dependencies
 dependency
   groupIdroot.ProjectX/groupId
   artifactIdClientModules/artifactId
   version1.0/version
 /dependency
   /dependencies
  /project
 
 

 **
 
 
  Thanks
 
 
 
 
  Nishant RAJ/HBEU/h...@hsbc
  Aug 26 2010 15:17
 
  Mail Size: 8020
 
  Please respond to
  Maven Users List users@maven.apache.org
 
 
  To
  users@maven.apache.org
  cc
 
  Subject
  Ear plugin issue
 
   Entity
HSBC Bank plc - HBEU
 
 
 
 
  Hi All,
 
  I am trying to get the ear plugin working.
 
  Followed all the guidelines but could not get it working as its not able
  to find the module that I want to package within the ear
 
  It looks for the module in my nexus repository but does not find it.
  I have also got the Resolve workspace project dependencies enables in
  eclipse.
 
  Pom is attached.
 
  Please advice as I have been struggling with the same for few hrs now.
 
  Thanks
  Nishant
 
 
 
  
  HSBC Bank plc
  Registered Office: 8 Canada Square, London E14 5HQ
  Registered in England - Number 14259
  Authorised and regulated by the Financial Services Authority
  
  - SAVE PAPER - THINK BEFORE YOU
  PRINT! This transmission has been issued by a member of the HSBC Group
  HSBC for the information of the addressee only and should not be
  reproduced and/or distributed to any other person. Each page attached
  hereto must be read in conjunction with any disclaimer which forms part
 of
  it. Unless otherwise stated, this transmission is neither an offer nor
 the
  solicitation of an offer to sell or purchase any investment. Its
 contents
  are based on information obtained from sources believed to be reliable
 but
  HSBC makes no representation and accepts no responsibility or liability
 as
  to its completeness or accuracy.
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
  
  HSBC Bank plc
  Registered Office: 8 Canada Square, London E14 5HQ
  Registered in England - Number 14259
  Authorised and regulated by the Financial Services Authority
  
 
 
  -
  SAVE PAPER - THINK BEFORE YOU PRINT!
 
  This transmission has been issued by a member of the HSBC Group
  HSBC for the information

Re: Ear plugin issue

[Stephane Nicoll]

What error message do you get exactly? ClientModules is not a dependency of
the project or something else?

S.

On Thu, Aug 26, 2010 at 4:20 PM, nishant@hsbcib.com wrote:

 It seems the attachments are not allowed. I have included the ear pom
 below..


 **
 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/xsd/maven-4.0.0.xsd;
  modelVersion4.0.0/modelVersion
  parent
artifactIdProjectX/artifactId
groupIdroot/groupId
version1.0/version
  /parent
  groupIdroot.ProjectX/groupId
  artifactIdEarAssembler/artifactId
  version1.0/version
  nameEarAssembler/name
  packagingear/packaging
  build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.4.2/version
configuration
  modules
jarModule
  groupIdroot.ProjectX/groupId
  artifactIdClientModules/artifactId
/jarModule
  /modules
  archive
manifest
  addClasspathtrue/addClasspath
/manifest
  /archive
/configuration
  /plugin
/plugins
  /build
  dependencies
dependency
  groupIdroot.ProjectX/groupId
  artifactIdClientModules/artifactId
  version1.0/version
/dependency
  /dependencies
 /project

 **


 Thanks




 Nishant RAJ/HBEU/h...@hsbc
 Aug 26 2010 15:17

 Mail Size: 8020

 Please respond to
 Maven Users List users@maven.apache.org


 To
 users@maven.apache.org
 cc

 Subject
 Ear plugin issue

  Entity
   HSBC Bank plc - HBEU




 Hi All,

 I am trying to get the ear plugin working.

 Followed all the guidelines but could not get it working as its not able
 to find the module that I want to package within the ear

 It looks for the module in my nexus repository but does not find it.
 I have also got the Resolve workspace project dependencies enables in
 eclipse.

 Pom is attached.

 Please advice as I have been struggling with the same for few hrs now.

 Thanks
 Nishant



 
 HSBC Bank plc
 Registered Office: 8 Canada Square, London E14 5HQ
 Registered in England - Number 14259
 Authorised and regulated by the Financial Services Authority
 
 - SAVE PAPER - THINK BEFORE YOU
 PRINT! This transmission has been issued by a member of the HSBC Group
 HSBC for the information of the addressee only and should not be
 reproduced and/or distributed to any other person. Each page attached
 hereto must be read in conjunction with any disclaimer which forms part of
 it. Unless otherwise stated, this transmission is neither an offer nor the
 solicitation of an offer to sell or purchase any investment. Its contents
 are based on information obtained from sources believed to be reliable but
 HSBC makes no representation and accepts no responsibility or liability as
 to its completeness or accuracy.
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 
 HSBC Bank plc
 Registered Office: 8 Canada Square, London E14 5HQ
 Registered in England - Number 14259
 Authorised and regulated by the Financial Services Authority
 


 -
 SAVE PAPER - THINK BEFORE YOU PRINT!

 This transmission has been issued by a member of the HSBC Group
 HSBC for the information of the addressee only and should not be
 reproduced and/or distributed to any other person. Each page
 attached hereto must be read in conjunction with any disclaimer
 which forms part of it. Unless otherwise stated, this transmission
 is neither an offer nor the solicitation of an offer to sell or
 purchase any investment. Its contents are based on information
 obtained from sources believed to be reliable but HSBC makes no
 representation and accepts no responsibility or liability as to its
 completeness or accuracy.

Re: adding non-class files to a JAR

[Stephane Nicoll]

And it's not meant to be used with files that will be read from the
classpath anyway. s/m/r (deprecated to src/main/application) is for the
deployment descriptor of the ear only.

S.

---
[image: Linkedin] http://www.linkedin.com/in/snicoll[image:
Twitter]http://twitter.com/snicoll


On Fri, Jul 23, 2010 at 10:02 PM, Wayne Fay wayne...@gmail.com wrote:

  thx for the response.  the compiled .jasper files are in sub-directories
  inside src/main/resources, so perhaps that is the problem and they all
 need
  to be placed in src/main/resources directly so they are included in the
 JAR.

 If this is an EAR-packaged project, src/main/resources will not work.
 Read the docs:
 http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html

 Wayne

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

Re: Ear Plugin Version 5 issue

[Stephane Nicoll]

Sorry I don't understand. Can you create an issue and attach a project that
reproduce the problem?

On Tue, May 18, 2010 at 4:00 PM, Wale12 chris.w...@ontario.ca wrote:


 I changed the

 earSourceDirectory./earSourceDirectory

 to

 earSourceDirectory${basedir}/earSourceDirectory

 No difference in my build though.

 Thanks.

 C.


 Wale12 wrote:
 
  I go into the maven repository to
  \org\apache\maven\plugins\maven-ear-plugin and delete the 2.4.1. folder
  then run the build again.
 
 
  snicoll wrote:
 
  And it probably doesn't. I am not sure I get your it works if I delete
  the
  plugin thing. Can you replace the . by ${basedir} to avoid any
  reactor-related issue?
 
  Thx,
  S.
 
  On Fri, May 14, 2010 at 6:01 PM, Wale12 chris.w...@ontario.ca wrote:
 
 
  Fair point.
 
  I am using hudson so this is all I get.
 
  Deployment descriptor:
 
 
 D:\Hudson\jobs\HCV_1.0_Dev\workspace\hud_HCV_1.0_view1\UcmVob08A\Src_Java\HCVWebService\HCVServiceEAR\target\HCVServiceEAR\META-INF\application.xml
  does not exist.
 
 
  C.
 
 
  snicoll wrote:
  
  uh? Why on Earth would you do this:
  
  earSourceDirectory./earSourceDirectory
  
  Can you post the full stacktrace. Are you running from the reactor
  when
  it
  happens?
  
  S.
  
  
  On Fri, May 14, 2010 at 4:21 PM, Wale12 chris.w...@ontario.ca
 wrote:
  
  
   I have a weird issue with a project I have.  I am using maven 2 and
   version
   2.4.1 of the ear plugin and am using the version 5 no
 application.xml
   options for packing the ear.
  
   plugin
 artifactIdmaven-ear-plugin/artifactId
 version2.4.1/version
 configuration
  version5/version
  generateApplicationXmlfalse/generateApplicationXml
  earSourceDirectory./earSourceDirectory
  
  
  
 
 earSourceExcludespom.xml,pom.properties,.settings\,lib\,target\,.project/earSourceExcludes
  
  
  
 
 finalName${project.artifactId}-${project.version}.${BUILD_NUMBER}/finalName
  modules
  :
  /modules
  archive
   addMavenDescriptorfalse/addMavenDescriptor
   manifestEntries
  
   Implementation-Version${PRJVERSION}/Implementation-Version
   /manifestEntries
   /archive
   /configuration
   /plugin
  
   On one of my projects that use these option, I have several, I am
  finding
   that I need to delete the plugin in the maven repository so that I
  get a
   fresh download of the plugin to get it to package the ear and not
   complain
   about not having an application xml file.  Any time I already have
  the
   plugin in the repository and build the project it fails with the
   application.xml does not exist error. If I go and then delete the
   plugin
   again and built the project it builds fine.
  
   This does not happen with other project that I have using the same
   options?
  
   Any idea why this would happen?
  
   Thanks.
  
   --
   View this message in context:
  
 
 http://old.nabble.com/Ear-Plugin-Version-5-issue-tp28560014p28560014.html
   Sent from the Maven - Users mailing list archive at Nabble.com.
  
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
  
  
 
  --
  View this message in context:
 
 http://old.nabble.com/Ear-Plugin-Version-5-issue-tp28560014p28561249.html
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 
 

 --
 View this message in context:
 http://old.nabble.com/Ear-Plugin-Version-5-issue-tp28560014p28596361.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: Ear Plugin Version 5 issue

[Stephane Nicoll]

uh? Why on Earth would you do this:

earSourceDirectory./earSourceDirectory

Can you post the full stacktrace. Are you running from the reactor when it
happens?

S.


On Fri, May 14, 2010 at 4:21 PM, Wale12 chris.w...@ontario.ca wrote:


 I have a weird issue with a project I have.  I am using maven 2 and version
 2.4.1 of the ear plugin and am using the version 5 no application.xml
 options for packing the ear.

 plugin
   artifactIdmaven-ear-plugin/artifactId
   version2.4.1/version
   configuration
version5/version
generateApplicationXmlfalse/generateApplicationXml
earSourceDirectory./earSourceDirectory


 earSourceExcludespom.xml,pom.properties,.settings\,lib\,target\,.project/earSourceExcludes


 finalName${project.artifactId}-${project.version}.${BUILD_NUMBER}/finalName
modules
:
/modules
archive
 addMavenDescriptorfalse/addMavenDescriptor
 manifestEntries

 Implementation-Version${PRJVERSION}/Implementation-Version
 /manifestEntries
 /archive
 /configuration
 /plugin

 On one of my projects that use these option, I have several, I am finding
 that I need to delete the plugin in the maven repository so that I get a
 fresh download of the plugin to get it to package the ear and not complain
 about not having an application xml file.  Any time I already have the
 plugin in the repository and build the project it fails with the
 application.xml does not exist error. If I go and then delete the plugin
 again and built the project it builds fine.

 This does not happen with other project that I have using the same options?

 Any idea why this would happen?

 Thanks.

 --
 View this message in context:
 http://old.nabble.com/Ear-Plugin-Version-5-issue-tp28560014p28560014.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: Ear Plugin Version 5 issue

[Stephane Nicoll]

And it probably doesn't. I am not sure I get your it works if I delete the
plugin thing. Can you replace the . by ${basedir} to avoid any
reactor-related issue?

Thx,
S.

On Fri, May 14, 2010 at 6:01 PM, Wale12 chris.w...@ontario.ca wrote:


 Fair point.

 I am using hudson so this is all I get.

 Deployment descriptor:

 D:\Hudson\jobs\HCV_1.0_Dev\workspace\hud_HCV_1.0_view1\UcmVob08A\Src_Java\HCVWebService\HCVServiceEAR\target\HCVServiceEAR\META-INF\application.xml
 does not exist.


 C.


 snicoll wrote:
 
 uh? Why on Earth would you do this:
 
 earSourceDirectory./earSourceDirectory
 
 Can you post the full stacktrace. Are you running from the reactor when
 it
 happens?
 
 S.
 
 
 On Fri, May 14, 2010 at 4:21 PM, Wale12 chris.w...@ontario.ca wrote:
 
 
  I have a weird issue with a project I have.  I am using maven 2 and
  version
  2.4.1 of the ear plugin and am using the version 5 no application.xml
  options for packing the ear.
 
  plugin
artifactIdmaven-ear-plugin/artifactId
version2.4.1/version
configuration
 version5/version
 generateApplicationXmlfalse/generateApplicationXml
 earSourceDirectory./earSourceDirectory
 
 
 
 earSourceExcludespom.xml,pom.properties,.settings\,lib\,target\,.project/earSourceExcludes
 
 
 
 finalName${project.artifactId}-${project.version}.${BUILD_NUMBER}/finalName
 modules
 :
 /modules
 archive
  addMavenDescriptorfalse/addMavenDescriptor
  manifestEntries
 
  Implementation-Version${PRJVERSION}/Implementation-Version
  /manifestEntries
  /archive
  /configuration
  /plugin
 
  On one of my projects that use these option, I have several, I am
 finding
  that I need to delete the plugin in the maven repository so that I get a
  fresh download of the plugin to get it to package the ear and not
  complain
  about not having an application xml file.  Any time I already have the
  plugin in the repository and build the project it fails with the
  application.xml does not exist error. If I go and then delete the
  plugin
  again and built the project it builds fine.
 
  This does not happen with other project that I have using the same
  options?
 
  Any idea why this would happen?
 
  Thanks.
 
  --
  View this message in context:
 
 http://old.nabble.com/Ear-Plugin-Version-5-issue-tp28560014p28560014.html
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 

 --
 View this message in context:
 http://old.nabble.com/Ear-Plugin-Version-5-issue-tp28560014p28561249.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: finalName in Ear plugin

[Stephane Nicoll]

Like any other plugin. It refers to the name of the file created when the
built project is packaged. In this case, the name of the ear file in the
target directory.


---
[image: Linkedin] http://www.linkedin.com/in/snicoll[image:
Twitter]http://twitter.com/snicoll


On Thu, Apr 15, 2010 at 3:13 PM, Timothy Mcginnis
tmcgi...@aessuccess.orgwrote:

 What is the purpose of the finalName tag in the Ear plugin?

 Tim McGinnis
 717 720-1962
 Web Development
 AES/PHEAA

 ==
 This message contains privileged and confidential information intended for
 the above addressees only.  If you
 receive this message in error please delete or destroy this message and/or
 attachments.

 The sender of this message will fully cooperate in the civil and criminal
 prosecution of any individual engaging
 in the unauthorized use of this message.

 ==

Re: Re : Embedded error: Unknown artifact type[xml.zip]

[Stephane Nicoll]

Indeed. map it to zip and not jar

S.

---
[image: Linkedin] http://www.linkedin.com/in/snicoll[image:
Twitter]http://twitter.com/snicoll


On Wed, Feb 17, 2010 at 3:12 PM, Julien HENRY henr...@yahoo.fr wrote:

 Hi Stephane,

 I've mapped xml.zip custom type using this syntax:
 artifactTypeMappings
 artifactTypeMapping type=xml.zip mapping=jar/
 /artifactTypeMappings

 The build is now able to terminate, but in my EAR file I can see all
 xml.zip files are packaged inside. So for me this is not a correct
 workaround.

 Regards,

 Julien



 - Message d'origine 
  De : Stephane Nicoll stephane.nic...@gmail.com
  À : Maven Users List users@maven.apache.org
  Envoyé le : Mar 16 Février 2010, 23 h 08 min 40 s
  Objet : Re: Embedded error: Unknown artifact type[xml.zip]
 
  You can also map xml.zip in the plugin configuration if you want, which
 will
  avoid that useless message
  http://maven.apache.org/plugins/maven-ear-plugin/faq.html#har-files
 
  S.
 
  On Tue, Feb 16, 2010 at 5:02 PM, Julien HENRY wrote:
 
   Hi,
  
   One project I'm dealing with is bitten by an issue when assembling EAR
   artifact in a multi-module build. It seems the EAR plugin try to
 process a
   dependency that it should not see when building from parent project.
 The
   build is ok when building ear module alone.
  
   [INFO] Failed to initialize ear modules
   Embedded error: Unknown artifact type[xml.zip]
  
   I've created a short test case to reproduce the issue. The build fail
 when
   using Maven 2.2.1 but is successful when using Maven 3.0-alpha-6.
   Unfortunately the project will not be able to switch until Maven 3 is
   advertised as stable.
  
   2 questions:
  
- where do you think should I open the JIRA issue? In EAR plugin or
 Maven
   core?
- do you think there is half a chance the bug may be fixed in 2.2.x
   branch?
  
   Regards,
  
   Julien
  
  
  
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
 
  --
  Large Systems Suck: This rule is 100% transitive. If you build one, you
  suck -- S.Yegge





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

[ANN] Maven EAR Plugin 2.4.1 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven EAR
Plugin, version 2.4.1

This version fixes namely a regression in the application.xml
compliance introduced in 2.4.

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

You should specify the version in your project's plugin configuration:

plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-ear-plugin/artifactId
 version2.4.1/version
/plugin

Release Notes - Maven 2.x Ear Plugin - Version 2.4.1

** Bug
* [MEAR-85] - ejb-client dependencies should be placed in
defaultLibBundleDir
* [MEAR-117] - Ear resource filtering fails if target destination
doesn't exist
* [MEAR-118] - Invalid application.xml generated
* [MEAR-121] - Cannot disable displayName appearance in application.xml
* [MEAR-122] - Setting of contextRoot in pom.xml is ignored.
ArtifactId of a WebModule is set as context-root in the
application.xml instead.


Enjoy,

-The Maven team

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

Re: Embedded error: Unknown artifact type[xml.zip]

[Stephane Nicoll]

You can also map xml.zip in the plugin configuration if you want, which will
avoid that useless message
http://maven.apache.org/plugins/maven-ear-plugin/faq.html#har-files

S.

On Tue, Feb 16, 2010 at 5:02 PM, Julien HENRY henr...@yahoo.fr wrote:

 Hi,

 One project I'm dealing with is bitten by an issue when assembling EAR
 artifact in a multi-module build. It seems the EAR plugin try to process a
 dependency that it should not see when building from parent project. The
 build is ok when building ear module alone.

 [INFO] Failed to initialize ear modules
 Embedded error: Unknown artifact type[xml.zip]

 I've created a short test case to reproduce the issue. The build fail when
 using Maven 2.2.1 but is successful when using Maven 3.0-alpha-6.
 Unfortunately the project will not be able to switch until Maven 3 is
 advertised as stable.

 2 questions:

  - where do you think should I open the JIRA issue? In EAR plugin or Maven
 core?
  - do you think there is half a chance the bug may be fixed in 2.2.x
 branch?

 Regards,

 Julien





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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Release schedule for ear plugin version 2.4.1

[Stephane Nicoll]

The release vote for 2.4.1 has just been sent on the dev list.

S.

On Tue, Jan 19, 2010 at 8:47 AM, Markku Saarela markku.saar...@iki.fiwrote:

 Hi,

 What is plan for releasing version 2.4.1 of ear plugin? All issues for this
 release are resolved.

 rgds,

 Markku


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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Release schedule for ear plugin version 2.4.1

[Stephane Nicoll]

On Tue, Jan 19, 2010 at 4:58 PM, Wayne Fay wayne...@gmail.com wrote:

  What is plan for releasing version 2.4.1 of ear plugin? All issues for
 this
  release are resolved.

 Version 2.4 was just released in late Oct 2009. Are you having
 specific problems related to a Jira issue that has been resolved, or
 is this just a general inquiry?


There was a regression in 2.4 that was fixed. I believe it should be fixed
ASAP. I was just waiting for feedbacks from voters but since I got nothing,
I'll go on with the release. I'll try to do it over the week-end.

Regards,
Stéphane



 Wayne

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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Unused dependencies in ear

[Stephane Nicoll]

This plugin is meant to be ran on a project that actually uses the code from
a compilation standpoint.

Please note also that your modules section in the ear plugin is useless. The
plugin will auto-detect what's necessary from your pom, you only need to set
values there if you actually want to customize something.

HTH,
S.

On Wed, Feb 3, 2010 at 1:31 PM, Ignatyev Vjacheslav ignat...@lanit.ruwrote:

 Hi, all.

 Problem with maven-ear-plugin. Why dependency:analyze say Unused
 declared dependencies found?

 ---
 Command output:
 [...@ivv]~/projects/lodint% mvn dependency:analyze
 [...]
 [INFO] Building Packaging project
 [...]
 [INFO] [dependency:analyze {execution: default-cli}]
 [WARNING] Unused declared dependencies found:
 [WARNING]org.drools:drools-core:jar:5.0.1:compile
 [WARNING]org.jboss.seam:jboss-seam:ejb:2.2.0.GA:compile
 [WARNING]
  ru.lanit.samara.core-process:lodint-ejbs:ejb:1.0-SNAPSHOT:compile
 [WARNING]ru.lanit.samara.core-process:egr:ejb:1.0-SNAPSHOT:compile
 [WARNING]ru.lanit.samara.core-process:kladr:ejb:1.0-SNAPSHOT:compile
 [WARNING]
  ru.lanit.samara.core-process:lodint-web:war:1.0-SNAPSHOT:compile
 [WARNING]org.richfaces.framework:richfaces-api:jar:3.3.1.GA:compile
 [...]
 ---
 Packaging project's pom:
 [...]
 parent
 groupIdru.lanit.samara.core-process/groupId
 artifactIdparent/artifactId
 version1.0-SNAPSHOT/version
 /parent
 artifactIdlodint/artifactId
 namePackaging project/name
 packagingear/packaging

 [...]
 plugins
 artifactIdmaven-ear-plugin/artifactId
 [...]
 modules
 ejbModule
 groupId${project.groupId}/groupId
 artifactIdlodint-ejbs/artifactId
 /ejbModule
 ejbModule
 groupId${project.groupId}/groupId
 artifactIdkladr/artifactId
 /ejbModule
 ejbModule
 groupId${project.groupId}/groupId
 artifactIdegr/artifactId
 /ejbModule
 webModule
 groupId${project.groupId}/groupId
 artifactIdlodint-web/artifactId
 contextRoot//contextRoot
 /webModule
 /modules
 [...]
 dependencies
 dependency
 groupId${project.groupId}/groupId
 artifactIdlodint-ejbs/artifactId
 typeejb/type
 /dependency

 dependency
 groupId${project.groupId}/groupId
 artifactIdkladr/artifactId
 typeejb/type
 /dependency
 [...]


 Full pom.xml:
 http://samara.lanit.ru/anon-repos/lodint/trunk/packaging/pom.xml
 Thanks.


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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: maven-ear-plugin: MEAR-85 patch

[Stephane Nicoll]

Yup. Done and applied.

Thanks,
Stéphane

On Tue, Jan 12, 2010 at 12:09 PM, Aleksey Shipilev 
aleksey.shipi...@gmail.com wrote:

 All right, the tests and patch is right there in JIRA [1]. Can anybody
 take a look?

 Thanks,
 Aleksey.

 [1] http://jira.codehaus.org/browse/MEAR-85

 On Mon, Jan 11, 2010 at 7:37 PM, Aleksey Shipilev
 aleksey.shipi...@gmail.com wrote:
  Hi Wayne,
 
  On Mon, Jan 11, 2010 at 7:26 PM, Wayne Fay wayne...@gmail.com wrote:
  Why not? There is no good reason why you couldn't produce your own
  internally-versioned m-e-p
 
  This could spin off to theological discussion :) IMO, having
  custom-patched components is much worse than pushing the patch
  upstream, especially when the patch is trivial and problem manifests
  in large number of cases (10 votes just for that issue). Even though I
  could make my own patched version, it just feels right to get this in
  upstream.
 
  The patch alone is not sufficient. To make it appear faster, you
  also need to provide tests that demonstrate the functionality works as
  intended etc.
 
  Ok, taking off the tests, is there something else? I'd like to hear
  from EAR plugin committers (Stephane?) on this.
 
  Finally, the ear plugin did not appear to get many votes the last time
  a survey was performed, so I'm unsure when that will be released next.
 
  I would be happy with SNAPSHOT version of the plugin, not the named
  release. Doesn't snapshot version contain the latest code from the SVN
  trunk?
 
  Thanks,
  Aleksey.
 
 
 

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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: ear-plugin and profiles: poor cooperation?

[Stephane Nicoll]

A configuration item that is a list can't be merged in a profile. See the
modules element as a configuration item, like the JavaEE version you want
to use. If you override the value in the profile, you can't expect it to
merge the elements that are set in the main build (this is a global behavior
of Maven btw).

Why don't you add a dependency section in your profile instead? Why
quartz.jar should be added to the application context? Maybe you need to use
http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html#includeLibInApplicationXmlinstead.

Regards,
Stéphane

On Tue, Dec 22, 2009 at 4:12 PM, Rebholz Paul paul.rebh...@six-group.comwrote:

  Hi all!
 
  We have a project producing an ear artifact. The contents of the ear
  file are configured with the maven-ear-plugin. In profiles we want to
  be able to flexibly add more artifacts to the ear file as shown in the
  example below. Our tests so far revealed a different behaviour than
  expected. When adding a jar file with the jarModule element, all other
  entries corresponding to jarModules disappear in the application.xml
  and even some other jar files disappear completely from the ear.
  Moreover, when adding a second profile adding jars, the first is
  eclipsed. Is this a bug in the maven-ear-plugin implementation?
 
  Regards, Paul
 
 
  profile
idmy_test/id
activation
  property
namemy_switch/name
valuetrue/value
  /property
/activation
build
  plugins
plugin
  artifactIdmaven-ear-plugin/artifactId
  configuration
modules
  jarModule
groupIdquartz/groupId
artifactIdquartz/artifactId
 
  includeInApplicationXmltrue/includeInApplicationXml
  /jarModule
/modules
  /configuration
/plugin
  /plugins
/build
dependencies
  dependency
groupIdquartz/groupId
artifactIdquartz/artifactId
typejar/type
version1.5.2/version
  /dependency
/dependencies
  /profile

 This message is for the named person's use only. It may contain
 confidential, proprietary or legally privileged information. If you receive
 this message in error, please notify the sender urgently and then
 immediately delete the message and any copies of it from your system. Please
 also immediately destroy any hardcopies of the message.
 The sender's company reserves the right to monitor all e-mail
 communications through their networks.

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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Semi-automated application.xml generation

[Stephane Nicoll]

no it's no possible for the moment. You may want to add an improvement in
Jira with what you think to be an ideal solution.

Thanks,
Stéphane

2009/10/29 Thomas Göttlich guo.tu...@googlemail.com

 Hi,

 Is there a possibility to semi-automate application.xml generation?

 What I specifically want to do is this:

 Currently I use the maven ear plugin to create the application.xml.
 However, I need to register a module that should not be processed
 otherwise.
 This means, the only thing that should happen is that the application.xml
 contains a module description for that module.
 No files should be copied around and the module should not be contained in
 the ear (don't ask why).

 On the other hand, I don't want to create the complete application.xml
 manually.

 So I see two options:

 1. let the maven ear plugin generate the application.xml but add the module
 definition in another way (maybe using filtering)
 2. create a skeleton application.xml and add the other modules during the
 process-resources phase (filtering?)

 Is this possible? Or is there another way?

 Thanks in advance.

 Thomas




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

[ANN] Maven EAR Plugin 2.4 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven EAR
Plugin, version 2.4

This new release brings compatibility for Java EE 6 and a few bug fixes.

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

You should specify the version in your project's plugin configuration:

plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-ear-plugin/artifactId
 version2.4/version
/plugin

Release Notes - Maven 2.x EAR Plugin - Version 2.4

** Bug
* [MEAR-75] - Incorrect file name in class path (in manifest) if
specifying different bundleFileName for module
* [MEAR-103] - Filtered MANIFEST not added to generated EAR
* [MEAR-104] - wrong jboss-app.xml
* [MEAR-105] - Unable to set some properties for jboss-app.xml


** New Feature
* [MEAR-112] - support for java ee 6 missing

Enjoy,

-The Maven team

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

Re: Exploded WAR in exploded EAR

[Stephane Nicoll]

You can also activate that on a module per module basis[1]

Cheers,
Stéphane

[1]
http://maven.apache.org/plugins/maven-ear-plugin/examples/unpacking-a-module.html

On Wed, Jul 15, 2009 at 6:19 PM, george_bancos george_ban...@yahoo.comwrote:


 I could achieve this by configuring the ear plugin like this:

build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
   unpackTypeswar/unpackTypes


 workDirectoryE:\Programs\JBoss510\server\default\deploy\ejb3Test2.ear/workDirectory
 /configuration
/plugin
/plugins
/build


 brianwainwright wrote:
 
  Hi,
 
  I am currently trying to move my teams large
  multi-project/multi-webapp/multi-ear application from Maven 1.x to Maven
  2, and overcome most of the problems I've had on the way, but there's one
  issue I can't work out.
 
  Our current (Maven 1.x) build, we have a customized goal which produces
 an
  exploded ear which in turn contains an exploded war - (our current
  practise is for developers to deploy fully exploded ears/wars on their
 own
  JBoss servers while developing.).  We do this by unwaring any bundled
  war dependencies in the exploded ear.
 
  Is there any (simple) way to produce the same kind of fully exploded ear
  in M2?
 
  I've looked at war:exploded, which will build the exploded war, but then
  the ear plugin will look for the .war artifact in the repository when
  trying to bundle it's dependencies, so the exploded war wouldn't be used
  when packaging the ear?
 
  I've also looked at the maven-explosion plugin, which could possibly work
  for us, but it seems inefficient to war/ear the original artifacts and
  then unpack them to explode them when their exploded directories already
  exist.
 
  Thanks for your help,
 
  Brian Wainwright
  Developer
  Burns E-Commerce
  Mansion House, Manchester Road, Altrincham, Cheshire, WA14 4RJ, UK
  http://www.burnsecs.com
  mailto:brian.wainwri...@burnsecs.com
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Exploded-WAR-in-exploded-EAR-tp3968873p24501387.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: how can I filter the resources of one of the dependencies before building an EAR?

[Stephane Nicoll]

It would much more powerful to perform that transformation when you actually
deploy the artifacts on the server instead of burning the value in something
you could potentially deploy on the repository

I would leave the token in the file and add a filtering procedure when the
app is built and deployed. You lost the ability to copy an ear right the way
but you could have that with a separate project that relies on your ear and
perform the transformation for you.

S.

On Tue, Jun 23, 2009 at 9:10 AM, Sergio Rodriguez srodrig...@teralco.comwrote:


 Hello,

 I have an EJB project that is a dependency of several of my projects. I
 need
 to modify the JNDI name at the EJB's jboss.xml so I can deploy several apps
 on the same jboss server.

 How can I filter the resources of an already-compiled dependency? I have
 tried to unpack-dependencies and filter them, but don't know how to pack
 them again into a new EJB for my EAR.

 Any suggestions?
 --
 View this message in context:
 http://www.nabble.com/how-can-I-filter-the-resources-of-one-of-the-dependencies-before-building-an-EAR--tp24160990p24160990.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: how can I filter the resources of one of the dependencies before building an EAR?

[Stephane Nicoll]

On Wed, Jun 24, 2009 at 9:31 AM, Sergio Rodriguez srodrig...@teralco.comwrote:


 Thanks for your answers. Is it possible to filter the contents of an EAR? I
 thought you could only do that by previously unpacking the resources in a
 tmp directory.


Then you misunderstood my proposal. My proposal is to keep your ear project
like it is (no token filtering) and then reuse the EAR to do the filtering
according to your environment. You could do this through Maven or with a
simple ant script that you ship with your distribution.

What's missing is a plugin that performs the filtering on an existing file
(no copy just overwrite) and that takes arbitrary resource set. I have
actually implemented a custom plugin that does that but maybe it exists
somewhere now.

S.




 snicoll wrote:
 
  It would much more powerful to perform that transformation when you
  actually
  deploy the artifacts on the server instead of burning the value in
  something
  you could potentially deploy on the repository
 
  I would leave the token in the file and add a filtering procedure when
 the
  app is built and deployed. You lost the ability to copy an ear right the
  way
  but you could have that with a separate project that relies on your ear
  and
  perform the transformation for you.
 
  S.
 
  On Tue, Jun 23, 2009 at 9:10 AM, Sergio Rodriguez
  srodrig...@teralco.comwrote:
 
 
  Hello,
 
  I have an EJB project that is a dependency of several of my projects. I
  need
  to modify the JNDI name at the EJB's jboss.xml so I can deploy several
  apps
  on the same jboss server.
 
  How can I filter the resources of an already-compiled dependency? I have
  tried to unpack-dependencies and filter them, but don't know how to pack
  them again into a new EJB for my EAR.
 
  Any suggestions?
  --
  View this message in context:
 
 http://www.nabble.com/how-can-I-filter-the-resources-of-one-of-the-dependencies-before-building-an-EAR--tp24160990p24160990.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
 
 
 
 
  --
  Large Systems Suck: This rule is 100% transitive. If you build one, you
  suck -- S.Yegge
 
 

 --
 View this message in context:
 http://www.nabble.com/how-can-I-filter-the-resources-of-one-of-the-dependencies-before-building-an-EAR--tp24160990p24180002.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: mvn install for ear project

[Stephane Nicoll]

On Fri, May 22, 2009 at 4:41 PM, fachhoch fachh...@gmail.com wrote:


 my mvn version

 Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
 Java version: 1.6.0_11
 Java home: C:\Program Files\Java\jdk1.6.0_11\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows

 this is the same version  and still I am getting this error .
 sairam


The war PLUGIN version has been fixed. It has nothing to do with Maven. Lock
down the war plugin to 2.1-beta-1.

S.





 snicoll wrote:
 
  It's a bug of the war plugin that has been fixed a while back. Please use
  the latest version.
 
  S.
 
  On Tue, May 19, 2009 at 8:55 PM, tubin gen fachh...@gmail.com wrote:
 
  my project   has subprojects one for ear , one for war  and one for jar
 .
 
 
  I get this error   when I run mvn install
 
 
  java.lang.NullPointerException
 at
 
 
 org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109)
 at
 
 
 org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288)
 at
 
 
 org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46)
 at
 
 
 org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439)
 at
 
 
 org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375)
 at
  org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181)
 at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)
 at
 
 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at
 
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
  org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at
  org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 
 
  please help me, what is causing  this error ?
 
 
 
 
  --
  Large Systems Suck: This rule is 100% transitive. If you build one, you
  suck -- S.Yegge
 
 

 --
 View this message in context:
 http://www.nabble.com/mvn-install-for-ear-project-tp23622756p23671801.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: mvn install for ear project

[Stephane Nicoll]

It's a bug of the war plugin that has been fixed a while back. Please use
the latest version.

S.

On Tue, May 19, 2009 at 8:55 PM, tubin gen fachh...@gmail.com wrote:

 my project   has subprojects one for ear , one for war  and one for jar .


 I get this error   when I run mvn install


 java.lang.NullPointerException
at

 org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109)
at

 org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288)
at

 org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46)
at

 org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439)
at

 org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375)
at
 org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)
at

 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)


 please help me, what is causing  this error ?




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: maven-ear-plugin or maven-ejb-plugin and persistence.xml

[Stephane Nicoll]

Jean-Claude,

On Tue, Apr 21, 2009 at 7:03 PM, Jean-Claude jean-claude.rouvi...@ipi.chwrote:


 Is it a way to automatically generate the list of the jar files to avoid
 having to manually edit the file persistence.xml each time there is a new
 version of the jar files (e.g. using the maven-ejb-plugin)?


There's two ways you can do this. The first is to store the version in a
property in your pom and use it in your dependency and in the
persistence.xml and filter it when the EJB is built. Something like

properties
  foo.version1.0.0-SNAPSHOT/foo.version
/properties

.

depepdencies
   dependency
 groupIdcom.foo/groupId
 artifactIdactivity-bo/artifactId
 version${foo.version}/version
 typeejb/type
  /dependency
/dependencies


(Then put the ${foo.version} in your persistence.xml instead of the version
and configure the build to filter it)

The other way is to ask the ear plugin to change the name of the file when
it's packaged. See the documentation for more details
http://maven.apache.org/plugins/maven-ear-plugin/examples/customizing-a-module-filename.html

HTH,
Stéphane



-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Ear plugin EJB module

[Stephane Nicoll]

The ear plugin just uses the standard maven API. It relies on the Artifact
interface that should return the location of the file (target of the module,
local repository, etc).

I don't see much trouble here but if you can confirm this scenario with EJB
modules only, just file an issue with a projet that reproduce the problem.

HTH,
Stéphane

On Wed, Apr 8, 2009 at 12:33 PM, CemKoc
cem.koc.fwd+nbl...@gmail.comcem.koc.fwd%2bnbl...@gmail.com
 wrote:


 I have checked source of ear plugin in limited time, I noticed in EarMojo
 class:

 public void execute()


 final File sourceFile = module.getArtifact().getFile();
 final File destinationFile = buildDestinationFile( getWorkDirectory(),
 module.getUri() );
 ...
 ...
 ...
 unpack( sourceFile, destinationFile );

 -

 What is getFile() method returning? It seems that our configuration is a
 little bid buggy.

 Thanks
 --
 View this message in context:
 http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604407.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Ear plugin EJB module

[Stephane Nicoll]

On Wed, Apr 8, 2009 at 1:28 PM, CemKoc
cem.koc.fwd+nbl...@gmail.comcem.koc.fwd%2bnbl...@gmail.com
 wrote:


 Hi Stephane,

 I have some questions for you.

 1 - Why are the default locations of war and ejb projects.


It depends. Maven is supposed to provide that based of your environment. If
you're running a reactor project, it will fetch the build from the target
directory of the module. If you're relying on an external dependency, it
will first resolve it and provide a link to your local repository.



 2 - In this scenario, without installing to a local repository and ejb
 project we can not produce an ear file. Is it normal?


No it's not. But I vaguely remember that there were some limitations with
some module types. If you can reproduce with the latest 2.0.x Maven release,
file a bug please.

Thanks,
Stéphane


  --
 View this message in context:
 http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604674.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: maven-ear-plugin: jarModule or ejbModule

[Stephane Nicoll]

You need to provide good metadata for your projects. Maven defaulting
principles work quite fine if you respect that.

If you project builds an ejb, the packaging type must be ejb. If you don't,
Maven can't understand in other modules (that depend on it) what to do with
the dependency. Typically, the ear plugin takes care of ejbs and will
generate the deployment descriptor automatically if you need one.

2 is the solution and 1 seems more like a hack to me.

HTH,
S.

On Fri, Apr 3, 2009 at 5:49 PM, Jean-Claude jean-claude.rouvi...@ipi.chwrote:


 Hi,

 I want to build an EAR file with modules. All EJB modules have been defined
 as jar (packagingjar/packaging).
 What is the best way:

 1).
 Include those EJB modules in the EAR file using jarModule

 or

 2).
 Change the packaging of all EJB modules to ejb (packagingejb/packaging)
 and then include those EJB modules in the EAR file using ejbModule

 What are the advantages or disadvantages of each solution?

 Thank you for your Help!
 --
 View this message in context:
 http://www.nabble.com/maven-ear-plugin%3A-jarModule-or-ejbModule-tp22871170p22871170.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Any java ee 5 directory structure available?

[Stephane Nicoll]

You could start with this
http://maven.apache.org/plugins/maven-archetype-plugin/examples/j2ee-simple.html

Note that you don't have to explicitly call mvn ear:ear to package an ear
file. The ear project will have an 'ear' packaging type which means that
Maven will call the right things with the standard goal (i.e. mvn package in
that ear project will actually package the ear file)

S.

On Sun, Mar 15, 2009 at 10:04 AM, Thai Dang Vu dx...@yahoo.com wrote:

 Is there any java ee 5 directory structure with maven2 support available on
 the Internet? I'm looking to something like this:

 project-name
|-- ear
||-- pom.xml
|-- ejb
||-- src
||-- pom.xml
|-- war
||-- src
||-- pom.xml
|-- pom.xml

 with which I can go to the ear directory and type mvn ear:ear and have an
 ear file.
 I'm quite new to maven, so it'll take me a while to make one of my own.








-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Multiple module maven project questions

[Stephane Nicoll]

See responses inline.

On Sun, Mar 15, 2009 at 12:24 PM, Thai Dang Vu dx...@yahoo.com wrote:

 This is the directory structure of my project


[...]



 I have some questions here:

 1. How to tell the maven-ear-plugin to use my application.xml? And where in
 the ear directory should I place my own application.xml?


The default directory for ear sources is src/main/application. If you put
your application.xml file in src/main/application/META-INF/application.xml,
Maven will pick it up automatically. Most users let maven generates it for
you. The ear plugin does that by default.





 2. Because of the dependency on the ejb, I have to run mvn install in the
 ejb directory before I can run mvn compiler:compile in the war directory. Is
 there any way (like target dependencies in ant) to tell maven to compile /
 install all modules needed before the mvn compiler:compile is executed?


Well, you invoke mvn package at the root level and it will do that for you.




 3. In my application.xml, beside the ejb and war modules, I need to add one
 more module like this:

 moduleejbjboss-seam-2.1.1.GA.jar/ejb/module

 The jboss seam jar file can be found with a dependency. What should I do
 to tell maven to include that file into the root of the ear file it creates
 when I run mvn ear:ear in the ear directory?


Make it a dependency :) If you need something, it needs to be a dependency.
You miss the typeejb/type in the jboss-seam dep.




 4. If I don't want to create the seam-glassfish-ear-1.0-SNAPSHOT.ear file,
 but a seam-glassfish-ear-1.0-SNAPSHOT_ear directory in which the ejb module
 is unpacked in the seam-glassfish-ejb-1.0-SNAPSHOT_jar directory, the war
 module is unpacked in the seam-glassfish-war-1.0-SNAPSHOT_war directory and
 the jboss seam library above is unpacked in the jboss-seam-2.1.1.GA_jar
 directory, what should I do?


Read the doc a bit more. To explode the modules, there's an option for that
http://maven.apache.org/plugins/maven-ear-plugin/examples/unpacking-a-module.html

For the EAR itself there's a feature request (
http://jira.codehaus.org/browse/MEAR-51) but you can have a direct solution
with the dependency plugin (unpack goal)




 I read the http://maven.apache.org/plugins/maven-ear-plugin/ but found no
 shine to my questions (maybe there are, but not apparent to a maven newbie
 like me).


Question 1,2,3 are not maven ear plugin's question but Maven questions. You
better have to read more tutorial on Maven itself first

HTH,

S.



 Thank you.








-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

[ANN] Maven EAR Plugin 2.3.2 Released

[Stephane Nicoll]

The Maven team is pleased to announce the release of the Maven EAR
Plugin, version 2.3.2

This version supports JBoss5 and filtering of the ear resources
directory, namely.

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

You should specify the version in your project's plugin configuration:

plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-ear-plugin/artifactId
 version2.3.2/version
/plugin


Release Notes - Maven 2.x Ear Plugin - Version 2.3.2

** Bug
* [MEAR-70] - loader-repository node for jboss configuration
* [MEAR-79] - generated application.xml is empty (0 bytes) if
generatedDescriptorLocation is redefined
* [MEAR-82] - From version 2.3 on, resources are not always copied
to the EAR structure
* [MEAR-94] - Synchronize module releases and documentation releases
* [MEAR-96] - earSourceExcludes does not work for jar dependency
filtering like warSourceExcludes / packagingExcludes for the
maven-war-plugin
* [MEAR-99] - Corrupted deployment descriptor if configured
encoding does not match platform encoding
* [MEAR-100] - Support altDeploymentDescriptor for J2EE 1.4
* [MEAR-101] - workDirectory contents added to target/ear file.

** Improvement
* [MEAR-78] - Library directory configuration
* [MEAR-81] - Suppressing application.xml creation (and inclusion)
completely
* [MEAR-86] - Add a property to automatically add jars
dependencies into application.xml (TEST AND PATCH ATTACHED).
* [MEAR-102] - Support for JBoss 5 as well as some missing elements

** New Feature
* [MEAR-43] - add ability to do filtering (i.e. template var
replacement) for files in src/main/application/
* [MEAR-97] - Add ability to generate jboss-app.xml for JBoss 5

** Wish
* [MEAR-52] - Ability to add jboss dataosources (*ds.xml) files as
a jarModule

Enjoy,

-The Maven team

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

Re: running obfuscator after packaging

[Stephane Nicoll]

You need to bind the obfuscation to the package phase of each of your
project and attach the result to the lifecycle with some classifier (see
also the buildhelper plugin). Once you have that, depends on obfuscated jar
in your EAR project.

HTH,
S.

On Thu, Mar 5, 2009 at 6:25 PM, Mohammad Norouzi mnr...@gmail.com wrote:

 Hello

 I am having a problem using YGuard as our obfuscator. Our project includes
 several modules and a separate module namely product will gather all the
 jar files from the modules and build an EAR file. No we need to tell our
 ant-run-plugin which is responsible for obfuscating the jar files that to
 be
 executed right after the jar files being created and before the ear file is
 built. so the porduct's pom can create an ear file containing obfuscated
 jar
 files.

 Please share your experience on this with me.

 Thanks in advance


 Regards,
 Mohammad
 --
 Sun Certified Web Developer
 ExpertsExchange Certified, Master:
 http://www.experts-exchange.com/M_1938796.html
 Have a look at some pictures @ http://pixelshot.wordpress.com/
 Do you like to read, see http://brainable.blogspot.com/
 For the Persians see http://fekre-motefavet.blogspot.com/




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Ear application.xml

[Stephane Nicoll]

Two options for you:

# Use the lib directory (lib by default) if you're using EE5
# Wait for MEAR- 86

S.

On Fri, Feb 27, 2009 at 11:49 AM, JC Walmetz jc7...@yahoo.fr wrote:


 Hi,

 I use Maven ear plugin to generate an ear. This ear is used in jboss5. My
 EAR application is huge and contains a lot of jars. Application.xml file is
 difficult to maintain.

 I have an EJB module that has a lot of transitive dependencies. I'd like to
 list all that transitive dependencies in the application.xml file as java
 module.

 Ear plugin add jars in the EAR. To add the EJB module ine the
 application.xml I have
 ejbModule
groupIdcom.foo/groupId
artifactIdejbservice/artifactId
 /ejbModule

 This configuration adds the module in the application.xml but not all its
 transitive dependencies. Is there a solution to add automatically all
 transitive dependencies in the applpication.xml ?

 Previously I was using the JBoss 4.2.3, I have move to JBoss 5. With JBoss
 4.2.3, I was adding the transitive dependencies in the classpath of the
 manifest.mf of the ejb module and I just need to declare to ejb module in
 the application.xml ... unfortunatelly it does not works anymore with
 JBoss5. In JBoss 5, it works only if I removed the claaspath in manifest.mf
 and adds all the lib in application.xml as java module.

 Does someone have the same issue ?

 Thks


 --
 View this message in context:
 http://www.nabble.com/Ear---application.xml-tp22243464p22243464.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Problem with maven-ear-plugin

[Stephane Nicoll]

For the record, I am stuck on one issue but when I am done I will probably
call for vote since the plugin will support JBoss5.

S.

On Sat, Feb 21, 2009 at 6:02 PM, David Goodenough 
david.goodeno...@btconnect.com wrote:

 Great, that fixed that problem.  It was (fortunately) a package under my
 control.

 But now I have a further problem.

 It complains:-

 [INFO] Deployment
 descriptor: ... /AdminEar-0.0.1-SNAPSHOT/META-INF/application.xml does not
 exist

 Now in pom.xml I have,

 ...
configuration
  version5/version
  generateApplicationXmlfalse/generateApplicationXml
 ...

 In EJB Version 5 application.xml is not required.  I found a hit on google
 from a while back saying that this problem existed, and making reference
 to a new version of the maven-ear-plugin (2.3.2) which fixes this, but
 the latest version in the central maven repositories is 2.3.1.  Does the
 new version exist, and if so how does it get uploaded to the central
 repository?

 David

 On Saturday 21 February 2009, Stephane Nicoll wrote:
  You have a transitive dependencies of type zip which seems pretty bad to
  me.
 
  mvn dependency:resolve will give you the list of dependencies
  mvn dependency:tree will explain where this zip dependency is coming from
 
  You can use excludes or you can fix the project you own it.
 
  HTH,
  Stéphane
 
 
  On Fri, Feb 20, 2009 at 10:08 PM, David Goodenough 
 
  david.goodeno...@btconnect.com wrote:
   I am trying to use the maven-ear-plugin, and I keep getting:-
  
   [INFO] Failed to initialize ear modules
  
   Embedded error: Unknown artifact type[zip]
  
   I have tried using -X to get the debug messages, but I can not
   see where it is finding a ZIP file to use as an artifact.  There are
   three modules I have specified (all jar files), but nothing else.
  
   How do I find out what it was trying to package that is causing it
   to try package a ZIP file.
  
   David
  
   -
   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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: How to manage your artifact versions

[Stephane Nicoll]

On Mon, Feb 9, 2009 at 5:46 PM, Avihaimar avihai...@yahoo.com wrote:


 Hey,

 My application is composite from a lot of artifacts.
 If i set my artifact version to be snapshot than each time a developer will
 build the ear on his machine maven will download a newer version from the
 remote repository and not use the developer version.


Well, sounds like you need some background info here. The purpose of
SNAPSHOT is to give you latest development version of an artifact. Ideally
(IMO), SNAPSHOTs should be deployed by a developer when (s)he considers that
it reaches some state (feature partly implemented or stable, etc). If you
have a CI system that deploys every 2 hours it defeats this principle.

However, you can configure your settings to look for snapshot only when your
copy is 1 hour, 4 hours, 1 day old, etc.

When you say that it does not use the developer version, it simply means
that the version on the repository is newer than the one from the developer.
If you decide to use SNAPSHOT, it is normal that you get the latest one.

You can have some fallback strategies though. For instance, we have two
snapshot repositories. The  first one is stable development snapshot and
contains only artifacts deployed by a team member. The second one is updated
automatically at every CI build. That way, if an artifact was never deployed
for a given version, we can just activate a profile and fetch it from the
second repository.

HTH,
Stéphane




 So, i dont understand the benefit of snapshot.

 From the other side if i have 20 artifacts , which develop by differnet
 teams there is no reason to me to compile the artifacts that i didnt touch
 them.

 Advices will be welcome
 --
 View this message in context:
 http://www.nabble.com/How-to-manage-your-artifact-versions-tp21916752p21916752.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: [MAVEN RELEASE PLUGIN] NoSuchMethodError: org.apache.maven.settings.Settings.getRuntimeInfo() for goal prepare

[Stephane Nicoll]

)
 at
 org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42)
 at
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:196)
at
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:133)
at
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:96)
at
 org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:161)
 at
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:180)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at
 org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at
 org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at
 org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at
 org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at
 org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:52)

 
 -Message d'origine-
 De : Stephane Nicoll [mailto:stephane.nic...@gmail.com]
 Envoyé : vendredi 23 janvier 2009 18:42
 À : Maven Users List
 Objet : Re: [MAVEN RELEASE PLUGIN] NoSuchMethodError:
 org.apache.maven.settings.Settings.getRuntimeInfo() for goal prepare

 it looks like mvn is not on your path. The release plugin forks a
 process and call the mvn.bat (or mvn.sh) script. Make sure that you
 can invoke mvn from any directory with the user you are using to test
 your release.

 HTH,
 Stéphane

 On Fri, Jan 23, 2009 at 3:55 PM, Lesaint Sébastien
 sebastien.lesa...@ginerativ.fr wrote:
  Hello there,
 
  I'm working for a small company and we are currently looking into Maven.
 
  I've created a few jar projects which I can build and deploy OK.
  I am now working on a parent POM for all them and looking for a formal
 release process. This is why I'm trying the release plug-in.
 
  When invoking the following command on the parent-pom project:
  mvn -DdryRyn=true -B -X -e -s C:\Documents and
 Settings\[user]\.m2\settings.xml release:clean release:prepare
 
  I am blocked by the following error:
  java.lang.NoSuchMethodError:
 org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;
 
  I have tried not using dry mode, removing any profile from my
 settings.xml file. No difference.
 
  I am using Eclipse Europa, on windows XP, with the M2Eclipse plugin
 (embedded Maven 2.1 SNAPSHOT version) and the release plugin beta 8.
 
  I enclosed below the log file, the POM and settings.xml files I use (a
 little cleaned up of sensitive data though).
 
  (as debug is quite verbose, I cut most of the log file but keep the full
 one available on demand)
 
  Any help will be greatly appreciated.
 
  Sébastien Lesaint
 
 
 
 
 ===
  + Error stacktraces are turned on.
  Maven version: 2.1-SNAPSHOT
  Java version: 1.5.0_06
  Default locale: fr_FR, platform encoding: Cp1252
  OS name: windows xp version: 5.1 arch: x86 family: windows
  [DEBUG] Activated the following profiles for standalone super-pom:
 [Profile {id: cvs credentials, source: settings.xml}, Profile {id:
 development, source: settings.xml}]
  [DEBUG] Pre-scanning POM lineage of:
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\pom.xml for build extensions.
  [DEBUG] Building model-lineage for:
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\pom.xml to pre-scan for extensions.
  [DEBUG] Checking for external profiles in:
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
  [DEBUG] Checking: com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT for
 extensions. (It has 0 modules.)
  [DEBUG] Checking com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT for
 extensions.
  [DEBUG] Basedir is: F:\bar.DOO\Eclipse\Java\foo-parent-pom
  [DEBUG] Checking for external profiles in:
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
  [DEBUG] Checking for external profiles in:
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
  [DEBUG] Checking for external profiles in:
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
  [DEBUG] Aligning project: com.foo:foo-parent-pom:pom

Re: [MAVEN RELEASE PLUGIN] NoSuchMethodError: org.apache.maven.settings.Settings.getRuntimeInfo() for goal prepare

[Stephane Nicoll]

it looks like mvn is not on your path. The release plugin forks a
process and call the mvn.bat (or mvn.sh) script. Make sure that you
can invoke mvn from any directory with the user you are using to test
your release.

HTH,
Stéphane

On Fri, Jan 23, 2009 at 3:55 PM, Lesaint Sébastien
sebastien.lesa...@ginerativ.fr wrote:
 Hello there,

 I'm working for a small company and we are currently looking into Maven.

 I've created a few jar projects which I can build and deploy OK.
 I am now working on a parent POM for all them and looking for a formal 
 release process. This is why I'm trying the release plug-in.

 When invoking the following command on the parent-pom project:
 mvn -DdryRyn=true -B -X -e -s C:\Documents and 
 Settings\[user]\.m2\settings.xml release:clean release:prepare

 I am blocked by the following error:
 java.lang.NoSuchMethodError: 
 org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;

 I have tried not using dry mode, removing any profile from my settings.xml 
 file. No difference.

 I am using Eclipse Europa, on windows XP, with the M2Eclipse plugin (embedded 
 Maven 2.1 SNAPSHOT version) and the release plugin beta 8.

 I enclosed below the log file, the POM and settings.xml files I use (a little 
 cleaned up of sensitive data though).

 (as debug is quite verbose, I cut most of the log file but keep the full one 
 available on demand)

 Any help will be greatly appreciated.

 Sébastien Lesaint



 ===
 + Error stacktraces are turned on.
 Maven version: 2.1-SNAPSHOT
 Java version: 1.5.0_06
 Default locale: fr_FR, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 family: windows
 [DEBUG] Activated the following profiles for standalone super-pom: [Profile 
 {id: cvs credentials, source: settings.xml}, Profile {id: development, 
 source: settings.xml}]
 [DEBUG] Pre-scanning POM lineage of: 
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\pom.xml for build extensions.
 [DEBUG] Building model-lineage for: 
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\pom.xml to pre-scan for extensions.
 [DEBUG] Checking for external profiles in: 
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
 [DEBUG] Checking: com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT for extensions. 
 (It has 0 modules.)
 [DEBUG] Checking com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT for extensions.
 [DEBUG] Basedir is: F:\bar.DOO\Eclipse\Java\foo-parent-pom
 [DEBUG] Checking for external profiles in: 
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
 [DEBUG] Checking for external profiles in: 
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
 [DEBUG] Checking for external profiles in: 
 F:\bar.DOO\Eclipse\Java\foo-parent-pom\profiles.xml
 [DEBUG] Aligning project: com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT to base 
 directory: F:\bar.DOO\Eclipse\Java\foo-parent-pom
 [DEBUG] Capturing session for backward compatibility aspect: 
 org.apache.maven.execution.mavensess...@3c2378
 [INFO] Searching repository for plugin with prefix: 'release'.
 [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins
 [DEBUG] Checking repositories:
 [[central] - http://central, [foo] - 
 http://[host]:8081/nexus/content/repositories/releases/, [foo-snapshots] - 
 http://[host]:8081/nexus/content/repositories/snapshots/]

 [...]

 for plugin: 
 /plugins/org.apache.maven.plugins:maven-release-plugin:2.0-bet...@48/thread:main
 [DEBUG] Constructing build plan for foo Parent POM
 Id: com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT
 task-segment: [release:clean, release:prepare] (aggregator-style)
 [INFO] 
 
 [INFO] Building foo Parent POM
 [INFO]
 [INFO] Id: com.foo:foo-parent-pom:pom:1.0.1-SNAPSHOT
 [INFO] task-segment: [release:clean, release:prepare] (aggregator-style)
 [INFO] 
 
 [DEBUG] Resolving plugin: org.apache.maven.plugins:maven-release-plugin with 
 version: 2.0-beta-7
 [DEBUG] In verifyVersionedPlugin for: 
 org.apache.maven.plugins:maven-release-plugin
 [DEBUG] 
 org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-7:runtime 
 (selected for runtime)
 [DEBUG]   org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for 
 runtime)
 [DEBUG]   
 org.apache.maven.release:maven-release-manager:jar:1.0-alpha-4:runtime 
 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.3:runtime (selected for 
 runtime)
 [DEBUG] 
 org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-6:runtime 
 (selected for runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.4:runtime (removed - 
 nearer found: 1.3)
 [DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for 
 runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - 
 nearer found: 1.3)
 [DEBUG] 

Re: Maven EAR Plugin ContextRoot

[Stephane Nicoll]

On Wed, Jan 14, 2009 at 11:39 PM, Stephen Duncan Jr
stephen.dun...@gmail.com wrote:
 I'm following the instructions here to set the context-root for my web
 modules as specified here:
 http://maven.apache.org/plugins/maven-ear-plugin/examples/customizing-context-root.html

 It seems to have no effect on the generated application.xml, the
 context-root still has the default values.  I couldn't find any mention of
 this problem.  Can anyone else indicate if this works or not in the current
 release of the maven-ear-pluging (2.3.1)?

It is working with both 2.3.1 and the trunk. I've just tried on a
stupid project that I have for testing and it worked. Can you maybe
post your pom.xml file?

plugin
  artifactIdmaven-ear-plugin/artifactId
  version2.3.1/version
  configuration
modules
  webModule
groupIdroot.project.servlets/groupId
artifactIdservlet/artifactId
contextRoot/foobar/contextRoot
  /webModule
/modules
  /configuration
/plugin


 --
 Stephen Duncan Jr
 www.stephenduncanjr.com




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: maven-ear-plugin: Always throws Embedded error: Unknown artifact type[test-jar]

[Stephane Nicoll]

The modules configuration is completely useless since the EAR plugin will
build the modules list using the dependencies section of your EAR project.

You have a test-jar without a scope test so the ear plugin tries to package
it since it's not scoped properly.



On Fri, Jan 9, 2009 at 11:55 AM, Jaikiran jai_forums2...@yahoo.co.inwrote:


 I am using Maven-2.0.9 in a multi-module project. One of the modules uses
 the
 maven-ear-plugin to generate an ear. Here's how it looks like:

 Parent pom.xml:
 -
 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;

  artifactIdParentArtifact/artifactId
  version0.1.0-SNAPSHOT/version
  packagingpom/packaging

  modules
!-- Create 2 jar files --
modulemyjarOne/module
modulemyjarTwo/module

!-- Combine the above 2 jars into ear --
moduleenterprise_Ear/module
  /modules



 Module1 = Jar artifact:
 -
 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

artifactIdParentArtifact/artifactId

  /parent

  artifactIdmyjarOne/artifactId
  version0.1.0-SNAPSHOT/version
  packagingjar/packaging


 /project


 Module 2 = Jar artifact:
 -
 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

artifactIdParentArtifact/artifactId

  /parent

  artifactIdmyjarTwo/artifactId
  version0.1.0-SNAPSHOT/version
  packagingjar/packaging


 /project


 Module 3 = Ear artifact:
 -
 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

artifactIdParentArtifact/artifactId

  /parent

  artifactIdenterprise_Ear/artifactId
  packagingear/packaging


  build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
modules
 jarModule
   groupIdblah.blah/groupId
   artifactIdmyjarOne/artifactId

 /jarModule

jarModule
   groupIdblah.blah/groupId
   artifactIdmyjarTwo/artifactId

 /jarModule
  /modules

/configuration
  /plugin
/plugins
  /build

!-- Dependencies --
dependencies


  dependency
groupIdblah.blah/groupId
   artifactIdmyjarTwo/artifactId
versionsomeversion/version
typejar/type
/dependency

  dependency
groupIdblah.blah/groupId
   artifactIdmyjarOne/artifactId
versionsomeversion/version
typejar/type
/dependency

/dependencies
 /project


 When i run mvn clean package on the parent pom, i always get a

 [INFO] [ear:generate-application-xml]
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Failed to initialize ear modules

 Embedded error: Unknown artifact type[test-jar]

 This happens irrespective of whether i include any modules in the ear
 plugin configuration. No matter what i tried, i keep getting this error. I
 then decided to run mvn in debug mode and this is what i see in the logs:

 [DEBUG] Resolving ear modules ...
 [DEBUG] Resolving ear module[jar:blah.blah.blah:myjarOne]
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Failed to initialize ear modules

 Embedded error: Unknown artifact type[test-jar]
 [INFO]
 
 [DEBUG] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
 initialize
 ear modules
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at

 

Re: packagingEcludes question

[Stephane Nicoll]

All maven plugins use the standard ant pattern resolution for paths.

S.

On Tue, Jan 13, 2009 at 4:10 PM, Mateusz Grzechociński 
mate...@grzechocinski.net wrote:

 Hi, thanks for answer.

 On 13th January 2009 14:02 user Stephane Nicoll
 stephane.nic...@gmail.com wrote:
  In my project I need to have a profile which excludes some jars (about
  30) from packaging when war is being created. It should create
  distribution war which contains only submodule jars, not external
  libraries which will be stored always on server.
 
  I used:
  plugins
   plugin
   artifactIdmaven-war-plugin/artifactId
   version2.1-alpha-2/version
   configuration
  packagingExcludesWEB-INF/lib/*.jar/packagingExcludes
   /configuration
   /plugin
  /plugins
 
  and it works really great. Unfortunately it exludes all jars. A I
  mentioned, there some jars (other modules of my app) which have to be
  in WEB-INF/lib. I wonder if I could specify regular expression like:
 
  packagingExcludes^WEB-INF/lib/prefix*.jar/packagingExcludes
 
  Well, you can have as many excludes as you want so you need to define the
  different libs that must be excluded.
 
 
 packagingExcludesWEB-INF/lib/foo*.jar,WEB-INF/lib/bar*.jar/packagingExcludes

 Yes I can, but specifying 30 jars explicity by name for me is the same
 as copy/paste 30 dependencies with scopeprovided/scope. I'd like
 to specify a mask (regexp) for those jars which should be excluded.

 If WEB-INF/lib/foo*.jar work pretty well, why ^WEB-INF/lib/foo*.jar
 doesn't ? For me the first example (foo*) is also some kind of regexp.
 Do you resolve only * or some other regexp signs?

  That being said, using a regexp is a good idea, you can file an
 improvement
  in Jira for this.

 Ok, I'll propose that improvement.

 --
 Cheers,
 Matthew

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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: maven-ear-plugin: Always throws Embedded error: Unknown artifact type[test-jar]

[Stephane Nicoll]

On Tue, Jan 13, 2009 at 1:59 PM, Jaikiran jai_forums2...@yahoo.co.inwrote:

 Right, that's what seems to be happening. Here's a trimmed down version of
 the pom.xml which manifests the issue:

groupIdorg.myapp/groupId
  artifactIdsample-maven-ear-app/artifactId
   version0.1.0-SNAPSHOT/version
   packagingear/packaging
  nameSample Maven EAR/name
!-- Dependencies --
dependencies
  dependency
   groupIdorg.someapp.ejb/groupId
   artifactIdsomeejbapp/artifactId
version1.0.0/version
typeejb/type
/dependency

/dependencies

 All i am trying to do is package only the someejbapp.jar into the EAR. I
 do not want the rest of the nested dependency to be packaged in the EAR.
 This nested dependency has the test-jar and i have no control over changing
 the scope of that test-jar. I have been searching the EAR plugin docs and
 haven't yet found a way to include only the someejbapp.jar in the EAR. Is
 it
 possible? Did i miss some existing documentation?


That's not the way Maven works. Maven works with a transitive dependency
system and all plugins are basically built on top of this mechanism. The
assembly plugin has some nice way to actually disable transitive
dependencies which could be reused in the ear but for the moment it's not
possible.

You may try to rescope your dependencies in the someejbapp pom by addition
optional tags for instance.

Best,
Stéphane




 --
 View this message in context:
 http://www.nabble.com/maven-ear-plugin%3A-Always-throws-%22Embedded-error%3A-Unknown-artifact-type-test-jar-%22-tp21370128p21435283.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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: ear plugin: earSourceExcludes

[Stephane Nicoll]

On Fri, Jan 2, 2009 at 11:30 PM, Scott Heaberlin heabd...@gmail.com wrote:

 Hello all,



 I am unable get earSourceExcludes to work.  Here is my build section
 from pom.xml:


Mmm, it should work. Please create an issue in Jira.

Thanks,
Stéphane





 build
plugins
plugin
artifactIdmaven-ear-plugin/artifactId
configuration
!-- this places all jar modules into a lib dir --
defaultJavaBundleDirlib//defaultJavaBundleDir
earSourceExcludeslib/commons-logging*/earSourceExcludes
modules
webModule
groupIdmy-groupid/groupId
artifactIdone-of-my-webmodules/artifactId

 bundleFileNameone-of-my-webmodules.war/bundleFileName
/webModule
!-- ... --
/modules
/configuration
/plugin
/plugins
 /build

 Yet, no matter what, commons-logging keeps showing up in my packaged
 ear file under the lib/ path.  I've tried other patterns as well;
 **/commons-logging* does not work either.

 http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#earSourceExcludes


 Thoughts?

 Thanks in advance,


 Scott Heaberlin

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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Ear plugin: artifact is not a dependency of the project

[Stephane Nicoll]

On Sat, Dec 20, 2008 at 11:05 AM, Laurens Blankers 
laur...@blankersfamily.com wrote:

 Hello,

 I'm trying to use the ear plugin to generate an application.xml. However
 when I try this I get the following error:

 Artifact[ejb3:stateless:stateless-ejb] is not a dependency of the project.


Use ejbModule. Also, you don't need to specify the list of modules in your
configuration since it will be built automatically based on the dependencies
of the project. The modules configuration is to be used when you want to
customise the way a module is packaged in the EAR.

S.



-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: [EAR-Plugin] - Include Resources

[Stephane Nicoll]

On Tue, Nov 18, 2008 at 9:34 PM, Paulo Cesar Silva Reis casmei...@gmail.com
 wrote:

 Hi folks,

 I have a multi-module project with several ejb modules. Also, I have custom
 configurations for each client so I generate like a sql file contains the
 specific properties for each one. It¹s possible to include this file inside
 the .ear? Or it¹s better to generate like a file (.tar.gz) with the
 generated resources and plus the ear file? And if so, how can I do that?


Yes but it has nothing to do with the ear IMO. If you ever need to load that
file from the classpath, adding it to the EAR won't help.



 Also, I would like to know if its possible to execute the deploy stage for
 an EAR module using a custom name for the file. For example, when I pass
 some parameters for maven, the finalName for the project changes but when I
 execute deploy maven does that:

  cp myProject-version-client-ABCX.jar - myProject-version.jar

 It removes my custom finalName.


The pattern used for deployed artifacts is standardized and you can't change
it. The repository won't be able to function properly if users have the
ability to customize the name of the file deployed on the repository.
finalName is honored for the package phase.

S.




 I really appreciate the help, I tried to search the answer in the mail list
 but nothing found.

 Thanks guys.




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: ear-plugin: webModule problems

[Stephane Nicoll]

It has nothing to do with the EAR plugin. Your pom is wrong. The
default type for a dependency is jar. If you want to depend on a war,
you must specify it.

So

dependency
groupIdch.ildsoftware/groupId
artifactIdildContact/artifactId
version1.0-SNAPSHOT/version
typewar/type
/dependency

On Fri, Nov 14, 2008 at 2:06 PM, Oliver Freivogel
[EMAIL PROTECTED] wrote:
 Hi

 I need help with the ear plugin.

 I have the following pom:

 ?xml version=1.0?
 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
   artifactIdILD_Export-Demo/artifactId
   groupIdch.ildsoftware/groupId
   version1.0-SNAPSHOT/version
   /parent
   modelVersion4.0.0/modelVersion
   groupIdch.ildsoftware/groupId
   artifactIdILD-Export-Demo-EAR/artifactId
   nameILD-Export-Demo-EAR/name
   version1.0-SNAPSHOT/version
   packagingear/packaging
   dependencies dependency
   groupIdch.ildsoftware/groupId
   artifactIddemoDB/artifactId
   version1.0-SNAPSHOT/version
   /dependency
   dependency
   groupIdch.ildsoftware/groupId
   artifactIdILD-Export-EJB/artifactId
 version1.0-SNAPSHOT/version
   /dependency
   dependency
   groupIdch.ildsoftware/groupId
   artifactIdILD-Export-WEB/artifactId
   version1.0-SNAPSHOT/version
 /dependency
   dependency
   groupIdch.ildsoftware/groupId
   artifactIdildContact/artifactId
   version1.0-SNAPSHOT/version /dependency
 /dependencies
   build plugins
   plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-ear-plugin/artifactId
   version2.3.1/version configuration
 modules
   ejb3Module
   groupIdch.ildsoftware/groupId
   artifactIddemoDB/artifactId
   /ejb3Module
   ejb3Module
   groupIdch.ildsoftware/groupId
   artifactIdILD-Export-EJB/artifactId
 /ejb3Module
   webModule
   groupIdch.ildsoftware/groupId
   artifactIdildContact/artifactId
   contextRoot/ildContact/contextRoot
   /webModule
   webModule
   groupIdch.ildsoftware/groupId
   artifactIdILD-Export-WEB/artifactId

 contextRoot/ExportWeb/contextRoot

 /webModule
   /modules
   /configuration
 /plugin
   /plugins
   /build  /project

 I can't create the package for this project because  maven looks out for jar
 files instead of war files in the case of the web modules, even though for
 ILD-Export-Web and ildContact the packaging is set as war in their pom.
 Both war files exists in my local repository.

 Any ideas? What is wrong im my pom?

 Thanks

 Oliver

 --
 ===
 ILD Software GmbH

 E-Mail: [EMAIL PROTECTED]
 Tel: 032 512 70 04

 Postadresse:
 ILD Software GmbH
 Postfach 845
 3000 Bern 8
 ===

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





-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

how to configure a mirror?

[Stephane Nicoll]

Hi,

I am trying to configure a mirror. We have development teams around
the world so I would like to be able to configure the central mirror
with a property that would be define in a profile for instance
(developers may travel around so they need to use the closest mirror).

We can't set a mirror in a profile.

I tried to do something like

mirrors
mirror
idinternal/id
nameReleases - Liege repository/name
url${internal.url}/url
mirrorOfcentral/mirrorOf
/mirror
/mirrors

And define internal.url in a profile that is in the activeProfiles
section of the settings but it did not replaced the value.

Any solution to this problem?

Thanks,
Stéphane

-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: War file with no java code

[Stephane Nicoll]

Nope. Is it a problem?

On Jan 23, 2008 1:13 PM, Jeff Mutonho [EMAIL PROTECTED] wrote:
 The web module for our project does not have have any java src , only a
 couple of  wsdls ,some ibm binding xml files and the web.xml file.
 When I build the war using the maven-war-plugin  , I noticed a  classes
 directory is created under  the  war's WEB-INF folder. Since there no java
 code
 , this classes folder is empty (which makes sense). Is there  a way I can
 configure the maven-war-plugin to not bother with  creating this empty
 classes folder?


 --

 Don't take the name of root in vain.

 Jeff  Mutonho
 Cape Town
 South Africa

 GoogleTalk : ejbengine
 Skype: ejbengine
 Registered Linux user number 366042




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: Continuum 1.1. and PostgreSQL?

[Stephane Nicoll]

Yep. Our instance is running on postgresql and we have no problem so far.

On 1/14/08, Bjørn T Johansen [EMAIL PROTECTED] wrote:
 Is this a fine match? Or should one use a different database?


 --

 Regards

 Bjørn T Johansen

 ---
 Someone wrote:
 I understand that if you play a Windows CD backwards you hear strange 
 Satanic messages
 To which someone replied:
 It's even worse than that; play it forwards and it installs Windows
 ---



-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working

[Stephane Nicoll]

Since you haven't filled a Jira issue, I did and added a
packagingExcludes parameter

http://jira.codehaus.org/browse/MWAR-135

Stéphane

On 12/12/07, Stephane Nicoll [EMAIL PROTECTED] wrote:
 You shouldn't use that for that. That's exactly what I meant:
 warSourceExcludes is used to exclude content in the directory defined
 by the warSourceDirectory. The documentation is confusing though.

 Now, I don't see any quick solution to your problem so we'll have to
 investigate a bit to clarify.

 Please file a Jira issue.

 Stéphane

 On Dec 12, 2007 1:37 PM, maarten roosendaal [EMAIL PROTECTED] wrote:
  This is in relation to the skinny-war. I wanted to exclude all libs from 
  WEB-INF\lib for all my WAR's.
 
  This also had to do with transitive dependencies in combination with 
  optional = true problem. I want to include only 1 specific jar in the 
  WEB-INF\lib and the rest should only be included in the manifest. I saw a 
  path in JIRA but this was not working because it was missing a few classes, 
  didn't look into it.
 
  Thanks,
  Maarten
 
 
  - Original Message 
  From: Stephane Nicoll [EMAIL PROTECTED]
  To: Maven Users List users@maven.apache.org
  Sent: Wednesday, December 12, 2007 12:49:21 PM
  Subject: Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working
 
 
  I've been changing something there indeed because it was excluding
  stuff in the resulting archive (which was not the expected behavior at
  all). I just hope I didn't break something :)
 
  Can you please elaborate because is not working is not especially
   helpful.
 
  this should only apply to stuff from the src/main/webapp directory. If
  you used this to filter the content of the war, it has only worked by
  side effect.
 
  Regards,
  Stéphane
 
  On Dec 12, 2007 11:19 AM, maarten roosendaal [EMAIL PROTECTED]
   wrote:
   Hi,
  
   It seems that the option warSourceExcludes for war-plugin
   2.1-alpha-2-SNAPSHOT is not working. I've been using alpha-1 and that was 
  working
   fine. Any ideas?
  
   Thanks,
   Maarten
  
  
  
  
  
   
  
   Looking for last minute shopping deals?
   Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
 
 
 
  --
  Large Systems Suck: This rule is 100% transitive. If you build one,
  you suck -- S.Yegge
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 
 

  
  Never miss a thing.  Make Yahoo your home page.
  http://www.yahoo.com/r/hs



 --
 Large Systems Suck: This rule is 100% transitive. If you build one,
 you suck -- S.Yegge



-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: Difference between webappDirectory and webResources

[Stephane Nicoll]

you don't need to exclude CVS files unless you're running the very old
v2.0. Use v2.0.2

Stéphane

On Jan 9, 2008 12:23 PM, amit kumar [EMAIL PROTECTED] wrote:
 Hi,
 when I use webappDirectory for my webroot directory the exclusion of
 files doesn't work( I want to exclude CVS files. But it works fine
 with webResources tag. What is the work around for webappDirectory
 or some other tag available?


 regards,
 Amit


 On 1/5/08, Stephane Nicoll [EMAIL PROTECTED] wrote:
  webappDirectory is for the main web app structure. webResources is a
  list of webapp-application related resources. The latter has been
  added afterwards for convenience.
 
  Regards,
  Stéphane
 
  On Jan 3, 2008 7:27 AM, amit kumar [EMAIL PROTECTED] wrote:
   Hi,
   I see to tags in maven-war-plugin, webappDirectory and webResources
  tag,
   what is the difference between two?
  
   Regards,
   Amit
  
 
 
 
  --
  Large Systems Suck: This rule is 100% transitive. If you build one,
  you suck -- S.Yegge
 
  -
  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]





-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: Difference between webappDirectory and webResources

[Stephane Nicoll]

webappDirectory is for the main web app structure. webResources is a
list of webapp-application related resources. The latter has been
added afterwards for convenience.

Regards,
Stéphane

On Jan 3, 2008 7:27 AM, amit kumar [EMAIL PROTECTED] wrote:
 Hi,
 I see to tags in maven-war-plugin, webappDirectory and webResources tag,
 what is the difference between two?

 Regards,
 Amit




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: CVS files being packaged in WAR

[Stephane Nicoll]

Upgrade to 2.0.2. This bug is fixed for over a year.

Stéphane

On Jan 1, 2008 1:59 PM, amit kumar [EMAIL PROTECTED] wrote:
 Hi,
 I am facing this problem of getting CVS files packaged in the WAR build from
 maven. I am overriding the maven's default directory layout. Below is the
 part of my pom.xml

  build
   finalNamePortal/finalName
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 version2.0/version
 configuration
 webappDirectory
 ${basedir}/webRoot
 /webappDirectory
 excludes
  exclude**/CVS/exclude
   /excludes
 /configuration
 /plugin
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 configuration
 source1.5/source
 target1.5/target
 optimizetrue/optimize
 /configuration
 /plugin
 /plugins
 sourceDirectory${basedir}/src/sourceDirectory
 directoryC:\finalbuilds\readioneportal/directory
 resources
 resource
  directory${basedir}/resources/directory
 /resource
 /resources
 /build

 How shall I avoid this? Any help?

 Regards,
 Amit




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: an mvn setup:diagnose would be nice at times like this :)

[Stephane Nicoll]

Try telnet repo1.maven.org 80

(or check the options if you are on Windows, I think specifying the
port is -p). Ping only means that you can reach that machine on a
particular protocol. If HTTP is forbidden on the way it won't help.

Anyway, back to the original question, I think that Maven can't do
much for you. It brings the original exception (the Java network
exception) which is good. I don't see how it could inspect your
network configuration.

Regards,
Stéphane

On Dec 29, 2007 1:39 PM, Pete Carapetyan [EMAIL PROTECTED] wrote:
 answer is inline below question:

 On Dec 29, 2007 6:30 AM, Tom Huybrechts [EMAIL PROTECTED] wrote:
  The UnknownHostException make this look like a network issue. Can you do a
  ping repo1.maven.org ?

 $ ping repo1.maven.org

 Pinging repo1.maven.org [63.246.20.112] with 32 bytes of data:

 Reply from 63.246.20.112: bytes=32 time=46ms TTL=52
 Reply from 63.246.20.112: bytes=32 time=46ms TTL=52
 Reply from 63.246.20.112: bytes=32 time=44ms TTL=52
 Reply from 63.246.20.112: bytes=32 time=45ms TTL=52

 Ping statistics for 63.246.20.112:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
 Approximate round trip times in milli-seconds:
 Minimum = 44ms, Maximum = 46ms, Average = 45ms

 
  Tom
 
 
  On Dec 29, 2007 1:26 PM, Pete Carapetyan [EMAIL PROTECTED] wrote:
 
   Long time Maven user getting the dreaded plugin does not exist or no
   valid version could be found on every maven call after unrelated
   software installation. Any advice where to look next greatly
   appreciated.
  
   Ran on same box 2 hours before, runs on every other box same network
   connection, only thing different is I installed some screen capturing
   software (Camtasia) which might have done something - don't know how
   to diagnose what. Everything else on the box still running great far
   as I can tell.
  
   Here is what I have done to make sure it isn't the usual suspects.
   - no proxy - other computer works fine as did this one two hours earlier
   - no firewall - turned off firewall to test that
   - installed bran new latest version of maven, pointed to fresh empty
   repository
   - virgin conf/settings.xml
   - ran archetype:create to make sure it wasn't a lame pom.xml in an
   existing project
  
   Below is example of what I ran and what came back (blowing away
   repository first). It does go as far as to build one
   maven-metadata-central.xml in
   ~\.m2\repository\org\apache\maven\plugins then it quits and prints the
   stacktrace below.
  
  
   $ mvn -X archetype:create   
   -DarchetypeGroupId=org.apache.maven.archetypes  -D
   archetypeArtifactId=maven-archetype-site   -DgroupId=org.artofillusion
   -Darti
   factId=maven-sample
  
   + Error stacktraces are turned on.
   Maven version: 2.0.8
   Java version: 1.6.0_01
   OS name: windows xp version: 5.1 arch: x86 Family: windows
   [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
   Settin
   gs\Administrator\.m2\plugin-registry.xml'
   [DEBUG] Building Maven global-level plugin registry from:
   'c:\dev\apache-maven-2
   .0.8\conf\plugin-registry.xml'
   [INFO] Scanning for projects...
   [INFO] Searching repository for plugin with prefix: 'archetype'.
   [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins
   [INFO] org.apache.maven.plugins: checking for updates from central
   [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be
   retri
   eved from repository: central due to an error: Error transferring file
   [INFO] Repository 'central' will be blacklisted
   [DEBUG] Exception
   org.apache.maven.wagon.TransferFailedException: Error transferring file
  at
   org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputD
   ata(LightweightHttpWagon.java:104)
  at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
  at
   org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(D
   efaultWagonManager.java:462)
  at
   org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMeta
   data(DefaultWagonManager.java:363)
  at
   org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada
   taManager.resolveAlways(DefaultRepositoryMetadataManager.java:364)
  at
   org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada
   taManager.resolve(DefaultRepositoryMetadataManager.java:97)
  at
   org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMapping
   s(DefaultPluginMappingManager.java:103)
  at
   org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMapping
   s(DefaultPluginMappingManager.java:87)
  at org.apache.maven.plugin.DefaultPluginMappingManager.getByPrefix
   (Defau
   ltPluginMappingManager.java:61)
  at
   org.apache.maven.plugin.DefaultPluginManager.getPluginDefinitionForPr
   efix(DefaultPluginManager.java:150)
  at
   

Re: Maven2 + WLS - Exploded EAR

[Stephane Nicoll]

On Dec 28, 2007 12:03 PM, amidrunk [EMAIL PROTECTED] wrote:

 Hi,

 I think I've looked through the entire Internet by now,

Waouh, it may have taken some time :)

 but I can't find any
 way to explode ear:s using maven2. Does anyone know how to do this? I'm
 using maven 2.0.6 and weblogic 9.2.

See http://jira.codehaus.org/browse/MEAR-51

Stéphane


 Regards,
 Nille
 --
 View this message in context: 
 http://www.nabble.com/Maven2-%2B-WLS---Exploded-EAR-tp1452s177p1452.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]





-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: [m2] addition resources to an ear?

[Stephane Nicoll]

On Dec 27, 2007 5:54 PM, Mick Knutson [EMAIL PROTECTED] wrote:
 First off, thank you SO MUCH for the response. It works like a charm.

 But, second, where is this documented? I assumed that the resources
 declaration was the same with all modules, and now I find another directory
 I needed to add.

Well, it depends. I think it was a misunderstanding with the original
version of the EAR plugin. Using resources for this is indeed the way
to go but at that time it wasn't that clear (hence the specific
directory for the ear)

See 
http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#earSourceDirectory

Stéphane







 On Dec 27, 2007 8:41 AM, Tom Huybrechts [EMAIL PROTECTED] wrote:

   just put in src/main/application ?
 
  On Dec 27, 2007 5:39 PM, Mick Knutson [EMAIL PROTECTED] wrote:
 
   Is this not possible? I really have a Oc4j requirement that I need to
  add
   an
   orion-application.xml into my ear. Can someone please help me add this?
  
   On Dec 26, 2007 12:47 PM, Mick Knutson [EMAIL PROTECTED] wrote:
  
I have this in my ear's pom.xml
   
 resources
resource
directory${basedir}/src/main/resources/directory
targetPathMETA-INF/targetPath
filteringtrue/filtering
/resource
/resources
   
but my orion.xml inside ${basedir}/src/main/resources does not get
included into my ear.
   
Can anyone help please?
   
--
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
   ---
  
 



 --

 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
 ---




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working

[Stephane Nicoll]

I've been changing something there indeed because it was excluding
stuff in the resulting archive (which was not the expected behavior at
all). I just hope I didn't break something :)

Can you please elaborate because is not working is not especially helpful.

this should only apply to stuff from the src/main/webapp directory. If
you used this to filter the content of the war, it has only worked by
side effect.

Regards,
Stéphane

On Dec 12, 2007 11:19 AM, maarten roosendaal [EMAIL PROTECTED] wrote:
 Hi,

 It seems that the option warSourceExcludes for war-plugin 
 2.1-alpha-2-SNAPSHOT is not working. I've been using alpha-1 and that was 
 working fine. Any ideas?

 Thanks,
 Maarten




   
 
 Looking for last minute shopping deals?
 Find them fast with Yahoo! Search.  
 http://tools.search.yahoo.com/newsearch/category.php?category=shopping



-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: maven-war-plugin webResources - relative path

[Stephane Nicoll]

ah, that's the filtering issue. I don't fully get this one but it's
related to the content of your filters and the interpolation.

If you can reproduce easily file a jira issue with a sample project.

Stéphane

On Dec 11, 2007 12:07 PM, Jan Torben Heuer [EMAIL PROTECTED] wrote:
 Stephane Nicoll wrote:

  Replace 2.0 by 2.0.2.
 
  It's a bug and it has been fixed.

 Sorry, but I still cannot run mvn install from my parent pom.

 Additionally, when I try to run mvn install from the webapps pom I get:


 [INFO] [war:war]
 [INFO] Exploding webapp...
 [INFO] Assembling webapp sas-communication-http in ...
 [INFO] Copy webapp webResources to ...
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] org.apache.maven.project.MavenProject cannot be cast to
 java.lang.String
 [INFO] 
 
 [INFO] Trace
 java.lang.ClassCastException: org.apache.maven.project.MavenProject cannot
 be cast to java.lang.String
 at
 org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
 at
 org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
 at java.io.Reader.read(Reader.java:123)
 at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
 at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
 at
 org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921)
 at
 org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415)
 at
 org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518)
 at
 org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347)
 at
 org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164)
 at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130)
 at
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] 
 
 [INFO] Total time: 8 seconds
 [INFO] Finished at: Tue Dec 11 12:05:18 CET 2007
 [INFO] Final Memory: 7M/14M
 [INFO] 
 


 Is 2.0.2 still beta?


 Jan


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





-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working

[Stephane Nicoll]

You shouldn't use that for that. That's exactly what I meant:
warSourceExcludes is used to exclude content in the directory defined
by the warSourceDirectory. The documentation is confusing though.

Now, I don't see any quick solution to your problem so we'll have to
investigate a bit to clarify.

Please file a Jira issue.

Stéphane

On Dec 12, 2007 1:37 PM, maarten roosendaal [EMAIL PROTECTED] wrote:
 This is in relation to the skinny-war. I wanted to exclude all libs from 
 WEB-INF\lib for all my WAR's.

 This also had to do with transitive dependencies in combination with optional 
 = true problem. I want to include only 1 specific jar in the WEB-INF\lib and 
 the rest should only be included in the manifest. I saw a path in JIRA but 
 this was not working because it was missing a few classes, didn't look into 
 it.

 Thanks,
 Maarten


 - Original Message 
 From: Stephane Nicoll [EMAIL PROTECTED]
 To: Maven Users List users@maven.apache.org
 Sent: Wednesday, December 12, 2007 12:49:21 PM
 Subject: Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working


 I've been changing something there indeed because it was excluding
 stuff in the resulting archive (which was not the expected behavior at
 all). I just hope I didn't break something :)

 Can you please elaborate because is not working is not especially
  helpful.

 this should only apply to stuff from the src/main/webapp directory. If
 you used this to filter the content of the war, it has only worked by
 side effect.

 Regards,
 Stéphane

 On Dec 12, 2007 11:19 AM, maarten roosendaal [EMAIL PROTECTED]
  wrote:
  Hi,
 
  It seems that the option warSourceExcludes for war-plugin
  2.1-alpha-2-SNAPSHOT is not working. I've been using alpha-1 and that was 
 working
  fine. Any ideas?
 
  Thanks,
  Maarten
 
 
 
 
 
  
 
  Looking for last minute shopping deals?
  Find them fast with Yahoo! Search.
   http://tools.search.yahoo.com/newsearch/category.php?category=shopping



 --
 Large Systems Suck: This rule is 100% transitive. If you build one,
 you suck -- S.Yegge

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







   
 
 Never miss a thing.  Make Yahoo your home page.
 http://www.yahoo.com/r/hs



-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: maven-war-plugin webResources - relative path

[Stephane Nicoll]

Replace 2.0 by 2.0.2.

It's a bug and it has been fixed.

Stéphane

On Dec 10, 2007 4:03 PM, Jan Torben Heuer [EMAIL PROTECTED] wrote:
 Hi,

 I'm using the following settings to include and filter webresources:

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 version2.0/version
 configuration
 webResources
 resource
 
 directorysrc/main/webresources/directory
 
 filteringtrue/filtering
 /resource
 /webResources
 /configuration

 /plugin

 However, the project is a multi-module project. Thus, running it in the
 submodule works, but in the parent it expects the resource to be relative
 to it's own pom.xml (so module/src/main/webresources, would be correct).

 Can I fix it?

 Jan


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





-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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

Re: Alpha plugin

[Stephane Nicoll]

Can you create an issue with a description and a way to reproduce?

Stéphane

On 11/6/07, Jean-Yves LEBLEU [EMAIL PROTECTED] wrote:
 Hello all,

 Is there any way to avoid using alpha version of plugins with maven.

 I have some builds which used to run fine and as the plugin is updated
 to alpha version they are not running properly anymore
 (war plugin alpha 2.1 does not filter ressources correctly), had the
 same pb with the assembly plugin 

 Thanks for any answer.

 Jean-Yves

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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck -- S.Yegge

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