j
> artifacts in version < 1.6 it may have in dependency to use a version
> 1.7.x
> like our core.
>
> It may me think that the colorized logging may be perhaps distributed
> as
> an extension ?
>
> cheers
>
>
> On Tue, Oct 6, 2015 at 4:23 AM, Igor F
It is possible to use ClassRealmManagerDelegate to replace "bad"
slf4j-related plugin dependencies with compatible "good" dependencies.
This is what I do in my "better multithreaded logging" maven extension
and it works quite well from what I can tell.
--
Regards,
Igor
On Sun, Oct 4, 2015, at 10
I'd let animal-sniffer remember what classes it scanned last build and
process only changed/new classes (and clean up messages related to the
deleted classes). This is how we implemented incremental build behaviour
in takari lifecycle. You may also want to have a look at
io.takari.incrementalbuild
@Component
private ResourceManager locator;
--
Regards,
Igor
On Fri, Oct 2, 2015, at 06:31 AM, Jochen Wiedmann wrote:
> Hi,
>
> I am trying to migrate a plugin from XDoclet to Annotations. In my new
> Mojo, I have a parameter declared like this:
>
> /**
> * Plexus resource manager use
Not sure if this answers your question, but MNG-5742 explains why you
see multiple @Singleton instances in maven 3.1.1 but not in 3.3.1. There
was related smaller MNG-5793 which I fixed in 3.3.3.
https://issues.apache.org/jira/browse/MNG-5742
https://issues.apache.org/jira/browse/MNG-5793
--
Reg
Like I mentioned earlier, tycho-versions-plugin uses decentxml to
manipulate pom.xml files. There is more or less complete version
refactroing engine implementation there, but actual pom changes go
through MutablePomFile [1]. The advantages of decentxml is that it has
good and easy to use API and i
No, not possible to inject mojo parameters into plain components.
With recent versions of Maven, it is possible to inject MavenSession,
MavenProject and MojoExecution into components. Not example what you are
asking, but maybe close enough. Be careful not to inject those into
singleton components
I used decentxml quite successfully for this purpose in Tycho and elsewhere.
--
Regards,
Igor
On August 26, 2015 3:40:13 AM Barrie Treloar wrote:
The release plugin has AbstractRewritePomsPhase which uses a lot of private
methods to do its work.
Is there a more utilitarian way of writing a
I am not sure I understand your concerns. Consider the following simple
source tree with a parent and single child project
some:parent:1.2.3
some:module parent=some:parent:[1.0,2.0)
Before this change Maven simply ignored local some:parent:1.2.3 when
building the module and always attem
I am pretty sure somebody provided an example project that showed memory
increase in Maven 3.2.x some time last year iirc. Could have been direct
email, not 100% sure. From what I remember, the problem was triggered by
specific way to reference parent pom, this is why only few projects are
affected
-1 FWIW
There is a regression with parent pom version range support (see
MNG-2199 [1]) when locating locally-available parent pom. I've pushed
MavenITmng2199ParentVersionRangeTest#testValidLocalParentVersionRange
regression test [2] to demonstrate the issue. The test works with Maven
3.3.3 but fai
rverhagen.net ]
>
> NOTICE: my e-mail address has changed. Please remove verha...@sander.com
> now and start using san...@sanderverhagen.net from now on. Please update
> your address book. Thank you!
>
>
> > -Original Message-
> > From: Igor Fedorenko [mai
Maybe related
https://github.com/codehaus-plexus/plexus-archiver/issues/5
--
Regards,
Igor
On Thu, Jul 2, 2015, at 05:11 PM, Jason van Zyl wrote:
> As for how maven-archiver works exactly these days I’m not sure. Anything
> I care about I have shifted over to using takari-archiver and it streams
maven uses eclipse sisu, which provides plexus compatibility layer on
top of guice-based jsr330 implementation. you can use both plexus and
jsr330 components in maven. search for references to @Named annotation
to find jsr330 annotated classes. here is one totally random example
https://github.com
Based on the feedback I got on this list I did not include the logger
extension in maven itself but kept it in a separate repository. I may
opensource that repository some time in the future but it is not a priority
for me right now.
--
Regards,
Igor
On June 9, 2015 1:33:46 PM Sander Verhag
Nexus UI showed up from here (Toronto).
--
Regards,
Igor
On Sun, Jun 7, 2015, at 08:41 PM, Dan Tran wrote:
> Can someone confirm if http://repository.apache.org is down at your side?
>
> Thanks
>
> -Dan
-
To unsubscribe, e-ma
If I provide custom jar manifest, I expect the manifest to be used
as-is, without anything added, removed or reordered. Just my 2 kopecks.
--
Regards,
Igor
On Sun, Jun 7, 2015, at 12:50 PM, Karl Heinz Marbaise wrote:
> On 6/7/15 6:49 PM, Karl Heinz Marbaise wrote:
> > Sorry was too fast with my
for other logging framework. But
I agree, this does not have to be implemented in the core so I'll try to
rework my implementation as lib/ext extension.
--
Regards,
Igor
On Wed, May 27, 2015, at 06:40 PM, Jason van Zyl wrote:
>
> On May 27, 2015, at 3:55 PM, Igor Fedorenko wrote:
&
very much the same way they
need to do it now to use any of the advanced logging frameworks.
--
Regards,
Igor
On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote:
> I spent some time looking into this, and I think project-level logging
> will require several semi-related changes.
f you are saying that the log lines include newlines in them that should
> still be OK. The only way the lines should be mangled is if each thread
> somehow has its own instance of the logging framework and they are all
> configured to write to the same file.
>
> Ralph
>
&
; processing.
>
> --
> Sean
> On May 25, 2015 6:30 AM, "Igor Fedorenko" wrote:
>
> > I had to troubleshoot a large multithreaded build last week and that
> > proved to be rather difficult mostly because build log was a jumble of
> > messages produced by concurrently
I had to troubleshoot a large multithreaded build last week and that
proved to be rather difficult mostly because build log was a jumble of
messages produced by concurrently running threads. It was not possible
to tell which message came from which thread, which made the build log
more or less usel
Does anyone know how to fix ssl error below when using git (from
macports) on osx 10.9.5? Everything works just fine on ubuntu, so I
think this is osx or macports issue.
mpb:maven igor$ git pull --rebase
fatal: unable to access
'https://git-wip-us.apache.org/repos/asf/maven.git/': SSL
Is the new skin supposed to work on mobile? The site still renders
poorly on android chrome.
--
Regards,
Igor
On Sun, May 10, 2015, at 07:43 AM, Olivier Lamy wrote:
> Nice change. Well done!
>
> On 10 May 2015 at 21:38, Martijn Verburg
> wrote:
>
> > Looks great!
> >
> > Cheers,
> > Martijn
>
How do you expect this to work during multithreaded build, when there is
more than one running plugin at any given time?
What you probably want is some sort of thread-local logging level, which
can be scoped to specific plugin and configured from the core.
--
Regards,
Igor
On Sat, Apr 4, 2015,
If Tycho use of Sirefire is the driving force behind that pull request,
I would like to see end-to-end demo/proof-of-concept that show how
adding OSGi headers to Surefire helps. I don't believe Tycho itself will
benefit from this any, but the problem appears to be specific to redhat
repackaged vers
On 2015-03-08 9:35, Tibor Digana wrote:
@Igor
Would you introduce trully incremental compiler with JDT?
I guess the surefire would need the interface from core or compiler to be
notified about modified tests in order to execute only those.
Incremental test execution requires full impact analys
Sorry, I am not following.
The current majority agreement is to change compiler target level
together with maven core minor version change from 3.2.x to 3.3.0. Then
we can gradually introduce java 7 features in future 3.3.x releases.
This way to avoid dead-end 3.3.0 release immediately followed b
How is this a breaking change? All plugins that worked with 3.2.5 are
expected to work as is. All projects that built with 3.2.5 are expected
to build.
--
Regards,
Igor
On 2015-03-07 17:35, Tibor Digana wrote:
(Replying on this thread from my mail server does not work for me)
Usually the opens
Ant bootstrap is also used in the build process. I'd be very
grateful if you could keep maintaining it, the Maven packaging is
already quite difficult (we are blocked on the 3.0.5-> 3.1.1 upgrade)
and removing the Ant script is likely to be disrupting.
Emmanuel Bourg
Le 26/02/2015 19:15, Igor
e to a higher major Java version, in that we should
release what we currently have in trunk before upgrading to a higher
major Java version.
My votes are:
-1 for Java 7 in 3.3.0
+1 for Java 7 in 3.4.0
[1] http://maven.apache.org/developers/java6.html
On Thu, Mar 5, 2015 at 1:19 PM, Igor Fe
On 2015-03-05 14:12, Kristian Rosenvold wrote:
Actually Files.walkFileTree is just about the only NIO 7 feature we're
not using. Anyone have any specific pointers/experience that actually
show this being faster than the current strategy ?
I ran some tests about a year ago on a large 200K files
#x27;t know the numbers, but I think JDK6 is still used a lot by the
community.
Current code builds fine with JDK6.
Which JDK7 specific features do you want to use, which are not possible
with the current codebase?
Without any critical codechanges I'd go for -1.
Robert
Op Thu, 05 Mar 2015 13
With maven core version change to 3.3.0 on master, any objections I
change compile source/target to java 7?
--
Regards,
Igor
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@ma
If you are talking about few russian pages at the end of the list, these
are just spam, no useful maven information there.
--
Regards,
Igor
On 2015-03-04 7:52, Martin Gainty wrote:
From: herve.bout...@free.fr
To: dev@maven.apache.org
Subject: Codehaus EOL and MAVENUSER Confluence Wiki
Date
5, at 10:15 AM, Igor Fedorenko wrote:
Sorry if this is a dup of a recent discussion, but I couldn't find
anything so here it goes.
Why do we use ant to run Maven CI build at https://builds.apache.org?
Seems odd we need to maintain both maven and ant builds for maven core.
I am quite certai
Sorry if this is a dup of a recent discussion, but I couldn't find
anything so here it goes.
Why do we use ant to run Maven CI build at https://builds.apache.org?
Seems odd we need to maintain both maven and ant builds for maven core.
I am quite certain maven is mature enough to bootstrap itself
a joy, but what's in the patch should be
translatable.
Andreas
2015-02-25 17:01 GMT+01:00 Igor Fedorenko :
You can see actual diff to mvn shell script in [1], but the changes was
basically two-fold. First, find nearest parent directory that contains
.mvn/ subdirectory. This parent is consider
You can see actual diff to mvn shell script in [1], but the changes was
basically two-fold. First, find nearest parent directory that contains
.mvn/ subdirectory. This parent is considered "true" multi-module
project root (MNG-1958). Second, if .mvn/java.config file is present
immediately under th
s downloaded.
But when I tried mvn install, the version 3.2.3 was downloaded but it
has only 178 bytes.
Don't know if it was downloaded wrongly or the file was corrupted by
other means.
On 21-02-2015 18:48, Igor Fedorenko wrote:
Looks like maven distribution gz is corrupted in your loc
Looks like maven distribution gz is corrupted in your local repo. See if
removing ~/.m2/repository/org/apache/maven/apache-maven directory will
solve the problem for you. If not, file github issue like Jason suggested.
--
Regards,
Igor
On 2015-02-21 16:08, Cristiano Gavião wrote:
Hello,
I'm tr
ed multimodule structure?
Robert
Op Sat, 21 Feb 2015 16:44:24 +0100 schreef Igor Fedorenko
:
Correct. What I called "projectBaseDirectory" represents root directory
of a multimodule project. It is not related to parent/child relationship
among project modules. And it is not the same as &q
21, 2015, at 8:57 AM, Robert Scholte wrote:
Op Sat, 21 Feb 2015 14:12:22 +0100 schreef Igor Fedorenko :
On 2015-02-21 7:02, Robert Scholte wrote:
Hi Igor,
I agree that something like MNG-5767 can indeed help with the experience.
Looking at the implementation I find the name projectBaseDirec
Updated Branches:
refs/heads/master ee7dbab69 -> 8ed9a1caa
MNG-5767 .mvn/ for project specific jvm options and maven parameters
Signed-off-by: Igor Fedorenko
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/8ed9a1ca
T
/plugins/maven-site-plugin/dependencies.html
[1] https://issues.apache.org/jira/browse/RAT-158
Le mardi 3 février 2015 23:31:24 Igor Fedorenko a écrit :
MavenPluginManager#setupPluginRealm "imports" parameter is not used in
any meaningful way. No matter what packages are passed in, the creat
Kristian,
Can you add me to classworlds repo collaborators? Github userid is
ifedorenko. Plan to make some changes needed to fix component lookup
ordering. Thank you in advance.
--
Regards,
Igor
On 2015-02-09 12:13, Kristian Rosenvold wrote:
They are now all at https://github.com/codehaus-plex
-0500
schrieb Igor Fedorenko :
What if there was single "real" mvn script and mvnDebug/mvnyjp were
just symlinks pointing back to it? The script will behave differently
based on the script name. Any objections to this plan?
I am all for having only one script. They have diverged too m
inux and for windows ...
On Sun, Feb 8, 2015 at 3:04 PM, Jason van Zyl wrote:
I think that also works. But I think the script not being executable it
makes it clear it's not a script. Whatever we decide I'm again filtering
it, just makes debugging painful.
On Feb 8, 2015, at 7:57
't be too hard to do some filtering and only have useful
scripts (and disable it if you want to patch/test)
thanks,
Robert
Op Sat, 07 Feb 2015 15:12:17 +0100 schreef Igor Fedorenko
:
Robert,
Can you explain your concerns? I believe it is a common practice to use
separate "include" file
t
Op Fri, 06 Feb 2015 22:31:47 +0100 schreef :
Repository: maven
Updated Branches:
refs/heads/project-basedir 888109c68 -> e91144fbe (forced update)
.mvn/ for project specific jvm options and maven parameters
Signed-off-by: Igor Fedorenko
Project: http://git-wip-us.apache.org/repos
and possible
cleanup the implementation.
--
Regards,
Igor
On 2015-02-03 22:04, Hervé BOUTEMY wrote:
Le mardi 3 février 2015 16:42:47 Igor Fedorenko a écrit :
Does anyone have a usecase that demonstrates use of
MavenPluginManager#setupPluginRealm "imports" parameter? I've fou
Does anyone have a usecase that demonstrates use of
MavenPluginManager#setupPluginRealm "imports" parameter? I've found
DefaultMavenReportExecutor from maven-reporting-exec, which provides
list of imported packages, but not sure how to use it from a project.
From what I can tell, this parameter i
Duplicate plugin classloader fix applies to all plugins with
extensions=true. This is far more common than "advanced integration".
I've been working around the problem in my plugins for years. I would
like to see it fixed in an official maven release sooner rather than
later.
--
Regards,
Igor
On
a problem?
Thanks
-D
On Tue, Jan 27, 2015 at 3:01 PM, Igor Fedorenko wrote:
On 2015-01-27 17:35, Dan Tran wrote:
My bad, it is not obvious it is from an experimental branch. However,
even
if this gets committed master, the configuration changes in that script
may
impact other distribution usi
On 2015-01-27 17:35, Dan Tran wrote:
My bad, it is not obvious it is from an experimental branch. However, even
if this gets committed master, the configuration changes in that script may
impact other distribution using M2_HOME.
Can you explain how changes on that branch can impact other
di
You sure you linked the right commit? The commit you linked is from my
experimental branch and it does not change how mvn* scripts use M2_HOME
environment variable.
--
Regards,
Igor
On 2015-01-27 16:26, Dan Tran wrote:
Just see this change [1] at Maven core where the 'mvn' script get altered.
I think we should. I also noticed the current formatter and checkstyle
disagree about explicit type parameters like in
Collections.emptyList()
I'd be happy to test the new formatter configuration.
--
Regards,
Igor
On 2015-01-20 15:19, Dan Tran wrote:
The current maven java formatter [1] k
I probably wouldn't use this for my plugins
Today, plugin extensions are loaded in the same classloader as the rest
of plugin dependencies. Hiding plugin dependencies from extensions
during compile-time does not reflect runtime and can do more harm than
good. If, for example, a plugin depends on
on
--
Regards,
Igor
On 2015-01-15 0:43, Kristian Rosenvold wrote:
2015-01-15 4:48 GMT+01:00 Igor Fedorenko :
Although I generally *strongly* discourage resolution of plugins and
plugin dependencies from the reactor
Why ?
Kristian
--
Although I generally *strongly* discourage resolution of plugins and
plugin dependencies from the reactor, it is expected to work with maven
3.0+ for regular extensions=false plugins. If you have a testcase when
it does not work, I can have a look.
--
Regards,
Igor
On 2015-01-14 10:10, Kristian
I think my question was not clear. I do not understand the problem you
are trying to solve, i.e. user and/or plugin developer usecases that are
not (well) supported with the current APIs. This is why I am asking for
some representative examples that highlight the problem. I do not
suggest or imply
Do you think you can give a couple of representative examples that
explain what you are trying to achieve?
--
Regards,
Igor
On 2015-01-13 9:33, Tibor Digana wrote:
Hi All,
We want to prepare an experimental release of maven-surefire-plugin
customizing the plugin behavior. Basically we want to
400MB/s is way faster than any single spinning disk can do and actually
quite a bit faster than SATA I/II max speeds [1]. This suggests the data
was written to the operating system caches but never made it to the disk
physical media. That is, unless you had a RAID connected to system using
some so
On 2015-01-11 14:48, Hervé BOUTEMY wrote:
The change does not affect classloading of "normal" maven runtime, so
>there is no need to update the diagram or documentation.
IIUC, in the Wiki, what is currently described as "system classloader" is now
"initial classloader, containing classworlds",
pdated Branches:
refs/heads/master 5f71f9789 -> bb4988496
better plugin/extensions realm parent classloader
Signed-off-by: Igor Fedorenko
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/bb498849
Tree: http://git-wip-u
Out of curiosity, what hardware did you use? 400MB/s seems too high
even for many modern SSDs [1], let alone mechanical hard drives.
[1] http://techreport.com/review/25391/wd-red-4tb-hard-drive-reviewed/4
--
Regards,
Igor
On 2015-01-10 13:55, Tibor Digana wrote:
Hi Kristian,
Are you using NIO
I am not sure I understand your questions, maybe you can explain you
what you are trying to achieve and I can tell how to do it.
Few general comments
As I tried to explain in the hangout, proper incremental compilation
requires type reference information. Consider two classes, A and B
extends A,
What kind of changes to the model do you expect? Can you give some
pointers that explain verification logic you have in mind?
--
Regards,
Igor
On 2015-01-05 9:11, Kristian Rosenvold wrote:
I'd be interested in using cglib to generate a full set of subclasses
for the entire maven model. These su
Can somebody with PMC powers copy the source release to the Apache
Distribution Area? Thank you in advance.
--
Regards,
Igor
On 2014-12-30 8:55, Igor Fedorenko wrote:
Hi,
The vote has passed with the following result:
+1 (binding): Jason, Karl Heinz, Kristian, Hervé
+1 (non binding): Igor
I
Hi,
The vote has passed with the following result:
+1 (binding): Jason, Karl Heinz, Kristian, Hervé
+1 (non binding): Igor
I will promote the artifacts to the central repo.
Thank you Karl Heinz for giving this vote little extra push it needed.
--
Regards,
Igor
On 2014-12-17 20:40, Igor
Out of curiosity, how do you plan to use snappy compressed files and why?
--
Regards,
Igor
On 2014-12-23 13:38, Benson Margulies wrote:
What would the path be to adding support for snappy-compressed files
to the assembly plugin?
https://github.com/xerial/snappy-java
--
t;
ᐧ
On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko
wrote:
Ok, I understand the problem now, but I don't think forcing everything
to explicitly state dependency type is the right solution here.
"Convention over configuration" is one of fundamental Maven principals,
and by conventi
community. While
it stemmed from Java builds, it is now used much more widely than pure Java
libraries.
William
ᐧ
On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko wrote:
I am not sure I follow. Can you explain what actually happens and how
forcing element for all projects dependencies is
Hi,
We solved 1 issue:
https://jira.codehaus.org/browse/MPLUGINTESTING-44
There are no issues left in JIRA
Staging repo:
https://repository.apache.org/content/repositories/maven-1106/
http://repository.apache.org/content/repositories/maven-1106/org/apache/maven/plugin-testing/maven-plugin-test
o this will be
>3.2.5,
>> yes?
>>
>> On Saturday, December 13, 2014, Jason van Zyl
>wrote:
>>
>>> The fixes have been made, I'll recut the release.
>>>
>>> On Dec 13, 2014, at 9:44 AM, Igor Fedorenko >> > wrote:
>>>
>&g
ot expected)
I'm in favor of introducing deprecated DefaultJavaToolChain
that extends the new implementation, which is easy to do: just need to
understand how it is used in Tycho, since the class is supposed to be used
by JavaToolchainFactory (on only this one).
Regards,
Hervé
Le vendredi 12
d to be used by
JavaToolchainFactory (on only this one).
Regards,
Hervé
Le vendredi 12 décembre 2014 18:38:44 Igor Fedorenko a écrit :
Unfortunately, I have to take this back. The changes to toolchain
broke Tycho and, short of using reflection, I don't see how
to make Tycho work with maven 3.2.4 and
e looking for a "jdk" toolchain with "vendor" requirement
the configuration has to be:
fake
Regards,
Hervé
Le samedi 13 décembre 2014 07:22:03 Igor Fedorenko a écrit :
Are you able to run &qu
#x27;re using custom compoennt more tied to core than expected.
Regards,
Hervé
Le samedi 13 décembre 2014 00:03:38 Igor Fedorenko a écrit :
Providing backwards compatibility shim seems to be quite
straightforward, but there appears to be another problem. From what I
can tell, current maven master
ow did they not break?
>>
>> On Dec 12, 2014, at 6:38 PM, Igor Fedorenko
>wrote:
>>
>>> Unfortunately, I have to take this back. The changes to toolchain
>>> broke Tycho and, short of using reflection, I don't see how
&
--
Regards,
Igor
On 2014-12-12, 18:01, Igor Fedorenko wrote:
+1
--
Regards,
Igor
On 2014-12-12, 16:54, Jason van Zyl wrote:
Hi,
Time to release Maven 3.2.4!
Here is a link to Jira with 20 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20574
+1
--
Regards,
Igor
On 2014-12-12, 16:54, Jason van Zyl wrote:
Hi,
Time to release Maven 3.2.4!
Here is a link to Jira with 20 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20574
Staging repo:
https://repository.apache.org/content/repositories/mav
I am not sure I follow. Can you explain what actually happens and how
forcing element for all projects dependencies is expected to help
the problem?
--
Regards,
Igor
On 2014-12-07, 19:25, William Ferguson wrote:
## Cross posting to Maven Dev list
One solution to this would be to change the PO
I think selected JDK should also be used to resolve ${java.home} in
system-scoped dependencies. Which I think means concept of project
"target" JDK should be directly supported by Maven itself.
--
Regards,
Igor
On 2014-12-01, 4:23, Mark Struberg wrote:
The issue is that there are classes which
Key is a child element name. For Dependency it can be "groupId",
"version", "exclusions", etc. Empty string, i.e. "", is the key used to
identify location of the element itself. Search for
Dependency#setLocation method invocation to find all key values.
--
Regards,
Igor
On 2014-11-29, 13:22, Kar
Out of curiosity, why do you want to get exactly the same bytecode? Does
the code compiled with java8 not work under java7?
--
Regards,
Igor
On 2014-11-27, 15:39, Mark Struberg wrote:
Hi!
Today I had a discussion with Robert about how we can solve a problem I had
over at Apache OpenWebBeans:
At m2e, we automatically close bugs that have not seen a meaningful
movement for 12+ months. This helps keep our bug backlog manageable and
m2e users seems to be content with this policy for the most part.
We don't have development resources to fix every single problem in our
projects, so we only
If you haven't pushed the tag, it is perfectly safe to delete and
recreate it. If you did push, however, the new tag will have to be
propagated manually in each and every clone. You can find more details
in [1], look for "On Re-tagging" section.
Even without git, I find artifacts with the same ve
You can also use MojoRule#readMavenProject from
maven-plugin-testing-harness [1]. You'd have to inject any cross-module
dependencies manually.
You can also see how we do this in Tycho [2], where we delegate to
DefaultMaven to read and resolve multimodule project.
And, of course, you can just cre
fects relativly small number of users.
[1] http://jira.codehaus.org/browse/MNG-5669
--
Regards,
Igor
On 2014-10-23, 1:27, Milos Kleint wrote:
is there an issue to watch?
Thanks
Milos
On Fri, Oct 17, 2014 at 10:59 PM, Igor Fedorenko
wrote:
I think I know the problem.
Current master cr
Kristian,
Where can I find the test case and more information about the problem
and the fix? Thank you in advance.
--
Regards,
Igor
On 2014-10-18, 14:22, Kristian Rosenvold wrote:
Thanks to an excellent testcase provided by a JIRA user, a significant
source of thread safety bugs has been locat
ially if we want
to maintain backwards compatibility and keep model instances mutable.
--
Regards,
Igor
On 2014-10-16, 13:30, Jörg Schaible wrote:
Hi Igor,
Igor Fedorenko wrote:
You can zip and email it to me directly or share it on github, dropbox
or google drive and send me the link.
You can zip and email it to me directly or share it on github, dropbox
or google drive and send me the link. I am flexible :-)
--
Regards,
Igor
On 2014-10-16, 11:41, Jörg Schaible wrote:
Hi Igor,
Igor Fedorenko wrote:
Can you provide an example project we can use to reproduce the problem
Can you provide an example project we can use to reproduce the problem
locally? You may be able to strip your source tree from everything bun
pom.xml files, for example.
--
Regards,
Igor
On 2014-10-16, 5:12, Jörg Schaible wrote:
Hi folks,
we have a single build with currently ~400 projects (in
If eclipse usage survey is any indication, users tend to move to the latest
eclipse version quite fast. I think it is okay to expect m2e 1.5 or better at
this point. For actively developed codebases anyways.
On October 13, 2014 3:03:21 PM EDT, Anders Hammar wrote:
>>
>> this is the only change
s not contain "xml" files. This is the one I have added:
*.java text diff=java
*.html text diff=html
*.csstext
*.js text
*.sqltext
So we need to add *.xml to all of them, and probably *.properties too.
Any others ?
Kristian
2014-10-12 14:53 GMT+02:00 Igor Fedorenko :
What E
think of: always use the same EOL, no matter the OS
(though I'm not sure about the consequences) or when generating the
-source-release.zip the EOL should be changed to the preferred one.
thanks,
Robert
Op Sun, 12 Oct 2014 14:53:32 +0200 schreef Igor Fedorenko
:
What EOL handling are we expect
What EOL handling are we expected to use for Maven git repositories? I
don't recall this was discussed before, but this commit [1] stands out
from the rest. I usually follow github recommendation [2], so I wonder
if we can adopt the same for Maven work. Any thoughts?
[1]
https://git-wip-us.apac
and more modern maven versions (I am having a quite
>some trouble with Maven versions greater than 3.1)
>
>But if you say that even if Maven comes with one version, a plugin
>should be able to work with another, then that's good enough for me,
>I'll start migrating Flexmojo
What version of Maven do you use? Can you provide a small standalone
example that demonstrate the problem? Like a sample plugin with a
trivial demo project, for example.
Generally, each Maven plugin runs in its own classloader with only
subset of Maven core classes available to it. Guava is not p
101 - 200 of 454 matches
Mail list logo
