RE: Issue running mvn deploy using Maven 3.0.3

[Henika Tekwani]

Thanks Anders. I will take this to nexus.

-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Wednesday, June 01, 2011 1:52 AM
To: Maven Users List
Subject: Re: Issue running mvn deploy using Maven 3.0.3

I think you should move this discussion to the Nexus users list. The nexus
people should be able to give you a quick answer if it's a Nexus issue or
something else.

/Anders

On Tue, May 31, 2011 at 17:47, Henika Tekwani  wrote:

> Thanks Anders for the updates.
>
> Not sure if I found the particular link that you were referring to. Was it
> https://issues.sonatype.org/browse/NEXUS-3573 ?
>
> Are you trying to say that the issue is at Sonatype's end? Is there a way
> to increase the timeout?
>
> Thanks
> Henika
>
> -Original Message-
> From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
> Behalf Of Anders Hammar
> Sent: Monday, May 30, 2011 11:22 PM
> To: Maven Users List
> Subject: Re: Issue running mvn deploy using Maven 3.0.3
>
> I don't have the answer for you, but I recall seeing a similar question
> before. I think it was on the Nexus users list. You can find info about the
> archive at [1].
>
> /Anders
>
> [1] http://nexus.sonatype.org/project-information.html
>
> On Mon, May 30, 2011 at 17:35, Henika Tekwani  wrote:
>
> > Any updates on this?
> >
> > From: Henika Tekwani
> > Sent: Monday, May 30, 2011 10:26 AM
> > To: Maven Users List
> > Cc: Henika Tekwani
> > Subject: Issue running mvn deploy using Maven 3.0.3
> >
> > Hi,
> >
> > I have a maven project that generates a 363 MB jar artifact. I am getting
> > following error while deploying the artifact to our nexus repository:
> >
> >
> > Could not transfer artifact test:test:jar:10.0.0 from/to releases (
> > http://localhost.corp.adobe.com/nexus/content/repositories/releases): No
> > response received after 6 -> [Help 1]
> >
> >
> >
> > The above error is observed when I run my project using MAVEN 3.0.3. But
> > when I run the same project using MAVEN 2.2.1, the artifact deploys
> > successfully.
> >
> > Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make
> any
> > additional configuration settings?
> >
> > I tried using Webdav based wagon but that also doesn't solve the issue.
> >
> >
> >
> > Any clue what could be the issue?
> >
> >
> >
> >
> >
> > Thanks
> >
> > Henika
> >
> >
> >
>
> -
> 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: Alternative dependency mediation

[Leonard Ehrenfried]

We tried to change the version *range* resolution strategy once at my old
company. We found that this component is not injected by the DI container
but rather instantiated with 'new'.

A colleague of mine wrote a patch and opened a ticket [1] that does exactly
that. We didn't end up using the patch ourselves but maybe it can give you a
clue where you need to be looking.

[1] http://jira.codehaus.org/browse/MNG-5017

Lenni


On Wed, Jun 1, 2011 at 6:39 AM, Anders Hammar  wrote:

> No, it doesn't. At least not out-of-the-box. I don't know if it would be
> possible to extend in any way to get this behavior.
>
> /Anders
>
> On Wed, Jun 1, 2011 at 06:08, Phillip Hellewell  wrote:
>
> > Does Maven 3.x support any strategies other than "nearest definition" for
> > transitive dependency mediation?
> >
> > Specifically I am interested in if it has the ability to use the "highest
> > version #" found anywhere in the dependency tree.
> >
> > Phillip
> >
>

Re: SNAPSHOT's in Maven Central

[Juven Xu]

Here is the JIRA project where you can create tickets if you see any problem
in Maven Central.

On Tue, May 31, 2011 at 4:31 PM, Karl Heinz Marbaise wrote:

> Hi Baptiste,
>
>
>  Just for information: did you care about it because you found it and
>> wanted
>> to improve central, or because you ended up downloading it locally? You
>> sure
>> use a local maven repository manager?
>> Using a nexus locally repository, I'm pretty sure you would just not see
>> those snapshots because of the repository policy management, isn't it?
>>
> I just saw the SNAPSHOT's by accident via searching some other
> artifacts...so i decied to give this information to improve the quality of
> Maven Central...i had no problem with downloading artifacts...and yes i'm
> using a repository manager...
>
>
> Kind regards
> Karl Heinz Marbaise
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Why can't 'mvn site' find a grand-parent pom?

[Michael Remijan]

I'm using Maven 3.0.2 and when I execute 'mvn site' I get errors saying Maven 
cannot find one of my pom files.  The error is:

[INFO] --- maven-site-plugin:2.1:site (default-site) @ ferris-bible-jmce ---
Downloading: 
http://repo1.maven.org/maven2/org/ferris/ferris-standard-project/0.0.2/ferris-standard-project-0.0.2.pom
[INFO] Unable to load parent project from a relative path: 1 problem was encount
ered while building the effective model for org.ferris:ferris-bible-parent:0.0.4

I have 2 questions:
1) Why isn't Maven looking for the file in .m2/repository/ ?  The POM is 
already there.

2) Why is Maven only look in "http://repo1.maven.org/maven2"; for the pom and 
not look through the rest of  entries in my settings.xml? 

Re: Pretty-printing/compressing HTML in post-site phase

[Andreas Sewe]

Kathryn Huxtable wrote:

My purpose in writing htmlfilter-site-maven-plugin was to better incorporate 
docbkx-tools output into Doxia-generated output.


Yes, that seems to be the rationale for the maven-tidy-plugin 
 as well, 
although this plugin seems to allow one to configure JTidy. 
Unfortunately, it is not available in central. :-(


Best wishes,

Andreas

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

Re: Alternative dependency mediation

[Phillip Hellewell]

Cool, thanks!  I might just look into that.

Phillip

On Wed, Jun 1, 2011 at 3:28 AM, Leonard Ehrenfried <
leonard.ehrenfr...@web.de> wrote:

> We tried to change the version *range* resolution strategy once at my old
> company. We found that this component is not injected by the DI container
> but rather instantiated with 'new'.
>
> A colleague of mine wrote a patch and opened a ticket [1] that does exactly
> that. We didn't end up using the patch ourselves but maybe it can give you
> a
> clue where you need to be looking.
>
> [1] http://jira.codehaus.org/browse/MNG-5017
>
> Lenni
>
>
> On Wed, Jun 1, 2011 at 6:39 AM, Anders Hammar  wrote:
>
> > No, it doesn't. At least not out-of-the-box. I don't know if it would be
> > possible to extend in any way to get this behavior.
> >
> > /Anders
> >
> > On Wed, Jun 1, 2011 at 06:08, Phillip Hellewell 
> wrote:
> >
> > > Does Maven 3.x support any strategies other than "nearest definition"
> for
> > > transitive dependency mediation?
> > >
> > > Specifically I am interested in if it has the ability to use the
> "highest
> > > version #" found anywhere in the dependency tree.
> > >
> > > Phillip
> > >
> >
>

Re: Pretty-printing/compressing HTML in post-site phase

[Kathryn Huxtable]

On Jun 1, 2011, at 9:54 AM, Andreas Sewe wrote:

> Kathryn Huxtable wrote:
>> My purpose in writing htmlfilter-site-maven-plugin was to better incorporate 
>> docbkx-tools output into Doxia-generated output.
> 
> Yes, that seems to be the rationale for the maven-tidy-plugin 
>  as well, 
> although this plugin seems to allow one to configure JTidy. Unfortunately, it 
> is not available in central. :-(

Mine is available on my github site 
(http://github.com/khuxtable/htmlfilter-site-maven-plugin) and you could clone 
it and modify it. It uses JTidy, so you could strip out the stuff you didn't 
want and change the JTidy configs. It's Apache licensed, so no worries.

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

Re: Why can't 'mvn site' find a grand-parent pom?

[Dennis Lundberg]

On 2011-06-01 16:18, Michael Remijan wrote:
> I'm using Maven 3.0.2 and when I execute 'mvn site' I get errors saying Maven 
> cannot find one of my pom files.  The error is:
> 
> [INFO] --- maven-site-plugin:2.1:site (default-site) @ ferris-bible-jmce ---

Note that maven-site-plugin 2.1 is not compatible with Maven 3. Please
use version 3.0-beta-3.

> Downloading: 
> http://repo1.maven.org/maven2/org/ferris/ferris-standard-project/0.0.2/ferris-standard-project-0.0.2.pom
> [INFO] Unable to load parent project from a relative path: 1 problem was 
> encount
> ered while building the effective model for 
> org.ferris:ferris-bible-parent:0.0.4

This is a standard error message in Maven 3. It occurs when Maven is
building a project and cannot find the parent of the project using
 / . See

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ParentPOMResolution

> I have 2 questions:
> 1) Why isn't Maven looking for the file in .m2/repository/ ?  The POM is 
> already there.
> 
> 2) Why is Maven only look in "http://repo1.maven.org/maven2"; for the pom and 
> not look through the rest of  entries in my settings.xml? 


-- 
Dennis Lundberg

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

enforcer and reporting

[Benson Margulies]

Has anyone ever considered a reporting plugin associated with the
enforcer to report 'what did it look at and why was it ok?'

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

Re: Maven 3.0 Artefact/Dependency version discussion request

[Russ Tremain]

At 9:26 PM +0200 5/29/11, Arnaud Héritier wrote:
>For now it is just impossible to use properties in GAV for various technical
>and also philosophical reasons.


I still don't see why the maven deployment plugin cannot be responsible for 
hardening artifact properties inside deployed poms.
The help plugin goal help:effective-pom does this for example.

This would effectively synchronize the external location of the artifact with 
the contents of the artifact's pom.

/r


>You may not be agree with the philosophy behind this choice but it is sure
>that for now it is more secure in Maven to avoid this usage as it creates
>many issues.
>
>About the philosophy even if I can be agree that having in the project
>version the one of the SCM may be useful it is with really few SCMs.
>For exemple with CVS it is impossible as each file has a different version.
>And For a DSCM like Git & co your version will be a hash and thus you won't
>be able to sort them.
>
>Arnaud
>
>
>On Thu, May 26, 2011 at 5:24 PM, Manfred Moser  wrote:
>
>> Why dont you use the buildnumber plugin? That might be able to do it for
>> you..
>>
>> http://mojo.codehaus.org/buildnumber-maven-plugin/
>>
>> > For what it's worth, I agree with you both (version strings should be
>> > controlled via the -ahem- version control system), but I am willing to
>> > allow Maven (more to the point, the maven-release-plugin) to take care
>> > of the version strings for me.
>> >
>> > However, if you don't want to, you can still do it yourself with Maven
>> > 3 ... but you *can't* do it with properties at the command-line; you
>> > *will* need to update the poms.  Just do it outside of maven before
>> > you perform the final build - should not be hard.  If doing that is
>> > too much to ask ... then, yeah, Maven may not be the right framework
>> > for you.  But consider that you will need to do *something* similar --
>> > either you write your own around maven, or you write your own around
>> > some other system.
>> >
>> > On Tue, May 17, 2011 at 11:12 AM, Russ Tremain 
>> > wrote:
>> >> +1.
>> >>
>> >> this is the major reason I won't be upgrading to maven 3.
>> >>
>> >> I do think that versions should be fixed at maven deploy time - i.e.,
>> >> when artifacts are deployed to the repository.
>> >>
>> >> -Russ
>> >>
>> >> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>> >>>Hi,
>> >>>
>> >>>I am also getting grief from maven for using variables in my version
>> >>> fields.
>> >>>For me, this is unavoidable. Let me explain...
>> >>>
>> >>>In my parent pom I have:
>> >>>
>> >>>${productVersion}
>> >>>
>> >>>And in my properties I have:
>> >>>
>> >>>0-SNAPSHOT
>> >>>13.0.${productRevision}
>> >>>
>> >>>On a developer's machine, this produces a version number of
>> >>>
>> >>> 13.0.0-SNAPSHOT
>> >>>
>> >>>Which is exactly what I want.
>> >>>
>> >>>However, in my hudson CI server, as part of the maven command I have:
>> >>>
>> >>>  -DivpnRevision=$SVN_REVISION-nt3
>> >>>
>> >>>The $SVN_REVISION variable is provided by hudson. It contains the svn
>> >>>revision number that has just been built, and the '-nt3' bit is the
>> >>>environment it was built for.
>> >>>
>> >>>I do this because subversion is my revision control system and it,
>> >>> rightly,
>> >>>controls the revision number (the clue as to it's purpose is in it's
>> >>> name).
>> >>>This is not a job I want to hand off to maven, for many reasons.
>> >>>
>> >>>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij)
>> >>> are
>> >>>totally messed up -- maven 3 messes up the classpath because it can't
>> >>> deal
>> >>>with the variables. So, I'm stuck on maven 2.
>> >>>
>> >>>Now, I don't see this as providing the slightest obstacle to my ability
>> >>> to
>> >>>get repeatable builds. Rather, it's the opposite -- if I want to repeat
>> >>> a
> > >>>build all I have to know is the subversion revision number of the build
>> >>> I
>> >>>want and I can check out that revision and rebuild to recreate an exact
>> >>> copy
>> >>>of the original.
>> >>>
>> >>>Just because maven thinks that an alternative approach is 'convention'
>> >>>doesn't mean that I shouldn't be able to achieve this. CoC is supposed
>> >>> to
>> >>>allow one the choice of following convention, but provide the ability to
>> >>> use
>> >>>configuration where the convention does not fit one's requirements.
>> >>>
>> >>>So, what to do?
>> >>>
>> >>>Bryan
>> >
>> > -
>> > 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