I filed https://github.com/apache/maven/pull/225 a few months ago and
have not gotten any feedback. Is there anything I can do to move this
forward? This bug affects some uses of `flatten-maven-plugin`.
Thanks,
-Jesse
-
To
On 22 July 2014 09:00, Igor Fedorenko i...@ifedorenko.com wrote:
Unfortunately, MNG-5312 didn't have any
test case so I am wondering if Jesse or somebody else can provide more
details about exact conditions that triggered MNG-5312 and, ideally,
setup a regression test.
As noted in MNG-5312, I
On 05/16/2013 05:42 PM, Jörg Hohwiller wrote:
is there already some slight inital draft or idea for a strategy how maven x.y
could deal with jigsaw?
I wrote up a very preliminary sketch about a year ago [1] but have not worked on it since then, and whatever worked then may or may not work
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html still
shows documentation for 2.13.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
https://github.com/apache/maven-3 does not seem to contain recent changes, such as 3.0.5. https://github.com/apache/maven does seem to be properly mirrored, so maybe
someone can delete or deprecate the old mirror?
-
To
FYI, I have found what is for me at least a critical regression in 3.0.5
relating to HTTPS deployment:
https://jira.codehaus.org/browse/MNG-5443
(Sorry for not testing during voting period.)
-
To unsubscribe, e-mail:
On 02/19/2013 10:28 AM, Olivier Lamy wrote:
We fixed 1 issue:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088
I guess this means that fixes such as MNG-5312 are deferred to another release
like 3.1.0?
[1] https://jira.codehaus.org/browse/MNG-5312
On 02/06/2013 05:23 PM, Mark Struberg wrote:
What are the big features and possibilities we gain from 1.6?
The largest in this context would probably be:
- annotation processors
- script engine
- split bytecode verifier (thus quicker startup)
Java 7 is a bigger bump (NIO.2,
On 01/13/2013 02:09 PM, Kristian Rosenvold wrote:
Anyone have any other suggestions?
http://piccolo.sourceforge.net/ is old but claims to be what you asked for.
Central does not seem to have the most “recent” release unfortunately.
On 11/28/2012 11:04 AM, Arnaud Héritier wrote:
there are only few bug fixes
For the affected users, MNG-5312 [1] is pretty serious.
[1] https://jira.codehaus.org/browse/MNG-5312
-
To unsubscribe, e-mail:
On 11/12/2012 02:00 PM, Dennis Lundberg wrote:
I had a quick look at the Windows ITs and the problem seems to be that
Maven/Jenkins is unable to delete files. This looks like a Windows path
length issue, because the path it complain about is 264 chars long.
JENKINS-15418 [1] was fixed in
On 09/13/2012 10:16 AM, Kristian Rosenvold wrote:
https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin
Interesting. I had a thought a while ago for an IDE to help you with similar tasks [1] but having it as a Maven plugin would arguably be better, especially if user
On 09/05/2012 08:39 AM, Olivier Lamy wrote:
I'm a bit curious to see if that will increase externals contributions.
I think plain Git is only marginally more friendly for external contributors than Subversion. Yes you can create a local branch and update it against trunk changes, but
you
On 08/03/2012 09:15 AM, Anders Hammar wrote:
What's the benefit of this approach rather than just having the user adding the
dependencies directly to the plugin (execution) declaration?
Linkage safety. If you have the-plugin built directly against
the-build-tool@1.1.2, and the user
On 08/02/2012 04:58 AM, Anders Hammar wrote:
not have a dependency on some library in the plugin itself but rely on it being
declared as a dependency in the Maven project where the plugin is bound. That
made it
totally controllable by the project.
If the build-time code would not normally
On 07/31/2012 02:43 PM, Hervé BOUTEMY wrote:
compile is the default scope, isn't it?
Or do I miss something?
Perhaps scopeprovided/scope was meant?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional
On 08/01/2012 09:57 AM, Jesse Farinacci wrote:
http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
Side note: this page fails to mention -Dmaven.ext.class.path=... as an alternative to adding to lib/ext/*.jar, which I guess would work (based on its recommendation from
On a related note, I think we need a new archetype for plugins; the existing
maven-archetype-mojo 1.0 is out of date and not ready for annotations.
Specifically needed:
1. Need a dep on maven-plugin-annotations.
2. Need to specify skipErrorNoDescriptorsFound.
3. Have to explicitly call
On 05/11/2012 04:15 AM, Kristian Rosenvold wrote:
I have been considering fixing classworlds and m3 core to exploit the
parallel classloading abilities of java 7. The idea would be to load
plugin classloaders in parallel to increase performance.
You can load classes in multiple threads in
On 05/09/2012 12:56 PM, Olivier Lamy wrote:
we still need to do some javadoc parsing for @deprecated
Just look for @Deprecated - the real annotation - instead. (Note that javac
will warn you if you have the Javadoc tag without the annotation.)
@since and comments for class/field
On 04/27/2012 01:39 PM, Hilco Wijbenga wrote:
What about -am and -amd?
-am does work together with -pl. Vincent's issue is that -pl must be given a
full list of submodules; just passing an aggregator is not enough. For example,
take
top
+- libs
| +- lib1
| +- lib2
+- apps
+- app1
|
On 04/27/2012 01:34 PM, Ansgar Konermann wrote:
JFrog (the Artifactory guys) has already published a set of Java
1.5 annotations for mojo development, including a m-plugin-p extension to
use them.
Beware that (acc. to their documentation) the tool relies on APT, which is
deprecated in JDK 6
On 04/17/2012 03:24 AM, Vincent Latombe wrote:
Maven tries to parse the project and if it fails, it doesn't even call my mojo.
Same applies to 'mvn archetype:generate'. Seems to me that this is a bug more
than an RFE.
Note that invocations of bin/mvn without a goal but with e.g.
On 02/17/2012 04:03 AM, Romain Manni-Bucau wrote:
proxy settings (understand proxy defined in settings.xml)
By the way has any thought been given to better supporting -Djava.net.useSystemProxies=true, i.e. automatic detection according to system settings? It works on most
platforms for apps
On 02/17/2012 08:14 AM, Kristian Rosenvold wrote:
As long as the patch is to the appropriate
code style and containst test-cases, we will review it.
Not true in the case of e.g. MCOMPILER-140.
-
To unsubscribe, e-mail:
FYI - should be bundled in the next NetBeans nightly development build.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
FYI - again integrated into NetBeans development builds to spur testing.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On 12/08/2011 06:34 AM, Benson Margulies wrote:
In the test case, there's a maven plugin which declares various maven
2 components as provided dependencies, notably the
DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me
the source to the 2.2.1 version even though, since I'm
FYI - NetBeans nightly development builds [1] are now bundling RC3, to shake
out problems in either the embedded APIs or general usage.
[1] http://bits.netbeans.org/download/trunk/nightly/latest/
-
To unsubscribe, e-mail:
On 12/07/2011 02:04 PM, Olivier Lamy wrote:
please note it's *not* an official release so this will never be
distribute as an official Apache Maven release.
It's only a rc build to get feedbacks from users.
Yes of course. This is only temporary until another RC or a final build is
published -
On 11/15/2011 12:41 AM, Carlos Sanchez wrote:
Vote open for 72H.
What happened to this vote? Never finalized, and 2.4 is still unreleased?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands,
+1 (non-binding). Tested integration into a NetBeans development build, and
built some modules in Glassfish, so far without problem.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
Did you consider using the standard javax.script.* API instead of some or all of these interfaces? That would permit automatic support for many languages by just dropping
the JAR with the (non-Maven-specific) META-INF/services/javax.script.ScriptEngineFactory into the classpath/realm, and offers
On 11/09/2011 12:00 AM, Jason van Zyl wrote:
today we learned about the AbstractMavenLifecycleParticipant
Here's an example of how it works for matching the dependencies specified from
a 3rd party source to the reactor.
[...]
It's using JSR330, but you can pull those out and use Plexus
On 11/04/2011 07:13 AM, Stephen Connolly wrote:
you generate a class that extends
AbstractMojo, has the required injection fields for all the
@parameters and has an execute method that passes through all the
injection fields and then invokes the required method.
By the way this (as well as
A patch with test has been attached to MNG-5075 [1] since April but there have been no comments. Are pull requests on GitHub preferred, or anything else I need to do?
Pinging the list since I came across another case [2] of this bug needing to be worked around.
[1]
On 10/28/2011 03:13 PM, Benson Margulies wrote:
There's no ant-nodeps for 1.8.2.
Correct, this JAR was removed in 1.8.2 since many of the optional tasks did not differ in any fundamental way from core tasks. The separated JARs are now reserved for
bundled tasks which depend on third-party
On 10/22/2011 05:00 AM, Mark Struberg wrote:
there is atm a strict 1:1 between a Modul and a ClassLoader.
This would not be true for the special case of JDK modules (what is now rt.jar + tools.jar); probably TBD whether user modules will be permitted to share class loaders
for ease of
Reposting to an old thread, since I am still running into what seems to be
Maven 2 debris in the APIs.
On 11/19/2010 02:19 PM, Kristian Rosenvold wrote:
if it hurts you, make a patch; documentation upgrade, javadoc or code changes
The difficulty with submitting Javadoc changes is that if you
Non-binding +1.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On 08/26/2011 01:51 AM, Kristian Rosenvold wrote:
aiming for a release sometime mid-next week
Please consider including the fix for MCOMPILER-140 if you cut a release. It
has been sitting there with a patch for months with no activity.
On 08/25/2011 07:34 AM, Benson Margulies wrote:
I discovered yesterday that one team had taken this idea to its local
extreme, and were just using release versions, no -SNAPSHOTS at all.
Do you mean they were only using release versions in dependencies? This would make sense to me. If you want
On 07/31/2011 05:12 PM, Benson Margulies wrote:
https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
It would [...] be a bad idea to try to use namespaces as a versioning technique. - if you want to allow Schema validation of the entire POM, I think you have
On 08/02/2011 08:52 AM, Benson Margulies wrote:
Adding explicit elements next to xs:any is a far more user-friendly
extensibility mechanism than creating a hodgepodge of namespaces and
prefixes.
Agreed. But if ease of hand editing trumps validation and other tool support,
do you really want
On 08/02/2011 08:39 AM, Jason van Zyl wrote:
The schema is being generated from the Modello model so if you see things that
are incorrect...
For the record, XsdGenerator.java explains:
// Usually, would only do this if the field is not required, but due to
inheritance, it may be
// present,
On 08/02/2011 06:00 PM, John Casey wrote:
Anyone maybe have an advanced POM reader/writer stashed somewhere that can
preserve CDATA and the like?
http://code.google.com/p/decentxml/source/browse/trunk/src/test/java/de/pdark/decentxml/MavenSNR.java
is said to.
On 07/17/2011 05:30 PM, Benson Margulies wrote:
I can't even figure out which JIRA in MDEP corresponds to [the dependency
plugin issue]. Could someone please send me a pointer?
Are you referring to http://jira.codehaus.org/browse/MSHARED-167 by any chance?
https://jira.codehaus.org/browse/MSHARED-167 remains unfixed in this release, despite Maven 3 and Aether having been out for a while. (Perhaps the issue should be moved
to MDEP.)
-
To unsubscribe, e-mail:
On 07/02/2011 08:04 PM, Benson Margulies wrote:
In maven-shade-plugin, I modified my local copy to point to
maven-plugins version 20 as parent. This in turn points to maven
parent 20. Which configures the compiler plugin for source level 1.5.
Perhaps you mean you pointed to
On 06/27/2011 06:54 PM, Stephen Connolly wrote:
Critically missing from my PoV are:
Consider also 'endorsed' (a serious issue for EE projects especially):
http://jira.codehaus.org/browse/MNG-4752
Also some notes on a non-transitive compile scope: for NetBeans module development, module -
Non-binding +1; no apparent problems in NetBeans integration during basic
interactive tests.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On 05/24/2011 06:01 AM, Olivier Lamy wrote:
Something else I think in a 2.0 version is : upgrading to Apache HttpClient 4.x
http://jira.codehaus.org/browse/WAGON-314 is critical for the lightweight wagon, by the way. And if you are trying to drop dependencies, see my comment in
On 05/24/2011 01:30 AM, Brett Porter wrote:
Some notes on how I think it should work:
- templates should look like a normal POM (perhaps only differing in root
element, and less strict validation requirements) [...]
- any POM element is valid, other than
http://jira.codehaus.org/browse/MCOMPILER-140 is a fairly basic bug in plexus-compiler-javac. It is known to break error hyperlinking for Windows users on IDEA (as of six
months ago), and NetBeans 7.0 (until a planned workaround patch is released). I attached a proposed patch (including unit
On 04/22/2011 05:51 AM, Dennis Lundberg wrote:
There are a numbers of problems that prevents our plugins from building
successfully in the ASF Jenkins instance.
bui...@apache.org might be the better place to post, at least for issues
related to the build server itself.
On 04/12/2011 09:32 AM, Olivier Lamy wrote:
I'd like to release surefire 2.8.1
You may want to take a look at SUREFIRE-724 first. Not sure if this would be
simple to fix, though.
-
To unsubscribe, e-mail:
On 04/13/2011 07:56 AM, Julien HENRY wrote:
I would like to know if there is a standard Maven API to edit parts of a
pom.xml. I managed to parse a pom to a Model using ModelBuilder. Then I can do
some modifications and write Model to file using ModelWriter. But of course it
will completly
On 04/05/2011 12:31 AM, Brett Porter wrote:
2. mvn --also-make-goals -pl submodule test-compile test
Does the issue make sense now, and is it worth filing a JIRA ticket for this?
It makes sense.
Filed then: http://jira.codehaus.org/browse/MNG-5059
Not sure how it would be implemented,
On 10/02/2010 07:27 AM, Brett Porter wrote:
mvn -am -pl main run
would automatically invoke just 'install' (or 'package') on the calculated
dependencies.
I don't agree that install on one and package on the dependencies would make
sense - this would put something in the repository that
On 03/31/2011 03:55 PM, Brian Demers wrote:
https://repository.apache.org/content/repositories/maven-056/
Non-binding +1 based on testing in NetBeans integration.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
On 03/04/2011 12:29 PM, Benjamin Bentmann wrote:
As long as somebody else provides the patch, that's fine with me
http://jira.codehaus.org/browse/MNG-5046
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For
Is this line in .gitattributes for Maven 3 sources really necessary? Using $Id$ is ugly; right now seeing if I can work around a status bug in the NetBeans Git
integration caused by it. Wouldn't it be better to just delete $Id$ from those SVN sources where it appears?
On 02/28/2011 07:09 AM, Benjamin Bentmann wrote:
Fixed in trunk by now.
Rev 1075309, which seems to be included in 3.0.3 final. Suggestion for
tightening up RepositoryUtils.getLayout a bit:
1. Call repo.getLayout() outside the try block, since that is not expected to
give an error. It is
On 12/07/2010 06:09 PM, Brian Fox wrote:
We'll take a pass and see which are applicable
That's what I meant; of course some will not be.
flag them in some way.
Such as closing them and refiling in MINDEXER? If someone bothered to report a bug, it seems like the least you can do. (And the
On 11/23/2010 02:06 PM, Brian Demers wrote:
Vote open for 72 hours.
Is this release still going ahead?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Non-binding +1; seems to be working fine in NetBeans development builds.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On 11/23/2010 02:06 PM, Brian Demers wrote:
Staging repo: https://repository.apache.org/content/groups/maven_promotion-010/
Ironically enough, the index for this repo seems to be broken. :-) https://repository.apache.org/index.html#view-repositories;maven_promotion-010~browseindex gives a 500
On 11/19/2010 01:36 PM, Rex Hoffman wrote:
Maybe we should construct a cleaner api though. One that could wrap
maven-dependency-tree in maven 2.2.1 and use aether in 3.0.
Alternately: release maven-dependency-tree 1.3 with an unchanged public signature that is just a proxy for Aether API, and
On 11/18/2010 03:34 AM, Kristian Rosenvold wrote:
The rant is somewhat about seeing all these internal components.
A little bit, though it is generally easy to see from the package or class name that something should be considered an implementation. My slow learning curve has had to
do with
On 11/18/2010 07:20 PM, Rex Hoffman wrote:
it's pretty straight forward if you use some code provided by the dependencies
library (part of the maven-dependencies-plugin)
Beware that this does _not_ produce the same results as Aether in certain
cases, and there is no apparent plan to fix it:
On 11/15/2010 04:45 AM, nicolas de loof wrote:
AFAIK most code (including some
plugins) related to POM parsing use Xpp3Reader, as we don't provide an
abstraction API for POM parsing.
Along the same lines, http://jira.codehaus.org/browse/MNG-4862 shows that
On 11/09/2010 07:07 PM, Rex Hoffman wrote:
I'm leaning to using the (javadoc) annotations
The trouble with Javadoc pseudo-annotations is that they are unavailable in bytecode and thus invisible to a tool like sigtest. I don't know about Clirr. I suspect this
particular set of Javadoc tags was
On 11/08/2010 02:21 AM, Rex Hoffman wrote:
project: java-version-delta
By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license feature set suits your needs but it would make
a potentially useful alternate impl. This is the
On 11/09/2010 11:30 AM, Rex Hoffman wrote:
The only current problem is that it's not in the maven repo.
True. Probably not hard to fix, if that is the only obstacle; take it off list
if interested.
I don't suppose your teams usage of it is based off on an open source ant task?
Currently
On 11/09/2010 02:21 PM, Rex Hoffman wrote:
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
Take note of the distinction made on pp. 5-6 between interface and package. Without some special annotations, it is not possible for a tool to mechanically decide
whether a given interface
On 10/02/2010 07:27 AM, Brett Porter wrote:
Are there plans for a more clever make mode? The 3.0 compatibility guide
implies that there are, but does not give any specifics.
I'm not sure what you're referring to that gave that indication?
Nonbinding +1; seems to be working well embedded in NetBeans IDE development
builds. Nice job.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
While working on IDE support for running Maven on multi-module projects [1] I have run up against what seems to be a fundamental limitation of --also-make. This reactor
mode works fine when the specified goal is standard across all lifecycles in the tree, such as 'install' or 'package'.
But
[Originally posted to d...@mojo without response. This might be the more
appropriate list, so reposting here also with some updates.]
Recently I worked on an IDE feature [1] which enumerates archetypes available in your local repository that you might want to instantiate projects from, so you
http://jira.codehaus.org/browse/MNG-4836 may or may not be a recent regression, but I have recently (i.e. ~ RC1) observed it making projects sporadically unloadable
inside the NetBeans IDE, with no apparent workaround. Have been running with a patched plexus-interpolation and have not seen it
On 09/16/2010 05:21 AM, Benjamin Bentmann wrote:
This is an attempt to collect feedback from a broad audience before we start
the vote for 3.0, similar to what was done in the past.
I'm a bit confused over the labeling RC1, perhaps you could clarify.
1. Nothing is published at
On 09/15/2010 04:34 PM, Benjamin Bentmann wrote:
If you encounter unexpected build issues, please fil[e] a report in JIRA
Would be good to take a look at http://jira.codehaus.org/browse/MNG-4428 (server redirect handling) and reconsider its low priority. Although it is claimed to affect
2.2.1
82 matches
Mail list logo
