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

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

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: 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 
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  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...
> > > >
> > > > Re

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

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  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:
> >
> > 
> > org.apache.maven.plugins
> > maven-war-plugin
> > 2.5
> > 
> > 
> > org.company
> >
> >
>
> ^ missing  ...  ?
> > ui
> > zip
> > 
> > 
> > 
> >
> > 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
> > List collection. Any WAR developers here?
> >
> > Cheers,
> > Paul
> >
> >
>
>
>

Exception overlaying zip in war

[Paul Benedict]

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


  org.apache.maven.plugins
  maven-war-plugin
  2.5
  

  org.company
  ui
  zip

  


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
List 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  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 >:
> > >
> >
> 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
> 
> > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> >
> >
>
> --
> 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  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:
> 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";>
>   4.0.0
>   Classes
>   Classes
>   clasess
> 
> 
>
> ${maven.filters.generic.path}/Filters.properties
> 
> 
> 
> ${basedir}
> false
> 
> myfiles/**/*.*
> 
> 
> 
> src/main/java/
> true
> 
> **/*.xml
> **/*.xslt
> 
> 
> 
> 
> 
> maven-compiler-plugin
> 3.1
> 
> ${jdk.compilation.version}
> ${jdk.compilation.version}
> ${charSetEnconding}
> 
> 
> 
> maven-resources-plugin
> 2.6
> 
> 
> copy-resources
> validate
> 
> copy-resources
> 
> 
>
> ${basedir}/config
> 
> 
>
> ${basedir}/configTemplates
> true
> 
> 
> 
> 
> 
> copy-resources
> validate
> 
> copy-resources
> 
> 
> target
> 
> 
> ${basedir}/src/main/java
> false
> 
> **/*.java
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> org.eclipse.m2e
> lifecycle-mapping
> 1.0.0
> 
> 
> 
> 
> 
>
> org.apache.maven.plugins
>
> maven-dependency-plugin
>
> [1.0.0,)
> 
> copy-dependencies
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> postgresql
> postgresql
> 9.1-901.jdbc4
> 
> 
> commons-lang
> commons-lang
> 2.6
> 
> 
> commons-codec
> commons-codec
> 1.5
> 
> 
> javax.ejb
> ejb-api
> 3.0
> 
> 
> javax.transaction
> jta
> 1.1
> 
> 
> 
>

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 
> 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  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  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 :
> >  only affects  -- it does not affect
> :
> > https://jira.codehaus.org/browse/MNG-3385
> >
> > Cheers,
> > Paul
> >
> > On Thu, Oct 2, 2014 at 9:06 PM, Maxim Solodovnik 
> >
> > wrote:
> > > we using  for this
> > >
> > > On 3 October 2014 07:24, Kathryn Huxtable  >
> > >
> > > wrote:
> > > > I’ve always used , but would it work to use
> > > > ? -K
> > > >
> > > > On Oct 2, 2014, at 7:02 PM, Paul Benedict 
> wrote:
> > > > > I use the maven-javadoc-plugin in both  and . I
> > > > > don't
> > > > > want to fall back to  to share the plugin version. Is
> > >
> > > there a
> > >
> > > > > better way than using ?
> > > > >
> > > > > 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]

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

Cheers,
Paul

On Thu, Oct 2, 2014 at 9:06 PM, Maxim Solodovnik 
wrote:

> we using  for this
>
> On 3 October 2014 07:24, Kathryn Huxtable 
> wrote:
>
> > I’ve always used , but would it work to use
> > ? -K
> >
> > On Oct 2, 2014, at 7:02 PM, Paul Benedict  wrote:
> >
> > > I use the maven-javadoc-plugin in both  and . I don't
> > > want to fall back to  to share the plugin version. Is
> there a
> > > better way than using ?
> > >
> > > 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  and . I don't
want to fall back to  to share the plugin version. Is there a
better way than using ?

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 
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 
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  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  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"  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,
> ApplicationListener {
> [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.(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:
>
> 
> 
>   
> 
>   
>   
> 
>   
>   
> org.foobar.*
>   
>   src/main/javadoc
> 
> 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:
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> ${maven-javadoc-plugin.version}
> 
> 
> attach-javadocs
> 
> aggregate
> 
> 
> 
> 
>
> org.hibernate.*;org.spring.*
> true
> true
> true
> true
> ${java.source.version}
> ${java.target.version}
> ${java.source.version}
> -Xlint:all
> 128m
> 512m
>
> ${project.build.sourceEncoding}
>
> 
> -charset UTF-8
> -docencoding UTF-8
> -versi

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  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 >
> > 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
> > 
> > >
> > >
> >
>
>
> --
> Sent from my phone
>

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

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  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 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" 
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  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:
> > >
> > >
> > >
> > > 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> ">
> > >
> > > 4.0.0
> > >
> > > com.microsoft.sqlserver
> > >
> > > sqljdbc4
> > >
> > > 4.0
> > >
> > >
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > project.local
> > >
> > > project
> > >
> > > file:${project.basedir}/repo
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > >
> > >
> > >
> > >
> > > 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
>

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  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:
>
>
>
> 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> ">
>
>   4.0.0
>
>   com.microsoft.sqlserver
>
>   sqljdbc4
>
>   4.0
>
>
>
> 
>
> 
>
> 
>
> project.local
>
> project
>
> file:${project.basedir}/repo
>
> 
>
> 
>
> 
>
>
>
>
>
> 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:
>
> 
>
> com.microsoft.sqlserver
>
> sqljdbc4
>
> 4.0
>
> 
>
>
>
> I'm even using the maven assembly plugin to ensure a jar is built with all
> dependencies packaged in:
>
>
>
> 
>
>
> maven-assembly-plugin
>
>   
>
> 
>
>
> jar-with-dependencies
>
> 
>
> 
>
>   
>
> true
>
>
> productfeeds.main.ProductFeedDriver
>
>   
>
> 
>
>   
>
> 
>
>   
>
> package
>
> 
>
>   single
>
> 
>
>   
>
> 
>
> 
>
>
>
>
>
> 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 -DartifactId=sqljdbc4 -Dversion=4.0
> -Dpackaging=jar ', then everything works fine.
>
>
>
> Thanks,
>
>
>
> Matt
>
>
>
>

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  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"  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: 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 wrote:

> 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: 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ć wrote:

> 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: 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ć"  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

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 / tags need to be in the  of the
maven-war-plugin and NOT your . 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:

   
 
   maven-war-plugin
   
 
   src/main/filters/dev.properties


  
src/main/webapp/WEB-INF
true
jboss-web.xml
WEB-INF
  
.


Cheers,
Paul


On Thu, Apr 24, 2014 at 2:17 PM, Paul Benedict  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
>  tag and target the output at WEB-INF.
>
> Paul
>
>
>
> On Thu, Apr 24, 2014 at 1:37 PM, Paul Benedict 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.
>>
>> 
>>   
>> src/main/filters/dev.properties
>>
>>
>>  
>>maven-war-plugin
>>
>> 
>>   
>> src/main/webapp/WEB-INF
>> true
>> jboss-web.xml
>> WEB-INF
>>   
>> .
>> 
>>
>> What's missing/wrong in my config?
>>
>> --
>> Cheers,
>> Paul
>>
>
>
>
> --
> Cheers,
> Paul
>



-- 
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
 tag and target the output at WEB-INF.

Paul



On Thu, Apr 24, 2014 at 1:37 PM, Paul Benedict  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.
>
> 
>   
> src/main/filters/dev.properties
>
>
>  
>maven-war-plugin
>
> 
>   
> src/main/webapp/WEB-INF
> true
> jboss-web.xml
> WEB-INF
>   
> .
> 
>
> What's missing/wrong in my config?
>
> --
> Cheers,
> Paul
>



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


  
src/main/filters/dev.properties
   
   
 
   maven-war-plugin
   

  
src/main/webapp/WEB-INF
true
jboss-web.xml
WEB-INF
  
.


What's missing/wrong in my config?

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

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

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

> On 12 February 2014 07:41, laredotornado-3 
> 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.(ParentRunner.java:48)
> > at
> >
> org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:58)
> > at
> >
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.(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  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 wrote:

> My personal fear of the hat, is that it is too similar to Redhat IMHO.
>
>
> On 13 January 2014 22:29, John Miller  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  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  in  but it
> does not work.
>
>   
> maven-resources-plugin
> 
>   
> copy-xxx
> compile
> 
>   copy-resources
> 
> 
>   true
>
> ${webapp.dir}/example/resources
>   
> 
>   ${webapp.dir}/resources
>   
> **
>   
> 
>   
> 
>   
> 
>
> 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  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  >
> > 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  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 
> > 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" 
> > 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  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  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"  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  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  match .

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:
>
> 
> org.apache.maven.plugins
> maven-enforcer-plugin
> 1.3.1
> 
> 
> enforce-banned-dependencies
> 
> enforce
> 
> 
> 
> 
>
> true
> 
> commons-logging
> 
> 
> 
> true
> 
> 
> 
> enforce-same-versions
> 
> enforce
> 
> 
> 
> 
> 
>
> org.slf4j:*
> 
> 
> 
> true
> 
> 
> 
> 
> true
> 
> 
>
> 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 wrote:

> 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 src/main/java/*), 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

users@maven.apache.org

[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-beta2>mvn --encrypt-password
> toto&&titi
> {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

users@maven.apache.org

[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-beta2>mvn --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

users@maven.apache.org

[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-beta2>mvn --encrypt-password toto&titi
> {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-beta2>mvn --encrypt-password toto
> {DhN9VJ29e4QHksWV5dh9UrPL5LwrGbv119x9ptOlNpQ=}
> C:\outillivraison\outillivraison-1.0-beta2>mvn --encrypt-password "toto"
> {wAmp4BzifcMH0FjCCnmccIZeCLBI4dGL3eWz07zGomc=} <-- not the same value than
> previous one : quotes do not work
>
> C:\outillivraison\outillivraison-1.0-beta2>mvn --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: 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 wrote:

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

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

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  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
> >  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=1509594&view=markup
> > >
> > > Thoughts?
> > >
> > > -Stephen
> > >
> > > -- Forwarded message --
> > > From: 
> > > 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=1509594&r1=1509593&r2=1509594&view=diff
> > >
> >
> ==
> > > --- maven/site/trunk/content/markdown/project-roles.md (original)
> > > +++ maven/site/trunk/con

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

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

Re: Welcome Evgeny Mandrikov to Apache Maven Dev Team

[Paul Benedict]

Welcome 

On Sun, Jan 30, 2011 at 1:51 PM, Olivier Lamy  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  wrote:

> Congratulations Wayne!
>
> Keep up the good work ;)
>
> LieGrue,
> strub
>
> --- On Sat, 1/15/11, Olivier Lamy  wrote:
>
> > From: Olivier Lamy 
> > Subject: Re: Welcome Wayne Fay to the Maven PMC
> > To: "Maven Users List" 
> > Date: Saturday, January 15, 2011, 11:38 AM
> > Welcome aboard !
> >
> > --
> > Olivier
> >  Le 15 janv. 2011 02:08, "Brian Fox" 
> > 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
 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: [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
 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]

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

On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict  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]

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

On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang  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  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  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  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  
>>> wrote:
>>>> 
>>>>  2.5.6
>>>> 
>>>>
>>>> Then for your dependency versions, specify 
>>>> ${spring.version}
>>>>
>>>> For more information:
>>>> http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
>>>>
>>>> Paul
>>>
>>>
>>>
>>> On Mon, Oct 25, 2010 at 12:49 PM, Justin Edelson
>>>  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  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: 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  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  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  wrote:
>> 
>>  2.5.6
>> 
>>
>> Then for your dependency versions, specify 
>> ${spring.version}
>>
>> For more information:
>> http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
>>
>> Paul
>
>
>
> On Mon, Oct 25, 2010 at 12:49 PM, Justin Edelson
>  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  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]

  2.5.6


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

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

Paul

On Mon, Oct 25, 2010 at 1:45 PM, Babak Farhang  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: 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  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
 wrote:
>>-Original Message-
>>From: Wendy Smoak [mailto:wsm...@gmail.com]
>>
>>On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala 
>>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  wrote:
> On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala  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  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:
.gitignore,**/.gitignore

If you don't see the property as a List 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  wrote:
> Hi All,
>
> I have following configuration in war plugin:
> (parent pom)
> 
>                     org.apache.maven.plugins
>                     maven-war-plugin
>                     2.1
>                     
>                         
>                             .gitignore
>                             **/.gitignore
>                         
>                     
>                 
> (child pom)
> 
>                 org.apache.maven.plugins
>                 maven-war-plugin
>                 
>                     WEB-INF/lib/*.jar
>                 
>             
>
>
> 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  where you can declare what versions should
be used by inherited projects?

On Thu, Sep 16, 2010 at 10:11 AM, Antonio Petrelli
 wrote:
> 2010/9/16 Marcus Linke :
>> 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  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:///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:
>>
>>          
>>                 org.apache.maven.plugins
>>                 maven-release-plugin
>>                 2.0
>>                 
>>                     
>> false
>>                     clean install
>>                     clean install
>>                     -Dmaven.test.skip
>>                     svn:///data/svn/client/myapp/tags 
>> 
>>                     true
>>                 
>>             
>>
>> Any advice on how to get the expected behavior is appreciated.
>
>  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: 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
 wrote:
> 2010/8/27 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?
>
> 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

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

Re: force maven to redownload/refresh "released" dependencies

[Paul Benedict]

On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
wrote:

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

On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
wrote:

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

You can use -X for a debug log. Or you can funnel system out to a file. I
believe tools like Continuum or Hudson do such things.

Paul

On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed  wrote:

> no, this isn't in regard to our own published artifacts
>
> I regret starting this thread, I apologize
> I didn't mean this question to be an affront to maven conventions - I just
> need to figure out a better way to capture a full log
> they even want a log of how the build environment was downloaded and
> installed
>
>
> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict 
> wrote:
>
> > 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  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  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
> > > >
> > > >
> > >
> >
>

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

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