Sorry for not getting back to you sooner. I was on vacation.
it is something we prepared
https://lists.apache.org/thread/07p1xyz210755qsl5gt466nyp3tdzmrs
I don't know why it did not happen in this migration
@Benjamin any idea?
The PR linking did work because the step “importing issues” failed
No, sorry, no idea. I will ask Sandra about it.
Am Do., 6. Feb. 2025 um 08:25 Uhr schrieb Herve Boutemy :
>
>
>
> On 2025/02/05 08:16:44 Guillaume Nodet wrote:
> > Searching for infos in old issues often involves switching between github
> > (for commits / PRs) and JIRAs.
> > If history can be rew
triaged again - it is manually work
> >
> > Agreed.
>
> I'd like to understand what triage we're talking about, and how the triage
> done in Jira is lost when converted into GitHub Issues, IIUC
>
About triage I think that first we should review existing issues - if
On 2025/02/05 08:16:44 Guillaume Nodet wrote:
> Searching for infos in old issues often involves switching between github
> (for commits / PRs) and JIRAs.
> If history can be rewritten, it would clearly be a benefit.
> An example:
> * https://github.com/apache/maven-jlink-plugin/issues/499
> * h
Le mercredi 5 février 2025, 07:48:53 CET Guillaume Nodet a écrit :
> Le mer. 5 févr. 2025 à 07:36, Slawomir Jaranowski
>
> a écrit :
> > I'm still not convitient if we really need copy all issues from jira
> > to github - as I wrote many times
> >
> > - jira will be exist with us
> > - I don't b
In json, you need an empty list or object ([] or {}).
As of the duplicates:
I'll send GitHub support the list of duplicates today. They were willing to
help us clean up.
As of why the first created issues where pending, they are still
investigating that. Lessons learned: next time wait and don't
On Wed, 5 Feb 2025 at 09:55, Benjamin Marwell wrote:
>
> It should have been. You're right.
> I'll talk to infra about this.
> We also disabled jira comments to the ML for migration.
>
maybe we can put an empty value in notification ...
notifications:
...
issues:
...
https://github.com/apache
It should have been. You're right.
I'll talk to infra about this.
We also disabled jira comments to the ML for migration.
On Wed, 5 Feb 2025, 09:29 Slawomir Jaranowski,
wrote:
> One more issue ... we have many notifications on ML, like:
> https://lists.apache.org/list?iss...@maven.apache.org:l
One more issue ... we have many notifications on ML, like:
https://lists.apache.org/list?iss...@maven.apache.org:lte=1M:jira-importer
Maybe it can be possible to disable notifications during migration time.
On Tue, 4 Feb 2025 at 23:42, Elliotte Rusty Harold wrote:
>
> If you look at https://gith
Searching for infos in old issues often involves switching between github
(for commits / PRs) and JIRAs.
If history can be rewritten, it would clearly be a benefit.
An example:
* https://github.com/apache/maven-jlink-plugin/issues/499
* https://github.com/apache/maven-jlink-plugin/pull/229
It would
if we don't copy, we can't search in one place: I'm often searching in issues
to get why we did something in the past (that years later looks strange, but
history helps understand)
I'd love to let some time to try before admitting we can't keep it simple in
one single place once migrated
Regar
Le mer. 5 févr. 2025 à 07:36, Slawomir Jaranowski
a écrit :
> I'm still not convitient if we really need copy all issues from jira
> to github - as I wrote many times
>
> - jira will be exist with us
> - I don't believe that users before creating new issue look for old -
> if yes they have a link
I'm still not convitient if we really need copy all issues from jira
to github - as I wrote many times
- jira will be exist with us
- I don't believe that users before creating new issue look for old -
if yes they have a link to old issues
- many issues should be triaged again - it is manually wor
We are on contact with GitHub support. Please refrain from manually closing
them for now.
Before that, some were not displayed, were in status pending, which
effectively made them missing.
I'll keep you posted.
On Tue, 4 Feb 2025, 23:44 Elliotte Rusty Harold, wrote:
> If you look at https://
If you look at https://github.com/apache/maven-jlink-plugin/issues
you'll notice that all the issues from the Jira have been copied into
github multiple times.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail
Yes, those not in maven-api-impl are deprecated (should be marked as such).
This is true for all classes that have counterpart (copy) in api-impl.
T
On Sun, Sep 22, 2024, 13:52 Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Hello
>
> I just realized that there is two "DefaultMo
Hello
I just realized that there is two "DefaultModelPathTranslator" classes
with almost identical code: one in the "maven-model-builder" module and
one in the "maven-api-impl" module. I presume that one of them is
deprecated in the favor of the other? If so, can we put a @Deprecated
annotati
Le 2024-09-21 à 17 h 45, Tamás Cservenák a écrit :
PR seems ok
https://github.com/apache/maven/pull/1735
@Martin Desruisseaux pls confirm is this what you had in mind?
Yes, this is my guess of what was intended. Thanks!
Martin
---
PR seems ok
https://github.com/apache/maven/pull/1735
@Martin Desruisseaux pls confirm is this what you had in mind?
@Guillaume Nodet pls confirm the intent (and the assumption was it a
bug, or we overlooked something?)
T
On Sat, Sep 21, 2024 at 4:57 PM Tamás Cservenák wrote:
>
> Lets see what
Le 2024-09-21 à 16 h 43, Tamás Cservenák a écrit :
AFAIK, as I see, the point is that it nullifies if "default" value is
present, and those come from corresponding super POM? Basically, keep
only the non-default values?
But just above that method, there is another method which performs the
Lets see what this PR does
https://github.com/apache/maven/pull/1735
I agree with Martin, it really looks "sus"...
T
On Sat, Sep 21, 2024 at 4:49 PM Guillaume Nodet wrote:
>
> AFAIK, the Model.pomFile is null when the model is not a « build” Pom, I.e.
> is loaded from the local repository rathe
AFAIK, the Model.pomFile is null when the model is not a « build” Pom, I.e.
is loaded from the local repository rather than a project being built.
Not sure if that applies here, I’m on phone…
Le sam. 21 sept. 2024 à 16:43, Tamás Cservenák a
écrit :
> Howdy,
>
> AFAIK, as I see, the point is that
Howdy,
AFAIK, as I see, the point is that it nullifies if "default" value is
present, and those come from corresponding super POM?
https://github.com/apache/maven/tree/45f9b81b4a8451a75864ef1c861c5bb201a54790/maven-api-impl/src/main/resources/org/apache/maven/model
Basically, keep only the non-de
Hello all
I'm starting to work on a prototype using the new build element
(a proposal for a unified replacement for ,
, , etc.) proposed in a previous discussion on
this mailing list. For starting, I'm searching for usages of
in Maven source code and I try to add codes doing
something equi
Just curious, why is such an old version of maven-dependency-plugin used in
that build?
- Eric L
On Sat, Feb 25, 2023 at 2:46 PM Elliotte Rusty Harold
wrote:
> On Sat, Feb 25, 2023 at 11:46 AM Guillaume Nodet
> wrote:
> >
> > Which goal are you running ?
> > I think you need to run the package
On Sat, Feb 25, 2023 at 11:46 AM Guillaume Nodet wrote:
>
> Which goal are you running ?
> I think you need to run the package phase as hinted by the error.
>
mvn test
also
mvn compile; mvn test
mvn clean test
mvn package; mvn test
All end with the same failure. This seems to be a regression
Which goal are you running ?
I think you need to run the package phase as hinted by the error.
Le sam. 25 févr. 2023 à 07:58, Elliotte Rusty Harold a
écrit :
> FYI, maven core tests fail for me (Java 1.8. Maven 3.8.7) when
> building at head like so. I'm not sure what to do about this:
>
> [INFO
FYI, maven core tests fail for me (Java 1.8. Maven 3.8.7) when
building at head like so. I'm not sure what to do about this:
[INFO] Unpacking
/Users/elharo/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.0/plexus-utils-3.5.0.jar
to /Users/elharo/maven/plexus-utils/target/classes with includes
che.org/blue/organizations/jenkins/maven-box%2Fmaven-si
> > te-plugin/detail/master/94/pipeline>
> > Le dimanche 24 mai 2020, 12:01:46 CEST Karl Heinz Marbaise a écrit :
> >> Hi to all,
> >>
> >> I've stumbled upon the following problem during the s
On Mon, May 25, 2020 at 2:49 AM Hervé BOUTEMY wrote:
>
> removing Maven 2 code is a good simplification
> but FYI it won't remove dependency on plexus-classworld: it's the core of all
> plugins classloading mechanism to have independant plugins
>
Yes, but there's an explicit dependency on classor
CEST Karl Heinz Marbaise a écrit :
Hi to all,
I've stumbled upon the following problem during the site generation
mojo-parent (issue-105)$ mvn site site:stage
..
[INFO]
[INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
[INFO] configuring report plugin
org.apache.maven.
g in an earlier version of plexus-utils since maven-site-plugin
> > declares that dependency directly, but that's what seems to be
> > happening.
> >
> > On Sun, May 24, 2020 at 6:02 AM Karl Heinz Marbaise
wrote:
> > > Hi to all,
> > >
> > &g
Heinz Marbaise a écrit :
> Hi to all,
>
> I've stumbled upon the following problem during the site generation
>
> mojo-parent (issue-105)$ mvn site site:stage
> ..
> [INFO]
> [INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
Heinz Marbaise wrote:
> >
> > Hi to all,
> >
> > I've stumbled upon the following problem during the site generation
> >
> > mojo-parent (issue-105)$ mvn site site:stage
> > ..
> > [INFO]
> > [INFO] --- maven-site-plugin:3.9.0:site (default-si
gt; I've stumbled upon the following problem during the site generation
>
> mojo-parent (issue-105)$ mvn site site:stage
> ..
> [INFO]
> [INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:ma
Hi to all,
I've stumbled upon the following problem during the site generation
mojo-parent (issue-105)$ mvn site site:stage
..
[INFO]
[INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-plugin-plugin:
Downloading by the plugin works different compared to the takari-maven-plugin.
The takari-maven-plugin was downloading a URL, whereas the maven-wrapper-plugin
is downloading an artifact using the artifact resolver libraries, so these are
settings.xml-aware.
Would be nice to confirm this.
Robert
Hi Robert,
this is slightly offtopic but since you wrote:
On the other hand, the plugin must be able to download the apache-maven-wrapper
distribution.
Is this integration into Maven also adressing proxy handling for the
download?
I am asking because I had to add special handling to Quarkus t
To be clear: it is just a bootstrapping issue.
Once all is in place they can both have their own release cycle.
The plugin won't need to be released before every Maven Core release, as it can
pick up the Maven version from the runtime.
It is actually possible to run the plugin with 3.0 if we want
Now that maven-wrapper is available in master of maven-core, the next step
would be to make it easy to use.
I've created MNG-6917[1] to make it possible to simply call {{mvn wrapper}}
However, this requires the plugin to be available.
On the other hand, the plugin must be able to download the apac
Looks like I was wrong, everything is ok when using the latest Archetype Plugin.
On 2019/11/03 15:02:56, Lukasz Lenart wrote:
> Hi,>
>
> I'm working on Struts Archetypes [1] and discovered that running:>
>
> mvn clean install archetype:update-local-catalog>
>
> will create/update "~/.m2/reposit
Hi,
I'm working on Struts Archetypes [1] and discovered that running:
mvn clean install archetype:update-local-catalog
will create/update "~/.m2/repository/archetype-catalog.xml" but using command:
mvn archetype:generate -DarchetypeCatalog=local
reads data from "~/.m2/archetype-catalog.xml
2
>
>
> On Tue, 09 Oct 2018 17:45:45 +0200, Paul Benedict
> wrote:
>
> > Good day. I hope this post is acceptable. I don't mean to "cross post"
> > but
> > I think my problem may be too difficult for the common question on the
> > user@
> &
to "cross post"
but
I think my problem may be too difficult for the common question on the
user@
list.
I scoured all the MNG tickets regarding extensions and class loading
documentation on the Maven site (and elsewhere), but cannot find a clear
answer to my problem. This problem is a
Good day. I hope this post is acceptable. I don't mean to "cross post" but
I think my problem may be too difficult for the common question on the user@
list.
I scoured all the MNG tickets regarding extensions and class loading
documentation on the Maven site (and elsewhere), bu
We are using JDK10 on ASF Jenkins and I see that every build fails with
"The system cannot find the path specified" on Windows
and some Linux build fails with " /bin/sh: 1:
/home/jenkins/tools/java/latest10/bin/java: not found ".
See my last comments in
https://issues.apache.org/jira/browse/INFRA-
d Baden-Powell
> > >
> > > On Mon, Nov 27, 2017 at 10:22 PM, Tibor Digana >
> > > wrote:
> > >
> > > > My command *mvn clean* is not able to download a new artifact
> > > > *org.arquillian.universe:arquillian-junit:pom*
> > > > ho
na
> > wrote:
> >
> > > My command *mvn clean* is not able to download a new artifact
> > > *org.arquillian.universe:arquillian-junit:pom*
> > > however it exists on Maven Central.
> > >
> > > I run the command on Ubuntu Konsole, and
iverse:arquillian-junit:pom*
> > however it exists on Maven Central.
> >
> > I run the command on Ubuntu Konsole, and nothing is downloaded.
> > When I run wget [1] from the same Konsole, the POM is downloaded.
> >
> > The settings.xml is not a problem, I checked
universe:arquillian-junit:pom*
> > however it exists on Maven Central.
> >
> > I run the command on Ubuntu Konsole, and nothing is downloaded.
> > When I run wget [1] from the same Konsole, the POM is downloaded.
> >
> > The settings.xml is not a problem, I checked. There
of Nexus and not
downloading artifacts with IP of Nexus) but the Maven from commandline does
not download anything from our Nexus.
Why?
Maybe the Maven has problem with network domain.
The Nexus is in another domain. Is it necessary for Maven to know the
network domain?
If I run a pure Java app
run the command on Ubuntu Konsole, and nothing is downloaded.
> When I run wget [1] from the same Konsole, the POM is downloaded.
>
> The settings.xml is not a problem, I checked. There is a mirror of central
> and URL of Nexus in company.
>
> Is there any native difference betwe
not a problem, I checked. There is a mirror of central
and URL of Nexus in company.
Is there any native difference between wget and mvn/Java on Ubuntu so that
the remote mavenrepo may not be reached?
I did setup of /etc/environment, /etc/network/interface, ~/.profile due to
proxy, DNS, http_no_proxy
.ee module.
It is a big jump and it makes impossible to simply upgrade your java
installation from java8 to java9 and hope it will work
From my point of view the big problem is that existing libraries broke
encapsulation of jdk.
Recently there was a decision to allow illegal reraccessflect
l
> java8 jdk, which can be referenced using the java.se.ee module.
> It is a big jump and it makes impossible to simply upgrade your java
> installation from java8 to java9 and hope it will work
>
> From my point of view the big problem is that existing libraries broke
> encapsula
sible to simply upgrade your java
installation from java8 to java9 and hope it will work
>From my point of view the big problem is that existing libraries broke
encapsulation of jdk.
Recently there was a decision to allow illegal reraccessflective access by
default to every legacy classpath based
@Enrico
What "--add-modules ALL-SYSTEM" really does ?
For me it would be maybe a handy hack but for you it would be just a hack
anyway as it first seems. Strong encapsulation in Java9 can be openly
passed by.
For instance in Surefire we extend UrlClassLoader and I need to access
entire Java API an
+1, fully agree with Guillaume
There's no real need to make a plugin modular: it won't become a
dependency and the dependency management as done by Maven is strong enough
to have a stable plugin (i.e no need to add requires-statements).
In case of experiment if you want to add a module name
egacy java code which bypasses
encapsulation by using setAccessible.
Enrico
>
>
>
>
> Kind regards
> Karl Heinz Marbaise
> On 17/06/17 16:31, Enrico Olivelli wrote:
> > Karl,
> > I think that the problem is tha code is trying to access internals of
> > java
, Enrico Olivelli wrote:
Karl,
I think that the problem is tha code is trying to access internals of
java.io.File.
No module descriptor can help.
I think you should run with -X, get the stacktrace of the exception and
then we need to avoid that reflective call.
In the meantime you can use the
Karl,
I think that the problem is tha code is trying to access internals of
java.io.File.
No module descriptor can help.
I think you should run with -X, get the stacktrace of the exception and
then we need to avoid that reflective call.
In the meantime you can use the famous big kill switch.
Hope
Hi,
There was a link to Stephen Colebourne's blog about naming modules:
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html. So what
about "org.apache.maven.plugins.site" for the module name?
But I don't think it is necessary to make the plugin modular. The error
means that code l
Hi,
currently I'm a bit on testing JDK 9 EA+174..and found the following issue:
[INFO]
[INFO] <<< maven-plugin-plugin:3.4:report < process-classes @
maven-install-plugin <<<
[INFO]
[INFO] 'process-classes' forked phase execution for
maven-plugin-plugin:report report preparation done
[INFO] con
method cannot be called in *java.lang* or
*java.base* module.
I guess this class loader must be compiled in java 9 and the protected
method extended and then maybe the module *"java.se.ee
<http://java.se.ee>"*
would be loaded.
Do you have any idea to solve this
ule.
>
> I guess this class loader must be compiled in java 9 and the protected
> method extended and then maybe the module *"java.se.ee <http://java.se.ee
> >"*
> would be loaded.
>
> Do you have any idea to solve this problem and load *javax.xml.ws.Holder*
> properl
have any idea to solve this problem and load *javax.xml.ws.Holder*
properly?
[1]
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=shortlog;h=refs/heads/SUREFIRE-1265_2
[2]
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commitdiff;h=bce51369e3563ed95c91346cd89c80ba
Github user hgschmie closed the pull request at:
https://github.com/apache/maven-release/pull/17
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
GitHub user hgschmie opened a pull request:
https://github.com/apache/maven-release/pull/17
MRELEASE-979 - fix no branch name problem
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/hgschmie/maven-release
MRELEASE-979-fix-no
Github user hgschmie closed the pull request at:
https://github.com/apache/maven-release/pull/16
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
> >
> > Hello Robert,
> >>
> >> just watched your JavaOne presentation. Very interesting :-)
> >>
> >
> > thanks!
> >
> >
> >> Robert Scholte schrieb am So., 25. Sep. 2016 um
> >> 13:48 Uhr:
> >>
> >> It d
t 15:20, Robert Scholte >
> > wrote:
> >
> > > On Sun, 25 Sep 2016 16:11:22 +0200, Benedikt Ritter <
> brit...@apache.org >
> > > wrote:
> > >
> > > Hello Robert,
> > >>
> > >> just watched your JavaOne presentation
t;>
> >
> > thanks!
> >
> >
> >> Robert Scholte schrieb am So., 25. Sep. 2016 um
> >> 13:48 Uhr:
> >>
> >> It depends. If you are changing existing methods to only work with
> Java8,
> >>> that would be a problem (read:
t; > thanks!
> >
> >
> >> Robert Scholte <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5881611&i=2>> schrieb am So.,
> 25. Sep. 2016 um
> >> 13:48 Uhr:
> >>
> >> It depends. If you are changing existing methods
t;> Robert Scholte schrieb am So., 25. Sep. 2016 um
>> 13:48 Uhr:
>>
>> It depends. If you are changing existing methods to only work with Java8,
>>> that would be a problem (read: we cannot upgrade). If you have both Java8
>>> and pre-Java8 implementations, eit
t depends. If you are changing existing methods to only work with Java8,
>>> that would be a problem (read: we cannot upgrade). If you have both Java8
>>> and pre-Java8 implementations, either by reflection or proper
>>> encapsulated
>>> code it'll work for u
would be a problem (read: we cannot upgrade). If you have both
Java8
and pre-Java8 implementations, either by reflection or proper
encapsulated
code it'll work for us.
We do it ourselves too[1]
for us it would be nice if the target is still 1.7
if ( isJava8() )
{ // do java8 stuff }
else
Hello Robert,
just watched your JavaOne presentation. Very interesting :-)
Robert Scholte schrieb am So., 25. Sep. 2016 um
13:48 Uhr:
> It depends. If you are changing existing methods to only work with Java8,
> that would be a problem (read: we cannot upgrade). If you have both Java8
t;
> > Hi,
> >
> > at the Apache Commons Project we're currently discussing where we can
> host
> > utility classes for working with the features introduced in Java 8. One
> > proposal add this to Commons Lang [1]. Since Apache Maven makes use of
> >
It depends. If you are changing existing methods to only work with Java8,
that would be a problem (read: we cannot upgrade). If you have both Java8
and pre-Java8 implementations, either by reflection or proper encapsulated
code it'll work for us.
We do it ourselves too[1]
for us it
> Hi,
>
> at the Apache Commons Project we're currently discussing where we can host
> utility classes for working with the features introduced in Java 8. One
> proposal add this to Commons Lang [1]. Since Apache Maven makes use of
> Commons Lang, I would like to know whether
Hi,
at the Apache Commons Project we're currently discussing where we can host
utility classes for working with the features introduced in Java 8. One
proposal add this to Commons Lang [1]. Since Apache Maven makes use of
Commons Lang, I would like to know whether it would be a problem for y
nect to [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5877590&i=1> via WinSCP. First
> time it asked me to
> > update the certificate and I am in, but I cannot login via PuTTY.
> > Did [hidden email]
> <http:///user/SendEmail.jtp?type=node&am
PuTTY.
> Did peo...@apache.org change the host or certificate or do you know why
> PuTTY has problem to connect?
>
> Cheers
> Tibor
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
I can connect to peo...@apache.org via WinSCP. First time it asked me to
update the certificate and I am in, but I cannot login via PuTTY.
Did peo...@apache.org change the host or certificate or do you know why
PuTTY has problem to connect?
Cheers
Tibor
reason for
it:
addManifestAttribute( m, entries, "Built-By", System.getProperty(
"user.name" ) );
addManifestAttribute( m, entries, "Build-Jdk", System.getProperty(
"java.version" ) );
This is, unfortunately, a wellknown problem.
I already thought about using
quot;, System.getProperty(
"user.name" ) );
addManifestAttribute( m, entries, "Build-Jdk", System.getProperty(
"java.version" ) );
This is, unfortunately, a wellknown problem.
I already thought about using Toolchains in Maven-Archiver (or
maven-jar-plugin), but after i
er??? to maven-jar-plugin ?
So the question is:
Does someone has a good idea to solve this kind of problem ?
Any hints/tips/ideas are appreciated...
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: dev-unsubscr..
a bug, but instead I think there's room for
improvement (when using custom ArtifactHandlers)
thanks,
Robert
Op Thu, 07 Jan 2016 22:10:17 +0100 schreef Cristiano Gavião
:
After having lost many hours I finally found where the problem is likely
to be... :-(
maven is using aether for depend
After having lost many hours I finally found where the problem is likely
to be... :-(
maven is using aether for dependency resolution, but aether has not a
concept of packaging and extension as maven has. it only has extension.
as a workaround maven is saving the packaging type inside the
Well, is not the dot the culprit...
I tried with another packaging name and I got the same result.
I still don't know who injects the ArtifactHandler in the dependency...
any idea ?
-
To unsubscribe, e-mail: dev-unsubscr...@
Hello,
I'm facing a problem with a plugin that has a custom ArtifactHandler for
a custom packaging type. The custom class is being registered by sisu
and no problem was reported while running a build, except when a project
artifact has one artifact of this custom type as a dependency.
I think you need to specify all parameter values in test pom.xml, at
least this used to be one of annoying limitations of apache plugin
harness in the past. Personally I gave up on apache harness long time
ago. The harness I've written at Takari works much better everywhere I
used it and I am prett
Hi,
currently i'm trying to fix some issues in the maven-ejb-plugin and
within the test there is a setup like this:
EjbMojo mojo = (EjbMojo) lookupMojo( "ejb", pomFile );
But at the moment i don't understand why the defaults for the defined
parameters and not injected...
For examp
son Margulies:
>>
>> Maven-plugins 28 is released, of course; what's up? It worked for me,
>> but not for one of my co-workers.
>
>
> Benson,
>
> where you actually able to resolve your problem? From my point of view this
Am 2015-10-16 um 15:01 schrieb Benson Margulies:
Maven-plugins 28 is released, of course; what's up? It worked for me,
but not for one of my co-workers.
Benson,
where you actually able to resolve your problem? From my point of view
this should not hinder the plugin release.
Mi
On Fri, Oct 16, 2015 at 9:38 AM, Anders Hammar wrote:
> No, you don't. Maybe there is some cached metadata incorrect or the
> metadata at apache.
> Could you try adding the -U switch?
>
> Also, I only have the staging repo in my settings as a profile and I only
> activate it explicitly when testin
No, you don't. Maybe there is some cached metadata incorrect or the
metadata at apache.
Could you try adding the -U switch?
Also, I only have the staging repo in my settings as a profile and I only
activate it explicitly when testing staged stuff.
/Anders (mobile)
Den 16 okt 2015 15:35 skrev "Ben
Anders, I added a pluginRepository for the stage to my settings.xml.
As far as I know, adds, it
doesn't replace.
So why isn't it searching for the parent in the usual way in the other
repositories? Or do I have to manually put central in as a
pluginRepository if I'm just trying to add one?
It looks like a specific staging repo is accessed (look at the URL in the
end). As the parent has been released it is no longer available there.
/Anders (mobile)
Den 16 okt 2015 15:01 skrev "Benson Margulies" :
> Maven-plugins 28 is released, of course; what's up? It worked for me,
> but not for
Maven-plugins 28 is released, of course; what's up? It worked for me,
but not for one of my co-workers.
$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Parent for Text Analytics Maven Project
1 - 100 of 865 matches
Mail list logo
