../parent/pom.xml
> >>>
> >>
> >> WTF? How is this possible? Who signed this? The API should be completely
> >> decoupled of Weld. The repo is burried in the parents. This is
> >> absolutely unacceptable. It leaks now in the entire bu
If you configure a constant value in your POM then that takes precedence
over values from the command-line.
If you want to make the value configurable on the command-line and have a
default value in your POM then the recommended approach is to introduce a
property:
some-default-value
.MAX_VALUE)
to RedissonSyncContextFactory - this will give that component the highest
priority, so it will always appear before any other implementation of that
interface.
On Wed, 12 Aug 2020 at 10:17, Stuart McCulloch wrote:
> The issue is indeed with AetherModule which is installed b
this could be done.
On Tue, 11 Aug 2020 at 12:07, Michael Osipov wrote:
> Am 2020-08-11 um 11:48 schrieb Stuart McCulloch:
> > JSR330 annotation scanning is enabled for all realms including
> > extensions, so it should be picked up.
> >
> > Does the replacement impleme
JSR330 annotation scanning is enabled for all realms including
extensions, so it should be picked up.
Does the replacement implementation have the same "hint" or name?
ie. @Named("default")
You can turn on detailed container logging with -Dsisu.debug which will log
all bindings discovered in
It looks like you're missing the tag inside the
list:
https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
try:
javax.ejb
jakarta.ejb
javax.ejb.*
On Mon, 4 May 2020 at
Java version: 11.0.5, vendor: Private Build, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family:
> "unix"
The Java 11 warning mentions that "/usr/share/maven/lib/guice.jar" has a
class named "com.google.inject.internal.cglib.core.$ReflectUtils$1"
This looks suspect because the official Maven distribution uses the
"no-AOP" version of Guice which doesn't contain any CGLIB classes. It
suggests that
How are you replacing them currently?
The typical way is to use the extensions mechanism:
https://maven.apache.org/docs/3.3.1/release-notes.html#Core_Extensions
Components contributed via an extension have a higher priority over the
original component in core (assuming that they have the same
ModelResolver isn't a component and therefore isn't available for injection
- I can see two implementations of that interface in Maven, but both are
manually created:
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java#L276
I believe that's true for the current releases, but it looks like it will
change in the future:
https://github.com/AdoptOpenJDK/openjdk-build/issues/465
On Sun, 4 Nov 2018 at 19:46, Elliot Huntington
wrote:
> Now that Oracle is charging licensing fees to use Oracle Java as of Java
> 11, I am
On 3 Feb 2017 16:44, "Laird Nelson" wrote:
On Fri, Feb 3, 2017 at 1:15 AM Hervé BOUTEMY wrote:
> notice:@Component we're using in a Mojo is from Maven Plugin Tools
> org.apache.maven.plugins.annotations.Component [1]
>
Right; I (now :-)) understand
Here's a brief overview of the different layers...
Maven plugin annotations are only used at plugin build time to generate
Maven's plugin.xml - they are not used at runtime (at least the container
doesn't use them)
Maven uses this plugin.xml descriptor to setup the plugin in Plexus
(creating the
d
> >
> > So my change should be good for commit for 3.4?
> >
> > -Dan
> >
> > On Sun, Nov 13, 2016 at 3:01 PM, Stuart McCulloch <mccu...@gmail.com
> > (mailto:mccu...@gmail.com)>
> > wrote:
> >
> > > Hi Dan,
> >
able to get
> @PostContruct working yet
>
> Thanks
>
> -Dan
>
> On Sun, Sep 11, 2016 at 7:27 PM, Dan Tran <dant...@gmail.com
> (mailto:dant...@gmail.com)> wrote:
>
> > Thanks Stuart, very much appreciated
> >
> > -D
> >
> > On Sun, Sep
You could write a custom enforcer rule to check the classifier of projects
with particular groupIds:
http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html
Then configure the enforcer plugin to apply that rule in your corporate pom
or wherever you want to enforce it...
On 22
nt...@gmail.com
> > (mailto:dant...@gmail.com)> wrote:
> >
> > > here you go https://issues.apache.org/jira/browse/MNG-6084
> > >
> > > Very much appreciated
> > >
> > > -Dan
> > >
> > > On Fri, Sep 2, 2016 at 8
)
>
> should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
Sure - send me the ticket number and I’ll add some commentary this weekend
> looking forward to use it
>
> Thanks
>
> -Dan
>
>
>
> On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch &
Hi Dan,
Constructor injection (and component injection) is working for me with Maven
3.3.9 if I follow the example in http://maven.apache.org/maven-jsr330.html
Is your plugin code available somewhere?
PS. at the moment Maven doesn’t enable container support for JSR-250 lifecycle,
but it
If you don’t configure a specific version in your pom for one of the standard
plugins, Maven will use the version specified in the default lifecycle bindings.
For example Maven 3.3.3, defaults to maven-compiler-plugin 3.1:
On Monday, 25 May 2015 at 09:46, WonderCsabo wrote:
The documentation says it includes these resources by default, but apparently
it never does.
After examining the code, it seems CheckstyleViolationCheckMojo.execute()
forgets to call request.setTestResources(), hence that is always null and
The log shows that it’s looking for artifacts with an extension of ‘bundle’,
whereas the bundle packaging type actually produces artifacts with an extension
of ‘jar’ - this suggests that the bundle lifecycle extension has not been
installed for the itest project.
What does the sip-detection
schrieb Stuart McCulloch mccu...@gmail.com:
I see you're declaring dependencies with typebundle/type whereas you
should just leave them with the default type (jar). While the packaging
type is bundle (to activate the different packaging lifecycle) the
artifacts produced are declared
I see you're declaring dependencies with typebundle/type whereas you
should just leave them with the default type (jar). While the packaging
type is bundle (to activate the different packaging lifecycle) the
artifacts produced are declared as type jar and can be referenced as
dependencies with the
On Thursday, 19 March 2015 at 10:41, Markus Karg wrote:
As I said I cannot reproduce the bug anymore, so do you think the requested
test makes any sense still?
The Nexus system feeds record authz/authc events as well as any upload attempts:
Assuming you’re using Maven 3.1.1 or later then yes, that should work.
--
Cheers, Stuart
On Monday, 16 March 2015 at 18:09, Cristiano Gavião wrote:
Hello,
I've create a mojo and set it to use sisu based injection.
I added to this mojo a constructor like this:
@Inject
public
Use the jar-no-fork and test-jar-no-fork goals of the maven-source-plugin -
these won’t fork the build (which is what is causing initialize to run multiple
times)
On Thursday, 15 January 2015 at 16:24, org.apache.maven.u...@io7m.com wrote:
Hi.
I have a custom plugin that inserts some
On Monday, 8 December 2014 at 16:24, Paul Benedict wrote:
I configured the WAR plugin to overlay a zip file. Nothing fancy. Here's
the config:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.5/version
configuration
overlays
Does your pom have a release profile that executes gpg signing? ie. like in
https://github.com/sonatype/oss-parents/blob/master/forge-parent/pom.xml
On 9 Nov 2014 11:51, Simon Taddiken simon.taddi...@gmail.com wrote:
Hi,
I'm trying to introduce a common parent pom for my projects. So I have
On Wednesday, 22 October 2014 at 14:08, Michal Konopa wrote:
Hello all,
I'm experimenting a little bit with aggregating Javadoc from dependency
sources - according to:
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html
document.
I put the
On 19 Sep 2014 09:09, Edmond chouaffé e...@in-telegence.net wrote:
Hi guys.
I have been struggling to get systemPropertyVariables from the
maven-surefire-plugin working.
I am running an ubunto machine where I have defined the JBOSS_HOME
variable as such in the .profile file: export
On 19 Sep 2014 11:12, Stuart McCulloch mccu...@gmail.com wrote:
On 19 Sep 2014 09:09, Edmond chouaffé e...@in-telegence.net wrote:
Hi guys.
I have been struggling to get systemPropertyVariables from the
maven-surefire-plugin working.
I am running an ubunto machine where I have defined
I wonder if this might be related to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=418250 ?
On 27 Aug 2014, at 04:35, Juven Xu juvens...@gmail.com wrote:
maven: 3.1.1
jdk: 1.7.0_25 Java HotSpot(TM) Server VM (build 23.25-b01, mixed mode)
the error message is:
[INFO] Building
Each Maven distribution has various built-in defaults, you can see the defaults
for 3.2.1 here:
https://github.com/apache/maven/blob/maven-3.2.1/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
The compiler plugin is explicitly set to 2.5.1 unless you override the version
I don’t believe it ever existed on central, IIRC it’s a placeholder used by
m2e: http://stackoverflow.com/a/7423909
On 16 May 2014, at 20:48, Dan Tran dant...@gmail.com wrote:
any one?
http://central.maven.org/maven2/org/eclipse/m2e
Thanks
-D
On Thu, May 15, 2014 at 4:34 PM, Dan
On 16 May 2014, at 22:59, Dan Tran dant...@gmail.com wrote:
umm, what worries me why it disappears from maven central which suppose to
be a well guarded place?
It has not disappeared as it was never on central in the first place - it's
just a placeholder GAV that m2e uses for configuration
Also check your java imports, just in case you’ve imported a different Logger
by mistake (such as java.util.logging.Logger)
On 30 Apr 2014, at 12:48, Nick Stolwijk nick.stolw...@gmail.com wrote:
You can use the dependency:tree[1] goal to view a tree of your
dependencies to see if the correct
See
http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3ca70f13ef-38e2-49a8-b696-b5e592092...@gmail.com%3e
for why this is happening
AFAICT neither of the suggested solutions mentioned in the above email have
been applied to DefaultClassRealmManager, so I believe this is still an
to that maven-dev
discussion.
Martin Grigorov
Wicket Training and Consulting
On Thu, Apr 17, 2014 at 5:12 PM, Stuart McCulloch mccu...@gmail.com wrote:
See
http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3ca70f13ef-38e2-49a8-b696-b5e592092...@gmail.com%3efor
why this is happening
library that is a
different version of the running Maven instance?
You can’t without doing some complicated class loader hacks, this is a
fundamental feature of Maven’s plugin system.
William
On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch mccu...@gmail.comwrote:
On 28 Feb 2014, at 01:17
On 28 Feb 2014, at 01:17, William Ferguson william.fergu...@xandar.com.au
wrote:
As part of the development of the android-maven-plugin we have need to add
in an AbstractMavenLifecycleParticipant so that we can modify the compile
classpath to add artefacts that are contained within a
On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote:
Hi Mirko,
I think though 6 days!!! should be adequate for that.
In fact, I think 6 minutes should be adequate.
So I really need someone to explain how I can move forward with this issue.
FWIW, I did a search today for
instance (enabled to download remote indexes)
But I just tried from a fresh installation with the default repo to confirm
and it is in the latest index with nexus.index.timestamp=20140216125157.106
All the best,
DaveLaw
On 16.02.2014 14:36, Stuart McCulloch wrote:
On 16 February 2014 10:31
On 15 February 2014 11:13, 454329 abhi454...@gmail.com wrote:
Hi there ,
I have this dependency present in my pom.xml .
dependency
groupIdorg.apache.solr/groupId
artifactIdsolr-cell/artifactId
version4.0/version
Did
On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.com wrote:
On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net
wrote:
Hi Dan,
Not sure what you mean. You say CI, are you taking about a specific
server? If Jenkins for example, wouldn't it then be more a Jenkins
On 13 Feb 2014, at 17:46, Dan Tran dant...@gmail.com wrote:
A contributor for MOJO-2006 [1] uses array configuration at
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html (
array session)
here is the text
/**
* My List.
*/
@Parameter
private
On 5 Feb 2014, at 13:23, Melvyn de Kort mel...@mdekort.nl wrote:
Our maximum heap size is already 4G, can't increase that any more I'm
afraid.
It could be running out of PermGen space, which is controlled by a different
setting:
MAVEN_OPTS=-XX:MaxPermSize=256m
Regards,
Melvyn de
On 3 Feb 2014, at 14:34, Benson Margulies bimargul...@gmail.com wrote:
Does anyone recognize the following? It correlates with a mystery.
Looks like http://jira.codehaus.org/browse/MASSEMBLY-671 … basically it happens
when there’s a problem with the assembly descriptor which then triggers a
On 3 Feb 2014, at 14:44, Stuart McCulloch mccu...@gmail.com wrote:
On 3 Feb 2014, at 14:34, Benson Margulies bimargul...@gmail.com wrote:
Does anyone recognize the following? It correlates with a mystery.
Looks like http://jira.codehaus.org/browse/MASSEMBLY-671 … basically it
happens when
On 15 Jan 2014, at 08:20, Mikael Petterson mikael.petter...@ericsson.com
wrote:
Hi,
New try :-)
I have the following:
Interface in dependency jar javadoc:
/**
* Deletes the object found at the specified location.
*
* @param Object any type of object
* @throws
On 5 Jan 2014, at 13:15, Tommy Svensson to...@natusoft.se wrote:
I was asked to submit one of my opensource tools at github to maven central.
This turned out to be a rather complex procedure.
[ disclaimer: I work at Sonatype ]
Any suggestions for improving the process are welcome - most of
On 19 Dec 2013, at 15:31, Jeremy Whiting jwhit...@redhat.com wrote:
Hi,
I am using the maven-plugin-plugin for a hibernate project to provide a user
plugin. I am finding the Mojo definition is not generated. I found a
workaround for the issue. This discussion is related to the issue
Looks like a shading issue in maven-wagon/wagon-providers/wagon-http:
https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=wagon-providers/wagon-http/pom.xml;h=1fd61e34da435024062a566f6bd68410d98fdc67;hb=HEAD#l87
It doesn’t shade in commons-io, commons-lang, or jsoup;
/browse/WAGON-407
-D
On Mon, Dec 16, 2013 at 9:38 AM, Stuart McCulloch mccu...@gmail.com wrote:
Looks like a shading issue in maven-wagon/wagon-providers/wagon-http:
https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=wagon-providers/wagon-http/pom.xml;h
You could try replacing:
maven-3.1.1/boot/plexus-classworlds-2.5.1.jar
with:
maven-3.0.5/boot/plexus-classworlds-2.4.jar
in case the change to use unsynchronised class loading in classworlds 2.5 when
running on Java 1.7 is causing the issue.
On 5 Dec 2013, at 16:32, Collins
On 2 Dec 2013, at 11:15, Adrien Ruffié adriennolar...@hotmail.fr wrote:
I have found more information here:
http://stackoverflow.com/questions/19266797/different-compilation-behavior-w
ith-type-cast-between-eclipse-and-maven/19267547#19267547
that say:
Eclipse comes with its own Java
1.7 to use the eclipse compiler in Maven,
just use the plugin configuration shown below and Maven will compile your code
using the eclipse compiler (also known as ecj).
-Message d'origine-
De : Stuart McCulloch [mailto:mccu...@gmail.com]
Envoyé : lundi 2 décembre 2013 15:35
À : Maven
Looks like http://jira.codehaus.org/browse/PLXCOMP-208 which was fixed in
plexus-archiver-2.2.
Which plugin was executing before the error? It should hopefully just be a
matter of updating your pom.xml to use a more recent version of the plugin
which depends on plexus-archiver-2.2 or later.
Update the lib-jenkins-maven-embedder dependency to version 3.11, since this is
the version that works with the latest aether/sisu dependencies.
On 20 Nov 2013, at 09:41, Bernd Adamowicz wrote:
No answer so far. Should I file a bug? Any opinion?
Bernd Adamowicz
-Original
Try adding:
typeplugin/type
to those 2 dependency exclusions.
( the jaxen pom:
http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pom
declares those dependencies to be of type plugin )
On 14 Nov 2013, at 13:14, Jason Tesser wrote:
I have the following POM
, Jason Tesser wrote:
you are referring to the maven-plugins I think
But what about the xml-api thing?
On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.com wrote:
Try adding:
typeplugin/type
to those 2 dependency exclusions.
( the jaxen pom:
http
artifactIdmaven-cobertura-plugin/artifactId
typeplugin/type
/exclusion
On Thu, Nov 14, 2013 at 9:32 AM, Jason Tesser jasontes...@gmail.com wrote:
you are referring to the maven-plugins I think
But what about the xml-api thing?
On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu
BTW, I ran your pom.xml through:
mvn dependency:tree
using Maven3 and the exclusions for those 2 maven-plugins were respected, which
suggests your exclusion issue might also be specific to Gradle.
On 14 Nov 2013, at 14:53, Stuart McCulloch wrote:
You mean the POM relocation
Looks like a JDK issue, because I can recreate it by just using 'javac'
( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391197 seems the closest
match )
As a workaround, move the import pack.Prop; line above the static import and
it should compile.
On 12 Nov 2013, at 11:51, Adrian
Looking at the *MetadataSource components in the Maven source they're only
bound under:
org.apache.maven.artifact.metadata.ArtifactMetadataSource
and not:
org.apache.maven.repository.legacy.metadata.ArtifactMetadataSource
For example in MavenMetadataSource.java:
You can use requiresDependencyResolution (as Anders mentioned below) to choose
the initial scope of what gets populated into project.getArtifacts
You can also use maven-common-artifact-filters to filter those artifacts
further by scope, groupId, artifactId, etc:
Some related reports from 2011:
https://jira.codehaus.org/browse/MJAR-142
https://jira.codehaus.org/browse/MWAR-255
AFAICT the PlexusIoFileResource is effectively doing
setLastModified(file.lastModified()) to
On 3 Oct 2013, at 11:11, Anders Hammar wrote:
It should be the same for deps as well as parents. One difference could be
if you have a repo declared in the pom (not setiings.xml). It might be that
that repo is only used for deps and not the parent, I don't know.
FWIW, I've run some tests
The scenario described below fails for me with or without a mirror setting - as
I would expect it to.
Given a child project with a missing parent pom Maven will attempt to resolve
the parent given the available context, namely:
settings.xml
current pom.xml
Maven's
On 3 Oct 2013, at 14:31, NRO wrote:
Thanks for the clear explanation.
All our artifacts are served by our Nexus Repository Manager (external and
internal).
All our repositories (hosted and proxy) are managed by Nexus, this is why
our settings.xml and parent poms does not need to refer to
-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=82b345e0094813b34fcac85e64dde2d5e02b4cc9
Thanks,
Bernd
On Thu, 19 Sep 2013 23:52:20 +0200, Stuart McCulloch mccu...@gmail.com
wrote:
Maven 3.1.0 was released after the Maven runtime project moved to git:
https://git-wip
On 24 Sep 2013, at 01:31, Jamie Archibald wrote:
I typically work behind a Nexus server at work which I use a settings.xml
file. When I come home I remove the settings.xml from my m2 folder.
As soon as I do this I can no longer resolve my maven dependencies that are
my work modules, even
Maven 3.1.0 was released after the Maven runtime project moved to git:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=summary
Specifically:
On 18 Sep 2013, at 15:09, Paul Benedict wrote:
I believe this behavior is correct. IIRC, XML does not allow double-dashes
inside a comment.
Specifically http://www.w3.org/TR/REC-xml/#sec-comments
For compatibility, the string -- (double-hyphen) must not occur
within comments.
On
Wagon is trying to apply a given configuration, but it fails because it has a
property that doesn't exist in the chosen wagon provider.
Which version of Maven (and Wagon) are you using? Do you have a
httpConfiguration section in your settings.xml?
On 18 Sep 2013, at 21:37, Richard Sand wrote:
Since Maven3 this class is available in the maven-compat component:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-compat%22
Note that plugins compiled against the old maven-artifact component should
still work with Maven3 (it gets translated
On 9 Jul 2013, at 18:47, Richard Sand wrote:
Ah, simple solutions... :-)
Now I'm onto the next similar problem, getting a JarArchiver. I'm getting 1)
No implementation for org.codehaus.plexus.archiver.jar.JarArchiver was bound.
In the 2.0 plugin I'm attempting to migrate, it has the
On 3 Jul 2013, at 22:05, Mirko Friedenhagen wrote:
Hello Robert,
thanks for the quick answer, however I still get the same error :-(.
It looks like you have mismatched tags on line 27 of your components.xml:
validateorg.apache.maven.plugins:maven-enforcer-plugin:enforce/package
Regards
On 2 Jul 2013, at 11:52, Salva Vilarrasa wrote:
Hello,
My name is Salva and are preparing some slides to give a technical
presentation on Maven 3 and while preparing the slides i wanted to
introduce the changes from Maven 2 to Maven 3 and the compatibility issues
people may encounter but the
I'm still unable to recreate this locally, even when using a project with
exactly the same layout/hierarchy as the one from that gist.
Does this happen when building from the command-line, or is there another
step involved? Such as building from an IDE or from CI?
On 30 May 2013 08:50, Simone
On 31 May 2013, at 22:04, Loyall, David wrote:
Hello.
My maven installation has had some trouble downloading artifacts today.
hobbes@metalbaby:~/scratch$ mvn
org.apache.maven.plugins:maven-dependency-plugin:2.8:get
-Dartifact=org.springsource:spring-jdbc:3.2.3.RELEASE
[INFO]
Spring artifacts are deployed under a groupId of org.springframework, not
org.springsource:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.springframework%22
On 31 May 2013, at 22:17, Richard Vowles wrote:
It does appear dead,
http://repo1.maven.org/maven2/org/springsource/
On 29 May 2013, at 10:49, Simone Tripodi wrote:
Hi all mates,
I am updating a set of old Maven plugins using Mvn3+Aether APIs, but
unfortunately I am no longer able to run Mvn tests due to
org.sonatype.guice.bean.reflect.Logs class cannot be found in the
classpath, follows below the
found the extra
choice confusing).
Many thanks for your help and have a nice day!
All the best,
-Simo
[1] https://gist.github.com/simonetripodi/5670183
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, May 29, 2013 at 12:05 PM, Stuart McCulloch mccu
Have you tried restarting the affected slave? The remote class cache might be
holding onto an old/broken class.
On 12 Apr 2013, at 08:31, Johannes Pfeifer wrote:
Hello Maven users,
We use Maven and Jenkins to build our java products. Our builds broke the
maven repositories yesterday,
On 8 Mar 2013, at 16:54, Thomas Koch wrote:
Thomas Koch:
[DEBUG] Using 0 mojo extractors.
I could track down the problem. The field mojoDescriptorExtractors in the
DefaultMojoScanner class is not filed by plexus with the available extractors
although they should be available on the
On 11 Mar 2013, at 21:28, Thomas Koch wrote:
Stuart McCulloch:
Perhaps you could post a link to your re-packaging build so people can
recreate the issue? There's not enough information here to debug the
problem remotely.
http://anonscm.debian.org/gitweb/?p=pkg-java/maven-plugin-
tools.git
On 31 January 2013 21:29, Martin Gainty mgai...@hotmail.com wrote:
Gentlemen
I found a consistent bug with PluginManager not able to locate @goal/** *
artifactId=modello-maven-plugin
* @author a href=mailto:tryg...@inamo.no;Trygve Laugstøl/a
* @version 1.5
* @threadSafe
*/
public
On 1 February 2013 12:04, Martin Gainty mgai...@hotmail.com wrote:
Stuart
Yes i agree that the PluginManager *should* be discovering the implementor
at mojo implementation for Java class but instead pulls in
AbstractModelloGeneratorMojo which extends AbstractMojo
Remember to attach your
On 5 Nov 2012, at 09:30, Stadelmann Josef wrote:
my svn trunk update has
Completed: At revision: 1405720
using maven 3.0.5-snapshot to build maven 3.1-snapshot
Any particular reason why you're using one unreleased snapshot to build a
different snapshot?
it always fails when building
On 1 November 2012 10:29, Stadelmann Josef
josef.stadelm...@axa-winterthur.ch wrote:
How can I cure best the problems shown below? it occurs during a
bootstrap-build of maven-3/trunk on my Vista System.
(see red lines, which are of interesst to me).
I have successfully build from sources
-Ursprüngliche Nachricht-
Von: Stuart McCulloch [mailto:mccu...@gmail.com]
Gesendet: Donnerstag, 1. November 2012 14:52
An: Maven Users List
Betreff: Re: [maven-3/trunk] bootstrap-build failing
On 1 November 2012 10:29, Stadelmann Josef
josef.stadelm...@axa-winterthur.ch wrote:
How can I cure
On 4 Oct 2012, at 19:22, Davis Ford wrote:
This doesn't make a whole lot of sense to me. Any idea what the problem is
here?
You've given the jersey-server dependency a scope of runtime which means it
is on the runtime and test classpaths, but _not_ the compile classpath,
therefore the class
Bugs can be reported on the github site: https://github.com/bndtools/bnd or via
the Apache Felix project. You should also try the latest 2.4.0-SNAPSHOT of the
bundleplugin, as this uses the latest bndlib code which is expected to be
released soon.
--
Cheers, Stuart
On 21 Sep 2012, at 01:04,
On 12 Aug 2012, at 03:54, Wayne Fay wayne...@gmail.com wrote:
I'm also using the Apache Felix bundle-plugin which allows for:
packagingbundle/packaging
This is not a packaging delivered by Apache Maven. Thus you can
blame whoever is making this packaging available to you.
That
On 27 July 2012 14:05, Matthias Pfeifer mpfeife...@gmail.com wrote:
Hello,
I have a jar file that i plan to add to a projects dependencies. I
need to test this jar file as a dependency of some project and
therefore did
$ mvn -l mvn.log -e -X install:install-file -Dfile=myartifact.jar
Also be aware of an issue using JDK7 to compile against the official OSGi 4.3
API jars...
http://stackoverflow.com/questions/10911231/how-to-compile-mavenized-osgi-4-3-bundle-with-openjdk-7
Solutions are to either use JDK6, or use the recently released OSGi 5.0 API
jars, or rebuild the 4.3
display the full error message?
probably related to http://jira.codehaus.org/browse/MCOMPILER-158
W dniu 2012-07-16 15:03, Stuart McCulloch pisze:
Also be aware of an issue using JDK7 to compile against the official OSGi
4.3 API jars...
http://stackoverflow.com/questions/10911231/how
On 12 May 2012, at 07:32, Hilco Wijbenga wrote:
On 11 May 2012 22:47, Anders Hammar and...@hammar.net wrote:
This is not uncommon for large multi-module builds. You need to
increase the memory available for Maven, such as the heap depending on
the error you're getting.
Do this by setting the
expect many proxies to be generated with Maven - they're
typically only used when there are circular references between constructors.
Proxies are also loaded via the ClassLoader and consume perm gen space.
LieGrue,
strub
- Original Message -
From: Stuart McCulloch mccu...@gmail.com
1 - 100 of 229 matches
Mail list logo