Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0
+1!!! Dan > On Oct 29, 2019, at 4:11 PM, Karl Heinz Marbaise wrote: > > Hi to all, > > based on the discusion this is the formal VOTE to lift the minimum of > Maven Core with version 3.7.0 to JDK 8 minimum. > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Release Apache Maven 3.5.0-alpha-1
+1 Did some very basic tests running CXF builds and it all seems to work OK. Not very elaborate set of tests though. Dan > On Feb 27, 2017, at 9:42 AM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: > > Hervé, Robert you have commented but I do not see a vote cast. I believe I > have 3 binding votes, but as one of those is mine I would be more > comfortable with some more > > On 23 February 2017 at 16:10, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> Hi, >> >> We solved 65 issues: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa? >> projectId=12316922=12339664=Text >> >> There are still a couple of issues left in JIRA for 3.5.0, but I do not >> think any of those are blocking an alpha release: >> https://issues.apache.org/jira/issues/?jql=project%20% >> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND% >> 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER% >> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC >> >> In addition there are 315 issues left in JIRA for Maven core: >> https://issues.apache.org/jira/issues/?jql=project%20% >> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER% >> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC >> >> Staging repo: >> https://repository.apache.org/content/repositories/maven-1324 >> >> The distributable binaries and sources for testing can be found here: >> https://repository.apache.org/content/repositories/maven- >> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/ >> >> Specifically the zip, tarball, and source archives can be found here: >> https://repository.apache.org/content/repositories/maven- >> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache- >> maven-3.5.0-alpha-1-bin.zip >> https://repository.apache.org/content/repositories/maven- >> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache- >> maven-3.5.0-alpha-1-bin.tar.gz >> https://repository.apache.org/content/repositories/maven- >> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache- >> maven-3.5.0-alpha-1-src.zip >> https://repository.apache.org/content/repositories/maven- >> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache- >> maven-3.5.0-alpha-1-src.tar.gz >> >> Source release checksum(s): >> apache-maven-3.5.0-alpha-1-src.tar.gz sha1: 6055696aece5b0bfdd0308dae60838 >> b37e218aba >> apache-maven-3.5.0-alpha-1-src.zip sha1: 7d6adcdf8929205bf20399c71c6a2b >> db9ee4f6dd >> >> Git tag: >> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h= >> 8e6bbc4d4aa7cdc837625a05358c98ca15f72698 >> >> Staging site: >> https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/ >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> >> Thanks, >> -Stephen >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Checkstyle Plugin version 2.17
+1 Tested with CXF. I did get an strange class loader error at first as CXF tried to force the checkstyle plugin to use checkstyle 6.4.1 (due to a bug in 6.5.x) which is apparently too old, but once I removed that, it was fine. (and it appears the bug in 6.5 has been fixed, yea!) Dan > On Oct 15, 2015, at 2:59 PM, Michael Osipov <micha...@apache.org> wrote: > > Hi, > > We solved 7 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12333072 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project+%3D+MCHECKSTYLE+AND+resolution+%3D+Unresolved+ORDER+BY+priority+DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1223/ > https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17-source-release.zip > > Source release checksum(s): > maven-checkstyle-plugin-2.17-source-release.zip sha1: > 73c72f082ec3ee2a89f54563f8d65393cd6f3886 > > Staging site: > http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Writing poms from mojos
The shade plugin can also create a “dependency reduced” pom. Dan > On Sep 2, 2015, at 10:13 PM, Barrie Treloar <baerr...@gmail.com> wrote: > > There are ~3000 plugins in Maven Central ( > http://search.maven.org/#search|ga|1|p%3A%22maven-plugin%22). My eyes > glazed over after scanning through the first 100 to see if there are plugin > names to indicate if they might re-write poms. > > So I'll stick with the available plugins list ( > http://maven.apache.org/plugins/) and it looks like the only plugins that > modify the pom are: > * release > * versions > > I've also looked at m2eclipse (https://github.com/eclipse/m2e-core.git) to > see how it rewrites poms. m2eclipse can get away with working with the > Eclipse provided StructuredModels to grab a dom version of the editor and > just rewrite that one section, knowing that it doesn't need to rewrite the > whole file. > > The Maven plugins on the other hand need to stream in the file and preserve > all the kooky white space and commenting, as well as update just the > sections they want to modify. > > The release plugin uses org.jdom.Element to manipulate rewrites, and > org.jdom.output.XMLOutputter with a raw formatter to write the pom file out. > > The versions plugin uses StringBuilder as an in memory copy of the pom file > and the StAX2 api to manipulate rewrites, and an XmlStreamWriter to write > the pom file out. > > Have I missed any plugins? > > For such a small number of plugins that need to make rewrites it probably > not necessary to have this functionality offered in Maven directly... -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Eclipse Plugin Final Release ?
On Apr 30, 2015, at 4:25 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, i would like to know if there are any objections to make a final release of the maven-eclipse-plugin ? No objections to doing the release. Objection to calling it a final release. :-) Dan The reason is simply because it is the last plugin on the list which misses the Maven 2.2.1 minimum This could make our release map complete here... as you can see here: https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html If there will be no objections until 8. May 2015 i will start a release on weekend afterwards... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Compiler Plugin version 3.3
+1 Dan On Mar 25, 2015, at 4:10 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, here is my +1. Two more binding VOTE's needed. Kind regards Karl Heinz Marbaise On 3/23/15 7:45 PM, Karl Heinz Marbaise wrote: Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=20684 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MCOMPILER%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1156 ehttps://repository.apache.org/content/repositories/maven-1156/org/apache/maven/plugins/maven-compiler-plugin/3.3/maven-compiler-plugin-3.3-source-release.zip Source release checksum(s): maven-compiler-plugin-source-release.zip sha1: 1a5035708dac56ecbcb10c153110d00871e771f3 Staging site: http://maven.apache.org/plugins-archives/maven-compiler-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Open JIRA issues/retiring plugins
I’m -1 to retiring the maven-eclipse-plugin until the m2e stuff is at a state where it can be as flexible and useful as the maven-eclipse-plugin. Trying to bring a large complex project like CXF into eclipse with m2e is PAINFUL and doesn’t even result in fully configured and ready workspace. The developer experience within eclipse is so much better after using the maven-eclipse-plugin. I suppose that does mean I should step up and look at some of the JIRA’s and get a release out. I’ll see if I can find some time. Dan On Feb 2, 2015, at 4:23 AM, Michael Osipov 1983-01...@gmx.net wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Change project logo and adopt owl as mascot
+1 I like the owl. Dan On Nov 25, 2014, at 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: For anyone who has been living under a rock, here is the background Background = I think everyone can agree that the site needs a reorganisation and a rewrite. Users cannot find what they need, and the end result is that people keep on abusing maven rather than having maven help them. Try as I might, I have been unable to motivate myself to do the reorganisation with the current dated look and feel of the site... I am not saying that picking a new logo and selecting a mascot will result in making progress, but it can't hurt and I believe it will help Proposed changes === 1. Change the logo font to Alte Haas Grotesk Bold with italics applied by Inkscape 2. Change the highlighted letter from 'a' to 'v' and replace the v with two Apache Feathers 3. Adopt the (currently unnamed) owl as our mascot Here is a link to the font: http://www.dafont.com/alte-haas-grotesk.font Here is a large version of the owl and the logo: http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-large.png A regular version of the own and the logo, e.g. a size suitable for use in the top of the standard maven sites: http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final.png (Note that in all likelihood, the mascot would probably end up on the other side of the title bar from the logo... and that is IF the mascot ends up on the title bar) Here is both of those rendered in a site (as it can be helpful to see the graphics adjacent to text) http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-context.png Logo Rational === If we do some searches for the Maven logo: https://www.google.com/search?site=imghptbm=ischq=maven+logooq=maven+logo http://www.bing.com/images/search?q=maven+logogo=Submitqs=nform=QBLHscope=imagespq=maven+logo Our current logo, with a single highlighted letter stands out quite well from the other maven logos, so keeping a highlighted letter and an italic rendered font maintains continuity with our current logo. By changing the highlighted letter to the `v` and by using two Apache feathers to create the `v`, we connect our logo back to Apache... we are Apache Maven after all. The `v` is also the common short term for version (e.g.v3 is short for version 3). Apache Maven puts a lot of emphasis on versions of dependencies and plugins... you could say that versions are very important to Maven. The colours of the feather were changed to solid colours to match the owl mascot's scarf, beak and eyebrows Voting rules = Anyone who is subscribed to the dev or users list is eligible to vote. If you vote multiple times, only your final vote will be counted. The vote will be open until 1:00pm GMT on Wed 3rd Dec 2014 The vote is for all three changes as one single change. Partial votes (e.g. for the logo but not the mascot, or vice-versa) will not be counted. I, as the caller of the vote, reserve the right to cancel the vote if this vote is putting the harmony of the community at risk. If a majority of the PMC believe that this vote is putting the harmony of the community at risk, then the PMC may cancel this vote (though if even a small minority of the PMC were of that belief, I will more than likely have cancelled the vote before the PMC would need to decide... I'm just stating this FTR) The decision will be a simple majority, there will be no special veto powers. +1: [ ] Change the logo to the proposed logo and adopt the owl as project mascot 0: [ ] No opinion -1: [ ] No change Please only respond with +1, 0 or -1. If you want to discuss the proposed changes please use a different thread. This thread is for voting only. -Stephen -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Developer Hangout
Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(:);
String type = (s.length = 4 ? s[3] : jar);
Artifact artifact = repository.createArtifact(s[0], s[1], s[2], type);
ArtifactResolutionRequest request = new ArtifactResolutionRequest();
request.setArtifact(artifact);
request.setResolveRoot(true).setResolveTransitively(false);
request.setServers( session.getRequest().getServers() );
request.setMirrors( session.getRequest().getMirrors() );
request.setProxies( session.getRequest().getProxies() );
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(session.getRequest().getRemoteRepositories());
repository.resolve(request);
return artifact.getFile();
}
If you set “setResolveTransitively(true)” then the ArtifactResolutionResponse
would have all the deps available in it.
That seems to work for both Maven 3.0 and 3.1/3.2.
Dan
Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson
william.fergu...@xandar.com.au:
I asked on maven-users but didn't get any viable responses. So I'm hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies. How
can/should I do it?
If I can resolve the Artifact to a MavenProject then I can use
DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of
the deps. But I'm struggling to make the Artifact to MavenProject
conversion happen.
I thought that If I could get a URL to the Artifact's POM file then I could
use DefaultMavenRuntime (maven-runtime) to resolve the URL into a
MavenProject. But
1. I can't work out how to get a URL to the artifact's POM file (it
needs to handle both reactor artifacts and repo artifacts)
2. Even with a URL to the POM file, MavenRuntime#getProject) is
returning null.
Can someone please point me in the right direction?
Am I even on the right path or is there a much more straight forward way of
getting the dependencies for the Artifact?
--
William
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
On Jun 19, 2014, at 6:36 PM, William Ferguson william.fergu...@xandar.com.au
wrote:
Hi Dan,
if the ArtifactResolutionResult contains the deps for the Artifact in the
request then that's exactly what I want. However I can't see that it does.
What am I missing?
ArtifactResolutionResult.getArtifacts() is a list of all the artifacts that it
resolved.
NB the resolution also needs to be able to resolve Artifacts in the
reactor. I'm pretty certain that
@Component
private org.apache.maven.repository.RepositorySystem repository;
is only going to resolve from the local repo, not the reactor, right?
This I don’t know. I haven’t tried to have it resolve anything in the reactor.
Dan
William
On Fri, Jun 20, 2014 at 4:58 AM, Daniel Kulp dk...@apache.org wrote:
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(:);
String type = (s.length = 4 ? s[3] : jar);
Artifact artifact = repository.createArtifact(s[0], s[1], s[2],
type);
ArtifactResolutionRequest request = new
ArtifactResolutionRequest();
request.setArtifact(artifact);
request.setResolveRoot(true).setResolveTransitively(false);
request.setServers( session.getRequest().getServers() );
request.setMirrors( session.getRequest().getMirrors() );
request.setProxies( session.getRequest().getProxies() );
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(session.getRequest().getRemoteRepositories());
repository.resolve(request);
return artifact.getFile();
}
If you set “setResolveTransitively(true)” then the
ArtifactResolutionResponse would have all the deps available in it.
That seems to work for both Maven 3.0 and 3.1/3.2.
Dan
Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson
william.fergu...@xandar.com.au:
I asked on maven-users but didn't get any viable responses. So I'm hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies.
How
can/should I do it?
If I can resolve the Artifact to a MavenProject then I can use
DependencyGraphBuilder (from maven-dependency-tree) to construct a graph
of
the deps. But I'm struggling to make the Artifact to MavenProject
conversion happen.
I thought that If I could get a URL to the Artifact's POM file then I
could
use DefaultMavenRuntime (maven-runtime) to resolve the URL into a
MavenProject. But
1. I can't work out how to get a URL to the artifact's POM file (it
needs to handle both reactor artifacts and repo artifacts)
2. Even with a URL to the POM file, MavenRuntime#getProject) is
returning null.
Can someone please point me in the right direction?
Am I even on the right path or is there a much more straight forward way
of
getting the dependencies for the Artifact?
--
William
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: How do we close pull requests?
Or file a ticket with INFRA to have them closed. Or add a comment to the pull request to say “please close this” and hopefully the person who submitted it would close it. Dan On Jun 10, 2014, at 8:54 AM, Benson Margulies bimargul...@gmail.com wrote: you make a commit with a comment that instructs the daemon to close it, as per Dan Kulp's email the other day. On Tue, Jun 10, 2014 at 8:52 AM, Jason van Zyl ja...@takari.io wrote: How do we get access to close pull requests? These are just requests that are rejected and I'd like to get rid of them. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Processing Pull Request
On May 24, 2014, at 9:18 AM, Michael Osipov mosi...@gmx.de wrote: Hi, does it take special permissions on Github to process pull requests? Neither am I allowed to perform the merge from the website directly, nor does it display the command line steps as described in the GH help. Close is not available to me too. I simply pulled (PL 14) into my local repo and then pushed, asfgit processed but the PL is still on merged but not closed. Is there any writeup how a PL should happen in the project? Maven Git Convention [1] does not provide any valueable information. If it doesn’t auto close for whatever reason (likely a rebase or something), then you would need to put a comment on the pull request like: Can you verify that the functionality ha been merged correctly and close this if it has. or similar to get the requestor to close it. OR Make a simple commit with: This closes #14 in the log message and the asf bot will close it. OR File a request with INFRA to close it. In general, if you pull a pull request and it ends up rebating or similar so the sha1 is different, then you should likely do a “git -a —amend” and edit the commit message to to add the “This closes #XX” line to the message before you push. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven] removed XSD generation since it is not published (19247f3)
We need to file a request with infrastructure to have all the maven repos upgraded to the latest “github goodies”. Pull requests should have more information in them, comments on pull requests should come back to this list, etc…. I know that’s all working for the CXF pull requests. For example: http://cxf.547215.n5.nabble.com/GitHub-cxf-pull-request-PR-fix-CXF-5719-tt5744323.html And note how that then integrates with JIRA: https://issues.apache.org/jira/browse/CXF-5719 although that would require getting all our JIRA projects moved to apache. Dan On May 25, 2014, at 6:06 AM, Arnaud Héritier aherit...@gmail.com wrote: With a virtual account using this address and subscribing to github notifications ?— Sent from Mailbox On Sun, May 25, 2014 at 12:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: there are interesting discussion happening on github, but they are not routed to any mailing-list, so they stay completely personal: this is not good for community, IMHO is there a way to have such discussions sent to dev@? Regards, Hervé -- Message transmit -- Sujet : Re: [maven] removed XSD generation since it is not published (19247f3) Date : dimanche 25 mai 2014, 02:29:12 De : Dave Moten notificati...@github.com À : apache/maven ma...@noreply.github.com CC : Hervé Boutemy herve.bout...@free.fr I was interested in writing tooling around composing plugins maximising type safety for example but was disappointed that the definition of a plugin's configuration was not something I could reverse engineer satisfactorily from the plugin.xml and in the process discovered that the plugin.XML didn't have an xsd making more guesswork out of the process. I used xpath to get stuff out of it in the end but I stopped work when I realised that my only hope was parsing plugins' source code. I'm a big fan of XML always having an xsd but I probably won't be able to check out modello and get an xsd happening in the near future and I'm assuming for my interests that it won't help much either. I wonder if real type information for configuration will turn up in plugin.xml sometime? Thanks for chasing it. D On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote: on a pure principle, I know it looks awkward on a practical one: 1. did you ever try to write a plugin descriptor by hand? or do you always let plugin-tools generate the descriptor (like the vast majority of plugin developers)? 2. are you able to give us a xsd description for the configuration element content? and that fits into Modello descriptor, since Modello generates the xsd from .mdo? I'm not a big xsd expert: any help appreciated to fix the plugin.mdo I wrote to at least document the descriptor from a human point of view (ie not seeing in general that I had to cheat with configuration element) — Reply to this email directly or view it on GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6439921 . --- Reply to this email directly or view it on GitHub: https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6440111 - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Permissions change on cwiki?
Jason’s account was not in the maven-committers group. Now fixed. Dan On Apr 6, 2014, at 5:08 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: A couple of weeks ago infra disabled editing for all accounts due to an excessive spam influx. IIRC any admin can restore edit privileges. Martijn On Sun, Apr 6, 2014 at 9:17 PM, Jason van Zyl ja...@takari.io wrote: Can anyone else edit that page. Just checking to make sure it's just me before I ask infra to look. On Apr 6, 2014, at 9:41 AM, Jason van Zyl ja...@takari.io wrote: I can no longer see the edit button on a page I created: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Anyone else having permissions issues on cwiki? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release ASF Parent POM version 14
+1 Dan On Mar 6, 2014, at 4:18 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, Changes since the last release: http://svn.apache.org/viewvc/maven/pom/tags/apache-14/pom.xml?r1=HEADr2=1434717diff_format=h Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1000/ https://repository.apache.org/content/repositories/orgapacheapache-1000/org/apache/apache/14/apache-14-source-release.zip Source release checksum: apache-14-source-release.zip sha1: 6bed0856a4cc8d9ee5f4481b8a1e0a4460076073 Staging site: http://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
On Feb 13, 2014, at 11:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I suggest you convince at least one of these people: https://people.apache.org/committers-by-project.html#maven that they should act as release manager. EOL just means we will not be making new releases, and it will be moved to the archive section of the downloads. Well, one more thing: if it’s officially EOL, there is a much higher chance that plugins would be marked as using 3.x as a minimum and will no longer work with 2.1.1. API’s and such that the plugins use will likely get updated to 3.x level. Etc…. Anyway, I’m +1 to dropping 2.x support. Dan You will still be able to download it. You will still be able to get the source code. We just will be recognising the fact that there is nobody who wants to cut a release from the 2.x codebase. Hopefully focusing on the 3.x codebase will allow us to iron out the bugs you feel are present in 3.x and thus preventing you from migrating... but if there are any committers who want to cut 2.x releases, I - as a PMC member - will certainly stand up and do what is required in terms of testing the source bundle and checking the IP etc... I don't see any committers standing up. If the vote is for EOL and after this vote there is a committer who wants to act as release manager for 2.x, we will not stop them from releasing either... we will just stop putting 2.x on the active downloads page On 13 February 2014 15:52, Jörg Schaible joerg.schai...@swisspost.comwrote: Stephen Connolly wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. -1 This vote is real-life comedy as long as there is no newer version that succeeds with its core competence to build multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs. Embarassed, Jörg This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) +1 Good idea. Dan On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New logo?
On Dec 20, 2013, at 1:01 PM, Manfred Moser manf...@simpligility.com wrote: I would move the Raven closer to the word Maven but otherwise this looks good imho. Of course I am not sure if everyone would recognize it as a raven .. That’s my problem…. doesn’t look like a raven to me at all. When I first looked at it, I guess the “mouth + tough” part seemed to look more like the Seattle SeaHawks logo stuck on a boot with a weird swirly thing at the ankle. In other words, a little to “abstract” for me. :-) Dan manfred http://people.apache.org/~stephenc/maven-logo-contest/maven-6.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7a.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7b.png All based on this: http://people.apache.org/~stephenc/maven-logo-contest/maven-7b-big.pngwhich I traced from one of the raven totems The -7 set all echo the gradient used in the Apache feather, though I think the solid colour might have more strength. I'll see if I can find another one to try tracing On 19 December 2013 20:35, Manfred Moser manf...@simpligility.com wrote: Thats what I had in mind. Just a stylized version that is simplified and with not too many details. Even maybe just a head or upper body of the Maven Raven ... I just had to write that.. I like it ;-) manfred Likely that would be overly complex at small resolutions, but a monochrome all black stencil version might work for small versions with the full colour at 200px+ On Thursday, 19 December 2013, Paul Benedict wrote: I like the Raven idea -- especially if you can color the bird with the Apache feathers look. On Thu, Dec 19, 2013 at 12:13 PM, Manfred Moser manf...@simpligility.comjavascript:; wrote: What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- Cheers, Paul -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: pull requests on github?
On Sep 23, 2013, at 3:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: In order to accept patches into any Apache Foundation project there must be EITHER a signed ICLA on file from the person submitting the change OR a clear indication of intent to contribute the code to the Apache Foundation. For small or quick changes signing a ICLA is overkill and too large a barrier. The question then is, how do you indicate the intent to contribute the code to the Apache Foundation? 1. You could clearly state on the pull request that the changes are your own work and you are licensing them under the Apache License version 2.0 to the Apache Foundation. 2. You could create or update an existing issue in the project's issue tracker indicating that the patch is available as a pull request that you have authored and are licensing to the Apache Foundation under the Apache License version 2.0. The latter (i.e. just create or update an issue in the issue tracker and give a link to the pull request) is usually the easiest way to go. This has been discussed on a couple lists already. The consensus on the other projects I've been involved in is issuing a pull request from github is a clear enough intent to contribute. (as long as the pull request is properly forwarded to the right dev list which I think the mailer is setup OK for that now.) Several projects are grabbing fixes via pull requests. Dan On 23 September 2013 06:24, ryenus rye...@gmail.com wrote: Would anyone be taking care of the pull requests on github: https://github.com/apache/maven-plugins/pulls I just made 2 but saw there're pull requests open for years. Thanks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remote Resources Plugin issue
On Sep 18, 2013, at 2:04 PM, Jason van Zyl ja...@tesla.io wrote: I noticed while building on the plane today that I get this issue with the remote-resources-plugin: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default) on project apache-maven: Error rendering velocity resource. Invocation of method 'getResourceAsFile' in class org.codehaus.plexus.resource.DefaultResourceManager threw exception org.codehaus.plexus.resource.loader.ResourceNotFoundException: Could not find resource 'https://glassfish.java.net/public/CDDLv1.0.html'. at remote-resources[line 40, column 26] - [Help 1] This is not an issue with version 1.4. Anyone know what might be causing this and how to fix it before I go looking. This is a bad regression as it prevents builds from completing where you are not connected to the internet even if you have a local repository manager running. This would only be with the main Maven build. We HAVE to have the full text for all the licenses available in the binary distribution. Thus, in apache-maven/src/main/appended-resources/META-INF/LICENSE.vm you will see it uses the URL's from the dependent poms to download the various licenses. Eventually, I wanted to get it updated to store the licenses in the .m2/repository someplace, but didn't have the time to pursue that. Feel free to tackle it. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
On Sep 14, 2013, at 1:24 PM, Jason van Zyl ja...@tesla.io wrote: When a release fails like this it is annoying to have to rev back the version of the POM. I'm not sure who flipped the versions in the POM and while it's a little more visible to see what you're moving toward I prefer the pattern of: 3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 3.1.2 -- 3.1-SNAPSHOT I know this may not be obvious to the casual observer as they may think 3.1 is next, but I'm personally fine with that. Especially after a failed release because then I don't have to go change all the POMs (whether rolling back manually, using the release rollback, the version:set command, or whatever else). It's much easier to just fix what's necessary and carry on. You don't have to go back and reset the poms. Just re-run the maven-release-plugin and when it asks for the release version, type in 3.1.1 instead of defaulting to 3.1.2. Dan Unless anyone objects I would like to go back this pattern, what I previously had, because it's far easier to manage. Ideally it might be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of that I would prefer not to diddle POMs after a failed release. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
This should now be fixed on master. Feel free to cancel this vote and respin the builds. Thanks! Dan On Sep 10, 2013, at 11:33 AM, Daniel Kulp dk...@apache.org wrote: -1 The src.tar.gz and src.zip files have lost their top level NOTICE and LICENSE files. This is a regression from 3.1.0 (and 3.0.5). That definitely needs to be fixed. I don't have time today to look into that, but might tomorrow if someone doesn't beat me to it. Ran a couple builds with the result of building the source and things look OK. I checked the rest of the contents with the tag and everything looks OK. There are three files in the git repo that aren't part of the release (/.gitignore, /.gitattributes, and /apache-maven/src/bin/.gitattributes), but those files really are specific to our scm and thus don't need to be in the source release. Most likely, the doap_Maven.rdf shouldn't be part of the release either. Probalby shouldn't be in the main maven git repo. Definitely not a big deal. Dan On Sep 8, 2013, at 9:07 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 6 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968 Staging repo: https://repository.apache.org/content/repositories/maven-016/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
On Sep 10, 2013, at 10:11 AM, Jason van Zyl ja...@tesla.io wrote: On Sep 10, 2013, at 9:58 AM, sebb seb...@gmail.com wrote: Which as I have argued all along is insufficient. - the vote email does not have vital information for the record - indeed in the case of this vote, neither the vote e-mail nor the source archive (on which people are supposed to be voting) has the information. I note that no-one who has voted so far has stated that the contents of the source archives are all present and correct and that no files are missing from the release and more importantly that there are no files in the source archive that should not be there. IMO this is the most important part of the release vote, along with the NL contents. Get the PMC to agree and put it in the template and I'll use what's in the template. Which the PMC has already discussed and decided it was not needed. Sebb's opinion on this is respected, but it's still not something we, as the PMC, feel is required. The commits list is monitored If Sebb feels that strongly about it, he can take it up with the board or something, but for the purpose of this community, it's not something that is required. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
-1 The src.tar.gz and src.zip files have lost their top level NOTICE and LICENSE files. This is a regression from 3.1.0 (and 3.0.5). That definitely needs to be fixed. I don't have time today to look into that, but might tomorrow if someone doesn't beat me to it. Ran a couple builds with the result of building the source and things look OK. I checked the rest of the contents with the tag and everything looks OK. There are three files in the git repo that aren't part of the release (/.gitignore, /.gitattributes, and /apache-maven/src/bin/.gitattributes), but those files really are specific to our scm and thus don't need to be in the source release. Most likely, the doap_Maven.rdf shouldn't be part of the release either. Probalby shouldn't be in the main maven git repo. Definitely not a big deal. Dan On Sep 8, 2013, at 9:07 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 6 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968 Staging repo: https://repository.apache.org/content/repositories/maven-016/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
On Sep 10, 2013, at 12:04 PM, Jason van Zyl ja...@tesla.io wrote: What do you think happened? Is this a change in the remote resources plugin? No…. in the old releases, they were named LICENSE.txt and NOTICE.txt (txt extension) which is not how the RR plugin would have ever generated them. This is a source archive and thus the generated LICENSE/NOTICE is likely not applicable (as that would have information about the binary jars and such that aren't included in the source archive). Dan On Sep 10, 2013, at 11:33 AM, Daniel Kulp dk...@apache.org wrote: -1 The src.tar.gz and src.zip files have lost their top level NOTICE and LICENSE files. This is a regression from 3.1.0 (and 3.0.5). That definitely needs to be fixed. I don't have time today to look into that, but might tomorrow if someone doesn't beat me to it. Ran a couple builds with the result of building the source and things look OK. I checked the rest of the contents with the tag and everything looks OK. There are three files in the git repo that aren't part of the release (/.gitignore, /.gitattributes, and /apache-maven/src/bin/.gitattributes), but those files really are specific to our scm and thus don't need to be in the source release. Most likely, the doap_Maven.rdf shouldn't be part of the release either. Probalby shouldn't be in the main maven git repo. Definitely not a big deal. Dan On Sep 8, 2013, at 9:07 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 6 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968 Staging repo: https://repository.apache.org/content/repositories/maven-016/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
On Sep 10, 2013, at 12:16 PM, sebb seb...@gmail.com wrote: On 10 September 2013 16:33, Daniel Kulp dk...@apache.org wrote: -1 The src.tar.gz and src.zip files have lost their top level NOTICE and LICENSE files. This is a regression from 3.1.0 (and 3.0.5). That definitely needs to be fixed. I don't have time today to look into that, but might tomorrow if someone doesn't beat me to it. Ran a couple builds with the result of building the source and things look OK. I checked the rest of the contents with the tag and everything looks OK. There are three files in the git repo that aren't part of the release (/.gitignore, /.gitattributes, and /apache-maven/src/bin/.gitattributes), but those files really are specific to our scm and thus don't need to be in the source release. OK, so is it necessary to check the release against the tag? That's one way, sure. Personally, I log the trunk/master/branch, find the appropriate commit for prepare release maven-3.1.1, check that out, then diff that with the src tar ball as well as diff that with the tag to make sure all three match up. Likely not necessary with git where the tag would apply directly to that commit, but with subversion, it is certainly possible that the three don't match and the diffs make sure to check that.If any of the three diffs find differences, it's an immediate red-flag for further review and likely require a -1 on the vote until resolved. Or is that just your personal take on what a reviewer should do? A reviewer should do whatever they feel is necessary to do a thorough review. If it is necessary (for at least one reviewer) to do, then the SCM coordinates need to be provided in a transparent manner so any reviewer can do it, and the coordinates need to be part of the vote e-mail for the public record. No, each reviewer should do what they feel is appropriate for them. If every reviewer did the exact same thing, we'd get the exact same result from each of them. Some reviewers may checkout the tag, others may troll back master, others may do something completely different. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE
==**==** == --- maven/plugins/trunk/maven-**install-plugin/NOTICE (added) +++ maven/plugins/trunk/maven-**install-plugin/NOTICE Sat Jul 20 12:58:34 2013 @@ -0,0 +1,5 @@ +Apache Maven Install Plugin +Copyright 2007-2013 The Apache Software Foundation + +This product includes software developed at +The Apache Software Foundation (http://www.apache.org/). --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Apache 3.1.0
Jason, On Jul 13, 2013, at 12:44 PM, Jason van Zyl ja...@tesla.io wrote: I will try and automate for everyone to have a correct set of attributions. If you want to manually update the correct files that's fine too. I think this is now done on master, but requires a release of the remote-resources. Just haven't had time to do it. Dan On Jul 13, 2013, at 11:24 AM, sebb seb...@gmail.com wrote: On 13 July 2013 15:11, Jason van Zyl ja...@tesla.io wrote: Sorry about that. I did register the issue OK. and I'll make something to generate the correct attributions for the next release. There should be need to auto-generate anything for the source release; just ensure the correct NL files are present in the top-level of SCM. This is required anyway as the SCM is effectively another published source. Once established, the files will need to change rarely if ever. Similarly for the binary release, the NOTICE file may well need to be different, but won't change often. It's not a trivial matter for a program determine what goes in the NOTICE file from machine-readable data. Hopefully the next one will not take 7 months. I sent the first email out for the first 3.1.0 on December 2nd, 2012 :-) On Jul 13, 2013, at 10:00 AM, sebb seb...@gmail.com wrote: On 13 July 2013 14:54, Jason van Zyl ja...@tesla.io wrote: The vote has passed with the following: +1 Binding: Arnaud, Stephen, Olivier, Hervé +1 Non-binding: Stevo, Anders, Tony, Tamas, Baptiste, Mark, Mirko I voted -1 (non-binding) because of the invalid NOTICE file (amongst other reasons). I'll promote the release in Nexus and update the docs and announce Monday when it's all done. On Jun 30, 2013, at 3:00 PM, Jason van Zyl ja...@tesla.io wrote: Here are the release bits for 3.1.0: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-084/ Staged distribution: https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/ Staged Site: http://maven.apache.org/ref/3.1.0 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates (try 2)
+1 - I agree with Chris. Besides, if something DOES change in the svn/git tag, we get an email notification so we can immediately figure out what's going on. In addition, if you compare what you are voting on to whatever is the latest version of the the tag, if there is any difference whatsoever in the code, the reviewer should immediately figure out why.I really don't care about the exact revision number at all. Whatever is the latest tag (head/whatever) is what's important as that's what will be held there forever once the vote passes. Dan On Jul 1, 2013, at 2:18 AM, Chris Graham chrisgw...@gmail.com wrote: On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com wrote: Reminder: all this thread is just about is adding the following lines to vote e-mails: SVN Tag: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ (r1496317https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/(r1496317 ) I still find this redundant. Given that the tag will not change for the time window of the vote, and that the tag has it's own revision no, and you can derive the revision from the tag, so I see no need to quote the revision no. In the event of a failed vote, the version/tag will be reused and it will have a new revision, which also will be derivable. In the event of a successful vote, the tag will remain permanently. Should anyone ever wish to trawl through the (svn) history, then you will still be able to see the intermediate/failed votes and history. And you'd also need the archives of this list to address why the vote failed etc. or whatever the equivalent is for Git (or any other SCM that may be in use at the time). Yes, others wil have their own requirements. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
+1 for qualified releases (alpha, beta, RC, etc…) that are working toward the full blow release but aren't intended to be that. -1 for the actual releases. Dan On May 29, 2013, at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 9:40 AM, Jason van Zyl ja...@tesla.io wrote: So what do you normally use for documentation? Or what would you prefer? Of anything I've seen here the Confluence -- static website looked the most promising. As soon as you saved a page it attempted to make the update to the static website. I don't know if that's still in use but was being used by some projects at some point. Several projects still use Confluence - static website, but it's a bit more complicated now with svnpubsub in there. We have buildbot builds that run once an hour to export the confluence space to static HTML and check it into SVN where svnpubsub then takes over. CXF, Camel, ActiveMQ, Geronimo, etc… are using it. See: http://www.dankulp.com/blog/2012/03/svnpubsub-for-confluence-sites/ Dan On Mar 13, 2013, at 9:37 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: As long as one definitely and 100% stays away from the EU mirror it would seem to work. Running through the mirror is route to disaster and *lots* of wasted time. It would appear that the equivalent git-based solution for site publication is not ready yet. So for this moment someone will have to do the pom changes to make core use svnsubpub. There is little to like about svnsubpub. There was little to like about the previous solutions used for maven sites either. Nor do I like github pages. It all makes me feel a little depressed. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
a massive community and it is the defacto standard. JSR330 is standard More than one implementation, the two major implementations have completely different heritages, again, one may quibble with parts of the API, but it is able to have two big implementations stand on top of it. and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing But that is a different metric than the other two technologies. Yes it is better to use this than Sonatype Aether (which since the move to Eclipse is effectively a dead stack... but that was the point of *moving* it to Eclipse) but that does not prove (in the original sense of test) that the API is absent of biases. SLF4J is tackling a smallish problem, so biases are easy to spot. JSR330 is tacking a problem, to my view, comparable in size to Aether, yet it had two major heavyweight implementations collaborate/fight to build a common API. As such a lot of the biases will have been shaken out... there will still be biases, but there is enough scope between the two major implementations for a 3rd implementation to arise, innovate and steal the crown. How likely is it that a competing implementation could arise and do that with Aether's API? so it's best just to build on these technologies of any new versions of Maven and get on with it. SLF4J, you have my +1 JSR330, you have my +1 Eclipse Aether... * I am +1 on integrating that into Maven, * I am _undecided_ on officially exposing it as an API for plugin developers. I look forward to the debate of those who have the spare time and are prepared to walk the walk and commit code on my points above to sway my opinion. -Stephen Thanks, Jason [1]: http://ci.tesla.io:8080/job/tesla-its/ws/ -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h
Re: Releasing 3.1.0
With a bit of a notice (don't care if it's one week or 4 days or….), I certainly support this path. We need to talking about it and get 3.1 out. Dan On Feb 26, 2013, at 9:05 AM, Jason van Zyl ja...@tesla.io wrote: As I posted previously I would like to do the 3.1.0 release but I don't want to do the work of isolating SLF4J until it's shown that it will be a problem. I don't the believe the adoption of 3.1.0 is going to be so quick that we can't create a fix if necessary. I would rather do the release in a lean style and not do work for theoretical problems. In full disclosure I have a release of Tesla I want to make and I already have JSR330, SLF4J/Logback, and Eclipse Aether integrated so I would like to try and help get the JSR330, SLF4J out the door and then get Eclipse Aether integrated. If anyone feels strongly about trying to create the SLF4J isolation and is going to start the work to do it shortly there's no harm in waiting. But I would prefer to start getting the 3.1.0 release out the door, get some feedback and adjust if necessary. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.5
+1 Dan On Feb 19, 2013, at 10:28 AM, Olivier Lamy ol...@apache.org wrote: Hi, We fixed 1 issue: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088 Staging repository: https://repository.apache.org/content/repositories/maven-270/ Staging distribution: https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/ Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Pmd Plugin 3.0 (take 2)
+1 The artifacts look fine. Didn't really get a chance to test it due to the incompatibilities. Will likely take some effort for the projects using it to update, but that's the whole point of the 3.0 version number. :-) Dan On Feb 7, 2013, at 5:00 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Maven Pmd Plugin 3.0. Note this version is based on PMD 5.0.2 (reason for the version bump). We fixed 18 issues: https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MPMD+AND+fixVersion+%3D+%223.0%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide NOTE: this version use PMD 5.0.2 which is not backwards compatible with PMD 4.x (see more details here http://pmd.sourceforge.net/pmd-5.0.2/) Staging repository: https://repository.apache.org/content/repositories/maven-216/ Source release: https://repository.apache.org/content/repositories/maven-216/org/apache/maven/plugins/maven-pmd-plugin/3.0/maven-pmd-plugin-3.0-source-release.zip Staging site: http://maven.apache.org/plugins-archives/maven-pmd-plugin-3.0/ Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Wagon 2.4
+1 Dan On Feb 5, 2013, at 9:14 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Wagon 2.4. We fixed 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=18697 Staging repository: https://repository.apache.org/content/repositories/maven-199/ Source release: https://repository.apache.org/content/repositories/maven-199/org/apache/maven/wagon/wagon/2.4/wagon-2.4-source-release.zip Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
I ran the CXF build like: mvn -Pfastinstall -T8 -o using the latest on the two branches as of 11pm last night: 3.0.4: 1:16 log4j2: 1:12 logback: 1:19 Ran each 3 times and results were fairly consistent.Thus, for me using parallel builds, log4j2 is the fastest, but the difference is almost irrelevant. I'll repeat the tests later without the -T8, but this may show that multi-threaded logging is faster with log4j2. Dan On Dec 12, 2012, at 1:48 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Finally some interesting numbers, and if (heaven forbid) this decision should be based on technical grounds, this is one of the first significant pieces to come up in this discussion. Since I am quite unfamiliar with logging (I use loose coupling and tests instead ;), I took the opportunity to read http://logging.apache.org/log4j/2.x/performance.html Somehow the real-life results don't seem to match up with the advertising blurp on the log4j site. While it hardly surprises me, I was wondering if anyone actually knows why? Kristian 2012/12/12 Stephen Connolly stephen.alan.conno...@gmail.com: The consistent times (i.e. repeated runs after discarding the first) are: 3.0.4: 1min18sec logback: 1min13sec log4j2: 1min34sec The second test was building GIT hash 85dd6e37456d30d2661e10b044efa9036c528023 of jszip-maven-plugin (@jszip.org) with the following command line: mvn -o -X clean verify -DskipTests -Dinvoker.skip [Testing heavy logging] 3.0.4: 12.1sec logback: 12.2sec log4j2: 12.5sec - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
provided that the implementation is available under one of the ASL compatible licenses (i.e. Category A or Category B). If a Category B licensed implementation is chosen then for legal reasons the PMC must approve the use of that dependency. (Personally speaking, if that decision is purely based on technical grounds, I do not see why the PMC would object) Maven Committers can use other criteria in making th -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
My thoughts: 99.5% (or more) of the maven users will not care one way or another what logging impl we use. They won't configure anything beyond -X. They won't try changing loggers. They won't muck with the configs. Etc.. They just run mvn and expect it to work. For the remaining 0.5%, no matter what we do, we will need to document things clearly about how to configure things. For these folks, they are generally experts and thus a couple extra steps to replace a logging framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT this all clearly or provide a nice maven plugin or something to do it for them) My preference, in order: slf4j-jdk14 slf4j-simple log4j2 slf4j-log4j and then a big gap to logback. The first two are there as they would provide the least amount of extra dependencies, complexity, etc… That said, we know slf4j-simple has issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI case, I don't see any advantage of logback over log4j2 or slf4j-log4j.If the entire argument is around wanting something battle tested, go for slf4j-log4j. It's certainly used by more projects than logback and more people would already know it's configuration options. Personally, I find the number of projects argument annoying and mostly irrelevant. (and at least 2 of the Apache 8 projects that are on the logback homepage don't use logback, they now use slf4j-log4j) Thus, it comes down to two major things for me: 1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote -1 for logback if/when presented to the PMC for approval. There are very good options that would work just as well for our needs that are not EPL. 2) Community - Ceki is great, no doubt about it, but at the end of the day, logback is pretty much a one man show. Apache is more about community and community over code and all that. I strongly prefer something that has a community behind it, or, at the very least, is open to developing a community behind it. Major bonus points if that community already contains Maven PMC members/committers on it.If *we* run into issues, I strongly prefer that *we* can get those issues fixed. If two options are functionally and technically equivalent (within reasonable limits), then I'll take the community driven, permissive licensed version. That's my $0.02 worth. Dan On Dec 10, 2012, at 9:32 PM, Jason van Zyl ja...@tesla.io wrote: Hi, I looked around a bit more today and I don't think SLF4J Simple is viable long term, I don't want to patch it anymore as I would have to do a day's work to make changes that keep the performance levels up, get it reviewed and released, and I honestly don't think it's worth it anymore. I would rather spend my time building out the plugin test cases and help to finish the classloader blocking of SLF4J. I don't mind spending time getting it all working but I don't want to waste my time on an implementation we're going to toss. After a conversation with the PMC it will require a vote to accept Logback which is EPL but I wanted to ask committers and interested users about using Logback. I believe Logback is the best choice as it's the most mature and battle tested implementation because once it goes in it's likely not ever to come out. Many of us are users and have integration experience with Logback and it's what I use everyday for logging in all my other projects and I've been a happy user for years. I see Logback as best of breed and widely adopted including 8 projects at Apache. There's no point in asking the PMC to vote on the acceptance of Logback if it's not acceptable by the community. If there are interested users I would really like to hear what you think because you're the ones who will have to live with the choice that is made. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
On Dec 11, 2012, at 5:07 PM, Benson Margulies bimargul...@gmail.com wrote: I want to gently argue with a part of Dan Kulp's position. The PMC established the class B dependency rule in response to a particular conflict within this community. From my point of view, whether or not that conflict is entirely in our past, logback is not an example of the problem that the rule was intended to address. It is not a case of forking Maven code out and then licensing the derived work as EPL. If we ever got that far, I would argue pretty strenuously against a PMC-level rejection of something just based on being EPL. A class-B license is a perfectly legitimate dependency. Dan's points about preferring to use something with a community behind it do not disturb me. However, seriously, does anyone believe that any of these candidates are going to manifest some horrible problem that we need to get fixed? Umm.. how about adding things, like color? To me, the sophistication depends on our vision for the widespread use of the slf4j API in plugins. I hate the current -X behavior, with its horrible undifferentiated spew, with the power of 1000 suns. If picking logback offers a clean engineering pathway to helping users see only messages that will help them (which, of course, depends on plugins enabling the slf4j API and using it), then I'm all for logback. If there's all much of a muchness in this regard, then we might as well use the JDK. I completely agree with this. The -X behavior sucks and if logback can provide something better, that's great. However, if log4j can ALSO provide something that is equivalent to what logback could provide, then I would go with log4j. Basically, if given 2 essentially equivalent choices, I'd go with the community supported, permissively licensed option.That does require, however, 2 essentially equivalent choices. From what I see for our specific CLI use case, the two options are very close. Dan On Tue, Dec 11, 2012 at 4:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 11 December 2012 21:49, Olivier Lamy ol...@apache.org wrote: 2012/12/11 Stephen Connolly stephen.alan.conno...@gmail.com: On Tuesday, 11 December 2012, Daniel Kulp wrote: My thoughts: 99.5% (or more) of the maven users will not care one way or another what logging impl we use. They won't configure anything beyond -X. They won't try changing loggers. They won't muck with the configs. Etc.. They just run mvn and expect it to work. For the remaining 0.5%, no matter what we do, we will need to document things clearly about how to configure things. For these folks, they are generally experts and thus a couple extra steps to replace a logging framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT this all clearly or provide a nice maven plugin or something to do it for them) My preference, in order: slf4j-jdk14 slf4j-simple log4j2 slf4j-log4j and then a big gap to logback. The first two are there as they would provide the least amount of extra dependencies, complexity, etc… That said, we know slf4j-simple has issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI case, I don't see any advantage of logback over log4j2 or slf4j-log4j. If the entire argument is around wanting something battle tested, go for slf4j-log4j. It's certainly used by more projects than logback and more people would already know it's configuration options. Personally, I find the number of projects argument annoying and mostly irrelevant. (and at least 2 of the Apache 8 projects that are on the logback homepage don't use logback, they now use slf4j-log4j) Thus, it comes down to two major things for me: 1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote -1 for logback if/when presented to the PMC for approval. There are very good options that would work just as well for our needs that are not EPL. My points are: 1. that we should make sure the selected implementation passes the technical gate *first* Any technical definition of this gate ? All integration tests pass and no significant performance regression (I would say 5% is significant but I agree we do not have a strict measure of that). My first mail on this thread is awaiting confirmation from you that log4j2 meets the above. 2. That committers should not worry about the outcome of a PMC vote when making their recommendation on implementation. If the PMC chooses to say no to a specific dependency on the basis of its license *then* the community will presumably have a second option that passes the technical gate and can fall back to that... But the very first question that committers should consider is the technical basis. I don't care what criteria people use as long as technical is #1. 2) Community - Ceki is great, no doubt about
Re: [VOTE] Maven 3.1.0
to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. /Anders Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If y - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com wrote: I would go for 2.2. Releasing something and then include it as the default version the same day seems a bit too much for me. I would agree with this. The fact that I was the first one to even notice that 2.3 has issues on the Mac suggests it's not very widely tested. :-( Much like the compiler plugin, I'd let this bake a little more before making it the default. Dan On Thursday, November 29, 2012, Jason van Zyl wrote: I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin 2.4? On Nov 28, 2012, at 12:54 PM, Daniel Kulp dk...@apache.org wrote: On Nov 28, 2012, at 12:33 PM, Jason van Zyl ja...@tesla.io wrote: But what version of the plugin are users going to get? If it's not locked down, they would get 2.3. (maven 3.0.x users get 2.1.3 I think) However, I want to be clear: * The issue ONLY affects Mac users. Other platforms are OK. * The issue only affects users that use the war plugin. * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4 is released). * Another work around: adding the -Djava.awt.headless=true flag to the MAVEN_OPTS. * The issue does NOT affect the output of the war plugin. The plugin does exactly what it's supposed to do and produces a proper war. The only problem is the Java Icon that would appear on the Mac Dock for the duration of the build. It doesn't affect the actual build at all. So basically, it affects a relatively small number of maven users, doesn't affect the actual build at all, and has a relatively easy workaround for people that are annoyed by it. Dan On Nov 28, 2012, at 11:54 AM, Daniel Kulp dk...@apache.org wrote: On Nov 28, 2012, at 11:46 AM, Arnaud Héritier aherit...@gmail.com wrote: there is an issue opened about it ? I didn't find it. No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out what was going on. Once we figured it out, he committed a fix before I could even login to JIRA. :-) r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709 Dan On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp dk...@apache.org wrote: +1 I've tested this with a few projects and it seems to work. I DON'T like that it updates the war plugin to 2.3 as that version has issues on the Mac related to setting up an awt Toolkit. However, there is a simple workaround of locking the war version down to 2.2 in the project pom (which is something the project in question should have done anyway). Dan On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/the course of true love never did run smooth ... -- Shakespeare -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
+1 I've tested this with a few projects and it seems to work. I DON'T like that it updates the war plugin to 2.3 as that version has issues on the Mac related to setting up an awt Toolkit. However, there is a simple workaround of locking the war version down to 2.2 in the project pom (which is something the project in question should have done anyway). Dan On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On Nov 28, 2012, at 11:46 AM, Arnaud Héritier aherit...@gmail.com wrote: there is an issue opened about it ? I didn't find it. No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out what was going on. Once we figured it out, he committed a fix before I could even login to JIRA. :-) r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709 Dan On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp dk...@apache.org wrote: +1 I've tested this with a few projects and it seems to work. I DON'T like that it updates the war plugin to 2.3 as that version has issues on the Mac related to setting up an awt Toolkit. However, there is a simple workaround of locking the war version down to 2.2 in the project pom (which is something the project in question should have done anyway). Dan On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On Nov 28, 2012, at 12:33 PM, Jason van Zyl ja...@tesla.io wrote: But what version of the plugin are users going to get? If it's not locked down, they would get 2.3. (maven 3.0.x users get 2.1.3 I think) However, I want to be clear: * The issue ONLY affects Mac users. Other platforms are OK. * The issue only affects users that use the war plugin. * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4 is released). * Another work around: adding the -Djava.awt.headless=true flag to the MAVEN_OPTS. * The issue does NOT affect the output of the war plugin. The plugin does exactly what it's supposed to do and produces a proper war. The only problem is the Java Icon that would appear on the Mac Dock for the duration of the build. It doesn't affect the actual build at all. So basically, it affects a relatively small number of maven users, doesn't affect the actual build at all, and has a relatively easy workaround for people that are annoyed by it. Dan On Nov 28, 2012, at 11:54 AM, Daniel Kulp dk...@apache.org wrote: On Nov 28, 2012, at 11:46 AM, Arnaud Héritier aherit...@gmail.com wrote: there is an issue opened about it ? I didn't find it. No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out what was going on. Once we figured it out, he committed a fix before I could even login to JIRA. :-) r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709 Dan On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp dk...@apache.org wrote: +1 I've tested this with a few projects and it seems to work. I DON'T like that it updates the war plugin to 2.3 as that version has issues on the Mac related to setting up an awt Toolkit. However, there is a simple workaround of locking the war version down to 2.2 in the project pom (which is something the project in question should have done anyway). Dan On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven PMD Plugin 2.8
I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF)Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamy ol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven PMD Plugin 2.8
OK. Just read the release notes for PMD 5.0: http://sourceforge.net/projects/pmd/files/pmd/5.0.0/ PMD 5 is definitely NOT compatible with much of the configuration and custom rulesets and such that are out there. Thus, this really is a gigantic update. I would recommend canceling this and re-spin with a 3.0 version number as this is definitely not anywhere close to compatible to the 2.7 version of the plugin. Dan On Nov 26, 2012, at 9:50 AM, Daniel Kulp dk...@apache.org wrote: I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF)Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamy ol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
I'm +0.5 on everything that currently has the trunk/tags/branches setup in SVN. -1 on things that are not setup that way right now until more discussions and agreement can be made on how that should be approached. Really, I think we should just do Maven core and maybe one or two other simple ones for now and see how that goes. If that goes well over then next 3 months or so, expand a little more. Dan On Sep 5, 2012, at 7:04 AM, Olivier Lamy ol...@apache.org wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 2.0 -- attempt 2
+1 Dan On Sep 2, 2012, at 7:03 PM, Benson Margulies bimargul...@gmail.com wrote: We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-028/ https://repository.apache.org/content/repositories/maven-028/org/apache/maven/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 1.7.1
+1 Dan On Wednesday, June 27, 2012 07:53:44 AM Benson Margulies wrote: Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-p lugin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Compiler Plugin 2.5
+1 Dan On Thursday, May 24, 2012 01:38:10 PM Benson Margulies wrote: K. +1 On Thu, May 24, 2012 at 1:28 PM, Olivier Lamy ol...@apache.org wrote: Because I added new configuration parameter and upgrade with a new plexus-compiler version 2012/5/24 Benson Margulies bimargul...@gmail.com: Why not a 2.4.x release given the single issue? On Thu, May 24, 2012 at 1:19 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Maven Compiler Plugin 2.5. We fixed 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130versi on=18466 Staging repository: https://repository.apache.org/content/repositories/maven-135/ Staged Site: http://maven.apache.org/plugins/maven-compiler-plugin-2.5 (not yet synced). Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Shade Plugin 1.6
+1 Dan On Thursday, March 15, 2012 10:56:34 AM Olivier Lamy wrote: Hello, I'd like to release Apache Maven Shade Plugin 1.6. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18042styleName= TextprojectId=11540Create=Create Staging repo: https://repository.apache.org/content/repositories/maven-078/ Staged site: http://maven.apache.org/plugins/maven-shade-plugin-1.6 [-1] [0] [+1] Thanks, -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Subject: [VOTE] Release Maven Checkstyle Plugin version 2.9.1
+1 Dan On Wednesday, February 22, 2012 2:50:55 PM Dennis Lundberg wrote: Hi, We solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=H tmlversion=18335 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-007/ Staging site: http://maven.apache.org/plugins/maven-checkstyle-plugin-2.9.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCELLED][VOTE] Release Maven Archiver 2.5, Maven Jar Plugin 2.4, Maven War Plugin 2.2 and Maven Assembly Plugin 2.3
On Thursday, January 26, 2012 11:30:55 AM Kristian Rosenvold wrote: It's being suggested to me that this might have been caused by a 5 month old jar-plugin-2.4 tag in svn that someone (a nice rephrasing of I) has forgotten to delete. Is there some gotcha I should've been aware of here ? http://jira.codehaus.org/browse/MRELEASE-719 Several of us have been bitten by it. :-( Dan Kristian 2012/1/26 Kristian Rosenvold kristian.rosenv...@gmail.com: There is an error in the jar plugin pom that needs to be fixed, possibly including a new IT. I will re-roll once ready. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 Been using it all day for a variety of things and haven't run into any issues. Dan On Thursday, December 01, 2011 10:20:55 AM Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=172 15 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Use aether 1.13 and sisu 2.3.0 as dependencies of Apache Maven
+1 binding Dan On Wednesday, November 16, 2011 1:59:18 PM Olivier Lamy wrote: Hello, Note as stated here [1], this vote in order to pass need A majority of the PMC. AFAIK, this PMC is 22 people [2] and currently there is only 8 * +1. Thanks! Hello, Since last vote things have changed: * aether is in incubation process @eclipse * sisu is in incubation process @eclipse Due to the fact that those process can be long before having an official release from eclipse namespace, some new features are blocked. I propose to upgrade to: * aether 1.13 * sisu 2.3.0 Note: when a release will be available @eclipse, we will upgrade to this release. The technical details can be discussed later especially if we need to do some package changes. [+1] I'm in favor of this upgrade and the other upgrade when release will be available under eclipse.org governance [+0] I don't care, do what you want. [-1] I'm against because (please explain) The vote open is open for 6 days as we are near week end (with maybe bank holidays in some countries) and some people have too much beer in ApacheCon :-). Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Usage of Aether and Sisu as dependencies of maven core with EPL licenses - take 2
On Thursday, August 18, 2011 9:17:49 AM Benson Margulies wrote: Mark, Can it possibly matter what the java package names are? There are ton's of wierd historical package names floating around the universe. There is no requirement for incubating Apache projects to move package names just for the sake of moving them. I think that 'sonatype' in a package name is a herring of perfect redness. Well, I guess the real question is will they change the package names or not? If yes, then it MAY be better to wait a few weeks to get the version with the new package names. For example, when Jetty moved to eclipse, all the package names changed from org.mortbay.jetty to org.eclipse.jetty and you and I spent quite a bit of time updating CXF to use the new package names (amongst the other changes). If we're going to move forward with Aether/Sisu, I'd prefer to start off with the more stable names and such so an update to Aether/Sisu is really just a drop in update at that time. Dan On Thu, Aug 18, 2011 at 8:59 AM, Mark Struberg strub...@yahoo.de wrote: Jason, Brian, Benjamin or any other person involved, Before voting on this issue, I'd like to get an idea what it means for us. So please allow me a few questions: a.) how can appache maven committers anticipate on aether over at Eclipse? What if someone (like me) likes to contribute, but wants to make sure that his contributions are also possible to release separately under ALv2? b.) is it possible to operate aether without sisu? Pure JSR-330 and/or plexus DI stuff is fine. Is there any direct guice depending code in aether? c.) will the package names remain com.sonatype or will they get changed to org.eclipse.*? This is important for us to know. If so, we can just cancel the vote and wait for this stuff to be released at Eclipse. d.) How long will it take to get the first aether release done at Eclipse? If there is a chilly way for maven committers to get involved with that stuff over at Eclipse, then this would be a big pro. txs and LieGrue, strub --- On Thu, 8/18/11, Anders Hammar and...@hammar.net wrote: From: Anders Hammar and...@hammar.net Subject: Re: [VOTE] Usage of Aether and Sisu as dependencies of maven core with EPL licenses - take 2 To: Maven Developers List dev@maven.apache.org Date: Thursday, August 18, 2011, 10:56 AM +1 (non-binding) /Anders 2011/8/18 Arnaud Héritier aherit...@gmail.com: Hi all, Thus as decided with Mark and Kristian I relaunch a new vote with a better scope about what we are voting for. Next releases of SISU and Aether will be released at Eclipse.org under EPL 1.0 license. Before they were published under ASL or dual ASL/EPL licenses thus as defined in our policy [1] this change put them in Category B [2] and we need to validate this change by a vote with a majority of the PMC in favor (but the vote is open to everybody). I push only one vote for both dependencies as for now I see no reason to accept one and not the other. This vote will be open for 6 days as we are in august (If we have not enough votes at the end of next wednesday will see if we really need to extend it). The vote : [+1] I'm in favor to use as Maven core dependencies SISU and AETHER libraries published under EPL 1.0 License and released under eclipse.org governance [+0] No opinion, do what you want. [-1] I'm against because (please elaborate) Arnaud [1] http://maven.apache.org/developers/dependency-policies.html [2] http://www.apache.org/legal/resolved.html#category-b - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Checkstyle Plugin version 2.7
+1 Dan On Thursday, August 11, 2011 9:29:32 AM Olivier Lamy wrote: ping. Thanks ! 2011/8/10 Olivier Lamy ol...@apache.org: Here my +1. Thanks ! 2011/8/8 Olivier Lamy ol...@apache.org: Hi, We solved 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=16773styleN ame=TextprojectId=11127Create=Create Staging repo: https://repository.apache.org/content/repositories/maven-005/ Staging site: http://maven.apache.org/plugins/maven-checkstyle-plugin-2.7/ (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM reader that preserves CDATA?
You could TRY feeding the pom schema into JAXB to generate JAXB objects from it. From there, using a JAXBContext, you can call context.createBinder and then use that to unmarshall the XML DOM into JAXB objects. You can then manipulate the JAXB objects and then have it update the XML after word using the Binder. Supposedly, the binder allows semi-preserving of the infoset while using the JAXB objects. That said, I've never tried it, particularly with CDATA. :-) Dan On Tuesday, August 02, 2011 6:00:25 PM John Casey wrote: Hi all, I'm working on some tooling for $dayjob that needs to manipulate POM files according to certain rules. The problem I'm running into is that some of the POMs it much manipulate contain CDATA sections, comments, etc. Also, since the modified POM often will be used as the basis for a patch file, I'd like to preserve as much of the ordering and existing whitespace in the file as possible, to minimize the patchfile size. I'm currently using the JDom-driven, Modello-generated writer, coupled with the stock XPP3-driven reader (not the best, I know). It's losing the CDATA (big problem) and injecting ^M (wrong line ending, little problem)... Does anyone have experience with this? Anyone maybe have an advanced POM reader/writer stashed somewhere that can preserve CDATA and the like? Thanks, -john -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. 4) They are using such builds at their own risk. 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12
Re: Apache Maven distribution with fixes
On Thursday, July 28, 2011 9:32:07 AM John Casey wrote: Correct me if I'm wrong, but it's not okay to even call the binary maven-XXX or apache-maven-XXX (unless it's a snapshot) at all without getting a PMC vote. I thought there were rules in our ASF release protocols about that. That's actually a good point. In this case, the build contains stuff that is NOT part of any Apache Maven build, changes that are not in SVN, etc Thus, it's not Maven and cannot use those marks as part of the name.It can be Jason's build thingy based on Apache Maven, but not just Maven or Apache Maven. Also, as it is NOT a snapshot of code available in trunk/svn or part of the project, I also believe it's not something that can be distributed or promoted from Apache hardware or the Apache lists. Basically, it's not Maven and thus it cannot be treated as such. Dan On 7/28/11 9:18 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. 4) They are using such builds at their own risk. 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5]exclusion ondependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-1 for same reasons, but I'd be happy to switch to a +1 if the license was changed back to dual Eclipse/Apache AND it gets to Eclipse. Dan On Wednesday, July 27, 2011 3:04:42 PM John Casey wrote: -1 Definitely not until it's all the way moved to Eclipse...and even then, I'm personally reluctant. I'd much prefer to see Aether's functionality moved back into Maven, and streamlined to the point where it's easier to maintain. On 7/27/11 2:45 PM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-shade-plugin] Factor Out ResourceMerger ...?
On Sunday, July 03, 2011 7:19:36 PM Benson Margulies wrote: So, I'm a mostly a monkey here, but it seems very sensible to me. Perhaps Dan Kulp would chime in? It sounds reasonable to me. I know I copied one of the transforms into CXF at one point to make some small modifications. If it could have been accomplished as a subclass of some sort, that may have been avoidable. Dan On Sun, Jul 3, 2011 at 2:11 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: A number of feature requests [1][2] could be implemented in an elegant way by introducing an interface (ResourceMerger, say) similar to ResourceTransformer. I'm happy to dive in and provide integration and unit tests for this change, plus implementations for the requested features if the consensus is that it'd be a good change. Opinions? Improvements? Objections? Robert [1] http://jira.codehaus.org/browse/MSHADE-96 [2] http://jira.codehaus.org/browse/MSHADE-91 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-shade-plugin] TLC [WAS Re: [maven-assembly-plugin] smart(er) dependency merge]
On Thursday, June 30, 2011 12:21:34 PM Robert Burrell Donkin wrote: On Thu, Jun 30, 2011 at 11:41 AM, Benson Margulies bimargul...@gmail.com wrote: The JIRA count is not a reliable indication of anything. Lots of us use shade in production. The JIRA count can indicate a plethora of improvement suggestions, or a bunch of uninvestigated complaints. Don't get me wrong, please do dig in. But you are likely to find that it works for you as is. I'm looking for smart merger of NOTICEs and LICENSEs. How is this currently implemented? For the NOTICE stuff, you can look at the org.apache.maven.plugins.shade.resource.ApacheNoticeResourceTransformer which several projects use to merge the Apache NOTICE things.That could likely also be a starting point for mergers of LICENSE files. Dan Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
On Sunday, June 19, 2011 7:13:11 PM Dennis Lundberg wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. For CXF, we have a special NeedMoreInfo version that we use for this. We set the FixFor version to that when we've added a comment that requires more information from the user. We can easily get a list of all the issues that require more information, when we asked for it, etc. Probably an abuse of the version field though. :-) Dan K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. -- --- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown -- --- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven commit karma for me
Benson, Can you try again? Since Jim is quite busy with the OO stuff, I figured I'd help him out and added you to the group in LDAP. Dan On Saturday, June 04, 2011 9:11:16 AM Benson Margulies wrote: Been there, done that. I fear that Jim's temporary belief that I had been elected to the PMC led him to neglect to actually edit me into access. /Users/benson/asf/maven-deploy-plugin svn info Path: . URL: https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1131387 Node Kind: directory Schedule: normal Last Changed Author: stephenc Last Changed Rev: 1126408 Last Changed Date: 2011-05-23 05:42:16 -0400 (Mon, 23 May 2011) /Users/benson/asf/maven-deploy-plugin On Sat, Jun 4, 2011 at 9:07 AM, Wendy Smoak wsm...@gmail.com wrote: On Sat, Jun 4, 2011 at 9:04 AM, Benson Margulies bimargul...@gmail.com wrote: I don't seem to have commit karma: Double check that you have it checked out from the https:// url? (What does svn info say?) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java
(); +/** + * Perform a shading operation. + * @param jars which jars + * @param uberJar output jar + * @param filters the filters + * @param relocators the relocators + * @param resourceTransformers the transformers + * @throws IOException for IO errors reading the thing + * @throws MojoExecutionException for anything else that goes wrong. + */ void shade( Set jars, File uberJar, List filters, List relocators, List resourceTransformers ) -throws IOException; +throws IOException, MojoExecutionException; } - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java
On Friday, May 27, 2011 9:32:20 AM Benson Margulies wrote:
That's interesting. *how* did it break that build?
Honestly, I didn't really dig into it. I just noticed in the pom that you
updated the asm version to 3.3.1, but you didn't update the asm-common version
to match it.On a whim, I just updated it as well and the it test passed.
Apparently they need to be kept in sync.
In anycase, for your information, (and mine as I keep forgetting this) it's
good to run mvn install -Drun-its to run the integration tests as well.
Dan
On Fri, May 27, 2011 at 8:49 AM, Daniel Kulp dk...@apache.org wrote:
On Friday, May 27, 2011 4:37:45 AM Lukas Theussl wrote:
Daniel,
This commit breaks jenkins:
https://builds.apache.org//view/M-R/view/Maven/job/maven-plugins-ITs-2.x
/
and I also see it locally, can you review?
I committed a fix and re-triggered a Jenkins build and it looks OK now.
Thanks for the heads up! I always forget about the ITs.
I'll blame Benson, it was his patch... ;-)
Dan
Thanks,
-Lukas
dk...@apache.org wrote:
Author: dkulp
Date: Thu May 26 14:30:55 2011
New Revision: 1127943
URL: http://svn.apache.org/viewvc?rev=1127943view=rev
Log:
[MSHADE-99] Update to latest ASM to fix error message
Add javadoc
Patch from Benson Margulies applied
Modified:
maven/plugins/trunk/maven-shade-plugin/pom.xml
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mave
n/plugins/shade/DefaultShader.java
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mav
en/plugins/shade/Shader.java
Modified: maven/plugins/trunk/maven-shade-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/po
m. xml?rev=1127943r1=1127942r2=1127943view=diff
==
== == --- maven/plugins/trunk/maven-shade-plugin/pom.xml
(original) +++ maven/plugins/trunk/maven-shade-plugin/pom.xml Thu May
26 14:30:55 2011 @@ -97,7 +97,7 @@ under the License.
dependency
groupIdasm/groupId
artifactIdasm/artifactId
-version3.2/version
+version3.3.1/version
/dependency
dependency
groupIdasm/groupId
Modified:
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/DefaultShader.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/sr
c/
main/java/org/apache/maven/plugins/shade/DefaultShader.java?rev=11279
43r 1=1127942r2=1127943view=diff
==
== == ---
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/DefaultShader.java (original) +++
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/DefaultShader.java Thu May 26 14:30:55 2011 @@ -36,6
+36,7 @@ import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.zip.ZipException;
+import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.shade.relocation.Relocator;
import
org.apache.maven.plugins.shade.resource.ManifestResourceTransformer;
import org.apache.maven.plugins.shade.resource.ResourceTransformer;
@@ -57,7 +58,7 @@ public class DefaultShader
{
public void shade( Set jars, File uberJar, List filters, List
relocators, List resourceTransformers )
-throws IOException
+throws IOException, MojoExecutionException
{
Set resources = new HashSet();
@@ -241,7 +242,7 @@ public class DefaultShader
private void addRemappedClass( RelocatorRemapper remapper,
JarOutputStream jos, File jar, String name,
InputStream is )
-throws IOException
+throws IOException, MojoExecutionException
{
if ( !remapper.hasRelocators() )
{
@@ -264,7 +265,12 @@ public class DefaultShader
ClassVisitor cv = new TempRemappingClassAdapter( cw,
remapper );
-cr.accept( cv, ClassReader.EXPAND_FRAMES );
+try {
+ cr.accept( cv, ClassReader.EXPAND_FRAMES );
+} catch ( Throwable ise ) {
+ throw new MojoExecutionException (Error in ASM processing
class + + name, ise );
+}
byte[] renamedClass = cw.toByteArray();
Modified:
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/Shader.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/sr
c/
main/java/org/apache/maven/plugins/shade/Shader.java?rev=1127943r1=1
1279
Re: drop wagon-users list?
If no one objects to collapsing all the commits lists into comm...@maven.apache.org by tomorrow morning my time (Eastern US), I'll declare lazy consensus and go ahead and do it. Thus, speak up now if you object. :-) I don't have access to do anything about the dev/users lists. Dan On Tuesday, May 24, 2011 3:34:24 PM Daniel Kulp wrote: On Tuesday, May 24, 2011 3:24:34 PM Mark Struberg wrote: Done. https://issues.apache.org/jira/browse/INFRA-3653 Are there any other subprojects which we like to fold? (Lukas mentioned Doxia, right?) We currently have: [/maven] for_paths = maven/ to_addr = comm...@maven.apache.org suppress_if_match = yes bcc_addr = g...@git.apache.org [/maven/scm] for_paths = maven/scm/ to_addr = scm-comm...@maven.apache.org bcc_addr = g...@git.apache.org [/maven/wagon] for_paths = maven/wagon/ to_addr = wagon-comm...@maven.apache.org bcc_addr = g...@git.apache.org [/maven/doxia] for_paths = maven/doxia/ to_addr = doxia-comm...@maven.apache.org bcc_addr = g...@git.apache.org [/maven/surefire] for_paths = maven/surefire/ to_addr = surefire-comm...@maven.apache.org bcc_addr = g...@git.apache.org Do we want to just collapse it all down to just: [/maven] for_paths = maven/ to_addr = comm...@maven.apache.org suppress_if_match = yes bcc_addr = g...@git.apache.org so everything in the maven space goes to commits@maven? Dan LieGrue, strub --- On Tue, 5/24/11, Arnaud Héritier aherit...@gmail.com wrote: From: Arnaud Héritier aherit...@gmail.com Subject: Re: drop wagon-users list? To: Maven Developers List dev@maven.apache.org Cc: Maven Developers List dev@maven.apache.org Date: Tuesday, May 24, 2011, 7:12 PM We need to ask to infra. Just create a task in INFRA Jira project. Le 24 mai 2011 à 21:09, Mark Struberg strub...@yahoo.de a écrit : who/how is going to do this? Is this a post-commit hook in SVN we need to change? LieGrue, strub --- On Tue, 5/24/11, Arnaud Héritier aherit...@gmail.com wrote: From: Arnaud Héritier aherit...@gmail.com Subject: Re: drop wagon-users list? To: Maven Developers List dev@maven.apache.org Cc: Maven Developers List dev@maven.apache.org Date: Tuesday, May 24, 2011, 7:06 PM +1 to merge everything into maven mls Arnaud Le 24 mai 2011 à 20:53, Mark Struberg strub...@yahoo.de a écrit : already changed the wagon pom deprecating the old lists (textual) and adding the official maven-dev and maven-users lists. Btw, what about the commit messages? Should we keep them at wagon-commits? http://markmail.org/search/?q=list%3Aorg.apache.maven.wagon-commits or better move them to maven-commits? The traffic is _really_ low and I expect that to just grow a bit the next weeks and then drop to almost zero again. LieGrue, strub --- On Tue, 5/24/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: drop wagon-users list? To: Maven Developers List dev@maven.apache.org Date: Tuesday, May 24, 2011, 6:20 PM On 2011-05-24 13:36, Mark Struberg wrote: Hi! I was curious if someone still uses the wagon-usrs list. It is currently configured in wagons parent pom but I'd suggest to move this to maven-users and maybe even consolidate the wagon-dev list which is barely used too... The traffic is almost zero.. I'd suggest to change the lists in JIRA and in the pom to maven-users and maven-dev. any objections? +1 Let's do it LieGrue, strub [1] http://markmail.org/search/?q=list%3Awagon-users [2] http://markmail.org/search/?q=list%3Awagon-dev - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
Re: drop wagon-users list?
On Tuesday, May 24, 2011 3:24:34 PM Mark Struberg wrote: Done. https://issues.apache.org/jira/browse/INFRA-3653 Are there any other subprojects which we like to fold? (Lukas mentioned Doxia, right?) We currently have: [/maven] for_paths = maven/ to_addr = comm...@maven.apache.org suppress_if_match = yes bcc_addr = g...@git.apache.org [/maven/scm] for_paths = maven/scm/ to_addr = scm-comm...@maven.apache.org bcc_addr = g...@git.apache.org [/maven/wagon] for_paths = maven/wagon/ to_addr = wagon-comm...@maven.apache.org bcc_addr = g...@git.apache.org [/maven/doxia] for_paths = maven/doxia/ to_addr = doxia-comm...@maven.apache.org bcc_addr = g...@git.apache.org [/maven/surefire] for_paths = maven/surefire/ to_addr = surefire-comm...@maven.apache.org bcc_addr = g...@git.apache.org Do we want to just collapse it all down to just: [/maven] for_paths = maven/ to_addr = comm...@maven.apache.org suppress_if_match = yes bcc_addr = g...@git.apache.org so everything in the maven space goes to commits@maven? Dan LieGrue, strub --- On Tue, 5/24/11, Arnaud Héritier aherit...@gmail.com wrote: From: Arnaud Héritier aherit...@gmail.com Subject: Re: drop wagon-users list? To: Maven Developers List dev@maven.apache.org Cc: Maven Developers List dev@maven.apache.org Date: Tuesday, May 24, 2011, 7:12 PM We need to ask to infra. Just create a task in INFRA Jira project. Le 24 mai 2011 à 21:09, Mark Struberg strub...@yahoo.de a écrit : who/how is going to do this? Is this a post-commit hook in SVN we need to change? LieGrue, strub --- On Tue, 5/24/11, Arnaud Héritier aherit...@gmail.com wrote: From: Arnaud Héritier aherit...@gmail.com Subject: Re: drop wagon-users list? To: Maven Developers List dev@maven.apache.org Cc: Maven Developers List dev@maven.apache.org Date: Tuesday, May 24, 2011, 7:06 PM +1 to merge everything into maven mls Arnaud Le 24 mai 2011 à 20:53, Mark Struberg strub...@yahoo.de a écrit : already changed the wagon pom deprecating the old lists (textual) and adding the official maven-dev and maven-users lists. Btw, what about the commit messages? Should we keep them at wagon-commits? http://markmail.org/search/?q=list%3Aorg.apache.maven.wagon-commits or better move them to maven-commits? The traffic is _really_ low and I expect that to just grow a bit the next weeks and then drop to almost zero again. LieGrue, strub --- On Tue, 5/24/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: drop wagon-users list? To: Maven Developers List dev@maven.apache.org Date: Tuesday, May 24, 2011, 6:20 PM On 2011-05-24 13:36, Mark Struberg wrote: Hi! I was curious if someone still uses the wagon-usrs list. It is currently configured in wagons parent pom but I'd suggest to move this to maven-users and maybe even consolidate the wagon-dev list which is barely used too... The traffic is almost zero.. I'd suggest to change the lists in JIRA and in the pom to maven-users and maven-dev. any objections? +1 Let's do it LieGrue, strub [1] http://markmail.org/search/?q=list%3Awagon-users [2] http://markmail.org/search/?q=list%3Awagon-dev - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [VOTE] Release Apache Maven 3.0.1
+1 Dan On Tuesday 23 November 2010 6:18:15 am Benjamin Bentmann wrote: Hi, 3.0.1-RC1 seems to be fine, thanks to those who tested it. So let's do the real thing. We solved 21 issues since 3.0: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16 331 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500st atus=1 Staging repo: https://repository.apache.org/content/repositories/maven-004/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-004/org/apache/mav en/apache-maven/3.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate eclipse:eclipse plugin
I personally think deprecating/retiring the eclipse plugin is a bit premature. Looking at the svn log, there have been a buunch of commits and a release this year, so there definitely are people that are supporting it. Maybe if m2eclipse was actually usable for any of the projects I work on I might think differently, but it isn't. It's used a lot, it's at least somewhat supported here, and no viable alternative exists. Doesn't sound like deprecation material to me. Dan On Monday 01 November 2010 10:04:14 am Arnaud Héritier wrote: For the eclipse plugin, I think that just moving it to retired isn't a good think because even if we are agree that this one is now really difficult to maintain, this is always the preferred integration way with eclipse in many corporate environments. Thus we cannot just say to our community that we just stop to maintain it. We have to propose something else. m2eclipse or Q4E are the best choices for now but they don't cover all what eclipse:eclipse can do and they have always some performances/stabilities issues with large projects. Everybody can fork eclipse:eclipse plugin (and many teams already did it) but I think we should provide a solution for them to try to share their changes. How will we communicate around these changes ? On Nov 1, 2010, at 2:37 PM, Jason van Zyl wrote: I started moving any of the ones discussed here: http://svn.apache.org/repos/asf/maven/retired/ If anyone disagrees we can move them back but I think the ones suggest so far are good candidates. On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: Following up from a discussion on the user list. I think it's time to be realistic about providing a healthy level of support for plugins here. I think it makes more sense to reduce the foot print of plugins we say we support and do those well as opposed to housing many plugin that just don't get much love. I would ask people to think about the plugins we're housing that we shouldn't. Probably a thread per plugin would be fine for discussion. To that end the plugins I'll send the first thread. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0
+1 Dan On Monday 04 October 2010 8:16:07 am Benjamin Bentmann wrote: Hi, feedback on the RCs seems to be decreasing and I am currently not aware of any major regression so let's try and cross the finishing line of this marathon. We solved 31 issues since 3.0-beta-3: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=13 142 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500st atus=1 Staging repo: https://repository.apache.org/content/repositories/maven-004/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-004/org/apache/mav en/apache-maven/3.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fwd: [maven-release-plugin] Is it possible to configure maven-release-plugin to NOT pull in META-INF/LICENSE and NOTICE
On Friday 03 September 2010 2:34:00 am han hongfang wrote: Forward to dev list to see if somebody has some advice for me on this question. It's not the release plugin, it's the remote-resources plugin generating them. You would need to figure out where the remote-resources thing is configured. You don't mention which project, but if it's and Apache project using the Apache parent pom, that would be pulled in automatically. Th easy fix is to rename your files to LICENSE and and NOTICE. remote- resources will not overwrite new files if existing files exist. Dan Best regards, Han Hong Fang -- Forwarded message -- From: han hongfang hanhongf...@gmail.com Date: Fri, Aug 27, 2010 at 5:27 PM Subject: [maven-release-plugin] Is it possible to configure maven-release-plugin to NOT pull in META-INF/LICENSE and NOTICE To: us...@maven.apache.org Hi, Our project uses maven-release-plugin in the release process. We maintain the LICENSE.txt and NOTICE.txt (which contains module specifc statement) for each of our modules in subversion. When we issue mvn release:prepare, standard LICENSE and NOTICE files are pulled into META-INF folder of target artifact. These standard files are duplicated with LICENSE.txt and NOTICE.txt we maintained. Is it possible to configure maven-release-plugin to not pull in these files? If yes, could you show me how to do it? Thanks in advance for your reply! -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-beta-2
+1 It doesn't seem to be any WORSE than beta-1. It still doesn't build CXF's distribution module, but I didn't report that with beta-1 yet so not really expected to be fixed. I haven't had the time to figure out if it's a Shade plugin issue or beta-1/2 issue. Dan On Saturday 07 August 2010 7:16:42 am Benjamin Bentmann wrote: Hi, We solved 28 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16 090 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500st atus=1 Staging repo: https://repository.apache.org/content/repositories/maven-069/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-069/org/apache/mav en/apache-maven/3.0-beta-2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Parallel vs weave
Well, weave mode doesn't work for CXF. Ends up with a NullPointerException down in antrun-plugin someplace. Thus, I cannot help you there. For CXF on my i7 820QM (4 cores, 8 threads) turning off checkstyle/pmd and having everything already code generated/compiled (so mostly just running tests) Linear: 26 minutes Parallel: 9 minutes (-T 12 is what I'm using) Dan On Friday 11 June 2010 12:24:13 pm Kristian Rosenvold wrote: I am picking up some positive tweets here and there, but I'd be really happy if those of you who test parallel building could report back with some numbers in response to this message. I am particularly interested in the difference between parallel and weave (and linear too), mostly to assess that weave is worth the effort. So after tweaking around with threads a bit to find out what runs fastest I'd really enjoy reports like this one (real data): Linear: 50 seconds Parallel: 40 seconds Weave: 29 seconds For a 10 module project using -T 1C on a 6 core box. For those wondering: * Both parallel and weave favorize projects with lots of modules and wide dependency graphs. * Weave is /probably/ quite a lot faster than parallel for projects with lots of tests fairly evenly distributed among the modules. * Putting all your tests in one module is a bad idea in this context. * Some mojos (like war/ear) can dwarf all the others, effectively limiting the overall potential somewhat. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Parallel vs weave
On Friday 11 June 2010 1:40:07 pm Kristian Rosenvold wrote: Interesting info, and good numbers! Weave is a double edged sword; while it may be promising even faster builds, by design it has this irritating tendency to run mojos (of the same execution in different modules) *exactly* in parallel, more or less simulating how I'd write a unit test to test thread safety. So weave has proved to find almost *all* of the concurrency bugs I've located (where parallel doesn't have any problems). There are also a couple of minor details regarding the actual execution planning in weave mode that are still somewhat open - it's a much more complex execution model than parallel; but I'm concentrating on parallel and the ecosystem in general ATM and just making sure weave works for every project I test. Antrun itself is threadsafe, but whatever is being executed there is another matter. If this is committed to cxf trunk I can/will look at it once I get through the known issues. Yep. To reproduce 1) checkout CXF trunk from: http://svn.apache.org/repos/asf/cxf/trunk/ 2) Build everything (non-parallel right now) mvn -Pnochecks -Dmaven.test.skip.exec=true install That gets everything set and all the code generation done and such. (I'm pretty sure not all the code gen plugins are threadsafe yet, but they all do nothing if they don't have to do anything) Then just run: mvn -Pnochecks -T 12W or similar. For me, 100% of the time it barfs in antrun in the testutils module. You need the -Pnochecks right now when using -T until we get a release of checkstyle that is threadsafe. Alternatively, update the parent/pom.xml to use the snapshots of checkstyle and pmd. Dan Kristian On Fri, Jun 11, 2010 at 6:57 PM, Daniel Kulp dk...@apache.org wrote: Well, weave mode doesn't work for CXF. Ends up with a NullPointerException down in antrun-plugin someplace. Thus, I cannot help you there. For CXF on my i7 820QM (4 cores, 8 threads) turning off checkstyle/pmd and having everything already code generated/compiled (so mostly just running tests) Linear: 26 minutes Parallel: 9 minutes (-T 12 is what I'm using) Dan On Friday 11 June 2010 12:24:13 pm Kristian Rosenvold wrote: I am picking up some positive tweets here and there, but I'd be really happy if those of you who test parallel building could report back with some numbers in response to this message. I am particularly interested in the difference between parallel and weave (and linear too), mostly to assess that weave is worth the effort. So after tweaking around with threads a bit to find out what runs fastest I'd really enjoy reports like this one (real data): Linear: 50 seconds Parallel: 40 seconds Weave: 29 seconds For a 10 module project using -T 1C on a 6 core box. For those wondering: * Both parallel and weave favorize projects with lots of modules and wide dependency graphs. * Weave is /probably/ quite a lot faster than parallel for projects with lots of tests fairly evenly distributed among the modules. * Putting all your tests in one module is a bad idea in this context. * Some mojos (like war/ear) can dwarf all the others, effectively limiting the overall potential somewhat. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMD/Checkstyle and threadSafe....
On Tuesday 08 June 2010 5:51:09 am Olivier Lamy wrote: done too (and snapshot deployed). Can you test this with cxf build Looks good. :-) Dan 2010/6/8 Olivier Lamy ol...@apache.org: we probably need to add @threadSafe in PMD too. I have created MPMD-122 (and will try to do it today) 2010/6/8 Daniel Kulp dk...@apache.org: On Monday 07 June 2010 7:03:49 pm Olivier Lamy wrote: Hi, So I have fixed all dependencies issues and deploy a snapshot. Can you test on your large cxf build ? If all is fine you can close MCHECKSTYLE-139 I just ran mvn validate about a dozen times (both checkstyle and pmd bound into validate phase) with various -T's from 4-12 and not a single problem so I think we're OK with both of them. That said, something is definitely strange as the -T builds are taking as long or longer than the non -T things, especially the PMD plugin. The -T 8 is taking about 10% longer. Internally, they must be syncing on something or similar, but at least they seem to work fine. Dan 2010/6/3 Daniel Kulp dk...@apache.org: On Thursday 03 June 2010 12:54:07 pm John Casey wrote: Ah. The package name has changed, but the APIs are the same. So the imports for the interpolation stuff just need to be adjusted, once the plexus-interpolation dep is added. Right. But nothing in checkstyle plugin imports anything from interpolation. Nothing to adjust there. Thus, it's got to be something in one of the other deps that are pulled in. Maybe plexus-container-default or maven- plugin-testing-harness or similar. I've tried updating those, but still have failures. When I update plexus-container-default and add things like maven-plugin-descriptor and such the error changes to: org.codehaus.plexus.component.repository.exception.ComponentLookupExc epti on: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-checkstyl e- plugin:2.6-SNAPSHOT:check. at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContai ner. java:323) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContai ner. java:440) at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:222) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(Abstr actM ojoTestCase.java:182) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(Abstr actM ojoTestCase.java:127) at org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojoTest.t estD efaultConfig(CheckstyleViolationCheckMojoTest.java:46) Like I said, someone that is really familiar with all the changes that have gone on in all the plexus stuff is really going to have to do this. I'm just making blind shots in the dark and not getting anywhere and I really don't have the time to pursue this right now. Dan On 6/3/10 12:50 PM, Daniel Kulp wrote: On Thursday 03 June 2010 12:38:43 pm John Casey wrote: It needs a dependency added on plexus-interpolation, since the interpolation stuff was taken out of plexus-utils and migrated there. Didn't help. The stuff in plexus-interpolation has the ValueSource stuff in a different package. Thus, adding it isn't fixing the: java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource There is probably a harness update or something else required to get it to use the new package, but I've tried updating a bunch of things without success. Dan On 6/3/10 12:02 PM, Daniel Kulp wrote: I've been working on getting the CXF builds to at least build (not run the tests yet) with the Maven 3 // mode.With the updates to the checkstyle plugin, I've now done about a dozen or so builds with various -T settings without any failures. I'm not quite ready to declare an @threadSafe victory for the PMD and Checkstyle plugins (will probably loop it overnight), but it's definitely looking promising now. HOWEVER, according to Kristian, we need to update to org.apache.maven.plugins v18 (which seems to be OK) and plexus-utils 2.0.5 in order for the @threadSafe stuff to work. Updating to 2.0.5 causes most of the tests to fail with java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource That's really out of my area and would really appreciate it if someone would look into that. I tried updating a bunch of other deps (like doxia and such) but that didn't help. I'm really not sure where to look or why it's trying to grab the ValueSource stuff. Thanks for any help! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail
Re: PMD/Checkstyle and threadSafe....
On Monday 07 June 2010 7:03:49 pm Olivier Lamy wrote: Hi, So I have fixed all dependencies issues and deploy a snapshot. Can you test on your large cxf build ? If all is fine you can close MCHECKSTYLE-139 I just ran mvn validate about a dozen times (both checkstyle and pmd bound into validate phase) with various -T's from 4-12 and not a single problem so I think we're OK with both of them. That said, something is definitely strange as the -T builds are taking as long or longer than the non -T things, especially the PMD plugin. The -T 8 is taking about 10% longer. Internally, they must be syncing on something or similar, but at least they seem to work fine. Dan 2010/6/3 Daniel Kulp dk...@apache.org: On Thursday 03 June 2010 12:54:07 pm John Casey wrote: Ah. The package name has changed, but the APIs are the same. So the imports for the interpolation stuff just need to be adjusted, once the plexus-interpolation dep is added. Right. But nothing in checkstyle plugin imports anything from interpolation. Nothing to adjust there. Thus, it's got to be something in one of the other deps that are pulled in. Maybe plexus-container-default or maven- plugin-testing-harness or similar. I've tried updating those, but still have failures. When I update plexus-container-default and add things like maven-plugin-descriptor and such the error changes to: org.codehaus.plexus.component.repository.exception.ComponentLookupExcepti on: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-checkstyle- plugin:2.6-SNAPSHOT:check. at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer. java:323) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer. java:440) at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:222) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractM ojoTestCase.java:182) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractM ojoTestCase.java:127) at org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojoTest.testD efaultConfig(CheckstyleViolationCheckMojoTest.java:46) Like I said, someone that is really familiar with all the changes that have gone on in all the plexus stuff is really going to have to do this. I'm just making blind shots in the dark and not getting anywhere and I really don't have the time to pursue this right now. Dan On 6/3/10 12:50 PM, Daniel Kulp wrote: On Thursday 03 June 2010 12:38:43 pm John Casey wrote: It needs a dependency added on plexus-interpolation, since the interpolation stuff was taken out of plexus-utils and migrated there. Didn't help. The stuff in plexus-interpolation has the ValueSource stuff in a different package. Thus, adding it isn't fixing the: java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource There is probably a harness update or something else required to get it to use the new package, but I've tried updating a bunch of things without success. Dan On 6/3/10 12:02 PM, Daniel Kulp wrote: I've been working on getting the CXF builds to at least build (not run the tests yet) with the Maven 3 // mode.With the updates to the checkstyle plugin, I've now done about a dozen or so builds with various -T settings without any failures.I'm not quite ready to declare an @threadSafe victory for the PMD and Checkstyle plugins (will probably loop it overnight), but it's definitely looking promising now. HOWEVER, according to Kristian, we need to update to org.apache.maven.plugins v18 (which seems to be OK) and plexus-utils 2.0.5 in order for the @threadSafe stuff to work.Updating to 2.0.5 causes most of the tests to fail with java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource That's really out of my area and would really appreciate it if someone would look into that. I tried updating a bunch of other deps (like doxia and such) but that didn't help. I'm really not sure where to look or why it's trying to grab the ValueSource stuff. Thanks for any help! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h
Re: svn commit: r950747 - /maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java
I committed a fix for this, but it really is a complete hack. The basic issue is that MCHECKSTYLE-131 really is a BAD BAD idea and in my opinion and should not be supported. The basic issue of MCHECKSTYLE-131 is that it allows the plugin to traverse up the parent modules (actually, with 2.4 and olamy's original patch, it would be any module that has already run checkstyle which is really bad as it would depend on the ordering of the builds in the reactor which is really wacked out with parallel mode) and allows grabbing the config files from the root of those modules. Basically, grabs files from other modules, but not through installed jars or anything. Just files sitting in their original directory. Anyway, with the hack I added, it will go up parent modules and the dirs for them, but doesn't attempt to do the modules where checkstyle has already run thing. Dan On Thursday 03 June 2010 5:43:51 am Benjamin Bentmann wrote: Hi Dan, Author: dkulp Date: Wed Jun 2 20:23:49 2010 New Revision: 950747 URL: http://svn.apache.org/viewvc?rev=950747view=rev Log: Since the DefaultCheckstyleExecutor contains an object (ResourceManager) that holds onto state and must be per-lookup, the DefaultCheckstyleExecutor must also be per-lookup to be thread safe. Modified: maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache /maven/plugin/checkstyle/DefaultCheckstyleExecutor.java This appears to have broken the integration tests [0], can you double-check this? Benjamin [0] https://grid.sonatype.org/ci/job/maven-plugins-ITs/454/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
PMD/Checkstyle and threadSafe....
I've been working on getting the CXF builds to at least build (not run the tests yet) with the Maven 3 // mode.With the updates to the checkstyle plugin, I've now done about a dozen or so builds with various -T settings without any failures.I'm not quite ready to declare an @threadSafe victory for the PMD and Checkstyle plugins (will probably loop it overnight), but it's definitely looking promising now. HOWEVER, according to Kristian, we need to update to org.apache.maven.plugins v18 (which seems to be OK) and plexus-utils 2.0.5 in order for the @threadSafe stuff to work.Updating to 2.0.5 causes most of the tests to fail with java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource That's really out of my area and would really appreciate it if someone would look into that. I tried updating a bunch of other deps (like doxia and such) but that didn't help. I'm really not sure where to look or why it's trying to grab the ValueSource stuff. Thanks for any help! -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMD/Checkstyle and threadSafe....
On Thursday 03 June 2010 12:38:43 pm John Casey wrote: It needs a dependency added on plexus-interpolation, since the interpolation stuff was taken out of plexus-utils and migrated there. Didn't help. The stuff in plexus-interpolation has the ValueSource stuff in a different package. Thus, adding it isn't fixing the: java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource There is probably a harness update or something else required to get it to use the new package, but I've tried updating a bunch of things without success. Dan On 6/3/10 12:02 PM, Daniel Kulp wrote: I've been working on getting the CXF builds to at least build (not run the tests yet) with the Maven 3 // mode.With the updates to the checkstyle plugin, I've now done about a dozen or so builds with various -T settings without any failures.I'm not quite ready to declare an @threadSafe victory for the PMD and Checkstyle plugins (will probably loop it overnight), but it's definitely looking promising now. HOWEVER, according to Kristian, we need to update to org.apache.maven.plugins v18 (which seems to be OK) and plexus-utils 2.0.5 in order for the @threadSafe stuff to work.Updating to 2.0.5 causes most of the tests to fail with java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource That's really out of my area and would really appreciate it if someone would look into that. I tried updating a bunch of other deps (like doxia and such) but that didn't help. I'm really not sure where to look or why it's trying to grab the ValueSource stuff. Thanks for any help! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMD/Checkstyle and threadSafe....
On Thursday 03 June 2010 12:54:07 pm John Casey wrote: Ah. The package name has changed, but the APIs are the same. So the imports for the interpolation stuff just need to be adjusted, once the plexus-interpolation dep is added. Right. But nothing in checkstyle plugin imports anything from interpolation. Nothing to adjust there. Thus, it's got to be something in one of the other deps that are pulled in. Maybe plexus-container-default or maven- plugin-testing-harness or similar. I've tried updating those, but still have failures. When I update plexus-container-default and add things like maven-plugin-descriptor and such the error changes to: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-checkstyle- plugin:2.6-SNAPSHOT:check. at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:222) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:182) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:127) at org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojoTest.testDefaultConfig(CheckstyleViolationCheckMojoTest.java:46) Like I said, someone that is really familiar with all the changes that have gone on in all the plexus stuff is really going to have to do this. I'm just making blind shots in the dark and not getting anywhere and I really don't have the time to pursue this right now. Dan On 6/3/10 12:50 PM, Daniel Kulp wrote: On Thursday 03 June 2010 12:38:43 pm John Casey wrote: It needs a dependency added on plexus-interpolation, since the interpolation stuff was taken out of plexus-utils and migrated there. Didn't help. The stuff in plexus-interpolation has the ValueSource stuff in a different package. Thus, adding it isn't fixing the: java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource There is probably a harness update or something else required to get it to use the new package, but I've tried updating a bunch of things without success. Dan On 6/3/10 12:02 PM, Daniel Kulp wrote: I've been working on getting the CXF builds to at least build (not run the tests yet) with the Maven 3 // mode.With the updates to the checkstyle plugin, I've now done about a dozen or so builds with various -T settings without any failures.I'm not quite ready to declare an @threadSafe victory for the PMD and Checkstyle plugins (will probably loop it overnight), but it's definitely looking promising now. HOWEVER, according to Kristian, we need to update to org.apache.maven.plugins v18 (which seems to be OK) and plexus-utils 2.0.5 in order for the @threadSafe stuff to work.Updating to 2.0.5 causes most of the tests to fail with java.lang.ClassNotFoundException: org.codehaus.plexus.util.interpolation.ValueSource That's really out of my area and would really appreciate it if someone would look into that. I tried updating a bunch of other deps (like doxia and such) but that didn't help. I'm really not sure where to look or why it's trying to grab the ValueSource stuff. Thanks for any help! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Very slight (almost silly) 3.0-beta-1 incompatibility
With maven 2.x, I could do: mvn -? and get the help. With 3.0-beta-1, that prints the help, but then: [ERROR] Error executing Maven. org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -? and a stack trace. I know, it's pretty silly. Thought I'd mention it anyway. :-) -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Very slight (almost silly) 3.0-beta-1 incompatibility
On Wednesday 26 May 2010 1:17:26 pm Paul Benedict wrote: Should -? work? I thought the double dash should work only. Well, I guess the main difference is that in 2.x, you would get: Unable to parse command line options: Unrecognized option: -? printed at the top and then the help appears. Thus, it kind of looks like it's working. With 3.0-beta-1, you get that message, the help, and then an: [ERROR] Error executing Maven. and then a 17 line stack trace. At the very least, I don't think the stack trace should be there. (without -e) Dan On Wed, May 26, 2010 at 11:21 AM, Daniel Kulp dk...@apache.org wrote: With maven 2.x, I could do: mvn -? and get the help. With 3.0-beta-1, that prints the help, but then: [ERROR] Error executing Maven. org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -? and a stack trace. I know, it's pretty silly. Thought I'd mention it anyway. :-) -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Very slight (almost silly) 3.0-beta-1 incompatibility
On Wednesday 26 May 2010 3:39:40 pm Daniel Kulp wrote: On Wednesday 26 May 2010 1:17:26 pm Paul Benedict wrote: Should -? work? I thought the double dash should work only. Well, I guess the main difference is that in 2.x, you would get: Unable to parse command line options: Unrecognized option: -? printed at the top and then the help appears. Thus, it kind of looks like it's working. With 3.0-beta-1, you get that message, the help, and then an: [ERROR] Error executing Maven. and then a 17 line stack trace. At the very least, I don't think the stack trace should be there. (without -e) Gack. I meant should NOT be there. Dan Dan On Wed, May 26, 2010 at 11:21 AM, Daniel Kulp dk...@apache.org wrote: With maven 2.x, I could do: mvn -? and get the help. With 3.0-beta-1, that prints the help, but then: [ERROR] Error executing Maven. org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -? and a stack trace. I know, it's pretty silly. Thought I'd mention it anyway. :-) -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Compiler Plugin 2.3
+1 - This change should have been done ages ago. :-) Dan On Saturday 10 April 2010 7:40:55 am Jason van Zyl wrote: Hi, This was simply to bump the default source/target to 1.5. I don't want 3.0-beta-1 released requiring people to set these as they should be defaults now. Staging repo: https://repository.apache.org/content/repositories/maven-011 All we fixed was this: http://jira.codehaus.org/browse/MCOMPILER-80 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release MavenCheckstyle plugin version 2.5
+1 Dan On Mon February 8 2010 8:06:59 am Olivier Lamy wrote: Hi, I'd like to release maven-checkstyle-plugin version 2.5. It's a small release to make it working with maven 3. We solved 1 issue: http://jira.codehaus.org/browse/MCHECKSTYLE-123 Staging repo: https://repository.apache.org/content/repositories/maven-002/ Staging site: http://maven.apache.org/plugins/maven-checkstyle-plugin-2.5 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing maven-eclipse-plugin
Can we at least get a snapshot staged with your changes so I can double check that it doesn't break the CXF instructions? Specifically, we tell people not to use m2eclipse as it generally takes a couple HOURS to import CXF into m2eclipse and then the normal edit/save/run unit test cycle in m2eclipse takes minutes, not seconds.With the normal maven-eclipse-plugin setup and such, it's all MUCH MUCH faster.If the m2eclipse experience could match, I'd have no problems recommending it. But it's too painful right now. Dan On Thu January 14 2010 10:43:45 am Jason van Zyl wrote: Hi, There are some issues left in the 2.8 for the maven-eclipse-plugin but if no one is going work on it then I'll just release it. I specifically want to release the addition I've made to the maven-eclipse-plugin which will stop the confusion among users where they think stuff generated by maven-eclipse-plugin is supported in M2Eclipse. There are projects like CXF that specifically tell users not to use M2Eclipse, which is fine, but I want support issues to fall back to those projects who want to support the maven-eclipse-plugin. More often then not they become the problem of the M2Eclipse developers. So this is really to partition the support where it belongs. It's a simple change, I just added a comment which we will detect in M2Eclipse and tell users what they are attempting are not supported. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: repository.apache.org, gpg signatures and site:attach-descriptor
Why does the site descriptor need to be released as part of the plugin? Why not release surefire without it? It's definitely a bug, but I'm failing to see why it's a blocker for now. Dan On Tue January 12 2010 11:56:28 am Stephen Connolly wrote: I've raised http://jira.codehaus.org/browse/MGPG-19 to track the root cause. A temporary work around would be to disable GPG validation on r.a.o -Stephen P.S. I'm blocked from releasing Surefire 2.5 due to this issue 2010/1/12 Stephen Connolly stephen.alan.conno...@gmail.com: For some reason the site descriptor does not get a signature generated by the gpg plugin. As r.a.o now requires all artifacts to be signed, it would appear to be impossible to close a staged repository. Or do other people have information to the contrary? -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: repository.apache.org, gpg signatures and site:attach-descriptor
Why is the site descriptor being generated for surefire? The shade release two weeks ago didn't generate a site file: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-shade-plugin/1.3/ and neither did the patch plugin: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-patch- plugin/1.1.1/ Dan On Tue January 12 2010 12:51:55 pm Stephen Connolly wrote: The root cause seems to be that m-gpg-p does not consider that project.artifact may have multiple entries (specifically the site metadata) We can argue that the site needs to be decoupled from releasing, but as the site descriptor is one of the artifacts of a project (as opposed to the site) then the site descriptor needs to be pushed to the repo too... therefore m-site-p is correct to attach it (but possibly incorrect attaching it directly to project.artifact) In any case MGPG-19 reflects this crazy model of attaching artifacts to a project because m-gpg-p does not look in this (frankly unknown to me) other way of attaching an artifact. If we are to fix this it will require re-deploying all the parents after deploying a new m-gpg-p... all of which I suspect will require turning off gpg validation on r.a.o first -Stephen 2010/1/12 Stephen Connolly stephen.alan.conno...@gmail.com: Fair enough, but we cannot make releases as things currently stand 2010/1/12 Jason van Zyl ja...@sonatype.com: The site stuff needs to be completely decoupled from releases. It such a horrible coupling and causes nothing but problems. Release and the documentation that goes along with it are completely separate. On 2010-01-12, at 12:08 PM, Daniel Kulp wrote: Why does the site descriptor need to be released as part of the plugin? Why not release surefire without it? It's definitely a bug, but I'm failing to see why it's a blocker for now. Dan On Tue January 12 2010 11:56:28 am Stephen Connolly wrote: I've raised http://jira.codehaus.org/browse/MGPG-19 to track the root cause. A temporary work around would be to disable GPG validation on r.a.o -Stephen P.S. I'm blocked from releasing Surefire 2.5 due to this issue 2010/1/12 Stephen Connolly stephen.alan.conno...@gmail.com: For some reason the site descriptor does not get a signature generated by the gpg plugin. As r.a.o now requires all artifacts to be signed, it would appear to be impossible to close a staged repository. Or do other people have information to the contrary? -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Just to follow up on this, it looks like the two main options are: 1) Add an endorsed scope. What would be involved with that? What would happen when a 2.0.10/2.2.1 maven version hits such a scope?This seems to be a maven core thing with updates needed to a bunch of core things. Not a BAD thing, especially for 3.0 or something, but increases the complexity. 2) maven-endorsed-plugin - similar to the toolchains thing, but provides special endorsing capabilities. Would be done in parts. The plugin plus updates to surefire and compiler (and others that may need it). (2) can definitely be made to work with existing versions of maven, but (1) definitely seems cleaner. (1) would also allow endorsements to be handled from transitive deps, although I'm not sure if that's a good thing or not. :-) Anyway, what are peoples thoughts? I think after thanksgiving, I may need to start working on bits of this so I'd like to get peoples thoughts and ideas before then. Dan On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
On Thu November 12 2009 2:22:51 pm Paul Benedict wrote: Is it possible to add endorsed libraries programatically? I thought the JDK grabbed all its endorsements from jdk_home\lib\ext When you fork a jvm (javac fork or surefire set to fork), you can specify a system property of other places to look. Thus, then endorsed stuff would only apply when those are set to fork. Dan Paul On Thu, Nov 12, 2009 at 12:48 PM, Daniel Kulp dk...@apache.org wrote: Just to follow up on this, it looks like the two main options are: 1) Add an endorsed scope. What would be involved with that? What would happen when a 2.0.10/2.2.1 maven version hits such a scope?This seems to be a maven core thing with updates needed to a bunch of core things. Not a BAD thing, especially for 3.0 or something, but increases the complexity. 2) maven-endorsed-plugin - similar to the toolchains thing, but provides special endorsing capabilities. Would be done in parts. The plugin plus updates to surefire and compiler (and others that may need it). (2) can definitely be made to work with existing versions of maven, but (1) definitely seems cleaner. (1) would also allow endorsements to be handled from transitive deps, although I'm not sure if that's a good thing or not. :-) Anyway, what are peoples thoughts? I think after thanksgiving, I may need to start working on bits of this so I'd like to get peoples thoughts and ideas before then. Dan On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
endorsing: ToolChain thing or compiler/surefire plugin thing or ....
While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
