acts 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
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
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
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
--
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
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 baerr...@gmail.com wrote:
The release plugin has AbstractRewritePomsPhase which uses a lot of private
methods to do its work.
Is there a more
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
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
-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
and start using san...@sanderverhagen.net from now on. Please update
your address book. Thank you!
-Original Message-
From: Igor Fedorenko [mailto:i...@ifedorenko.com]
Sent: Tuesday, June 09, 2015 12:15
To: Maven Developers List; Sander Verhagen
Subject: Re: logging during
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
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
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
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
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-mail:
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.
* As Ralph pointed out
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 i...@ifedorenko.com wrote:
So I
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
On May 25, 2015, at 7:28 AM, Igor Fedorenko i...@ifedorenko.com wrote:
Yes, thread-id
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
On May 25, 2015 6:30 AM, Igor Fedorenko i...@ifedorenko.com 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 running threads. It was not possible
to tell which
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 martijnverb...@gmail.com
wrote:
Looks great!
Cheers,
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
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
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 Fedorenko i...@ifedorenko.com
. 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 Fedorenko a écrit :
Sorry if this is a dup
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
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
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
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:
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:19:11 +0100 schreef Igor Fedorenko
i
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
a joy, but what's in the patch should be
translatable.
Andreas
2015-02-25 17:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:
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
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
, at 10:15 AM, Igor Fedorenko i...@ifedorenko.com 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
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 the
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 local repo. See if
removing ~/.m2
, 2015, at 8:57 AM, Robert Scholte rfscho...@apache.org
wrote:
Op Sat, 21 Feb 2015 14:12:22 +0100 schreef Igor Fedorenko
i...@ifedorenko.com:
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
/ for project specific jvm options and maven parameters
Signed-off-by: Igor Fedorenko ifedore...@apache.org
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/8ed9a1ca
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree
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
://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 created
plugin realm will have access to all classes from the provided parent
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
-0500
schrieb Igor Fedorenko i...@ifedorenko.com:
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
:31:47 +0100 schreef ifedore...@apache.org:
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 ifedore...@apache.org
Project: http://git-wip
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
i...@ifedorenko.com:
Robert,
Can you explain your concerns? I believe it is a common practice to use
separate include file to keep logic shared
...
On Sun, Feb 8, 2015 at 3:04 PM, Jason van Zyl ja...@takari.io 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 AM, Igor Fedorenko
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 found
DefaultMavenReportExecutor from maven-reporting-exec
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 is
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
?
Thanks
-D
On Tue, Jan 27, 2015 at 3:01 PM, Igor Fedorenko i...@ifedorenko.com 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
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.
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
I think we should. I also noticed the current formatter and checkstyle
disagree about explicit type parameters like in
Collections.StringemptyList()
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
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
-01-15 0:43, Kristian Rosenvold wrote:
2015-01-15 4:48 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:
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
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
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
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
:
refs/heads/master 5f71f9789 - bb4988496
better plugin/extensions realm parent classloader
Signed-off-by: Igor Fedorenko ifedore...@apache.org
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
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, which
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
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
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
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
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
than pure Java
libraries.
William
ᐧ
On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko i...@ifedorenko.com wrote:
I am not sure I follow. Can you explain what actually happens and how
forcing type element for all projects dependencies is expected to help
the problem?
--
Regards,
Igor
On 2014
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 i...@ifedorenko.com
wrote:
I am not sure I follow. Can you explain what actually happens and how
forcing type element for all projects dependencies is expected
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/
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 breaks maven-toolchains-plugin
Le samedi 13 décembre 2014 07:22:03 Igor Fedorenko a écrit :
Are you able to run mvn validate on the attached project with staged
maven 3.2.4 or current master? The log you attached is from maven 3.2.3.
I've attached log from current master.
--
Regards,
Igor
On 2014-12-13, 3:32, Hervé BOUTEMY
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 earlier versions
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écembre 2014 18:38:44 Igor Fedorenko a écrit :
Unfortunately, I have to take
after a .0 so this will be
3.2.5,
yes?
On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io
wrote:
The fixes have been made, I'll recut the release.
On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com
javascript:; wrote:
I've already reintroduced
+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=10500version=20574
Staging repo:
,
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=10500version=20574
Staging repo
, 2014, at 6:38 PM, Igor Fedorenko i...@ifedorenko.com
wrote:
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 earlier versions of Maven.
For better or worse
I am not sure I follow. Can you explain what actually happens and how
forcing type 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
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, Karl Heinz
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
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
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
affects 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 i...@ifedorenko.com
wrote:
I think I know the problem
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
especially 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. I
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
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
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 and...@hammar.net wrote:
this is
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]
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
i...@ifedorenko.com:
What EOL handling
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 i...@ifedorenko.com:
What
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
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 Flexmojos.
Chris
-Ursprüngliche Nachricht-
Von: Igor Fedorenko
Agree. 1.7 makes more sense at this point.
On September 27, 2014 1:41:31 PM EDT, Michael Osipov 1983-01...@gmx.net wrote:
We moved core to 1.6 some time ago. Time to move everything else as
well ?
Kristian (Who's ready to say 1.7 but we stop by 1.6 first :)
I would favor the move to Java
101 - 200 of 453 matches
Mail list logo
