Sharing components between build extension and plugin

[Paul Benedict]

Good day. I am seeking help for a Maven 3 (3.3.9) problem I am unable to
resolve. I've been hacking at it for about three weeks on-and-off and I
cannot find any solution. I've gone pretty much around the block both in
trial-and-error changes and web searches to no avail.

Here are the details in a simplified manner:

Project A
*) Common component library
*) A bunch of my own Plexus components
*) One such is @Component(role=Foo.class, instantiationStrategy="singleton")

Project B
*) Maven build extension
*) Dependent upon Project A artifact
*) One class of @Component(role = AbstractMavenLifecycleParticipant.class)
*) Takes the injected Foo component and stuffs it into a plugin context

Project C
*) Maven build plugin
*) Dependent upon Project A artifact
*) Retrieves Foo component instance from its plugin context

Project D
*) Application
*) POM specifies build  of Project B's artifact
*) POM specifies build 

When I build Project D, I cannot ever get the extension (Project B) and the
plugin (Project C) to ever see the same instance of Foo. As I said, I have
tried a myriad of configurations without success. The build dies with a
CastClassException because the extension and plugin clearly have a
different Class instance.

So my question is...

What is the cookbook formula where a build extension and a build plugin,
specified in the same POM, are able to share one and only one instance of
Foo component?

Cheers and God bless,
Paul

Re: Curious DEBUG message from maven-script-ant plugin

[Paul Benedict]

I am following up on my question. No answer yet. I don't have an answer
myself In addition, I have noticed that none of Maven's properties are
available to me inside my Ant script. I have to explicitly create
parameters in my Ant-mojo descriptor with default values. Could this be
related to the aforementioned?

Cheers and God bless,
Paul

On Mon, Feb 12, 2018 at 3:06 PM, Paul Benedict <pbened...@apache.org> wrote:

> I found this message in my output when turning on Maven's debug option
> (-X). It looks like an error to me, or at least a warning, and I don't know
> what the consequences are. It "sounds bad" but I am not sure what it is
> complaining about or what to do about it.
>
> Output:
> ===
> [DEBUG] The following standard Maven Ant-mojo support objects could not be
> created:
>
> -  Maven parameter expression evaluator for Ant properties.
>
> Maven project, session, mojo-execution, or path-translation parameter
> information is
> missing from this mojo's plugin descriptor.
>
> Perhaps this Ant-based mojo depends on maven-script-ant < 2.1.0, or used
> maven-plugin-tools-ant < 2.2 during release?
> ===
>
> What am I do to about this?
>
> Cheers and God bless,
> Paul
>

Re: Question regarding Maven's local repository use

[Paul Benedict]

Anders, I am researching my project/repository against your explanation. I
will follow up with a real answer once complete. Thanks for your response.

On Mon, Feb 5, 2018 at 3:25 PM, Anders Hammar <and...@hammar.net> wrote:

> I'd like to stress that my explanations are from what I recall. I could be
> wrong.
>
> If my memory serves me right and this is how it works, I believe it was
> just to prevent the scenario you're describing (switching between different
> repos) from causing the wrong result. The idea was then that if you change
> your repo/mirror config, your intention is to use the current declared
> repo(s)/mirror(s). So anything from some other repo(s) shouldn't be used.
> However, using the repo/mirror id is probably not the best solution; using
> the url would probably be better.
>
> So, in your scenario, you typically work with a corporate proxy/mirror
> (like Nexus) that only gives you access to procured artifacts. Then you
> want to use/test some artifact that the mirror don't allow, so you work
> directly towards central. Then you switch back to your procured mirror and
> Maven now prevents you from using the artifact that doesn't exist in the
> procured mirror.
> I'd say everything works as intended then. Maven stops you from using an
> artifact that you shouldn't be using according to your configuration. If
> you would like to use that artifact, you should be working towards central
> directly or your mirror should provide it.
> Do you see my point?
>
> /Anders
>
> On Mon, Feb 5, 2018 at 10:06 PM, Paul Benedict <pbened...@apache.org>
> wrote:
>
> > Anders, I have a question for your clarification. I think you're saying
> > that because some repositories aren't in best condition, this is a way to
> > make sure the intended artifact of the intended repository is downloaded?
> > Okay. If that's the case, that sounds like a really weird edge case that
> > shouldn't figure into normal use. If I ever encountered such a problem, a
> > developer should rely on dependency:purge-local-repository to trash the
> > bad
> > download.
> >
> > So is there any room for a Maven enhancement here? I am still not
> convinced
> > the current behavior is sensible as a default. I really want to allow my
> > repositories, with local artifacts pre-cached in my local repository, to
> go
> > offline without causing a build panic. What are anyone's thoughts on here
> > about how Maven could adopt behavior like I want? I could probably write
> a
> > patch but I'd like a "meeting of the minds" to turn this idea from good
> to
> > better.
> >
> > On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net>
> wrote:
> >
> > > IIRC this change was introduced as an artifact sometimes differ between
> > > repositories. They shouldn't do, but some repos aren't handled
> correctly.
> > > So if the repo id changes compared to the one stored for a locally
> cached
> > > artifact, Maven tries to download it again.
> > >
> > > /Anders
> > >
> > > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org>
> > > wrote:
> > >
> > > > I think you're right. However, I am still curious why Maven is acting
> > > like
> > > > it does -- in terms of requirements. Maven already has the artifact
> > > > locally. There's not a reason (and never a reason?) for it to ever be
> > > > retrieved again, right?
> > > >
> > > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net>
> > wrote:
> > > >
> > > > > What I think you're running into is that Maven keeps track of from
> > > which
> > > > > repo an artifact in the local repo was downloaded from. When you
> > > > > remove/restore the mirror config the repo id most likely changes
> > which
> > > > > causes Maven to try to download again.
> > > > > There should be a filed named _remote.repositories next to every
> > > artifact
> > > > > in the loca lrepo where you can find this info.
> > > > >
> > > > > IIRC this was a change between Maven 2 and Maven 3, or a change
> that
> > > > > happened very early in the life of Maven 3. Before that Maven
> didn't
> > > keep
> > > > > track of from where an artifact was downloaded.
> > > > >
> > > > > /Anders
> > > > >
> > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <
> pbened...@apache.org>
> > > > > wrote

Curious DEBUG message from maven-script-ant plugin

[Paul Benedict]

I found this message in my output when turning on Maven's debug option
(-X). It looks like an error to me, or at least a warning, and I don't know
what the consequences are. It "sounds bad" but I am not sure what it is
complaining about or what to do about it.

Output:
===
[DEBUG] The following standard Maven Ant-mojo support objects could not be
created:

-  Maven parameter expression evaluator for Ant properties.

Maven project, session, mojo-execution, or path-translation parameter
information is
missing from this mojo's plugin descriptor.

Perhaps this Ant-based mojo depends on maven-script-ant < 2.1.0, or used
maven-plugin-tools-ant < 2.2 during release?
===

What am I do to about this?

Cheers and God bless,
Paul

Metadata multiplicity of maven-script-ant plugins

[Paul Benedict]

I have a question based on these two references:

*)
https://maven.apache.org/plugin-tools-archives/plugin-tools-3.2/maven-plugin-plugin/examples/ant-mojo.html

*) https://books.sonatype.com/mcookbook/reference/ch04s04.html

In each reference, the reader is directed to create one xxx.build.xml and
xxx.mojos.xml where "xxx" represents the plugin name. I have done that.
However, is there an implication here that ONLY ONE plugin can be defined?
Am I able to also include a yyy.build.xml and yyy.mojos.xml?

Cheers,
Paul

Re: Question regarding Maven's local repository use

[Paul Benedict]

Anders, I have a question for your clarification. I think you're saying
that because some repositories aren't in best condition, this is a way to
make sure the intended artifact of the intended repository is downloaded?
Okay. If that's the case, that sounds like a really weird edge case that
shouldn't figure into normal use. If I ever encountered such a problem, a
developer should rely on dependency:purge-local-repository to trash the bad
download.

So is there any room for a Maven enhancement here? I am still not convinced
the current behavior is sensible as a default. I really want to allow my
repositories, with local artifacts pre-cached in my local repository, to go
offline without causing a build panic. What are anyone's thoughts on here
about how Maven could adopt behavior like I want? I could probably write a
patch but I'd like a "meeting of the minds" to turn this idea from good to
better.

On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> wrote:

> IIRC this change was introduced as an artifact sometimes differ between
> repositories. They shouldn't do, but some repos aren't handled correctly.
> So if the repo id changes compared to the one stored for a locally cached
> artifact, Maven tries to download it again.
>
> /Anders
>
> On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org>
> wrote:
>
> > I think you're right. However, I am still curious why Maven is acting
> like
> > it does -- in terms of requirements. Maven already has the artifact
> > locally. There's not a reason (and never a reason?) for it to ever be
> > retrieved again, right?
> >
> > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote:
> >
> > > What I think you're running into is that Maven keeps track of from
> which
> > > repo an artifact in the local repo was downloaded from. When you
> > > remove/restore the mirror config the repo id most likely changes which
> > > causes Maven to try to download again.
> > > There should be a filed named _remote.repositories next to every
> artifact
> > > in the loca lrepo where you can find this info.
> > >
> > > IIRC this was a change between Maven 2 and Maven 3, or a change that
> > > happened very early in the life of Maven 3. Before that Maven didn't
> keep
> > > track of from where an artifact was downloaded.
> > >
> > > /Anders
> > >
> > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org>
> > > wrote:
> > >
> > > > My Maven version is 3.3.9. For my typical use case, my settings.xml
> > has a
> > > >  of "central" that provides a procured subset of artifacts.
> It
> > > > contains nearly everything I might need to do a desktop build.
> However,
> > > > sometimes I need to connect to the real "central" directly to try and
> > > test
> > > > an experimental artifact; therefore I temporarily wipe out my
> ,
> > > let
> > > > Maven resolve the artifact and place it in my local repository, and I
> > can
> > > > test accordingly.
> > > >
> > > > Now this is where my trouble begins. After restoring my ,
> Maven
> > > > complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> > > > repository, resolution will not be reattempted until...".
> > > >
> > > > This is very confusing to me. The artifact version is NOT a snapshot.
> > > Yes,
> > > > I am online, but why does Maven need to verify the artifact in the
> > remote
> > > > repository given it already resides in my local repository? Since
> > > > non-snapshots can never be re-updated, I don't see a need for Maven
> to
> > > make
> > > > a remote connection. It seems unnecessary.
> > > >
> > > > Perhaps I am misunderstanding a requirement of Maven. I was really
> > > hoping I
> > > > could be disconnected from the artifact's remote repository, but
> > > evidently
> > > > not. Why is Maven acting this way?
> > > >
> > > > Thank you!
> > > >
> > > > Cheers,
> > > > Paul
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>



-- 
Cheers,
Paul

Re: Question regarding Maven's local repository use

[Paul Benedict]

I think you're right. However, I am still curious why Maven is acting like
it does -- in terms of requirements. Maven already has the artifact
locally. There's not a reason (and never a reason?) for it to ever be
retrieved again, right?

On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote:

> What I think you're running into is that Maven keeps track of from which
> repo an artifact in the local repo was downloaded from. When you
> remove/restore the mirror config the repo id most likely changes which
> causes Maven to try to download again.
> There should be a filed named _remote.repositories next to every artifact
> in the loca lrepo where you can find this info.
>
> IIRC this was a change between Maven 2 and Maven 3, or a change that
> happened very early in the life of Maven 3. Before that Maven didn't keep
> track of from where an artifact was downloaded.
>
> /Anders
>
> On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org>
> wrote:
>
> > My Maven version is 3.3.9. For my typical use case, my settings.xml has a
> >  of "central" that provides a procured subset of artifacts. It
> > contains nearly everything I might need to do a desktop build. However,
> > sometimes I need to connect to the real "central" directly to try and
> test
> > an experimental artifact; therefore I temporarily wipe out my ,
> let
> > Maven resolve the artifact and place it in my local repository, and I can
> > test accordingly.
> >
> > Now this is where my trouble begins. After restoring my , Maven
> > complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> > repository, resolution will not be reattempted until...".
> >
> > This is very confusing to me. The artifact version is NOT a snapshot.
> Yes,
> > I am online, but why does Maven need to verify the artifact in the remote
> > repository given it already resides in my local repository? Since
> > non-snapshots can never be re-updated, I don't see a need for Maven to
> make
> > a remote connection. It seems unnecessary.
> >
> > Perhaps I am misunderstanding a requirement of Maven. I was really
> hoping I
> > could be disconnected from the artifact's remote repository, but
> evidently
> > not. Why is Maven acting this way?
> >
> > Thank you!
> >
> > Cheers,
> > Paul
> >
>



-- 
Cheers,
Paul

Question regarding Maven's local repository use

[Paul Benedict]

My Maven version is 3.3.9. For my typical use case, my settings.xml has a
 of "central" that provides a procured subset of artifacts. It
contains nearly everything I might need to do a desktop build. However,
sometimes I need to connect to the real "central" directly to try and test
an experimental artifact; therefore I temporarily wipe out my , let
Maven resolve the artifact and place it in my local repository, and I can
test accordingly.

Now this is where my trouble begins. After restoring my , Maven
complains: "Failure to find xxx:yyy:1.0.0  was cached in local
repository, resolution will not be reattempted until...".

This is very confusing to me. The artifact version is NOT a snapshot. Yes,
I am online, but why does Maven need to verify the artifact in the remote
repository given it already resides in my local repository? Since
non-snapshots can never be re-updated, I don't see a need for Maven to make
a remote connection. It seems unnecessary.

Perhaps I am misunderstanding a requirement of Maven. I was really hoping I
could be disconnected from the artifact's remote repository, but evidently
not. Why is Maven acting this way?

Thank you!

Cheers,
Paul

Re: Multiproject build that needs to build one project only if on a particular os?

[Paul Benedict]

In addition, you can use the --pl option (requires Maven 3.2.1+) to exclude
the child module of your choice.

This example excludes child module "foo":
mvn --pl !foo

Cheers,
Paul

On Tue, Aug 16, 2016 at 2:54 PM, Bernd Eckenfels 
wrote:

> This describes how to control modules with profiles and how to activate
> profiles based on os family:
>
>
> http://books.sonatype.com/mvnref-book/reference/
> profiles-sect-activation.html
>
> Gruss
> Bernd
>
>  Am Tue, 16 Aug 2016 19:47:38 +
> schrieb "KARR, DAVID" :
>
> > I have a multiproject build with three modules, not counting the
> > top-level.  I can build this on either Windows or Linux, but if I'm
> > building on Windows, one of the subprojects should not be built.  I
> > vaguely remember seeing ways to set architecture properties and check
> > for those, but I can't find info on that right now.  How do I set
> > this up?
> >
> > -
> > 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: API for annotation scanning in a mojo?

[Paul Benedict]

Thanks Robert. Just to be clear, because I want to know if your link still
applies, I don't want to scan for Maven annotations, but annotations in the
reactor's current project. Can you confirm I can still use this for that
purpose?

Cheers,
Paul

On Wed, Jul 13, 2016 at 4:58 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi Paul,
>
> In general there are descriptors generated at compile-time based on either
> doclettags (old-style) or annotations (new-style).
> At runtime it is a matter of reading the descriptor and build up the Maven
> runtime, which should be much faster then runtime annotation scanning.
>
> Here's an example of the default implementation of the MojoScanner:
>
> https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/xref/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.html
>
> Hope this helps,
> Robert
>
>
> On Wed, 13 Jul 2016 23:13:41 +0200, Paul Benedict <pbened...@apache.org>
> wrote:
>
> Is there any existing API in any of these projects [1] for scanning
>> annotations? I am writing a Mojo and want to scan either the project's
>> source files or binary files -- haven't decided. The answer will depend on
>> what APIs are available to me.
>>
>> [1] https://maven.apache.org/ref/3.3.9/index.html
>>
>> Cheers,
>> Paul
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

API for annotation scanning in a mojo?

[Paul Benedict]

Is there any existing API in any of these projects [1] for scanning
annotations? I am writing a Mojo and want to scan either the project's
source files or binary files -- haven't decided. The answer will depend on
what APIs are available to me.

[1] https://maven.apache.org/ref/3.3.9/index.html

Cheers,
Paul

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Paul Benedict]

That is an interesting idea so no one gets blindsided by an important new
feature. Baby steps, right?

I recommend that you opine in the ticket:
https://issues.apache.org/jira/browse/MNG-5935

...and also write dev@ to pass on your idea. I think your idea has merit.

Cheers,
Paul

On Mon, Jun 20, 2016 at 3:00 PM, Oliver B. Fischer <o.b.fisc...@swe-blog.net
> wrote:

> Yes, I think this  would be very helpfull. Otherwise I see a lot of people
> complaining about Maven and that is not able to do its work.
>
> The best solution IMHO would be to print out a warning with a detailed
> hint that no one could ignore.
>
> Am 20.06.16 um 21:56 schrieb Paul Benedict:
>
>> Do you mean make it a warning in 3.4 and fix behavior in 3.5?
>>
>> Cheers,
>> Paul
>>
>> On Mon, Jun 20, 2016 at 2:42 PM, Oliver B. Fischer <
>> o.b.fisc...@swe-blog.net
>>
>>> wrote:
>>> Ok, I will fix it. But wouldn't it be an usefull option to print some
>>> warning about this problem before changing the current behaviour?
>>>
>>>
>>> WDYT?
>>>
>>>
>>> Am 12.06.16 um 23:08 schrieb Christian Schulte:
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fisc...@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fisc...@jabber.org
>>> X http://xing.to/obf
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
> -
> 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

[Paul Benedict]

Do you mean make it a warning in 3.4 and fix behavior in 3.5?

Cheers,
Paul

On Mon, Jun 20, 2016 at 2:42 PM, Oliver B. Fischer  wrote:

> Ok, I will fix it. But wouldn't it be an usefull option to print some
> warning about this problem before changing the current behaviour?
>
>
> WDYT?
>
>
> Am 12.06.16 um 23:08 schrieb Christian Schulte:
>
>> Am 06/12/16 um 22:01 schrieb Oliver B. Fischer:
>>
>>> With this snapshot I am unable to build jQAssistant. You can fetch it
>>> from g...@github.com:buschmais/jqassistant.git
>>>
>>> You need to fix the project. 3.4 adds support for managing the
>> 'optional' flag in dependency management and contains bugfixes to
>> resolution issues. Either you have used the 'optional' flag in
>> dependency management somewhere and have not noticed this is not
>> supported or you are managing some dependency to 'test' scope and Maven
>> correctly does no longer select such a dependency when transitive. All
>> of those bugfixes have already been reverted lately and the current
>> 3.4-SNAPSHOT now again behaves incorrectly without you noticing it.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Message typo

[Paul Benedict]

I think this must be a logger issue. The entire message is actually this:
"[options] bootstrap class path not set in conjunction with -source 1.7"

So the logger must be cutting into the beginning of the string with
"[WARN]" plus any whitespace padding.

Cheers,
Paul

On Wed, Jan 20, 2016 at 12:03 PM, Andreas Gudian 
wrote:

> The message itself originates from the compiler (javac). No idea why it's
> truncated, though... ;-)
>
> 2016-01-20 6:18 GMT+01:00 Gary Gregory :
>
> > I'm not sure who output this message but there is obviously a etter
> issing:
> >
> > [INFO] -
> > [WARN] COMPILATION WARNING :
> > [INFO] -
> > [WARN] ootstrap class path not set in conjunction with -source 1.7
> >
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>

Re: Offline builds nearly impossible

[Paul Benedict]

I think most people, at least once in their life, try to use their local
repository cache as an offline remote repository. However, the two aren't
the same in concept though, IIRC, the last time I tried. You still need to
keep the two separate.

Now it would be interesting if a tool existed to copy the contents of a
local repository and scrub its local metadata. That would then give you a
true "remote offline repo".


Cheers,
Paul

On Fri, Nov 13, 2015 at 11:17 AM, Jason van Zyl  wrote:

> If this does not work please let me know. This is what I’ve used in the
> past and if it doesn’t work I agree it needs to be fixed. I honestly
> haven’t tried making a hermetically sealed build in a few years but last
> year worked on a project that did no network traversal aside from using
> file-based repositories and it all worked fine.
>
> > On Nov 13, 2015, at 11:33 AM, Jörg Schaible 
> wrote:
> >
> > Hi Jason,
> >
> > Jason van Zyl wrote:
> >
> >> Use a file based remote repository instead of trying to build in offline
> >> mode.
> >>
> >> You can either use a repository manager to create the remote repository
> or
> >> an empty local repository with a full build. As noted though, you have
> to
> >> remove all local repository metadata and files if you create the
> >> repository locally.
> >>
> >> Now that you have the repository that contains everything you need to
> >> build create a settings.xml with a mirror pointing to a file-based
> >> repository. You shouldn’t need to build in offline mode but using a
> >> file-base repository in your mirror will effectively be the same. This
> way
> >> you will not be subject to every Maven plugins potentially flaking
> >> handling of offline mode.
> >
> > Good idea, thanks! And with a mirror setup to file:/// (except for that
> > file-based remote repo) we can even verify that no offline access is
> > required.
> >
> > Cheers,
> > Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> To think is easy. To act is hard. But the hardest thing in the world is to
> act in accordance with your thinking.
>
>  -- Johann von Goethe
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Offline builds nearly impossible

[Paul Benedict]

Jason's suggestion is what I have attempted in the past. You want to mirror
your remote repository using file:/// pointing to your disk copy. Then you
don't have to be offline. However, this is NOT your local repo! You still
need that. Don't confuse the two even if both are on your machine.


Cheers,
Paul

On Fri, Nov 13, 2015 at 1:36 PM, Ron Wheeler <rwhee...@artifact-software.com
> wrote:

> I certainly would defer to your expertise.
>
> Ron
>
> On 13/11/2015 2:33 PM, Jason van Zyl wrote:
>
>> In this case they would not be better and far less convenient. For a
>> hermetically sealed build at any rate. The local repository cache cleared
>> of the tracking files serves as a perfectly fine remote repository for this
>> use case. Most escrow bundles carry all the tools and sources required to
>> build the product: packaging a repository manager would probably be a bit
>> much.
>>
>> On Nov 13, 2015, at 2:09 PM, Ron Wheeler <rwhee...@artifact-software.com>
>>> wrote:
>>>
>>>
>>> Not sure if the extra work would be worthwhile when you have a number of
>>> free repo packages that are better in many ways than the maven cache and
>>> can be installed on Windows or Linux.
>>>
>>>
>>> Ron
>>>
>>> On 13/11/2015 12:44 PM, cody.a.fy...@wellsfargo.com wrote:
>>>
>>>> I just wanted to weigh in.
>>>>
>>>> This indeed does not function in what I would call an "intuitive" way.
>>>>
>>>> It would be really nice if offline mode meant just provide the switch
>>>> and everything used your local repo. No extra configuration or trickery
>>>> required.
>>>>
>>>> I know in modern times, the idea of always being connected is the norm,
>>>> but if you KNOW you don't need any updates and you have a lot of deps, this
>>>> could speed up the build a bit. Especially if you are forced to use a 3G
>>>> connection for a build on an emergency basis in your job.
>>>>
>>>> Then again, it would also be nice if Santa Claus were real.
>>>>
>>>> When will Apache have their open source Santa project? ;)
>>>>
>>>> Cody Fyler
>>>> Lending Grid Build Team
>>>> G=Lending Grid Builds
>>>> (515) – 441 - 0814
>>>>
>>>> -Original Message-
>>>> From: Paul Benedict [mailto:pbened...@apache.org]
>>>> Sent: Friday, November 13, 2015 11:27 AM
>>>> To: Maven Users List <users@maven.apache.org>
>>>> Cc: joerg.schai...@gmx.de
>>>> Subject: Re: Offline builds nearly impossible
>>>>
>>>> I think most people, at least once in their life, try to use their
>>>> local repository cache as an offline remote repository. However, the two
>>>> aren't the same in concept though, IIRC, the last time I tried. You still
>>>> need to keep the two separate.
>>>>
>>>> Now it would be interesting if a tool existed to copy the contents of a
>>>> local repository and scrub its local metadata. That would then give you a
>>>> true "remote offline repo".
>>>>
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>> On Fri, Nov 13, 2015 at 11:17 AM, Jason van Zyl <ja...@takari.io>
>>>> wrote:
>>>>
>>>> If this does not work please let me know. This is what I’ve used in
>>>>> the past and if it doesn’t work I agree it needs to be fixed. I
>>>>> honestly haven’t tried making a hermetically sealed build in a few
>>>>> years but last year worked on a project that did no network traversal
>>>>> aside from using file-based repositories and it all worked fine.
>>>>>
>>>>> On Nov 13, 2015, at 11:33 AM, Jörg Schaible <joerg.schai...@gmx.de>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi Jason,
>>>>>>
>>>>>> Jason van Zyl wrote:
>>>>>>
>>>>>> Use a file based remote repository instead of trying to build in
>>>>>>> offline mode.
>>>>>>>
>>>>>>> You can either use a repository manager to create the remote
>>>>>>> repository
>>>>>>>
>>>>>> or
>>>>>
>>>>>> an empty local repository with a full build. As noted though, you
>>>>>>> have
>>>>>

Re: build error on strutsel

[Paul Benedict]

Agreed. There's no point in using Struts-EL anymore. There was a time, as
David said, when EL was a tag-only solution. But since JSP 2.0, the servlet
container understands EL natively so every tag can use EL.


Cheers,
Paul

On Fri, Jul 24, 2015 at 4:20 PM, David Karr davidmichaelk...@gmail.com
wrote:

 One thing I should mention about your use of the Struts-EL library (which
 I wrote, like, 15 years ago). It was a stopgap solution to somewhat
 integrate Struts with JSP expressions, but only in JSP 1.2 containers.  If
 you use it in a JSP 2.0 or newer container, you'll likely get confusing
 results.  It should only be used in a JSP1.2 container.

 On Fri, Jul 24, 2015 at 2:14 PM Curtis Rueden ctrue...@wisc.edu wrote:

  Hi Hector,
 
  Maybe you are depending on the wrong version of those libraries? API
 change
  and evolve; you have to depend on a version compatible with what was
  originally coded against.
 
  -Curtis
 
  On Fri, Jul 24, 2015 at 3:04 PM, Magnanao, Hector 
 hector.magna...@sap.com
  
  wrote:
 
   Hi Curtis,
  
   I have these remaining errors on my compilation.  I can't figure out if
   this is code or package errors.  Can you help me out ?
  
   [ERROR] COMPILATION ERROR :
   [INFO] -
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[351,53]
   cannot find symbol
 symbol:   method getName()
 location: class foundation.web.taglib.struts.html.FormTagEl
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[352,18]
   cannot find symbol
 symbol: method setName(java.lang.String)
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[360,54]
   cannot find symbol
 symbol:   method getScope()
 location: class foundation.web.taglib.struts.html.FormTagEl
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[361,18]
   cannot find symbol
 symbol: method setScope(java.lang.String)
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[375,53]
   cannot find symbol
 symbol:   method getType()
 location: class foundation.web.taglib.struts.html.FormTagEl
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[376,18]
   cannot find symbol
 symbol: method setType(java.lang.String)
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,23]
   cannot find symbol
 symbol:   class License
 location: package aspose.pdf
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,59]
   cannot find symbol
 symbol:   class License
 location: package aspose.pdf
   [INFO] 8 errors
  
   -Original Message-
   From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
 Behalf
   Of Curtis Rueden
   Sent: Friday, July 24, 2015 1:13 PM
   To: Maven Users List
   Subject: Re: build error on strutsel
  
   Hi Hector,
  
package com.aspose.cells does not exist
  
   Looks like Aspose.Cells is in its own Maven repo from that company:
  
  
  
 
 http://www.aspose.com/blogs/aspose-products/aspose-total-product-family/archive/2014/08/12/aspose-for-maven-aspose-cloud-maven-repository.html
  
   Found by searching Google for com.aspose.cells maven
  
   Repeat these tricks for all packages you need to find.
  
   -Curtis
  
   On Fri, Jul 24, 2015 at 12:39 PM, Magnanao, Hector 
   hector.magna...@sap.com
   wrote:
  
Hi Curtis,  that’s ok, I got past that error.  Now I get this one.
   
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project foundation: Compilation failure:
  Compilation
failure:
[ERROR]
   
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[3,24]
package com.aspose.cells does not exist
   
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
  Behalf
Of Curtis Rueden
Sent: Friday, July 24, 2015 12:35 PM
To: Maven Users List
Subject: Re: build error on strutsel
   
Hi Hector,
   
 I clicked on the link and it returns nothing.
 How do I search for it in the repository ?
   
That's baffling. I see this:
   
[Inline image 1]
   
I have no clue why it would be different for you...
   
Regards,
Curtis
   
On Fri, Jul 24, 2015 at 12:31 PM, Magnanao, Hector 
hector.magna...@sap.commailto:hector.magna...@sap.com wrote:
Hi Curtis,
   
I clicked on the link and it returns nothing.  How do I search for it
  in
the repository ?
   
-Original Message-
From: ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com
 

Re: fixing an almost Maven project

[Paul Benedict]

It sounds like both your projects are snapshots. So when you build
B-SNAPSHOT you have no idea what's inside of A-SNAPSHOT. If this is
bothersome to you, you can think about releasing milestone versions of A so
that B-SNAPSHOT always has a known/reliable codebase to work with. Perhaps
you want weekly snapshots to be released, for example, but you definitely
want to lock down A's version for B.


Cheers,
Paul

On Thu, Jul 23, 2015 at 9:30 PM, V. Mark Lehky mark.le...@gmail.com wrote:

 Hello.

 I have taken it upon myself to fix our Maven project. :)

 Our current situation is that we have about dozen child projects, all tied
 together with one parent pom. Everything lives in git (Bitbucket) and is
 build by Jenkins. There are several (ugly?) python scripts that package and
 deploy the finished product. Further some of the tests need to be build
 into a jar and run from command line.

 Specifically there are two projects, projectB is dependent on
 projectA, and both of these have a lot of activity right now. The team
 decided to create one branch in git for work on projectA and a separate
 branch for work on projectB; let us call them branchA and branchB.
 Jenkins builds both of these branches with 'mvn clean install'.
 Subsequently tests are run separately with 'mvn -f projectB/pom.xml test'.
 The problem is: during test, I do not know which jars I am getting from
 the local m2 repo. Occasionally branchA is build and jars are pushed to the
 local repo. Then branchB test phase runs, but grabs jars from the local
 repo (branchA) which have different code.

 Would appreciate some advice how to move forward so as to minimize or
 outright eliminate grabbing the wrong jars from the local repo during the
 test phase.

 TIA for any advice.

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

Re: Maven Goes to Mars

[Paul Benedict]

The pun also works in regards to Eclipse 4.5 which is also named Mars.


Cheers,
Paul

On Sat, Mar 28, 2015 at 8:15 PM, Martin Gainty mgai...@hotmail.com wrote:

 http://www.nasa.gov/mission_pages/maven/main/
 was wondering why it took so long to get a response ..(know I know why)

 Maven is the first Interplanetary Build System

 Martin
 __

Exception overlaying zip in war

[Paul Benedict]

I configured the WAR plugin to overlay a zip file. Nothing fancy. Here's
the config:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-war-plugin/artifactId
  version2.5/version
  configuration
overlays
  groupIdorg.company/groupId
  artifactIdui/artifactId
  typezip/type
/overlays
  /configuration
/plugin

I get an exception:
java.lang.ClassCastException: java.lang.String cannot be
cast to org.apache.maven.plugin.war.Overlay
at
org.apache.maven.plugin.war.overlay.OverlayManager.initialize(OverlayManager.java:122)

I looked at the WAR source. I don't know how a String is making it into the
ListOverlay collection. Any WAR developers here?

Cheers,
Paul

Re: Exception overlaying zip in war

[Paul Benedict]

Yup. I copied/pasted and didn't even see the error I made. Thanks for
pointing that out, Stuart!

PS: Still sounds like a bug :-) It should not have seen any overlays -- but
it was coerced to a String unexpectedly.


Cheers,
Paul

On Mon, Dec 8, 2014 at 12:07 PM, Stuart McCulloch mccu...@gmail.com wrote:

 On Monday, 8 December 2014 at 16:24, Paul Benedict wrote:
  I configured the WAR plugin to overlay a zip file. Nothing fancy. Here's
  the config:
 
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-war-plugin/artifactId
  version2.5/version
  configuration
  overlays
  groupIdorg.company/groupId
 
 

 ^ missing overlay ... /overlay ?
  artifactIdui/artifactId
  typezip/type
  /overlays
  /configuration
  /plugin
 
  I get an exception:
  java.lang.ClassCastException: java.lang.String cannot be
  cast to org.apache.maven.plugin.war.Overlay
  at
 
 org.apache.maven.plugin.war.overlay.OverlayManager.initialize(OverlayManager.java:122)
 
  I looked at the WAR source. I don't know how a String is making it into
 the
  ListOverlay collection. Any WAR developers here?
 
  Cheers,
  Paul
 
 

Re: [DISCUSS] In the event of adopting the owl as project mascot, what will we call it?

[Paul Benedict]

I really don't think we need to name the owl, do we? Are we just naming it
for fun or is there a reason we want to?


Cheers,
Paul

On Tue, Nov 25, 2014 at 1:23 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Tuesday, November 25, 2014, Jeroen Hoek jer...@lable.org wrote:

  I would recommend leaving it without a name.


 I think that the name Pandora's box is already open, I suspect in the
 absence of a concrete alternative, shotgun will be the name


  The mascot can help in
  providing Maven with a stronger visual identity, but I'm not convinced
  naming it is helpful.
 
  On the contrary, it might come across as 'silly' or 'unprofessional',
  which for me goes against the nature of Maven: a mature tool many use
  as one of the steps towards stabilizing and professionalizing their
  code base.
 
  Why not call it simply 'The Maven Owl'?


 Ok, we'll add that suggestion into the pot.


 
  Kind regards,
 
  Jeroen Hoek
  Lable
 
  2014-11-25 12:05 GMT+01:00 Stephen Connolly 
  stephen.alan.conno...@gmail.com javascript:;:
  
 
 http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-large.png
  
   When I created this owl, I gave it the name Couché Tard which is a
  french
   nickname for an owl (literal translation: Sleeps Late)
  
   Early versions of this owl have ended up with the nickname Shotgun
 Owl
   due to the belly feathers being white in the initial versions, which
 some
   people thought made it look like it had been shot.
  
   Some people feel that we shouldn't name a mascot...
  
   As creator of the graphic, I could force the issue... but I would much
   rather if the community has a name that the community wants.
  
   Please provide your suggestions in this thread. If the owl is adopted
 as
  a
   mascot, we will have a second vote thread to confirm its name.
  
   I personally recommend a gender neutral name.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 javascript:;
  For additional commands, e-mail: users-h...@maven.apache.org
  javascript:;
 
 

 --
 Sent from my phone

Re: Enforcing annotations

[Paul Benedict]

I think you will find it easier to add a temporary Spring bean (during
development) that scans your beans/annotations to report what you want:
http://stackoverflow.com/questions/259140/scanning-java-annotations-at-runtime


Cheers,
Paul

On Mon, Nov 24, 2014 at 9:01 PM, Niranjan Rao nhr...@gmail.com wrote:

 Since this was not a maven question directly, I tried posting this at
 stackoverflow first at https://stackoverflow.com/
 questions/27068654/how-to-enforce-verify-spring-scope-
 annotation-on-spring-beans. Did not get much traction.

 We do use spring and its dependency injection mechanism using annotations
 only. No XML files for spring.  However the trouble starts when developers
 start mixing beans of different scopes - most of the time by accident. Many
 developers forget that beans are singleton in scope by default and end up
 creating beans (or services) that has state. They are happy because if it
 works on their machine but creates interesting mix/match of data when more
 than one user logs in to the application.

 Right now, I am thinking of simple solution - enforce that every spring
 component needs to have scope annotation also. Thought behind this is it
 will force developer to think about the scope by explicitly declaring the
 value.

 Are there any plugins that can do this? If not, can I extend maven
 enforcer plugin or findbugs in anyway to do this? Open to any other
 suggestions also.

 Regards,

 Niranjan

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

Re: i cannot add to my jar the xml files (help me please)

[Paul Benedict]

Get your XML and XSLT files out of src/main/java -- and you're filtering
that directory too. Put them in src/main/resources


Cheers,
Paul

On Sat, Nov 22, 2014 at 11:47 AM, Aitor Iturriondobeitia 
laudio.i...@gmail.com wrote:

 hello
 i have one problem and i am working two days an o dont solve it
 y have into may app (jar) several xml fiels into one dir.
 when i install the the project, the jar file doesn't constains the xml
 files. can you help me please?
 the files are into src/main/java/es.midomain/ernesto/security/templates ans
 are xml files

 my pom is this:
 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
 http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
 http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
   modelVersion4.0.0/modelVersion
   artifactIdClasses/artifactId
   nameClasses/name
   descriptionclasess/description
 build
 filters

 filter${maven.filters.generic.path}/Filters.properties/filter
 /filters
 resources
 resource
 directory${basedir}/directory
 filteringfalse/filtering
 includes
 includemyfiles/**/*.*/include
 /includes
 /resource
 resource
 directorysrc/main/java//directory
 filteringtrue/filtering
 includes
 include**/*.xml/include
 include**/*.xslt/include
 /includes
 /resource
 /resources
 plugins
 plugin
 artifactIdmaven-compiler-plugin/artifactId
 version3.1/version
 configuration
 source${jdk.compilation.version}/source
 target${jdk.compilation.version}/target
 encoding${charSetEnconding}/encoding
 /configuration
 /plugin
 plugin
 artifactIdmaven-resources-plugin/artifactId
 version2.6/version
 executions
 execution
 idcopy-resources/id
 phasevalidate/phase
 goals
 goalcopy-resources/goal
 /goals
 configuration

 outputDirectory${basedir}/config/outputDirectory
 resources
 resource

 directory${basedir}/configTemplates/directory
 filteringtrue/filtering
 /resource
 /resources
 /configuration
 /execution
 execution
 idcopy-resources/id
 phasevalidate/phase
 goals
 goalcopy-resources/goal
 /goals
 configuration
 outputDirectorytarget/outputDirectory
 resources
 resource
 directory${basedir}/src/main/java/directory
 filteringfalse/filtering
 excludes
 exclude**/*.java/exclude
 /excludes
 /resource
 /resources
 /configuration
 /execution
 /executions
 /plugin
 /plugins
 pluginManagement
 plugins
 plugin
 groupIdorg.eclipse.m2e/groupId
 artifactIdlifecycle-mapping/artifactId
 version1.0.0/version
 configuration
 lifecycleMappingMetadata
 pluginExecutions
 pluginExecution
 pluginExecutionFilter

 groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-dependency-plugin/artifactId

 versionRange[1.0.0,)/versionRange
 goals
 goalcopy-dependencies/goal
 /goals
 /pluginExecutionFilter
 action
 ignore /
 /action
 /pluginExecution
 /pluginExecutions
 /lifecycleMappingMetadata
 /configuration
 /plugin
 /plugins
 /pluginManagement
 /build
 dependencies
 dependency
 groupIdpostgresql/groupId
 artifactIdpostgresql/artifactId
 version9.1-901.jdbc4/version
 /dependency
 dependency
 groupIdcommons-lang/groupId
 artifactIdcommons-lang/artifactId
 version2.6/version
 /dependency
 dependency
 groupIdcommons-codec/groupId
 artifactIdcommons-codec/artifactId
 version1.5/version
 /dependency
 dependency
 groupIdjavax.ejb/groupId
 artifactIdejb-api/artifactId
 version3.0/version
 /dependency
 dependency
 groupIdjavax.transaction/groupId
 artifactIdjta/artifactId
 version1.1/version
 /dependency
 /dependencies
 /project

Re: [DISCUSS] Adopt Mr Couché-Tard as our mascot, change the logo font to Alte Haas Grotesk, change the colour letter to v

[Paul Benedict]

I found the shotgun owl to be pretty funny and unique. Part of choosing a
trademark is uniqueness and that is more valuable than something standard.
I think the white belly should return for that return.


Cheers,
Paul

On Thu, Nov 20, 2014 at 8:41 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 For Ron!

 http://people.apache.org/~stephenc/maven-logo-contest/ron.png

 (note quick and dirty using a shotgun.svg from the interwebs)

 On 20 November 2014 14:00, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  Add the shotgun and the slogan Resistance is futile.
  If you have trouble with the shotgun, perhaps a dead mouse in the claws
  might foster the right mindset.:-)
 
  Ron
 
 
  On 20/11/2014 7:51 AM, Stephen Connolly wrote:
 
  On 20 November 2014 12:05, Kristian Rosenvold 
  kristian.rosenv...@gmail.com
  wrote:
 
   Might be careful with the name; http://corpo.couche-tard.com/en/
 
  But shotgun owl will probably stick :)
 
   See if we call him shotgun owl I'll have to draw a shotgun so that we
  can
  use him for threats...
 
  I see you are not following the Maven way... be careful, or Shotgun Owl
  will be after you
 
  ;-)
 
  OTOH if people really object to Couché-Tard we can just call him
  Sleeps-Late instead... but I am sure there is probably an insult in
 some
  language or other if we go with Sleeps-Late!
 
  Note: I am not sure my [skills of an artist][1] are up to drawing a
  shotgun.
 
 [1]: https://www.youtube.com/watch?v=7gz1DIIxmEE
 
 
   I like it a lot :)
 
  K
 
 
  2014-11-20 11:49 GMT+01:00 Stephen Connolly 
  stephen.alan.conno...@gmail.com:
 
  The closest thing to a mascot that we have is
 
  http://maven.apache.org/images/maven-logo-2.gif
  Arse on desk behind laptop while waiting for Maven to finish
  downloading
  the interwebs
 
  I would like to call a vote in a couple of days to adopt M.
 Couché-Tard
 
  (my
 
  own creation) as our mascot
 
 
   http://people.apache.org/~stephenc/maven-logo-contest/
  maven-owl-5-large.png
 
  M. Couché-Tard
 
  In addition I am suggesting that we change the logo font to Alte Haas
  Grotesk Bold with italic applied by Inkscape
 
  I am also suggesting that we change the emphasis colour letter to the
 
  v...
 
  as in version... and we all know that Maven helps manage versions of
  things... versions are very important to Maven.
 
  The emphasis colour would be #cc to match the scarf worn by M.
  Couché-Tard
 
  My proposal would be to make these changes as a single vote, i.e. not
 
  three
 
  separate votes, the vote would be for all these changes in one go...
 in
  order to avoid design by committee.
 
  Having said that, community is more important than a new logo or even
  having a mascot, so hence this discuss thread before actually calling
 a
  vote.
 
  This is something that not just the developers of Maven should have a
  say
  in... if we have a mascot and a refreshed logo we can use these as aid
  to
  help drive a site refresh that makes Maven easier to understand for
  newcomers and helps existing users find what they are looking for
 easier
  and faster.
 
  For anyone not following the dev list, here is my reasons for picking
  M.
  Couché-Tard as a mascot...
 
  The definition of a maven is an expert or connoisseur... in the
  context
  of Apache Maven, the idea is that Maven knows the conventions for
 
  different
 
  types of software projects and is an expert in applying those
 
  conventions.
 
  M. Couché-Tard is a wise fellow, sleeping-in while he waits for the
  interwebs to finish downloading... he may look cute but if crossed or
 
  used
 
  incorrectly he will bite a chunk off your hand... but do right by him
  and
  he will do right by you.
 
  So WDYT? should I just call the vote already or do people want to
 think
 
  it
 
  over a bit more!
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
  --
  Ron Wheeler
  President
  Artifact Software Inc
  email: rwhee...@artifact-software.com
  skype: ronaldmwheeler
  phone: 866-970-2435, ext 102
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: explicit dependencies in maven

[Paul Benedict]

Your pom.xml should declare all dependency versions explicitly. And to
prevent any changes, do not use any snapshots. Furthermore, use
dependency:analyze on your project to make sure all libraries in use are
explicitly declared. After you lock them all down, tell your developers not
to update the pom.xml file. That will ensure it.


Cheers,
Paul

On Mon, Nov 3, 2014 at 10:33 PM, Irfan Sayed irfu.sa...@gmail.com wrote:

 hello,

 is there any good doc/blog which describes the handling of explicit
 declaration of dependencies.
 when we build the code, we use certain dependencies , how we can make sure
 that when we reproduce the same build after the gap of 6 months , same and
 exact dependencies will be used. ???
 i know we can have artifactory/nexus , but that does not guarantee the
 exact version of dependency when developer changes the code and make it
 public keeping the version same

 please suggest

 regards

Re: Don't want to repeat plugin version for both build and reporting

[Paul Benedict]

So, shouldn't the misleading warning be fixed? Sounds like something for
3.2.4 -- unless the warning is issued in the site plugin itself.


Cheers,
Paul

On Sat, Oct 4, 2014 at 2:15 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 that used to be true with Maven 2, but is not any more since Maven 3 and
 its
 m-site-p 3.0 version

 Notice that Maven 3.0.x issues a misleading warning about missing version
 in
 reporting section: see MNG-5477

 with m-site-p 3.4, even configuration content from pluginManagement is
 injected
 to reporting: see MSITE-516/MSHARED-338 and little note in
 http://maven.apache.org/shared/maven-reporting-exec/

 Regards,

 Hervé

 Le vendredi 3 octobre 2014 12:46:21 Paul Benedict a écrit :
  pluginManagement only affects plugins -- it does not affect
 reporting:
  https://jira.codehaus.org/browse/MNG-3385
 
  Cheers,
  Paul
 
  On Thu, Oct 2, 2014 at 9:06 PM, Maxim Solodovnik solomax...@gmail.com
 
  wrote:
   we using pluginManagement for this
  
   On 3 October 2014 07:24, Kathryn Huxtable kath...@kathrynhuxtable.org
 
  
   wrote:
I’ve always used properties, but would it work to use
buildDependencies? -K
   
On Oct 2, 2014, at 7:02 PM, Paul Benedict pbened...@apache.org
 wrote:
 I use the maven-javadoc-plugin in both build and reporting. I
 don't
 want to fall back to properties to share the plugin version. Is
  
   there a
  
 better way than using properties?

 Cheers,
 Paul
   
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
  
   --
   WBR
   Maxim aka solomax


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

Re: Don't want to repeat plugin version for both build and reporting

[Paul Benedict]

pluginManagement only affects plugins -- it does not affect reporting:
https://jira.codehaus.org/browse/MNG-3385

Cheers,
Paul

On Thu, Oct 2, 2014 at 9:06 PM, Maxim Solodovnik solomax...@gmail.com
wrote:

 we using pluginManagement for this

 On 3 October 2014 07:24, Kathryn Huxtable kath...@kathrynhuxtable.org
 wrote:

  I’ve always used properties, but would it work to use
  buildDependencies? -K
 
  On Oct 2, 2014, at 7:02 PM, Paul Benedict pbened...@apache.org wrote:
 
   I use the maven-javadoc-plugin in both build and reporting. I don't
   want to fall back to properties to share the plugin version. Is
 there a
   better way than using properties?
  
   Cheers,
   Paul
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 


 --
 WBR
 Maxim aka solomax

Don't want to repeat plugin version for both build and reporting

[Paul Benedict]

I use the maven-javadoc-plugin in both build and reporting. I don't
want to fall back to properties to share the plugin version. Is there a
better way than using properties?

Cheers,
Paul

Re: Maven, Dependencies and Vulnerabilities

[Paul Benedict]

There is a Maven Changes Plugin which projects can use to list out changes
to their project.
http://maven.apache.org/plugins/maven-changes-plugin/

Regarding CVE, Redhat has a Maven plugin to find victim dependencies:
https://securityblog.redhat.com/2013/01/02/detecting-vulnerable-java-dependencies-at-build-time/

Paul


Cheers,
Paul

On Tue, Sep 30, 2014 at 1:44 PM, David Dillard ddill...@symantec.com
wrote:

 Hi,

 I've been working on an internal presentation on how letting Maven's
 dependency mediation feature select versions of transitive dependencies can
 introduce vulnerabilities into a product and how to deal with that
 problem.  Unfortunately, it's a very manual process and I was thinking that
 perhaps changes could be made to Maven that would provide better
 automation.  To that end I'm wondering if the team has ever considered
 adding a section to the POM that would list significant changes in that
 release.  This would include a list of vulnerabilities fixed (e.g.
 CVE--) or serious bugs fixed.  Each one could include a known set
 of versions affected (ala how CVEs work today) thus allowing tooling to
 say: the version of artifact XYZ you're using has a known vulnerability,
 would you like to upgrade to this new version with that vuln fixed?

 On a related note, has a different dependency mediation system ever been
 considered (as an option), e.g. latest version or latest version on a
 branch?


 Thanks,

 David

Re: MD5 checksum validation tool [Windows]?

[Paul Benedict]

Yup. I've used HashTab for years.
http://www.implbits.com/hashtab.aspx


Cheers,
Paul


On Mon, Aug 4, 2014 at 11:16 AM, Justin Georgeson jgeorge...@lgc.com
wrote:

 All the checksum validation tools I've found only seem to support files
 with format produced by the md5sum tool, ie -

 checksum1 relative/path/file1
 checksum2 relative/path/to/file2
 ...

 But Maven publishes sibling files of the same name with .md5 appended,
 and no relative path in the file. Does anyone know of a tool on Windows
 (shell extension, standalone GUI) that people could use after downloading
 the artifact (in this particular case it's an executable installer) and the
 md5 file and just double-click the md5 file to validate the download (or
 drag/drop the artifact and md5 file)?

 --
 This e-mail, including any attached files, may contain confidential and
 privileged information for the sole use of the intended recipient.  Any
 review, use, distribution, or disclosure by others is strictly prohibited.
  If you are not the intended recipient (or authorized to receive
 information for the intended recipient), please contact the sender by reply
 e-mail and delete all copies of this message.

Re: Re: Re: Why not a forum

[Paul Benedict]

The apache mailing list is ran by Apache for legal reasons (e.g., proof of
release votes). Regardless, no one on this mailing list has the authority
to change the infrastructure. I am surprised this discussion keeps going.


Cheers,
Paul


On Tue, Jul 29, 2014 at 3:29 PM, Preston, Dale 
dale.pres...@conocophillips.com wrote:

 While I continue to feel the well-meant, I am sure, chastising for my
 sacrilegious proposal, and understand the view of most here, and in-spite
 of my own preference for forums, I can accept that the mailing list makes
 the most sense for this group.  But, never would I recommend FaceBook or
 Twitter.  I don't have accounts on either and I don't have any knowledge of
 how to use them or just barely what they do.

 Unfortunately, I do have a Linked-In account so their forum can help me,
 too.

 Dale

 -Original Message-
 From: Andrew Todd [mailto:andrew.todd...@gmail.com]
 Sent: Friday, July 25, 2014 9:26 AM
 To: Maven Users List
 Subject: [EXTERNAL]Re: Re: Why not a forum

 Apache is an independent non-profit dedicated to the dissemination of free
 software. The list archives are freely archivable and indexable by anyone
 who wants to -- and there are many sites, such as Nabble and MarkMail, who
 do. Using email as the primary means of distribution makes it easy for
 third parties to do this.

 On the other hand, LinkedIn is a for-profit corporation with a walled
 garden solution. It's free because it forces people to tie themselves
 into LinkedIn's system. It can't be easily archived or indexed without
 LinkedIn's permission. And if they decide to end the service, we're in
 trouble.

 There are people like me who will not even create a LinkedIn profile on
 principle. I don't like the company's business practices.

 In short, the suggestion is anathema to a free software organization. You
 might as well tell us to use Facebook as a discussion medium.


 On Wed, Jul 23, 2014 at 5:48 PM, Preston, Dale 
 dale.pres...@conocophillips.com wrote:

  I do participate in a couple other Linked-In lists.  I'll check that
  one out.  As the response to this thread shows, though, replies come
  pretty quickly in the email list.  In any case, the Linked-In list
  sounds worth investigating.
 
  Thanks.
 
 
  -Original Message-
  From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
  Sent: Wednesday, July 23, 2014 8:23 AM
  To: users@maven.apache.org
  Subject: [EXTERNAL]Re: Why not a forum
 
  On 23/07/2014 9:03 AM, Mark H. Wood wrote:
   On Tue, Jul 22, 2014 at 03:51:54PM +, Preston, Dale wrote:
   I was just wondering why this group uses an email list rather than
   a
  forum.  It seems forum software is more searchable and filterable than
  email lists.
   If it had been my choice:  because I'd have to go to a forum every
   day (and a hundred others!) while email comes to me.  I have plenty
   of powerful email search and filter tools right here on my workstation.
  
   Every time someone proposes some other medium for this sort of
   communication (forum, Twitter, etc.) my first question is how can I
   get that in email?  I can't think offhand of any forum software
   I've used that isn't uncomfortable, inconvenient and hard to search.
  
  The Maven LinkedIn forum will send you e-mails plus LinkedIn will
  inform you of activity in discussions in which you are active in all
  of the groups to which you belong.
 
  Ron
 
  --
  Ron Wheeler
  President
  Artifact Software Inc
  email: rwhee...@artifact-software.com
  skype: ronaldmwheeler
  phone: 866-970-2435, ext 102
 
 
  -
  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: Why not a forum

[Paul Benedict]

I agree with the guy who said bikeshed -- this is a bikeshed discussion.
But more than that, no one in this mailing list has authority to setup new
infrastructure and move lists to different technology. It really is a moot
point and nothing will change.


Cheers,
Paul


On Wed, Jul 23, 2014 at 8:23 AM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 On 23/07/2014 9:03 AM, Mark H. Wood wrote:

 On Tue, Jul 22, 2014 at 03:51:54PM +, Preston, Dale wrote:

 I was just wondering why this group uses an email list rather than a
 forum.  It seems forum software is more searchable and filterable than
 email lists.

 If it had been my choice:  because I'd have to go to a forum every day
 (and a hundred others!) while email comes to me.  I have plenty of
 powerful email search and filter tools right here on my workstation.

 Every time someone proposes some other medium for this sort of
 communication (forum, Twitter, etc.) my first question is how can I
 get that in email?  I can't think offhand of any forum software I've
 used that isn't uncomfortable, inconvenient and hard to search.

  The Maven LinkedIn forum will send you e-mails plus LinkedIn will inform
 you of activity in discussions in which you are active in all of the groups
 to which you belong.

 Ron


 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102


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

Re: Why not a forum

[Paul Benedict]

I think because Apache is a non-profit is cost should be minimal --
including cost of time by system administrators. If you want to search and
filter, you have Google and other search engines.


Cheers,
Paul


On Tue, Jul 22, 2014 at 10:51 AM, Preston, Dale 
dale.pres...@conocophillips.com wrote:

 I was just wondering why this group uses an email list rather than a
 forum.  It seems forum software is more searchable and filterable than
 email lists.

 Thanks,

 Dale

Re: Javadoc aggregate NullPointerException

[Paul Benedict]

I did a google search for the answer. This says Eclipse defers to Oracle's
javadoc.exe tool:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-export-javadoc.htm

So Eclipse must be configuring the tool in a way that doesn't trigger the
NPE. The NPE from javadoc.exe is obviously a bug regardless.


Cheers,
Paul


On Thu, Jul 10, 2014 at 1:16 PM, Alexddupree alexddup...@gmail.com wrote:

 Hey Paul
 I have tried 1.6 and 1.7 we haven't set up 1.8 yet so I haven't tried it. I
 can however generate javadoc in Eclipse for the same project. Does Eclipse
 use its own version of javadoc?
 Sorry if this is a newbie question I am an intern and trying to get up to
 speed.

 -Alex



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Javadoc-aggregate-NullPointerException-tp5799844p5799891.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: Javadoc aggregate NullPointerException

[Paul Benedict]

The NPE is in the javadoc compiler not Maven. You could submit the stack
trace to Oracle or do some research to determine if upgrading your JDK
fixes this problem.
On Jul 9, 2014 6:12 PM, Alexddupree alexddup...@gmail.com wrote:

 I am trying to create an aggregate javadoc for a multi module project. The
 project compiles with mvn install -DskipTests (I am not running tests on my
 machine). When I run mvn validate javadoc:javadoc it works and compiles all
 of the javadoc in each modules \target\apidocs directory. Then when I run
 either mvn validate javadoc:javadoc javadoc:aggregate or mvn validate
 javadoc:aggregate fails partway through with about 1200 lines of errors.
 Some examples of types are:

 Failed to execute goal
 org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:aggregate (default-cli)
 on project commons-superpom: An error has occurred in JavaDocs report
 generation:
 [ERROR] Exit code: 1 - C:\workspaces\win\tfs\\Foo.java:21: type
 org.springframework.context.ApplicationListener does not take parameters
 [ERROR] public class Foo implements ApplicationContextAware,
 ApplicationListenerContextRefreshedEvent {
 [ERROR] ^
 .
 .
 .
 C:\workspaces\win\tfs\\test\Bar.java:52: cannot find symbol
 [ERROR] symbol  : class PostInsertEvent
 [ERROR] location: class com.Barclass
 [ERROR] public void BarFunct(PostInsertEvent event) {
 [ERROR] ^
 [ERROR] C:java.lang.NullPointerException
 [ERROR] at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67)
 [ERROR] at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29)
 [ERROR] at
 com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:439)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:386)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:424)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.util.ClassTree.processType(ClassTree.java:162)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.util.ClassTree.buildTree(ClassTree.java:114)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.util.ClassTree.init(ClassTree.java:73)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:104)
 [ERROR] at

 com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64)
 [ERROR] at
 com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42)
 [ERROR] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23)
 [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [ERROR] at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 [ERROR] at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 [ERROR] at java.lang.reflect.Method.invoke(Method.java:597)
 [ERROR] at
 com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269)
 [ERROR] at
 com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143)
 [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
 [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:128)
 [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:41)
 [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:31)
 After it crashes all that is left in the /target directory next to my
 parent
 pom.xml is 2 files 1 is javadoc-bundle-options which contains an xml file:

 ?xml version=1.0 encoding=UTF-8?
 javadocOptions
   docletArtifacts
 docletArtifact /
   /docletArtifacts
   tagletArtifacts
 tagletArtifact /
   /tagletArtifacts
   excludePackageNames
 excludePackageNameorg.foobar.*/excludePackageName
   /excludePackageNames
   javadocResourcesDirectorysrc/main/javadoc/javadocResourcesDirectory
 /javadocOptions
 and the second is site which contains a file called apidocs which contains
 3
 files javadoc.bat, options, and packages. They contain what they appear to
 contain a batch script to run the javadoc.exe with those options and on
 those packages. When run without modification the javadoc.bat file fails
 with the same errors though slightly different output.

 The first error I copied is straight up wrong. ApplicationListener is
 parameterized and can take ContextRefreshedEvent per the spring
 documentation. PostInsertEvent is correctly imported as well in the second
 error.

 My plugin configuration for javadoc:aggregate is as follows:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version${maven-javadoc-plugin.version}/version
 executions
 execution
 idattach-javadocs/id
 goals
 goalaggregate/goal
 /goals
 /execution
 /executions
 configuration

 excludePackageNamesorg.hibernate.*;org.spring.*/excludePackageNames
 verbosetrue/verbose
 forktrue/fork
 

Re: Controlling order of plugin execution

[Paul Benedict]

I, myself, have also found the lack of ordered plugin execution to be
wanting. Stephen does have a point: complex behavior is likely be better
encapsulated in a new plugin. I don't disagree, but that route can be steep
and I don't want to be detoured into always writing a new plugin. Many
times such behavior can be emulated simply by aggregating the use of
plugins in an ordered fashion. For example, one plugin executes a SQL
script to setup a database, the next plugin executes a Java program to
populate the database according to logic. I've tried that before and can't
because such plugin ordering doesn't exist. So if there is an easy way to
bring this minor enhancement to the Maven community, in 3.x, I think we
should.


Cheers,
Paul


On Wed, Jun 4, 2014 at 3:08 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 We are not a cult.
 If we already have a we, we are half way there!
 Just short a charismatic leader and a Book of the Way.

 Ron

 On 04/06/2014 3:22 PM, Jason van Zyl wrote:

 On Jun 4, 2014, at 12:07 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  That's usually a sign that you have wandered off The Maven Way™

  No it's not. They have valid points and the implementation is deficient
 in this regard. Everything that's presently here is not immutable. Calling
 it The Maven Way doesn't make it usable or without flaws. I'm not even
 sure where this saying came from but we're not a cult.

  There are ways back onto the blessed path... they typically involve
 writing
 a plugin

  Thanks,

 Jason

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

 I never make the mistake of arguing with people for whose opinions I have
 no respect.

 -- Edward Gibbon












 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102


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

Re: Controlling order of plugin execution

[Paul Benedict]

I don't think this existed when I first tried with Maven (my example was
from many moons ago), but this is another tool in my toolbox now. Thank
you! :-)


Cheers,
Paul


On Wed, Jun 4, 2014 at 3:19 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Wednesday, 4 June 2014, Paul Benedict pbened...@apache.org wrote:

  I, myself, have also found the lack of ordered plugin execution to be
  wanting. Stephen does have a point: complex behavior is likely be better
  encapsulated in a new plugin. I don't disagree, but that route can be
 steep
  and I don't want to be detoured into always writing a new plugin. Many
  times such behavior can be emulated simply by aggregating the use of
  plugins in an ordered fashion. For example, one plugin executes a SQL
  script to setup a database, the next plugin executes a Java program to
  populate the database according to logic.


 Ahem  http://flywaydb.org

 I've tried that before and can't
  because such plugin ordering doesn't exist. So if there is an easy way to
  bring this minor enhancement to the Maven community, in 3.x, I think we
  should.
 
 
  Cheers,
  Paul
 
 
  On Wed, Jun 4, 2014 at 3:08 PM, Ron Wheeler 
  rwhee...@artifact-software.com javascript:;
  wrote:
 
   We are not a cult.
   If we already have a we, we are half way there!
   Just short a charismatic leader and a Book of the Way.
  
   Ron
  
   On 04/06/2014 3:22 PM, Jason van Zyl wrote:
  
   On Jun 4, 2014, at 12:07 PM, Stephen Connolly 
   stephen.alan.conno...@gmail.com javascript:; wrote:
  
That's usually a sign that you have wandered off The Maven Way™
  
No it's not. They have valid points and the implementation is
  deficient
   in this regard. Everything that's presently here is not immutable.
  Calling
   it The Maven Way doesn't make it usable or without flaws. I'm not
 even
   sure where this saying came from but we're not a cult.
  
There are ways back onto the blessed path... they typically involve
   writing
   a plugin
  
Thanks,
  
   Jason
  
   --
   Jason van Zyl
   Founder,  Apache Maven
   http://twitter.com/jvanzyl
   http://twitter.com/takari_io
   -
  
   I never make the mistake of arguing with people for whose opinions I
  have
   no respect.
  
   -- Edward Gibbon
  
  
  
  
  
  
  
  
  
  
  
  
   --
   Ron Wheeler
   President
   Artifact Software Inc
   email: rwhee...@artifact-software.com javascript:;
   skype: ronaldmwheeler
   phone: 866-970-2435, ext 102
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  javascript:;
   For additional commands, e-mail: users-h...@maven.apache.org
  javascript:;
  
  
 


 --
 Sent from my phone

Re: Controlling order of plugin execution

[Paul Benedict]

Jim, I reopened the issue for you, but, please note, this was closed
because the issue was created 6 years ago and no one ever submitted a
patch. Hopefully, someone has the incentive to work on this or it will be
closed again. If you find this feature critical to your own work, do you
have time to take a detour and submit a patch?


Cheers,
Paul


On Tue, Jun 3, 2014 at 2:48 PM, Jim Garrison jim.garri...@nwea.org wrote:

 I'm trying to set up a Maven build for CI/CD, and one of the requirements
 for testing is to create, populate and tweak a database schema.

 This involves interleaving various executions of maven-dependency-plugin,
 sql-maven-plugin and exec-maven-plugin, and there aren't enough lifecycle
 phases *-test-[re]sources to accommodate all the steps.

 I'd like to bind six executions as follows:

 1 maven-dependency-plugin:unpack - generate-test-resources
 2 sql-maven-plugin:execute   - generate-test-resources
 3 sql-maven-plugin:execute   - generate-test-resources
 4 exec-maven-plugin:exec - process-test-resources
 5 exec-maven-plugin:exec - process-test-resources
 6 sql-maven-plugin:execute   - process-test-resources

 But this doesn't work as Maven wants to execute sql-maven-plugin (steps 2
  3) before step 1 and I can't find a way to make it do things in the
 desired sequence.

 There's a bug in Jira for this http://jira.codehaus.org/browse/MNG-3522
 but it was closed as part of the great Jira cleanup of 2014.

 This has been an issue for several years but seems to get no attention.  I
 don't think I should be required to write my own plugin to do what should
 be a common requirement.

 Can someone explain if there's an approved way to accomplish this?

 I know Maven is supposed to be declarative in nature, but sequencing steps
 seems like a basic requirement.  From the lack of attention, and from
 reading other posts in places like StackOverflow, it appears there may be a
 philosophical objection to explicitly ordering executions.  Can someone
 explain the reasoning for this?

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

Re: Controlling order of plugin execution

[Paul Benedict]

I agree with Dan. Last I check, IIRC, the order of operations of plugins is
defined by their sequential order in the POM. However, I also find this a
bit problematic with inheritance -- I don't know off the top of my head
what happens then.


Cheers,
Paul


On Tue, Jun 3, 2014 at 3:01 PM, Dan Tran dant...@gmail.com wrote:

 Agree sequencing is a pain.  You may be able to get this working if you
 move your sql plugin delaration below exec-m-p

 -D


 On Tue, Jun 3, 2014 at 12:54 PM, Paul Benedict pbened...@apache.org
 wrote:

  Jim, I reopened the issue for you, but, please note, this was closed
  because the issue was created 6 years ago and no one ever submitted a
  patch. Hopefully, someone has the incentive to work on this or it will be
  closed again. If you find this feature critical to your own work, do you
  have time to take a detour and submit a patch?
 
 
  Cheers,
  Paul
 
 
  On Tue, Jun 3, 2014 at 2:48 PM, Jim Garrison jim.garri...@nwea.org
  wrote:
 
   I'm trying to set up a Maven build for CI/CD, and one of the
 requirements
   for testing is to create, populate and tweak a database schema.
  
   This involves interleaving various executions of
 maven-dependency-plugin,
   sql-maven-plugin and exec-maven-plugin, and there aren't enough
 lifecycle
   phases *-test-[re]sources to accommodate all the steps.
  
   I'd like to bind six executions as follows:
  
   1 maven-dependency-plugin:unpack - generate-test-resources
   2 sql-maven-plugin:execute   - generate-test-resources
   3 sql-maven-plugin:execute   - generate-test-resources
   4 exec-maven-plugin:exec - process-test-resources
   5 exec-maven-plugin:exec - process-test-resources
   6 sql-maven-plugin:execute   - process-test-resources
  
   But this doesn't work as Maven wants to execute sql-maven-plugin
 (steps 2
3) before step 1 and I can't find a way to make it do things in the
   desired sequence.
  
   There's a bug in Jira for this
 http://jira.codehaus.org/browse/MNG-3522
   but it was closed as part of the great Jira cleanup of 2014.
  
   This has been an issue for several years but seems to get no attention.
   I
   don't think I should be required to write my own plugin to do what
 should
   be a common requirement.
  
   Can someone explain if there's an approved way to accomplish this?
  
   I know Maven is supposed to be declarative in nature, but sequencing
  steps
   seems like a basic requirement.  From the lack of attention, and from
   reading other posts in places like StackOverflow, it appears there may
  be a
   philosophical objection to explicitly ordering executions.  Can someone
   explain the reasoning for this?
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 

Re: Unmanaged dependency question

[Paul Benedict]

I don't think you should make a project for your sql jar. My guess is when
you build+install that, you're creating an empty and useless jar file and
overwriting the good one you already placed in your local repo. The
mvn:install:install-file thing works and is what I would expect as the
answer.


Cheers,
Paul


On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman mwhite...@purelandsupply.com
 wrote:

 Hi,



 This has probably been answered before, but I haven't been able to find the
 answer and I'm hoping someone knows.



 I'm writing several apps that talk to a Microsoft SQL database, so I'm
 using
 the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
 available on Maven, I've downloaded it, and I'm trying to make it an
 unmanaged dependency in its own standalone project so that I can simply
 reference it in other projects' pom files without having to deploy the jar
 to each one individually.



 I've followed the instructions for deploying an unmanaged dependency. As I
 am the only developer at my company (at this time), I do not have a
 separate
 Maven server setup. I was hoping to simply deploy the dependency and then
 run 'maven install' so that it copies everything needed into my .m2 folder.
 This is my directory setup:



 (This is the project directory for the sqljdbc4 unmanaged dependency)

 C:\dev\Github-repos\addons\sqljdbc4

   +- pom.xml

   +-src

   +-repo



 I followed the instructions to use mvn deploy on the local sqljdbc4.jar
 file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
 com.microsoft.sqlserver. After deployment, the repo directory does appear
 to
 be correctly populated:



 C:\dev\Github-repos\addons\sqljdbc4

   +- pom.xml

   +-src

   +-repo

+-com

+-microsoft

   +-sqlserver

+-sqljdbc4

 +-maven-metadata

 +-4.0

   +-sqljdbc4-4.0.jar

   +-sqljdbc4-4.0.pom



 Next, following the instructions, I go back into the pom.xml file and add
 the repository tag, so my pom.xml for this now looks like:



 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
 
 http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0
 .
 xsd 

   modelVersion4.0.0/modelVersion

   groupIdcom.microsoft.sqlserver/groupId

   artifactIdsqljdbc4/artifactId

   version4.0/version



 repositories

 !--other repositories if any--

 repository

 idproject.local/id

 nameproject/name

 urlfile:${project.basedir}/repo/url

 /repository

 /repositories

 /project





 Now, here is the problem. Since I want to use this as a dependency in other
 projects, I am trying to run 'maven install' so that it will push
 everything
 into my .m2 directory. The maven build is a success. However, the resulting
 sqljdbc4.jar file in the target directory and up in the m2 directory is
 only
 2kb (whereas the original jar file is 571kb, none of the content made it
 in). As a result, projects that use this as a dependency build, but then
 throw a ClassNotFoundException at runtime, because the classes aren't
 there.



 I am building a separate project that uses this as a dependency:



 C:\dev\Github-repos\applications\myapp



 The pom.xml for this project uses the dependency correctly:

 dependency

 groupIdcom.microsoft.sqlserver/groupId

 artifactIdsqljdbc4/artifactId

 version4.0/version

 /dependency



 I'm even using the maven assembly plugin to ensure a jar is built with all
 dependencies packaged in:



 plugin


 artifactIdmaven-assembly-plugin/artifactId

   configuration

 descriptorRefs


 descriptorRefjar-with-dependencies/descriptorRef

 /descriptorRefs

 archive

   manifest

 addClasspathtrue/addClasspath


 mainClassproductfeeds.main.ProductFeedDriver/mainClass

   /manifest

 /archive

   /configuration

 executions

   execution

 phasepackage/phase

 goals

   goalsingle/goal

 /goals

   /execution

 /executions

 /plugin





 Any ideas what I'm doing wrong? I'm sure it's something really simple I've
 overlooked. If I don't make this a standalone dependency, and simply use
 'mvn install:install-file -Dfile=sqljdbc4.jar
 -DgroupId=com.microsoft.sqlserver 

Re: Unmanaged dependency question

[Paul Benedict]

I understand but you can't achieve this using a project to represent a
pre-existing jar. Your attempt won't work. The install-file command is
the correct solution; that is how you get it into your local repo without
downloading it from a remote repo.
On May 30, 2014 4:36 PM, Matt Whiteman mwhite...@purelandsupply.com
wrote:

 Hi Curtis,

 I'll take a look at that, thanks! Ideally, I'll eventually be able to have
 an
 internal Maven repository
 so that I can do everything right. What I had been trying to do in the
 meantime
 is having it set up
 so that when we set up a new development station, the user can simply
 clone the
 Github repo that
 has these dependency projects and just do 'mvn install' on each one, then
 build
 or develop the
 standalone app(s). Kinda  crude I know, but we're basically just starting a
 software development
 department, so have to work  with what's available in the short-term. If it
 doesn't work, I can just
 keep a batch script with the jar  that runs the mvn:install I suppose.

 Yup Paul, that's exactly what was happening. The jar file deployed into a
 local
 repo within the
 project directory, and put a reference pom file up in the .m2 directory.
 But as
 soon as I
 ran 'mvn install', it built an empty jar file and put that up in the .m2
 instead. I just wanted to try to
 have it in a separate project so that from the user's perspective, it
 would be
 as close as possible
 to what the process would be  if we had an actual internal maven repo.

 Thanks for the suggestions everyone!

 Matt

 On May 30, 2014 at 4:49 PM Curtis Rueden ctrue...@wisc.edu wrote:
  Hi Matt,
 
  Have you seen this article?
 
 http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
 
  If you cannot deploy the Microsoft JARs to your own internal Maven
  repository, then you could try the non-maven-jar-plugin approach. It is
  strongly recommended over the basedir repository hack approach that you
  are using (presumably from
  https://devcenter.heroku.com/articles/local-maven-dependencies).
 
  Regards,
  Curtis
 
 
  On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman 
 mwhite...@purelandsupply.com
   wrote:
 
   Hi,
  
  
  
   This has probably been answered before, but I haven't been able to
 find the
   answer and I'm hoping someone knows.
  
  
  
   I'm writing several apps that talk to a Microsoft SQL database, so I'm
   using
   the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
   available on Maven, I've downloaded it, and I'm trying to make it an
   unmanaged dependency in its own standalone project so that I can simply
   reference it in other projects' pom files without having to deploy the
 jar
   to each one individually.
  
  
  
   I've followed the instructions for deploying an unmanaged dependency.
 As I
   am the only developer at my company (at this time), I do not have a
   separate
   Maven server setup. I was hoping to simply deploy the dependency and
 then
   run 'maven install' so that it copies everything needed into my .m2
 folder.
   This is my directory setup:
  
  
  
   (This is the project directory for the sqljdbc4 unmanaged dependency)
  
   C:\dev\Github-repos\addons\sqljdbc4
  
   +- pom.xml
  
   +-src
  
   +-repo
  
  
  
   I followed the instructions to use mvn deploy on the local sqljdbc4.jar
   file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
   com.microsoft.sqlserver. After deployment, the repo directory does
 appear
   to
   be correctly populated:
  
  
  
   C:\dev\Github-repos\addons\sqljdbc4
  
   +- pom.xml
  
   +-src
  
   +-repo
  
   +-com
  
   +-microsoft
  
   +-sqlserver
  
   +-sqljdbc4
  
   +-maven-metadata
  
   +-4.0
  
   +-sqljdbc4-4.0.jar
  
   +-sqljdbc4-4.0.pom
  
  
  
   Next, following the instructions, I go back into the pom.xml file and
 add
   the repository tag, so my pom.xml for this now looks like:
  
  
  
   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
   
  
 http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0
   .
   xsd 
  
   modelVersion4.0.0/modelVersion
  
   groupIdcom.microsoft.sqlserver/groupId
  
   artifactIdsqljdbc4/artifactId
  
   version4.0/version
  
  
  
   repositories
  
   !--other repositories if any--
  
   repository
  
   idproject.local/id
  
   nameproject/name
  
   urlfile:${project.basedir}/repo/url
  
   /repository
  
   /repositories
  
   /project
  
  
  
  
  
   Now, here is the problem. Since I want to use this as a dependency in
 other
   projects, I am trying to run 'maven install' so that it will push
   everything
   into my .m2 directory. The maven build is a success. However, the
 resulting
   sqljdbc4.jar file in the target directory and up in the m2 directory is
   only
   2kb (whereas the original jar file is 571kb, none of the content 

Re: How to avoid checking parent project in maven-site-plugin

[Paul Benedict]

If worst comes to worst, modify the POM. It's your local repository. You
can do whatever you want to those files. Perhaps you should start by
removing the parent's pom parent.

Of course, this will be a routine to repeat when you get the vendor's
latest POM.


Cheers,
Paul


On Thu, May 15, 2014 at 3:31 AM, Dariusz Jurojć dariusz.jur...@daprog.plwrote:

 Sure, i have software vendor's poms in my local repository. But I can't
 modify them (mostly because vendor releases new version of poms, so I will
 have to change every version of their pom - it doesn't have any sense). And
 I can't force vendor to add site configuration to their poms. So I have to
 do it in my pom. And I tried various methods and in every one of them maven
 tried to download site configuration from parent pom. And I'm trying to
 avoid this.



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/How-to-avoid-checking-parent-project-in-maven-site-plugin-tp5792945p5793085.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: Sharing of values across dependant projects?

[Paul Benedict]

SNAPSHOTS are built for this use case. As long as B is in SNAPSHOT mode, A
can continue pulling the latest.


Cheers,
Paul


On Fri, May 9, 2014 at 9:02 AM, James Green james.mk.gr...@gmail.comwrote:

 I have two projects - A and B. B depends on A.

 A is built with a number (call it a build number). B needs to which number
 is in A at the time B builds.

 Any ideas how to achieve this without any human intervention?

 FWIW the use case here is that A is software distributed by B (a WAR
 archive). A queries B for an updated build number, thus implementing
 automatic updates. I'm trying to automate the setting of this number
 across the two projects but I've drawn a blank inside Jenkins for the
 moment.

 James

Re: What's a good plugin to translate markdown content?

[Paul Benedict]

Curtis, yes, the site plugin contains the support for the markdown content
but only if you're doing a site. There's no straightforward way (or anyway
that I know of) to take advantage of doxia as part of a project's build
(not the site build).


Cheers,
Paul


On Fri, May 16, 2014 at 7:24 AM, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi Paul,

  I am looking for a plugin that can generate HTML from markdown document.

 You could write your own plugin that uses Markdownj. Or easier: a groovy
 script that does so with groovy-maven-plugin bound to the desired Maven
 goal. [1]

 Otherwise, Doxia already supports Markdown so maven-site-plugin could work,
 couldn't it?

 -Curtis

 [1] We use this to code generate sources using velocity:
 https://github.com/imagej/imagej-ops/blob/imagej-ops-0.3.0/pom.xml

  On May 16, 2014 3:26 AM, Paul Benedict pbened...@apache.org wrote:

  I am looking for a plugin that can generate HTML from markdown document.
  This is not about using the site goal but static pages for a site. Anyone
  been using something like this?
 
  Cheers,
  Paul
 

Re: How to avoid checking parent project in maven-site-plugin

[Paul Benedict]

You need to have the parent projects available to you in your remote or
local repository. You can't build with them missing because the parent has
configuration which you project (the child) depends upon.
On May 14, 2014 12:48 AM, Dariusz Jurojć dariusz.jur...@daprog.pl wrote:

 I can't do it - as I said - I'm only writing extension to very big project
 which is not mine. And I have to use pom from that big project. And that
 pom has it's own parent and so on... I can't copy and modify all of them. I
 just want to create site with some reports for my project regardless of
 parent project.



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/How-to-avoid-checking-parent-project-in-maven-site-plugin-tp5792945p5793019.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

What's a good plugin to translate markdown content?

[Paul Benedict]

I am looking for a plugin that can generate HTML from markdown document.
This is not about using the site goal but static pages for a site. Anyone
been using something like this?

Cheers,
Paul

Problem with filtering web resources

[Paul Benedict]

I am trying to filter my jboss-web.xml but am having problems. For sure,
the file is getting processed because ${project.version} is substituted
just fine, but any of my custom properties are not. It doesn't seem that
the war plugin is paying attention to my list of filters.

build
  filters
filtersrc/main/filters/dev.properties/filter
   /filters
   plugins
 plugin
   artifactIdmaven-war-plugin/artifactId
   configuration
webResources
  resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
includejboss-web.xml/include
targetPathWEB-INF/targetPath
  /resource
.
/build

What's missing/wrong in my config?

-- 
Cheers,
Paul

Re: Problem with filtering web resources

[Paul Benedict]

I think my problem is regarding these open issues:

http://jira.codehaus.org/browse/MWAR-301
http://jira.codehaus.org/browse/MWAR-305

I did a debug dump of my build and noticed that my filters are definitely
not being included in the list of available properties.

Unless someone else can give advice on how to make this work (does anyone
else here filter web resources?), I'll simply have to use the normal
resources tag and target the output at WEB-INF.

Paul



On Thu, Apr 24, 2014 at 1:37 PM, Paul Benedict pbened...@apache.org wrote:

 I am trying to filter my jboss-web.xml but am having problems. For sure,
 the file is getting processed because ${project.version} is substituted
 just fine, but any of my custom properties are not. It doesn't seem that
 the war plugin is paying attention to my list of filters.

 build
   filters
 filtersrc/main/filters/dev.properties/filter
/filters
plugins
  plugin
artifactIdmaven-war-plugin/artifactId
configuration
 webResources
   resource
 directorysrc/main/webapp/WEB-INF/directory
 filteringtrue/filtering
 includejboss-web.xml/include
 targetPathWEB-INF/targetPath
   /resource
 .
 /build

 What's missing/wrong in my config?

 --
 Cheers,
 Paul




-- 
Cheers,
Paul

Re: Problem with filtering web resources

[Paul Benedict]

OK, I solved this. I've seen others on the web who complained of similar
issues -- and the JIRA tickets may be related -- but here's the answer for
posterity:

The filters/filter tags need to be in the configuration of the
maven-war-plugin and NOT your build. The former is for your web
resources; the latter for your normal resources. That's not obvious if your
glancing through many examples but that's how you solve this.

Example:
build
   plugins
 plugin
   artifactIdmaven-war-plugin/artifactId
   configuration
 filters
   filtersrc/main/filters/dev.properties/filter
/filters
webResources
  resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
includejboss-web.xml/include
targetPathWEB-INF/targetPath
  /resource
.
/build

Cheers,
Paul


On Thu, Apr 24, 2014 at 2:17 PM, Paul Benedict pbened...@apache.org wrote:

 I think my problem is regarding these open issues:

 http://jira.codehaus.org/browse/MWAR-301
 http://jira.codehaus.org/browse/MWAR-305

 I did a debug dump of my build and noticed that my filters are
 definitely not being included in the list of available properties.

 Unless someone else can give advice on how to make this work (does anyone
 else here filter web resources?), I'll simply have to use the normal
 resources tag and target the output at WEB-INF.

 Paul



 On Thu, Apr 24, 2014 at 1:37 PM, Paul Benedict pbened...@apache.orgwrote:

 I am trying to filter my jboss-web.xml but am having problems. For sure,
 the file is getting processed because ${project.version} is substituted
 just fine, but any of my custom properties are not. It doesn't seem that
 the war plugin is paying attention to my list of filters.

 build
   filters
 filtersrc/main/filters/dev.properties/filter
/filters
plugins
  plugin
artifactIdmaven-war-plugin/artifactId
configuration
 webResources
   resource
 directorysrc/main/webapp/WEB-INF/directory
 filteringtrue/filtering
 includejboss-web.xml/include
 targetPathWEB-INF/targetPath
   /resource
 .
 /build

 What's missing/wrong in my config?

 --
 Cheers,
 Paul




 --
 Cheers,
 Paul




-- 
Cheers,
Paul

Trouble downloading a dependency

[Paul Benedict]

Output from Maven...
Downloading:
http://repo1.maven.org/maven2/org/jboss/spec/javax/ejb/jboss-ejb-api_3.2_spec/1.0.0.Final/jboss-ejb-api_3.2_spec-1.0.0.Final.pom

...and then this error:
connect: Address is invalid on local machine, or port is not valid on
remote machine

I don't understand the error. If I paste the URL into my browser, the POM
exists. I even turned off my antivirus/firewall to make sure nothing was
blocking Java -- and still the same result.

Any clues what could be causing this?

-- 
Cheers,
Paul

Re: Why is dependency:analyze lying to me?

[Paul Benedict]

Especially if you use Spring XML configuration, it's impossible for the
Dependency Plugin to figure out you need this-or-that Spring jar. The best
you can do, actually, is use the new Spring Java Config so that your
configuration is code and thus able to be statically analyzed.


On Thu, Feb 13, 2014 at 3:54 PM, laredotornado-3 laredotorn...@gmail.comwrote:

 Hi,

 This may fall into the How the hell is Maven supposed to know? category,
 but one of the dependencies that dependency:analyze lists when I run it on
 my WAR project is

 [WARNING] Unused declared dependencies found:
 ...
 [WARNING]

 org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile

 However, when I comment this out of my pom, a few of my JSPs die with the
 error

 org.apache.jasper.JasperException: The absolute uri:
 http://www.springframework.org/security/tags cannot be resolved in either
 web.xml or the jar files deployed with this application


 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)


 org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)


 org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)

 because the JSP includes this

 %@ taglib prefix=sec
 uri=http://www.springframework.org/security/tags%

 Anyway, not sure if the plugin can be configured to detect these kind of
 things, but a guy can dream, can't he??



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Why-is-dependency-analyze-lying-to-me-tp5784108p5784691.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




-- 
Cheers,
Paul

Re: Code coverage with debug logs: 100% branch coverage not possible?...

[Paul Benedict]

IIRC, there should be an option in Emma/Cobertura that allows you to
exclude coverage on certain classes. So if you can exclude your log4j
classes (you don't really want to test your logging, do you?), then you
should be able to raise your percentage.


On Wed, Feb 12, 2014 at 2:30 PM, Benoît Berthonneau
ben...@berthonneau.comwrote:

 Hi all,



 I need your opinion/way to tackle the following problem:

 In many projects we use a Logger (doesn't matter which implementation). It
 is often recommend to test if the debug level is activated before logging a
 debug trace like the following:

 if (logger.isDebugEnabled()) {

 logger.debug(blah  + i +  in the loop that contains  + max);

 }



 Now when you run unit tests on this kind of code you need to make a choice:
 run tests with INFO level or run tests with ALL traces activated. I choose
 the second option in order to:

 * Check that debug traces doesn't throw unwanted exception (like
 NPE)

 * Have a better code coverage in term of covered lines



 But in term of branches coverage we could never have a 100% :(



 To me the only way to cover this is to run the tests suite 2 times: one
 with
 INFO traces configured, and another one with ALL traces activated.

 Did you face this issue and how did you solve it ?



 Thanks,

 Benoît.




-- 
Cheers,
Paul

Re: Why is dependency:analyze lying to me?

[Paul Benedict]

I am so happy someone brought this up. I actually hit this issue several
times but never got around to mentioning it. Please submit a JIRA issue!


On Tue, Feb 11, 2014 at 3:41 PM, Barrie Treloar baerr...@gmail.com wrote:

 On 12 February 2014 07:41, laredotornado-3 laredotorn...@gmail.com
 wrote:
  Hi,
 
  I'm using Maven 3.1.1 on Mac 10.9.1.  When I ran mvn
 dependency:analyze on
  my project, I got results that included:
 
  [WARNING] Unused declared dependencies found:
  ...
  [WARNING]junit:junit:jar:4.11:test
 
  So I commented out the above junit dependency in my pom (declared like
 so):
 [del]
  java.lang.NoSuchFieldError: NULL
  at
 org.junit.runners.ParentRunner.init(ParentRunner.java:48)
  at
 
 org.junit.runners.BlockJUnit4ClassRunner.init(BlockJUnit4ClassRunner.java:58)
  at
 
 org.springframework.test.context.junit4.SpringJUnit4ClassRunner.init(SpringJUnit4ClassRunner.java:104)
 
  This isn't the only dependency that the analyze goal lists that wreaks
 havoc
  when I comment it out.  Is there another way to detect what dependencies
 are
  truly not needed by my project?

 Unfortunately this stuff is not documented well enough in the plugin.
 You're welcome to submit a patch!

 Have a look at
 http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#unused

 I think Maven is missing a scope, it needs to break up test into two
 phases; testCompile and testRuntime instead of having one scope which
 means both.
 This means that the analyze code can't tell what stuff is needed for
 tests at compile time and what is needed at runtime.

 If my memory serves me right, that would mean for your example that
 Spring is a compile time dependency but junit would be a runtime
 dependency.
 Hence the incorrect Unused declared dependencies found error.

 I would manually ignore anything found in the test scope from the error
 list.
 I never found the time to go hacking the plugin to work better - i.e.
 if it is test scope it really can't tell the difference between unused
 dependencies and shouldn't report them.

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




-- 
Cheers,
Paul

Re: New logo?

[Paul Benedict]

Love this logo. Very awesome.


On Tue, Jan 14, 2014 at 9:51 AM, Mark H. Wood mw...@iupui.edu wrote:

 On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
  Putting maven-20 in context, you get:
 
 
 http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png

 *Very* nice work, but...what does this Native Americans theme have to do
 with maven?  Yes, I know, but people *will* ask.  Especially since
 the answer has no connection with what Maven would do for them.

 Unless I'm mistaken, the Maven landing page exists to sell Maven, not
 the Apache Software Foundation.  A link to the Foundation's landing
 page is quite appropriate and should be easy to find, but that's not
 why people come to this page.  They come because they've heard
 something about Maven and want to know more, or Google gave them a
 link when they asked something about software project management or
 build tools, or because some other project had a built with Maven
 link on its page and they're curious.  They'll probably be best
 pleased if, at a glance, they can get some notion of what Maven does.

 Possibly that message simply isn't very visual, and the best one can
 do is to select a (formerly) meaningless but unique mascot or abstract
 symbol.  Possibly there is an image that will make people think, yes!
 that is Maven in action.

 I'm really not that sort of visual thinker, but images of structure,
 assembly, or gathering seem appropriate.  The best(?) I've been able
 to imagine is a funnel with classes falling in and a package falling
 out.  Or perhaps an assembly line.  (What do classes look like? beats
 me.)  Maybe you can do something with the Reactor:  skinny pipes bring
 things in, one big pipe lets the product out.

 --
 Mark H. Wood, Lead System Programmer   mw...@iupui.edu
 Machines should not be friendly.  Machines should be obedient.




-- 
Cheers,
Paul

Re: New logo?

[Paul Benedict]

Great logo, but yes, an orange hat too similar to red hat. If we're using
an Apache feather, maybe we can use a Cowboy hat to complete the theme?


On Mon, Jan 13, 2014 at 5:22 PM, Adam Retter adam.ret...@googlemail.comwrote:

 My personal fear of the hat, is that it is too similar to Redhat IMHO.


 On 13 January 2014 22:29, John Miller john.w.mil...@oracle.com wrote:

 Well I guess the attachment did not go through..



 [image: Maven Hat..jpg]





 Thanks

 John




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




 --
 Adam Retter

 skype: adam.retter
 tweet: adamretter
 http://www.adamretter.org.uk




-- 
Cheers,
Paul

Re: New logo?

[Paul Benedict]

Good choice. I was hoping someone would find a picture that played off the
expertise definition of the word Maven.


On Thu, Jan 9, 2014 at 10:07 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 The Owl is usually a symbol of wisdom, e.g. the wise owl.

 Maven embodies the collective wisdom of how to build software

 Hence why I did #5


 On 9 January 2014 15:51, Mark H. Wood mw...@iupui.edu wrote:

  On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
   All of the logos are OK, but none of them really symbolize anything in
   particular about Maven. IMO the best logos encapsulate the purpose of
 the
   project somehow, either overtly, covertly or both.
 
  Good point.  I was associating with the name Maven, looking for a
  symbol of in-depth understanding of a specialized field.
 
  http://en.wiktionary.org/wiki/maven
 
  So, what does Maven do?  It passes unique source and object code
  inputs through a standardized process, guided by an expression of the
  relationships among those inputs, to assemble a well-specified
  configuration of runnable code.  What does that look like?
 
  --
  Mark H. Wood, Lead System Programmer   mw...@iupui.edu
  Machines should not be friendly.  Machines should be obedient.
 




-- 
Cheers,
Paul

Re: Skip copying resources

[Paul Benedict]

Your problem is that, I think, you attached the execution to the compile
phase. However, the process-resources phase already happened so you're
not getting the right behavior. Attach to the correct phase.


On Wed, Jan 8, 2014 at 4:05 PM, Kuo, Joncheng (HP Storage - MSDU) 
joncheng@hp.com wrote:

 How do I skip copying resources? I try skip in configuration but it
 does not work.

   plugin
 artifactIdmaven-resources-plugin/artifactId
 executions
   execution
 idcopy-xxx/id
 phasecompile/phase
 goals
   goalcopy-resources/goal
 /goals
 configuration
   skiptrue/skip

 outputDirectory${webapp.dir}/example/resources/outputDirectory
   resources
 resource
   directory${webapp.dir}/resources/directory
   includes
 include**/include
   /includes
 /resource
   /resources
 /configuration
   /execution
 /executions

 Joncheng Kuo




-- 
Cheers,
Paul

Re: New logo?

[Paul Benedict]

My suggestion is for someone in the PMC to pay $29 to
http://www.48hourslogo.com/ and have an extraordinary number of artists
show you their logo ideas. Buy the one you like and then donate it to
Apache.

Paul

Re: Excluding maven pom.xml from generated jar as a security precaution?

[Paul Benedict]

I wouldn't toss-off the idea that providing a POM can't be a security risk.
It *depends* what you are coding and what assets are being protected. True,
there is a bigger problem at hand if someone knowing an internal server is
a security risk, but even if there's no risk today, the risk can be
tomorrow. That's how attackers work: pieces of puzzles at a time. Anyone
trained in security would understanding this perspective. But if your
assets are minimal/worthless, who cares anyway?


On Tue, Nov 19, 2013 at 9:07 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 I used (former employer) use a process akin to shade to publish clean
 poms at an alternative groupId... it was OK but a bit of a pain


 On 19 November 2013 14:47, Benson Margulies bimargul...@gmail.com wrote:

  The security concern here is nonsense, at best it's 'security by
  obscurity'.
 
  However, there's a better reason to clean off the poms that happened
  to us. Our product poms use our internal parent POM, which encodes our
  chosen options for all the plugins we use at build time, and our
  infrastructure (e.g. Sonar). It makes no sense to distribute that POM,
  but without it, our poms don't work. So, our customers _asked us to
  remove our poms_ from the metadata, to make it _easier for them to
  push our jars to their repository manager_.
 
  The ideal solution would be for us to put 'clean' poms in the metadata
  that declared only dependencies and no parent. However, I am unaware
  of any way to get maven to automatically generate such things. Is
  anyone else?
 
 
  On Tue, Nov 19, 2013 at 5:57 AM, Adam Retter adam.ret...@googlemail.com
 
  wrote:
   I would of thought it would be better practice to keep a clean
   separation between your pom.xml and settings.xml where any sensitive
   server information goes in your settings.xml
  
   However, if you are worried that someone knowing a URL to an internal
   server is a security risk, then I would suggest you have bigger
   problems with your security infrastructure.
  
   As a developer, it it fantastically useful to have the pom's available
   even when working with closed (or non-open) source products.
  
   On 19 November 2013 02:16, Paul Benedict pbened...@apache.org wrote:
   My personal opinion for closed-source products is not to include the
   generated POM. If someone somehow stole your proprietary jar, the POM
  might
   help to find out where to steal the rest -- URL locations and custom
   properties, in particular.
  
  
  
  
   On Mon, Nov 18, 2013 at 7:46 PM, Tang Kin Chuen kct...@big2.net
  wrote:
  
   Same here.
  
   Just wondering if it's common practice for close sourced products to
  remove
   maven manifest info from jars... something we cannot search in open
  source
   codes! :-)
  
   I am hoping to get an authoritative reference that says it's OK to
  leave it
   there.
   On Nov 19, 2013 9:40 AM, Adam Retter adam.ret...@googlemail.com
  wrote:
  
I would be interested to know what your peers perceive the security
concerns as being?
   
On 19 November 2013 01:22, Tang Kin Chuen kct...@big2.net wrote:
 Hi guys,

 Are there any security concerns in leaving the default pom
 file(s)
  in
 meta-inf of generated jars for commercial products?

 I find it useful to leave it there for troubleshooting purpose,
   thinking
 that there is not much security concerns but my peers are
 thinking
 otherwise.

 I would like to seek some advise/opinions on this topic.

 Cheers!
   
   
   
--
Adam Retter
   
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
   
   
 -
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
  
  
  
   --
   Cheers,
   Paul
  
  
  
   --
   Adam Retter
  
   skype: adam.retter
   tweet: adamretter
   http://www.adamretter.org.uk
  
   -
   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
 
 




-- 
Cheers,
Paul

Re: Excluding maven pom.xml from generated jar as a security precaution?

[Paul Benedict]

My personal opinion for closed-source products is not to include the
generated POM. If someone somehow stole your proprietary jar, the POM might
help to find out where to steal the rest -- URL locations and custom
properties, in particular.




On Mon, Nov 18, 2013 at 7:46 PM, Tang Kin Chuen kct...@big2.net wrote:

 Same here.

 Just wondering if it's common practice for close sourced products to remove
 maven manifest info from jars... something we cannot search in open source
 codes! :-)

 I am hoping to get an authoritative reference that says it's OK to leave it
 there.
 On Nov 19, 2013 9:40 AM, Adam Retter adam.ret...@googlemail.com wrote:

  I would be interested to know what your peers perceive the security
  concerns as being?
 
  On 19 November 2013 01:22, Tang Kin Chuen kct...@big2.net wrote:
   Hi guys,
  
   Are there any security concerns in leaving the default pom file(s) in
   meta-inf of generated jars for commercial products?
  
   I find it useful to leave it there for troubleshooting purpose,
 thinking
   that there is not much security concerns but my peers are thinking
   otherwise.
  
   I would like to seek some advise/opinions on this topic.
  
   Cheers!
 
 
 
  --
  Adam Retter
 
  skype: adam.retter
  tweet: adamretter
  http://www.adamretter.org.uk
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 




-- 
Cheers,
Paul

Re: Some help needed with maven-enforcer-plugin

[Paul Benedict]

I looked up the ticket that introduced the feature:
http://jira.codehaus.org/browse/MENFORCER-147

It doesn't look like it enforces dependency versions; it enforces that
Maven plugin versions in build match reporting.

Paul



On Tue, Nov 5, 2013 at 10:07 AM, Markward Schubert 
markward.schub...@gmail.com wrote:

 Hi All!

 I am struggling with the enforcer-plugin's requireSameVersions rule.
 Introducing the bannedDependencies rule was successful, but somehow I seem
 to not get the right configuration for requireSameVersion.

 Here is my config:

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-enforcer-plugin/artifactId
 version1.3.1/version
 executions
 execution
 idenforce-banned-dependencies/id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 bannedDependencies

 searchTransitivetrue/searchTransitive
 excludes
 excludecommons-logging/exclude
 /excludes
 /bannedDependencies
 /rules
 failtrue/fail
 /configuration
 /execution
 execution
 idenforce-same-versions/id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 requireSameVersions
 dependencies

 dependencyorg.slf4j:*/dependency
 /dependencies
 /requireSameVersions
 /rules
 failtrue/fail
 /configuration
 /execution
 /executions
 configuration
 ignoreCachetrue/ignoreCache
 /configuration
 /plugin

 As a matter of fact we have

 org.slf4j:slf4j-api:1.7.5

 as well as

 org.slf4j:com.springsource.slf4j.api:1.6.1

 in our dependency tree. But still the build is SUCCESSFUL.
 Did I get anything wrong here? Some misconfiguration.

 I would expect that the rule as configured would enforce all
 org.slf4j-group dependencies to have the same version.

 Thanks for your help!

 Markward




-- 
Cheers,
Paul

Re: Trying to understand how maven finds source

[Paul Benedict]

You are likely not see src/main/java in POMs because that is the default
path. Unless you want to change the source directory, you can omit it
altogether.


On Thu, Oct 24, 2013 at 3:04 PM, Robert Dailey rcdailey.li...@gmail.comwrote:

 Hey everyone,

 I'm trying to understand something basic, I haven't been able to find
 the answer through Google surprisingly (maybe my searching abilities
 suck today). How is it that Maven is able to find source code to
 compile? What I would expect is the pom.xml to refer to some *.java
 path (something like sourcesrc/main/java/*/source), but I don't
 see anything like that.

 How does maven know what java source code to compile? Thanks in
 advance for any help.

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




-- 
Cheers,
Paul

Re: Problem with encrypt-password if password contains

[Paul Benedict]

I never encountered this problem, but I think  is a special token on the
Windows command line. Put a caret in front of it to see if it escapes it
properly: ^


On Thu, Sep 26, 2013 at 9:17 AM, djeanprost 
dominique.jean-pr...@sofaxis.com wrote:

 Hello,

 I'm trying to use maven password encryption feature.
 My problem is that the password I'm trying to encrypt contains the
 charatcter  (ampersand). Because of this, the command line does not work
 ran in Windows cli.

 C:\outillivraison\outillivraison-1.0-beta2mvn --encrypt-password tototiti
 {Crgi2Ua6uJkHCId5ol73dXfwHsoecIEAN+oCl0Ejh50=}
 'titi' n'est pas reconnu en tant que commande interne
 ou externe, un programme exécutable ou un fichier de commandes.

 I tried to add quotes, but I can't manage to to make it work

 C:\outillivraison\outillivraison-1.0-beta2mvn --encrypt-password toto
 {DhN9VJ29e4QHksWV5dh9UrPL5LwrGbv119x9ptOlNpQ=}
 C:\outillivraison\outillivraison-1.0-beta2mvn --encrypt-password toto
 {wAmp4BzifcMH0FjCCnmccIZeCLBI4dGL3eWz07zGomc=} -- not the same value than
 previous one : quotes do not work

 C:\outillivraison\outillivraison-1.0-beta2mvn --encrypt-password 'toto'
 {pv3FYsX7mzMHgHqUpym1TQBcFtnL+TRI7ouyIO1oAag=} -- again, not the same
 value

 Can someone help me please ? Should I fill a jira ?
 Thank you
 Dom



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Problem-with-encrypt-password-if-password-contains-tp5771921.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




-- 
Cheers,
Paul

Re: Problem with encrypt-password if password contains

[Paul Benedict]

Can you try a double ampersand and let me know if that works?


On Thu, Sep 26, 2013 at 9:23 AM, djeanprost 
dominique.jean-pr...@sofaxis.com wrote:

 Doesn't seem to be better :
 C:\outillivraison\outillivraison-1.0-beta2mvn --encrypt-password
 toto^titi
 'titi' n'est pas reconnu en tant que commande interne
 ou externe, un programme exécutable ou un fichier de commandes.
 {fepRzHofytAHYHH2O53qUS3yk/BlA7llKY8gunb2O2o=}




 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Problem-with-encrypt-password-if-password-contains-tp5771921p5771924.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




-- 
Cheers,
Paul

Re: Problem with encrypt-password if password contains

[Paul Benedict]

That's interesting. When I use a double ampersand, Maven looks for my
security-settings.xml correctly so it's finding the program. Without the
double ampersand, it doesn't work.




On Thu, Sep 26, 2013 at 9:32 AM, djeanprost 
dominique.jean-pr...@sofaxis.com wrote:

 with double ampersand, problem is still there
 C:\outillivraison\outillivraison-1.0-beta2mvn --encrypt-password
 tototiti
 {6coO4Ogj1ckH5QYSj8ZymSBzyC1y9WlTdVdPaTYQLLU=}
 'titi' n'est pas reconnu en tant que commande interne
 ou externe, un programme exécutable ou un fichier de commandes.

 dom



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Problem-with-encrypt-password-if-password-contains-tp5771921p5771927.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




-- 
Cheers,
Paul

Re: How to find which maven dependencies are missing?

[Paul Benedict]

You ask a really good question but one that eludes answer.

It seems several experts believe Maven is good at compile dependencies but
not runtime dependencies. If you care to see some of those discussions in
another mailing list, here you go:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2013-September/date.html

I also want a better way to know which runtime dependencies are missing,
but I don't have an answer for that. I typically have to examine a POM and
figure out which optional dependency I need through trial-and-error.

Paul


On Mon, Sep 23, 2013 at 5:20 AM, Krichevskiy Michael 
krichevsky.mich...@nixsolutions.com wrote:

 Hello.

 I have a web project and a pom.xml file. It has enough dependencies to
 compile and package but not enough to start the project. In my IDE it's
 shown that everything is ok, but when a start the application it has
 errors(internal, no matter what kind). When I add external pom.xml from
 another app, my application launches.

 So is there any way I can find out which dependencies are missing and how
 in
 future I can determine which dependencies are needed for using this or
 that?



 Thanks in advance,

 Mike






-- 
Cheers,
Paul

Re: Maven parsing pom.xml incorrectly

[Paul Benedict]

I believe this behavior is correct. IIRC, XML does not allow double-dashes
inside a comment.


On Wed, Sep 18, 2013 at 9:06 AM, Andrew Pennebaker apenneba...@42six.comwrote:

 I'm using Thrift in my Maven project, compiling my .thrift code to .java as
 part of the generate-sources step. To do this, I use the maven antrun
 plugin in my pom.xml, which executes a command line call to the thrift
 executable, and sends it the appropriate argument flags, such as -out and
 --gen.

 However, when I comment out this plugin with the standard XML comment
 syntax !-- ... --, Maven fails to parse the pom file. It doesn't like the
 fact that the comment contains --gen, expecting the comment to end right
 there.

 Can we please improve Maven's comment syntax parsing for pom.xml?




-- 
Cheers,
Paul

How to release:perform without site publishing?

[Paul Benedict]

I am fond of the Release plugin's ability to check out my code, tag, update
the POM, and check it back in. I just don't need any site generation or
publishing to a remote repository.

Is it possible to skip the latter? If not, can I publish to my local
repository without messing up its metadata?

-- 
Cheers,
Paul

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Paul Benedict]

Furthermore, I'd like to see explicit procedural rules on Maven Core and
forking. For example, if there's a critical component needing development
for Core, and a PMC expresses that such development will be done outside of
Apache and then used as a dependency, shouldn't there be a vote on that?


On Fri, Aug 2, 2013 at 10:24 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On 2 August 2013 16:07, Brian Fox bri...@infinity.nu wrote:

  I think the bulk of this is pretty good. On the fork section,
 specifically:
 
  
  As soon as changes in that
  fork are identified which should be brought back to the project those
  changes should be introduced into at least a branch hosted on the Apache
  Maven
  source control in order to facilitate the easier review by the community.
 
  The PMC should encourage by example the early committing of changes from
 a
  fork back to Apache Maven source control.
  
 
  This seems to want to compel code to be brought back as a
  responsibility, I don't think we need to spell that out.


 This is why I say as soon as ... are identified

 The wording could be clearer... if somebody can figure out a better way to
 say it.

 Basically, as soon as you say something like... Oh commit 1a2b3d4e, we
 really need to get that into Maven itself, it's too good to be in our
 fork... you should be trying to hasten getting that commit into Maven
 itself and if you are on the PMC and one of your commits is one that
 you say this of... you should just commit it back.

 Until you realise that a commit is one that you want to push to Maven, hey
 it's your work... whatever... but as soon as you identify the change as
 being one that should be at Maven, as a PMC member you are expected to try
 and get it into Maven quickly so that others working on the fork see that
 this is the example by which the PMC leads.

 If you can think of a clearer way to express that than my wording (which
 since you are not getting my intended meaning must therefore be lacking)
 please update.

 The section
  about the downsides to not doing so and attempting to do it later is
  really the core of the concerns... the extra diligence required to
  consume large bodies of work is bigger. That doesn't mean that code
  contributions are inherently bad just because they were developed
  elsewhere, it's just harder to pull in.
 

 Correct.


 
  On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
  stephen.alan.conno...@gmail.com wrote:
   I have updated the project-roles with my thoughts resulting from the
   healthy debate on the list and some debates elsewhere.
  
   If anyone wants to look at the resulting Work In Progress document as a
   whole:
  
 
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup
  
   Thoughts?
  
   -Stephen
  
   -- Forwarded message --
   From: steph...@apache.org
   Date: 2 August 2013 10:52
   Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
   project-roles.md
   To: comm...@maven.apache.org
  
  
   Author: stephenc
   Date: Fri Aug  2 09:52:11 2013
   New Revision: 1509594
  
   URL: http://svn.apache.org/r1509594
   Log:
   After a lengthy discussion on the users@maven list and some
   side discussions on members@apache, I think the following changes
   are more in line with what we should be seeking as responsibilities
   of the PMC.
  
   * Forks are not bad... letting changes stack up in the fork is bad
 but more from a 'it will be hard to review' point of view...
 similarly using a fork to get external contributions complicates
 the tracablity
  
   * We are not obligated to promote other ASF projects... but there
 should be a symmetry in how that lack of obligation plays out
  
   * I identified some more responsibilities of the PMC (if I have missed
 any, please add)
  
   * There is a special case where the PMC Chair can wear the dictators
 hat... but that is only in the case of unresolvable consensus
 and the lack of consensus is causing damage to the project
 and the board is well aware of the issue and expects the chair
 to put on the dictators hat (with the board watching on)
  
   As always, this is a Commit Then Review community... so these
   changes are being committed for review.
  
   Modified:
   maven/site/trunk/content/markdown/project-roles.md
  
   Modified: maven/site/trunk/content/markdown/project-roles.md
   URL:
  
 
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff
  
 
 ==
   --- maven/site/trunk/content/markdown/project-roles.md (original)
   +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug  2
  09:52:11
   2013
   @@ -174,11 +174,31 @@ are kept confidential.
  
The Project Management Committee has the following responsibilities:
  
   -* Proposing 

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Paul Benedict]

I don't understand the iron hand analogy. I was expressing the use of a
vote to allow or disallow critical development outside of Apache. The vote
would lead to a consensus, no?


On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote:

  Furthermore, I'd like to see explicit procedural rules on Maven Core and
  forking. For example, if there's a critical component needing development
  for Core, and a PMC expresses that such development will be done outside
 of
  Apache and then used as a dependency, shouldn't there be a vote on that?
 

 Votes should be a tool to confirm consensus... not an iron hand.

 If the consensus of the developers is to use the dependency which is
 external to the project, then that is fine. If there is no consensus then
 the dependency will not be introduced.

 We already have a policy that adding Category B dependencies to Core
 requires approval of the PMC, I don't see that there is much value in
 adding even more to this document... but if you can suggest a patch and
 people agree with it...

 -Stephen




-- 
Cheers,
Paul

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Paul Benedict]

I've stated from the beginning of this thread that it's impossible to
prevent someone from developing outside of Apache. I stand by that still.
That can't be prevented and any attempt will fail since it's not practical.

If my words today aren't clear, I'll try again. My stance isn't about
halting developing elsewhere, but to halt what I (and maybe some others)
perceive as a way of getting around the Apache community.

I won't use your ultra whizzbang high performance logging :-) example
because it doesn't fit what my concern; but imagine an existing component
(I won't name any) that is critical and Maven's existence and Maven can't
function without it. It's very easy for any PMC member to go to another OSS
community, develop it, and then kind of leave the other PMCs with no real
choice but to use it because the code realizes the future of Maven. Those
other PMCs are really backed into a corner; they have no real recourse to
preventing this, lest Maven development is simply halted altogether. The
other OSS community has other committers, other mailing lists, other
deliberations, etc. Community work and input becomes marginalized here.

Does this make sense to you? That kind of community-splitting effort needs
to stop and that's what I am trying to address.

Cheers,
Paul



On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 We cannot stop somebody from developing something outside of Apache.

 So I could go off and write a High Performance Logging API... now I could
 be doing that because I want to foist that Logging API on Maven... or I
 could be doing it as an experiment that, if successful, I may offer for
 Maven to consume... or I could be doing it because I need it for my Day
 Job...

 We cannot know the reasons why somebody is doing something outside of
 Maven... we can ask, but we cannot *know* if the answer we are given is
 truthful.

 So anyway, I now have this ultra whizzbang high performance logging API and
 I am aware of some deficit in the logging performance of Maven, so I spin
 up a private fork (it could be a hidden private fork, or it could be a
 public one... doesn't matter) and integrate the logging API and low and
 behold I see a whopping X% improvement... so I want to bring that back to
 Maven...

 Is there anything wrong with the above?

 If the library I created is under a Category A license and open source and
 I go with CTR and nobody vetos my commit... we have consensus... why do we
 need to go all Iron Fist and require a vote?

 We already have established tools: review of commits, vetos on commits,
 mandatory votes for Category B dependencies...

 Do we really need *more* processes and procedures to follow?

 On 2 August 2013 16:51, Paul Benedict pbened...@apache.org wrote:

  I don't understand the iron hand analogy. I was expressing the use of a
  vote to allow or disallow critical development outside of Apache. The
 vote
  would lead to a consensus, no?
 
 
  On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote:
  
Furthermore, I'd like to see explicit procedural rules on Maven Core
  and
forking. For example, if there's a critical component needing
  development
for Core, and a PMC expresses that such development will be done
  outside
   of
Apache and then used as a dependency, shouldn't there be a vote on
  that?
   
  
   Votes should be a tool to confirm consensus... not an iron hand.
  
   If the consensus of the developers is to use the dependency which is
   external to the project, then that is fine. If there is no consensus
 then
   the dependency will not be introduced.
  
   We already have a policy that adding Category B dependencies to Core
   requires approval of the PMC, I don't see that there is much value in
   adding even more to this document... but if you can suggest a patch and
   people agree with it...
  
   -Stephen
  
 
 
 
  --
  Cheers,
  Paul
 




-- 
Cheers,
Paul

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

[Paul Benedict]

Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external contributions. Isn't that the heart of this
debate? A person who solely contributes to Apache and no other OS
organizations has no divided loyalties -- they do all their work here. But
what happens when contributions are here and elsewhere? I ask rhetorically,
to solicit answers, of course... and I see where this is going and what
historical processes within Maven are being addressed.


On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Perhaps we could reframe the question a little then (as people seem to be
 testing hung up on the committed wording)...

 Should the PMC encourage people experimenting on new improvements to Maven
 to do that work at the ASF? And if so, should they then practice what they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or progress
 enough not to cause egg-on-face syndrome)?

 Shoud the PMC promote other Apache projects, or moving non-Apache projects
 to Apache? (Right now, to work on an issue in core and effect the change
 yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
 Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
 fine with half of these at Eclipse and the ther half here... Or maybe
 not... But that is a lot of projects where you need to establish merit and
 perhaps maintain merit just to be able to commit directly (which sometimes
 is the only way to effect the type of cross system changes that some of our
 more obscure bugs may require... GIT makes this less of a requirement, as
 patches on SVN are a PITA, though) )

 These types of questions need resolution as they will, further down the
 road, rise up again and cause wounds... Eg logback vs log4j2 is one that
 simmers at the edge (any time anyone mentioned coloured loggers)

 -Stephen

 On Thursday, 25 July 2013, Paul Benedict wrote:

  I don't think it is possible to force volunteer efforts and/or limit
  development elsewhere. The idea of supporting a project is a vague
 notion.
  I have my opinions too but this language is clearly unenforceable and
  impractical.
 
  Cheers,
  Paul
 
 
  On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:
 
   As a Maven user I think that everybody who is working on a project
 should
   behave the same. Hence, I would say, PMC members should rather
 certainly
   demonstrate how to live the community rules.
  
   -Ursprüngliche Nachricht-
   Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
   Gesendet: Donnerstag, 25. Juli 2013 15:16
   An: Maven Users List; Maven Developers List
   Betreff: [DISCUSS] Should the Maven PMC be an example of how we want
 the
   Maven Community to behave (was Re: svn commit: r1506778 -
   /maven/site/trunk/content/markdown/project-roles.md)
  
   There are two schools of thought amongst the current members of this
   projects PMC.
  
   Without wanting to deliberately tip my hand and reveal where my opinion
   is, we would like to solicit the opinions if the community that we
 serve.
  
   Please give us your thoughts.
  
   The topic is essentially:
  
   Do you want the members of the Maven PMC to be social leaders of the
  Maven
   community, who's actions demonstrate the best community behaviour?
  
   The alternative is that members of the Maven PMC are here purely to
   complete the legal requirements that an Apache TLP has delegated to
 PMCs
  
   This is not black and white... The answer can be grey... And everyone
 is
   human so can make mistakes...
  
   So community, what are you expecting?
  
   - Stephen Connolly
  
   On Thursday, 25 July 2013, wrote:
  
Author: jdcasey
Date: Wed Jul 24 23:21:58 2013
New Revision: 1506778
   
URL: http://svn.apache.org/r1506778
Log:
Adding section on PMC standards of community commitment
   
Modified:
maven/site/trunk/content/markdown/project-roles.md
   
Modified: maven/site/trunk/content/markdown/project-roles.md
URL:
   
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
-roles.md?rev=1506778r1=1506777r2=1506778view=diff
   
   
 ==

--- maven/site/trunk/content/markdown/project-roles.md (original)
+++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
23:21:58 2013
@@ -176,6 +176,29 @@ The Project Management Committee has the
 * Voting on release artifacts.
 * !-- TODO: get the rest of these --
   
+ Standards for Community Commitment
+
+In the spirit of supporting the health of our community, Project
+Management Committee members

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

[Paul Benedict]

Agreed. I'll tip my hand and give my opinion: PMC members should have an
Apache first mentality. They are gatekeepers and guardians of their
project. Spinning off critical code to other OSS organizations should be
frowned upon -- it splits the development and wider community into smaller
pieces.

NB: My original response was just criticism of the commitment wording. It's
nice to say what commitments PMC members should have, but if there's no way
to enforce it, it puts into question why the commitments are even expected.
AFAIK, merit at Apache is forever -- you can't have it undone. If someone
loses their Apache first spirit and begins critical development
elsewhere, what can be done about it? Are there any practical recourses? I
don't think there is which is why Maven development has that problem today.



On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote:

 On 7/25/13 4:17 PM, Paul Benedict wrote:

 Stephen, those are great questions. Yet, I think these questions are
 riding
 an assumption that PMC members are solely volunteering at Apache, because
 the emphasis (as I interpret your words) is to place the Apache project
 first/above other external contributions. Isn't that the heart of this
 debate? A person who solely contributes to Apache and no other OS
 organizations has no divided loyalties -- they do all their work here. But
 what happens when contributions are here and elsewhere? I ask
 rhetorically,
 to solicit answers, of course... and I see where this is going and what
 historical processes within Maven are being addressed.



 I don't think it's about whether you contribute elsewhere or not. It's
 about whether you expect to do a ton of work outside the community here,
 outside the commit logs and the review, in order to avoid the discussion
 and potential for veto.

 Working in this way opens the possibility for changing the rules for who
 gets to contribute, especially when code diverges for long periods then
 gets reconciled with a massive rebase.

 ASF is supposed to be about more than code. We're supposed to be working
 together on this project. I feel like the above hamstrings that whole
 process.

 And note: I'm only suggesting that the PMC - who is supposed to have the
 long-term interests of *this* project at heart - be held to a higher
 standard, to provide an example for the rest of the project. This is not
 saying you're stuck working solely within Maven just because you're on the
 PMC; it's saying that you should promote the health of the community by
 making sure the processes in place work as well as possible.

 ASF membership is supposed to be reserved for those who get the Apache
 Way, and I've heard it said that PMC membership should imply ASF
 membership. IMO, working for extended periods outside of the venues for our
 community is not consistent with having the best interests of this project
 in mind.




 On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
 stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com
 wrote:

  Perhaps we could reframe the question a little then (as people seem to be
 testing hung up on the committed wording)...

 Should the PMC encourage people experimenting on new improvements to
 Maven
 to do that work at the ASF? And if so, should they then practice what
 they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or
 progress
 enough not to cause egg-on-face syndrome)?

 Shoud the PMC promote other Apache projects, or moving non-Apache
 projects
 to Apache? (Right now, to work on an issue in core and effect the change
 yourself you may need to establish merit with: Apache Maven, Eclipse
 Sisu,
 Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
 fine with half of these at Eclipse and the ther half here... Or maybe
 not... But that is a lot of projects where you need to establish merit
 and
 perhaps maintain merit just to be able to commit directly (which
 sometimes
 is the only way to effect the type of cross system changes that some of
 our
 more obscure bugs may require... GIT makes this less of a requirement, as
 patches on SVN are a PITA, though) )

 These types of questions need resolution as they will, further down the
 road, rise up again and cause wounds... Eg logback vs log4j2 is one that
 simmers at the edge (any time anyone mentioned coloured loggers)

 -Stephen

 On Thursday, 25 July 2013, Paul Benedict wrote:

  I don't think it is possible to force volunteer efforts and/or limit
 development elsewhere. The idea of supporting a project is a vague

 notion.

 I have my opinions too but this language is clearly unenforceable and
 impractical.

 Cheers,
 Paul


 On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:

  As a Maven user I think that everybody who is working on a project

 should

 behave the same. Hence, I would say, PMC members should rather

 certainly

 demonstrate

Re: Welcome Evgeny Mandrikov to Apache Maven Dev Team

[Paul Benedict]

Welcome 

On Sun, Jan 30, 2011 at 1:51 PM, Olivier Lamy ol...@apache.org wrote:

 Hello,

 We just voted him as a committer.

 So Welcome Evgeny !

 Thanks,
 --
 Apache Maven Team

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

Re: Welcome Wayne Fay to the Maven PMC

[Paul Benedict]

Congrats Wayne!

On Sat, Jan 15, 2011 at 7:14 AM, Mark Struberg strub...@yahoo.de wrote:

 Congratulations Wayne!

 Keep up the good work ;)

 LieGrue,
 strub

 --- On Sat, 1/15/11, Olivier Lamy ol...@apache.org wrote:

  From: Olivier Lamy ol...@apache.org
  Subject: Re: Welcome Wayne Fay to the Maven PMC
  To: Maven Users List users@maven.apache.org
  Date: Saturday, January 15, 2011, 11:38 AM
  Welcome aboard !
 
  --
  Olivier
   Le 15 janv. 2011 02:08, Brian Fox bri...@infinity.nu
  a écrit :
   I'm sure you all know Wayne since he's been around
  forever answering
   user list questions. We recently voted him in both as
  a committer and
   a PMC member, so please join me in congratulating him.
  We're secretly
   hoping that he'll use his commit rights to start
  improving the
   documentation since he's so good at answering
  questions ;-)
  
   Welcome Wayne!
  
   --Brian Fox
   Apache Maven PMC Chair
  
  
  -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
 




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

Re: how can i have two compile phases?

[Paul Benedict]

On Fri, Oct 29, 2010 at 4:03 PM, Leon Rosenberg
rosenberg.l...@gmail.com wrote:
 Hi,

 I have following requirement. I have a project, in which I have one
 source folder which contains a code generator (run with apt), another
 source folder
 which contains code, which is processed by the generator from folder
 1, and a third folder that relies on the code generated by the second
 folder.
 Therefor I need two compilation executions after each other, one for
 the generator and one for the generated code.
 Is this possible with maven?


Yes. Attach your APT generation to generate-sources phase. That will
be included in the following compile phase but, I believe, the
plugin that generates the sources has to be smart enough to add it to
the class path.

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

Re: avoiding dependency version number duplication

[Paul Benedict]

On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict pbened...@apache.org wrote:
 I don't believe that's supposed to happen.

I realized how vague my answer was. Sorry! I mean the replacement is
NOT supposed to happen. It's a substitution variable. You won't get
the real value in there because it's resolved at build time.

Paul

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

Re: avoiding dependency version number duplication

[Paul Benedict]

Which is a problem because there's lots of other ways for that variable
 to be set that aren't going to be available after the pom is deployed.

I wouldn't deploy a POM with variables that are not set. Won't the
properties tag be included either in the POM or the parent POM?

Paul

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

Re: avoiding dependency version number duplication

[Paul Benedict]

Well, I use properties and publish POMs with them. I don't have an
issue with them. I am sorry the variable replacements don't meet your
needs; I don't know what else to suggest.

On Tue, Oct 26, 2010 at 11:46 AM, Haszlakiewicz, Eric
ehas...@transunion.com wrote:
-Original Message-
From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
 On
Behalf Of Paul Benedict
Sent: Tuesday, October 26, 2010 11:22 AM
To: Maven Users List
Subject: Re: avoiding dependency version number duplication

Which is a problem because there's lots of other ways for that
 variable
 to be set that aren't going to be available after the pom is
 deployed.

I wouldn't deploy a POM with variables that are not set. Won't the
properties tag be included either in the POM or the parent POM?

 Variables can be set in profiles.xml, or on the command line, or it'll
 might be conditional based on how the build is done (e.g. mvn -P
 devbuild deploy vs mvn -P releasebuild deploy, and perhaps those
 profile define different values).
 Those are just the few cases that I can think of off the top of my head,
 but I wouldn't be surprised if there are others.

 eric

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



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

Re: [Repetitive]: Maven does not live up to its promises

[Paul Benedict]

 I've looked at pages and pages of POM files, trying to learn things. And my 
 conclusion is that Maven was _fundamentally flawed_ in choosing XML as its 
 base.

XML isn't evil. XML is a compromise between human-readable and
computer-readable data. It's neither the best nor the worst format. If
you want something more friendlier, check out Polyglot Maven.

Also, XML isn't the memory representation of Maven's data structures.
XML is just the expressed format. So it's not a fundamental flaw by
any stretch.

Paul

On Tue, Oct 26, 2010 at 1:56 PM, Kenneth McDonald
kenneth.m.mcdon...@sbcglobal.net wrote:
 If a build can be described as a small number of facts, XML is an
 unobjectional representation for those facts. If a POM fits on a page,
 verbosity of XML is just not an issue.

 Yeah, but a build often does not fit on  a page, and I'm building some pretty 
 simple stuff!

 To argue for the flexibity of Maven is (AFAIK) defensible. It's power (from 
 what little knowledge I have), likewise.

 But, I'm sorry to say, the verbosity of XML is a major, major issue. I bring 
 you back to the simple fact of: If XML were so expressive, why aren't most 
 modern languages written in XML? If programmers had to write their systems in 
 a dialect of XML, put in the redundant tags, escape everything that _isn't_ a 
 literal, etc.,  then we would have very poor programmer productivity.

 I've looked at pages and pages of POM files, trying to learn things. And my 
 conclusion is that Maven was _fundamentally flawed_ in choosing XML as its 
 base.

 Cheers,
 Ken
 -
 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: avoiding dependency version number duplication

[Paul Benedict]

properties
  spring.version2.5.6/spring.version
/properties

Then for your dependency versions, specify version${spring.version}/version

For more information:
http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

Paul

On Mon, Oct 25, 2010 at 1:45 PM, Babak Farhang farh...@gmail.com wrote:
 Hi everyone,

 Say I have a number of modules that share a dependency on Spring. I'd
 like to centralize the version number of the Spring library that I'm
 using, that is, the version these modules depend on. I.e. I don't want
 the version number of the Spring dependency to be duplicated across
 many pom files. What's the maven way for doing this?

 -Babak

 -
 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: avoiding dependency version number duplication

[Paul Benedict]

Can you explain the transformed pom point? I believe Justin's
approach and my approach are identical -- all you are doing is
delaying the version resolution until you declare the dependency.
Anyway, let me know how it works out.

Paul

On Mon, Oct 25, 2010 at 7:03 PM, Babak Farhang farh...@gmail.com wrote:
 Paul's approach (using properties defined in the parent pom) is in
 fact what I've been trying.  Trouble is, the transformed pom still has
 ${spring.version}, not the *value* it should resolve to. From a
 practical standpoint, this should break transitive dependencies when
 someone includes my project (artifact) as a dependency.

 Justin's approach using the dependencyManagement element sounds more
 promising.  I'll report back when I've played it with it more..

 Thank you all!
 -Babak

 On Mon, Oct 25, 2010 at 12:49 PM, Paul Benedict pbened...@apache.org wrote:
 properties
  spring.version2.5.6/spring.version
 /properties

 Then for your dependency versions, specify 
 version${spring.version}/version

 For more information:
 http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

 Paul



 On Mon, Oct 25, 2010 at 12:49 PM, Justin Edelson
 justinedel...@gmail.com wrote:
 Use a property and/or dependency management in a shared parent POM.
 Spring has multiple modules, so it is frequently useful to store the
 common version for all modules in a single property and then specify
 each relevant module in a dependencyManagement element.

 Justin





 On Mon, Oct 25, 2010 at 1:45 PM, Babak Farhang farh...@gmail.com wrote:
 Hi everyone,

 Say I have a number of modules that share a dependency on Spring. I'd
 like to centralize the version number of the Spring library that I'm
 using, that is, the version these modules depend on. I.e. I don't want
 the version number of the Spring dependency to be duplicated across
 many pom files. What's the maven way for doing this?

 -Babak

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



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



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



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

Re: avoiding dependency version number duplication

[Paul Benedict]

I don't believe that's supposed to happen.

On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang farh...@gmail.com wrote:
 Can you explain the transformed pom point?

 Perhaps I'm not using the correct terminology, but what I meant was
 that I looked at the pom in my local repo after I mvn install'ed it,
 and it still contains the literal ${..} string where there should have
 been the version number.

 Babak

 On Mon, Oct 25, 2010 at 6:35 PM, Paul Benedict pbened...@apache.org wrote:
 Can you explain the transformed pom point? I believe Justin's
 approach and my approach are identical -- all you are doing is
 delaying the version resolution until you declare the dependency.
 Anyway, let me know how it works out.

 Paul

 On Mon, Oct 25, 2010 at 7:03 PM, Babak Farhang farh...@gmail.com wrote:
 Paul's approach (using properties defined in the parent pom) is in
 fact what I've been trying.  Trouble is, the transformed pom still has
 ${spring.version}, not the *value* it should resolve to. From a
 practical standpoint, this should break transitive dependencies when
 someone includes my project (artifact) as a dependency.

 Justin's approach using the dependencyManagement element sounds more
 promising.  I'll report back when I've played it with it more..

 Thank you all!
 -Babak

 On Mon, Oct 25, 2010 at 12:49 PM, Paul Benedict pbened...@apache.org 
 wrote:
 properties
  spring.version2.5.6/spring.version
 /properties

 Then for your dependency versions, specify 
 version${spring.version}/version

 For more information:
 http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

 Paul



 On Mon, Oct 25, 2010 at 12:49 PM, Justin Edelson
 justinedel...@gmail.com wrote:
 Use a property and/or dependency management in a shared parent POM.
 Spring has multiple modules, so it is frequently useful to store the
 common version for all modules in a single property and then specify
 each relevant module in a dependencyManagement element.

 Justin





 On Mon, Oct 25, 2010 at 1:45 PM, Babak Farhang farh...@gmail.com wrote:
 Hi everyone,

 Say I have a number of modules that share a dependency on Spring. I'd
 like to centralize the version number of the Spring library that I'm
 using, that is, the version these modules depend on. I.e. I don't want
 the version number of the Spring dependency to be duplicated across
 many pom files. What's the maven way for doing this?

 -Babak

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



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



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



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



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



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

Re: project structure with per-project trunks and svn

[Paul Benedict]

If you have trunks underneath subprojects, that tells me they have
independent release cycles. If you want them to be versioned
separately, your structure is okay. If you want the master project to
build and control the subprojects as modules, I would re-organize
everything under one trunk.

Paul

On Tue, Oct 19, 2010 at 9:40 AM, thisguy bobsmith30...@yahoo.com wrote:

 Hello experts, I'm trying to reconcile the standard maven project structure
 with the standard svn project structure (with per-project versioning).  I'd
 like to have a subversion structure like this:

 pom.xml
 --proj A
 trunk
 --pom.xml
 --src
 --proj B
 trunk
 --pom.xml
 --src

 etc.

 How can I get maven to build everything properly?

 Should I use svn externals to magically remove the trunk directories so that
 this layout would conform to standard maven layout?  If I did that, how
 would I handle the situation of wanting to build a particular
 branch..wouldn't I have to update the externals properties back and forth
 (cumbersome)?

 Or should I change all project poms to use parent relative paths of
 ../../pom.xml to get to the parent pom?  But this technique wouldn't work
 if I wanted to build a particular branch because it would be an extra level
 deep (i.e. proj-branches-1.0.0-pom.xml).

 What is best practice here?  Thank you.


 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/project-structure-with-per-project-trunks-and-svn-tp3219163p3219163.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

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



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

Re: naming now that Maven 3 is out..

[Paul Benedict]

Eric, you can look at these:

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

http://maven.40175.n5.nabble.com/Setting-goals-for-upcoming-releases-td2801569.html

Paul

On Thu, Oct 14, 2010 at 11:33 AM, Haszlakiewicz, Eric
ehas...@transunion.com wrote:
-Original Message-
From: Wendy Smoak [mailto:wsm...@gmail.com]

On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala na...@chikli.com
wrote:
 Kind of a random thought -- now that Maven 3 is out, are all those
 M2
based names going to be changed to M3, or more preferably a
 non-version
specific name?

 i.e. M2_HOME, m2eclipse, etc.?

This was discussed on the dev list a while back, you can check the
archives to see how it turned out.

 Ok, *where* on the dev list?  I just spent 15 minutes looking for
 mention of this and the only thing I found that said anything about this
 was:
 http://www.mail-archive.com/d...@maven.apache.org/msg84980.html
 but hardly counts as being discussed.

 How about providing a link to what you're talking about?

 eric

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



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

Re: naming now that Maven 3 is out..

[Paul Benedict]

I brought the issue up back then and it got at least pushed to 3.1

On Wed, Oct 13, 2010 at 9:48 AM, Wendy Smoak wsm...@gmail.com wrote:
 On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala na...@chikli.com wrote:
 Kind of a random thought -- now that Maven 3 is out, are all those M2 
 based names going to be changed to M3, or more preferably a non-version 
 specific name?

 i.e. M2_HOME, m2eclipse, etc.?

 This was discussed on the dev list a while back, you can check the
 archives to see how it turned out.

 (m2eclipse is a separate project, its naming wouldn't be decided here.)

 --
 Wendy

 -
 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: Need to specify versions of standard plugins in 3.0?

[Paul Benedict]

Yes, Maven provides default versions, but those are likely to change
as Maven does future patch releases. To give you a predictable build,
lock down your plugins so you control what versions are selected.

Paul

On Tue, Oct 12, 2010 at 10:27 AM, Patrick Aikens paik...@gmail.com wrote:
 I've got several projects that provide additional configuration of
 standard Maven plugins (like the compiler plugin or the jar plugin),
 most commonly changing the source and target values for the compiler
 plugin.  Unfortunately, I get the following warnings:

 [WARNING] 'build.plugins.plugin.version' for
 org.apache.maven.plugins:maven-compiler-plugin is missing.
 [WARNING] 'build.plugins.plugin.version' for
 org.apache.maven.plugins:maven-surefire-plugin is missing. [WARNING]
 'build.plugins.plugin.version' for
 org.apache.maven.plugins:maven-jar-plugin is missing.

 I know (and approve of) Maven 3.0 requiring versions on plugins, but
 shouldn't these particular plugins have versions specified in the
 super-pom that get merged into the references in my projects?  Is it
 expected behavior that to add configuration to these plugins that I go
 find out which version of the plugin is in the super-pom and add it
 again?  I can get rid of these warnings by simply putting the
 appropriate plugin version information in a common parent pom's
 pluginManagement section, but I'm not sure that I should need to.

 It just seems odd that I need to repeat the version info if I add some
 configuration to the plugin in a project, but another project that
 just uses the plugin as-is through inheritance from the super-pom
 works without warnings... it should have warnings in both or neither.

 --
 SELECT * FROM users WHERE clue  0

 -
 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: maven3 and issues with war plugin configuration

[Paul Benedict]

Try this:
excludes.gitignore,**/.gitignore/excludes

If you don't see the property as a ListString in the source, it must
be a comma-separated or space-separated value.

Paul

On Mon, Oct 11, 2010 at 10:38 AM, Dmitry Sklyut dmi...@dsklyut.com wrote:
 Hi All,

 I have following configuration in war plugin:
 (parent pom)
 plugin
                     groupIdorg.apache.maven.plugins/groupId
                     artifactIdmaven-war-plugin/artifactId
                     version2.1/version
                     configuration
                         excludes
                             exclude.gitignore/exclude
                             exclude**/.gitignore/exclude
                         /excludes
                     /configuration
                 /plugin
 (child pom)
 plugin
                 groupIdorg.apache.maven.plugins/groupId
                 artifactIdmaven-war-plugin/artifactId
                 configuration
                     packagingExcludesWEB-INF/lib/*.jar/packagingExcludes
                 /configuration
             /plugin


 This is the error I am getting:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-war-plugin:2.1:war (default-war)
  on project com.ptc.insight.runtime.theme:
  Unable to parse configuration of mojo
 org.apache.maven.plugins:maven-war-plugin:2.1-beta-1:war:
  When configuring a basic element the configuration cannot contain
 any child elements.
  Configuration element 'warSourceExcludes'. - [Help 1]

 I debugged through the maven-core and it looks like type converter is
 picked up based on the target type of the property.

 In maven-war-plugin warSourceExcludes is a String with an alias to 
 excludes

    /**
     * The comma separated list of tokens to exclude when copying the content
     * of the warSourceDirectory.
     *
     * @parameter alias=excludes
     */
    private String warSourceExcludes;

 The question that I have is that a oversight on the part of maven core
 or a issue with plugins that alias simple properties with complex
 properties?

 Regards,

 Dmitry

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



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

Maven generated MANIFEST.MF: Commit or ignore?

[Paul Benedict]

Can anyone recommend whether to SCM commit the generated MANIFEST.MF
files? Or should they just be ignored?

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

Re: Maven Release Plugin

[Paul Benedict]

I would agree that having dependencies in a POM project is curious,
and cannot think of a good use case for them. Are you really looking
for dependencyManagement where you can declare what versions should
be used by inherited projects?

On Thu, Sep 16, 2010 at 10:11 AM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
 2010/9/16 Marcus Linke li...@newsaktuell.de:
 i 've the following problem releasing a multi-module project with the
 maven-release-plugin (Version 2.0). The top (parent) pom-style project
 defines a set of snapshot dependencies that are inherited to all of its
 submodules. When using the release plugin in interactive mode, the plugin
 prompts for the new versions of these snapshot dependencies. So far, so
 good. But when diving into the submodules this is repeated for each module
 again.  This is really annoying me because i have 20 submodules in that
 project. Is this is a know problem or a type of misconfiguration.

 Sincerely having dependencies in a pom project is curious, definitely
 I'd remove them.
 I suppose that your modules have a precedence, i.e. a module depends on 
 another.
 If you play with transitive dependencies I think you'll get a clean
 (and real) dependency tree.

 Antonio

 -
 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: Release Plugin Failing on Commit

[Paul Benedict]

I get that error all too often, as well. I haven't found a solution for it.

On Sat, Sep 4, 2010 at 3:35 PM, Dennis Lundberg denn...@apache.org wrote:
 On 2010-09-04 00:16, Neil Chaudhuri wrote:
 I am using version 2.0 of the release plugin to tag a new version of my 
 multi-module application, but at the end when it goes to commit to SVN SCM, 
 I get the following:

 [INFO] Unable to tag SCM
 Provider message:
 The svn tag command failed.
 Command output:
 svn: Path 'svn://SVN IP/data/svn/client/myapp/tags/myapp-1.1.rc4' does not 
 exist in revision 5218

 To be fair, that's true--myapp-1.1.rc4 isn't a folder in the SVN tags 
 folder. But I figured the plugin would create it and put my source code 
 underneath.

 Another weird thing is that the poms are updated to 1.1.rc4 and committed to 
 the trunk and checked out to my local machine. The expected behavior is for 
 1.1.rc5-SNAPSHOT to be in the trunk and on my local while the 1.1.rc4 is in 
 the tagged version.

 Here is the plugin configuration:

          plugin
                 groupIdorg.apache.maven.plugins/groupId
                 artifactIdmaven-release-plugin/artifactId
                 version2.0/version
                 configuration
                     
 updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
                     preparationGoalsclean install/preparationGoals
                     goalsclean install/goals
                     arguments-Dmaven.test.skip/arguments
                     tagBasesvn://SVN IP/data/svn/client/myapp/tags 
 /tagBase
                     autoVersionSubmodulestrue/autoVersionSubmodules
                 /configuration
             /plugin

 Any advice on how to get the expected behavior is appreciated.

 updateWorkingCopyVersions is only available in the branch goal. Are
 you trying to release from a branch?

 If so then by using updateWorkingCopyVersions=false you have told the
 plugin that you don't want it to update the version in your working copy.


 Thanks.



 --
 Dennis Lundberg

 -
 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: Integration tests vs. unit tests

[Paul Benedict]

Thomas,

There isn't one right answer. Expect to find lots of variants.

I use a naming convention. Unit tests end in plain-old vanilla Test,
and integration tests end in *ITest. I use a wildcard pattern with
Maven to exclude integration tests since they are long-running and
need less execution. I can enable those, however, using a Maven
profile.

Also see:
http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing

Paul

On Fri, Aug 27, 2010 at 5:34 AM, Thomas Sundberg t...@kth.se wrote:
 Hi!

 This has been discussed previously. But I would like to ask the list
 again, how do you separate integrations test from unit tests in a
 Maven project?

 I define unit tests as being tests that will run in memory and not use
 any external resources. Anything external is mocked away. Everything
 will run in memory and as fast as possible.

 I define integration tests as tests that are dependent on other
 resources than the source code. This is (at least):
 * The file system
 * Databases
 * Network access

 Assume that we are dealing with a multi module build, how would you
 organize the modules? Would you consider adding a separate
 'integration-test' tree next to main and test?

 /Thomas

 --
 Thomas Sundberg
 M. Sc. in Computer Science

 Mobile: +46 70 767 33 15
 Blog: http://thomassundberg.wordpress.com/
 Twitter: @thomassundberg

 -
 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

Help needed with m2eclipse + Tomcat

[Paul Benedict]

My web project has these facets installed: Dynamic Web Module (2.4),
Java (1.5). I am also using the m2eclipse plugin and Eclipse's
built-in server integration for Tomcat 6.0.29.

I get this error on context startup:
java.lang.ClassNotFoundException:
org.springframework.web.context.ContextLoaderListener

I guess it is because my Maven dependencies are not being mapped. What
must I do to populate the WEB-INF/lib directory?

Paul

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

Re: Help needed with m2eclipse + Tomcat

[Paul Benedict]

Wow. That worked. How did you know? I mean, that solution is not
intuitive. I wouldn't even know how to recommend it as a JIRA
enhancement to Sonatype.

Paul

On Fri, Aug 27, 2010 at 2:27 PM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
 2010/8/27 Paul Benedict pbened...@apache.org:
 My web project has these facets installed: Dynamic Web Module (2.4),
 Java (1.5). I am also using the m2eclipse plugin and Eclipse's
 built-in server integration for Tomcat 6.0.29.

 I get this error on context startup:
 java.lang.ClassNotFoundException:
 org.springframework.web.context.ContextLoaderListener

 I guess it is because my Maven dependencies are not being mapped. What
 must I do to populate the WEB-INF/lib directory?

 Try with right clicking on project - Maven - Update project configuration.
 BTW, are the Spring dependencies compile (or, at least, runtime) scoped?

 Antonio

 -
 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: force maven to redownload/refresh released dependencies

[Paul Benedict]

On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
ehas...@transunion.comwrote:

 Please read the rest of the email thread.  The short summary is:
  Yes, I know what *should* happen, but the world isn't perfect and release
 artifacts DO sometimes change.  It is not absurd to be able to detect and
 recover from that kind of situation.


The solution is to wipe out your local artifact. No one should be updating
released artifacts. If they do, they abused what a release means -- hence
the problem to begin with. The solution given is the only (correct) one in
Maven.

Paul

Re: force maven to redownload/refresh released dependencies

[Paul Benedict]

On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
ehas...@transunion.comwrote:

 You're missing the point of what I'm asking.  I'm not suggesting that
 maven make it possible or easy to *create* the violation.  I'm
 suggesting that it should be able to *detect* the violation.

 I'm baffled as to why the maven community is so against the idea of
 having additional (optional) checks to detect problems.


Eric,

The point is releases don't change. To detect means wasting bandwidth
comparing your supposedly unchanging released local artifacts to supposedly
unchanging released remote artifacts. If anything, writing a Maven plug-in
for this would be more appropriate, but I don't see your suggestion as part
of Maven core.

Paul

Re: force maven to redownload/refresh released dependencies

[Paul Benedict]

Shan,

Maven has a policy how often it checks for updated snapshots. Is that what
you are looking for?

Paul

On Fri, Jul 30, 2010 at 11:39 AM, Jason van Zyl ja...@sonatype.com wrote:

 Maven won't do that, and we would never make that possible. If you require
 this you have something seriously wrong with your project infrastructure.
 Seriously bad project infrastructure smell.

 On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:

  is there a way to force a project to refresh certain dependencies every
  build? i.e. replicate SNAPSHOT behaviour with released artifacts
 
  S

 Thanks,

 Jason

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

Re: force maven to redownload/refresh released dependencies

[Paul Benedict]

Replacing a SNAPSHOT with a non-SNAPSHOT version is equivalent to upgrading.
Jason is right in that this should never be automatically done by Maven.
Maven cannot guess or determine when you are ready to give up SNAPSHOT
versions.

However, perhaps you need an external batch process that discovers new
versions and automatically upgrades POMs.

Paul

On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed shan...@gmail.com wrote:

 ok, thanks
 basically for liability reasons for a certain project, we have to provide
 specific times of when a project was built and when/where all its
 dependencies were retrieved at/from
 we have to ensure a sanitary build for all these JARs and a complete log of
 going from 0 to 100 for the build; so we are faced with either clearing out
 the .m2 each time
 I was wondering if there was a way to force this through maven

 On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
 manos_li...@geekologue.comwrote:

  On 07/30/2010 07:16 PM, Wayne Fay wrote:
 
  is there a way to force a project to refresh certain dependencies every
  build? i.e. replicate SNAPSHOT behaviour with released artifacts
 
 
  Absolutely not. Released artifacts MUST NOT CHANGE.
 
 
  +1, never ever ;-)
 
  Released artifact versioning is supposed to guarantee consistency.
 
  Manos
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: force maven to redownload/refresh released dependencies

[Paul Benedict]

There is a maxim to follow when deploying: do not redeploy a version more
than once. Once you deploy version X.Y.Z, it should never be updated, and
those who download it never need to download it again. So, back to the
original problem, are you guys doing that?

On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed shan...@gmail.com wrote:

 it only applies to our final release cuts, not our day-to-day
 just once for this project really; I wanted to insert such this switch (if
 existed) in our delivery build profile
 we use archiva for everything else, and actually only make use of public
 maven repositories when we up a version of our dependencies, which is rare
 because of change control

 it's all weird stuff, I know, but sometimes I just don't question it

 On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wayne...@gmail.com wrote:

   deleting the m2 works, I was just curious to see if there was a switch
  in
   maven to force all downloads again
  
   This makes absolutely no sense, doesn't change your BOM, and is just
   wasteful. Consumes bandwidth unnecessarily from a resource that is
 being
   used by the whole Maven community.
 
  I'd think that if you had enough developers doing this on every
  machine on a consistent basis (eg every build), it might add up to
  enough traffic to get you on a blacklist somewhere... You really need
  to install Nexus or another MRM, this is just plain dumb.
 
  Wayne
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org