Hi all,
I was a bit surprised at something I saw when a project A had an optional
dependency on B and a non optional dependency on C that had a dependency on
B.
I couldn't find any documentation about the expected behaviour but to me
the observed behaviour seems wrong, so either I am wrong and wo
Thanks again.
/James
> -Original Message-
> From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> Sent: 30 September 2014 22:00
> To: Maven Users List
> Subject: Re: Maven JXR 2.4 site.
>
> update done
>
> Regards,
>
> Hervé
>
> Le mardi 30 sep
Sorry don’t know what happened with my mailer there - hadn't finished writing
and wasn't ready for sending.
The re-direct works - but shouldn't it redirect to the plugin page rather than
the top level jxr page?
ie. Would the redirect not be better as
http://maven.apache.org/plugins/maven-jxr-p
Hi Karl
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: 30 September 2014 07:28
> To: Maven Users List
> Subject: Re: Maven JXR 2.4 site.
>
> I have created a redirect
> http://maven.apache.org/plugins/maven-jxr-plugin/ to
> http://maven.apache.org/jxr
Hi all,
The default google page when you search for maven-jxr-plugin is
http://maven.apache.org/plugins/maven-jxr-plugin/ which is version 2.3 rather
than the up-to-date http://maven.apache.org/jxr/maven-jxr-plugin/
This confused me for a while and probably will other users. Is there any
cha
> > What's the killer feature is
> > 1) automatic (zero conf) finding of artifacts / test reports /
> > findbugs report pickup etc etc...
> >
>
> Well James, you do know *you* could use templates (as you have the
> enterprise plugins ;-) ) and give a locked down build.
With literate? How - I did
Hi Stephen,
I'm not sure why you think that per module reporting is the killer feature.
For me I couldn’t give a hoot if I saw all reports from maven modules munged in
a single report or spread across 100 different pages (in fact I generally use
the top level aggregate anyway).
What's the kill
shouldn't release:branch still support this still though?
If not that's bad as you will end up with a release version on the head of
either the source branch or the new branch (and both should be used for ongoing
development so should be snapshots...)
/James
> -Original Message-
> From
> > Nowhere in that was the sources jar mentioned - yet you seemed to have
> jumped directly to a solution and then said can’t be done.
>
> No, I discussed the two paths from the POM: -sources and
My mistake, sorry.
> > There is a critical need for this inside businesses as well as Debian (how
Nowhere in that was the sources jar mentioned - yet you seemed to have jumped
directly to a solution and then said can’t be done.
There is a critical need for this inside businesses as well as Debian (how do
we know that "org.foobar:baz:1.2.3:jar" is MIT as it claims and doesn’t contain
some G
> > Or to put a contrived (yet realistic) example on this - Consider a
> > shared library Y. You have no auto testing of it so its only tested
> > inside products (otherwise you know its good to go - and wouldn't
> > release RCs).
> > Library Y is in a stage at version 1.2.3 This library is picke
I wouldn't have normally chimed in here against Stephen (He knows what he is on
about) however...
IMHO Staging only works with very small teams with dedicated infrastructure (in
which case QC generally are ok with a rebuild!).
If you have larger teams and share infrastructure (repo manager, CI)
Hi all,
The site:site and site:deply goals are not marked as threadsafe which is pretty
reasonable as it relies on the underlying reporters and wagons to be threadsafe
before it can make that contract (and not all reporters and wagons are
threadsafe - esp the default scp wagon - so it can't be
tures or relying on newer
> exposed properties hence the value in the pom.
>
> Solution for now is to bind the enforcer plugin to validate :-(
>
>
> On 14 March 2013 11:58, James Nord (jnord) wrote:
>
> > Hi all,
> >
> > I've just realised that the
Hi all,
I've just realised that the "prerequisites" section of a parent pom is not
inherited by its children.
This surprised me - but it is also documented that this section doesn't
inherit[1]
My question is is this intentional or an oversight?
We have a parent pom that mandates maven3 (and s
15 matches
Mail list logo
