Jsch issue with Java 7 and Kerberos enabled ssh servers (was Re: about the bug)
I had a few private email discussion with Deng: it seems he is facing a known
issue with Java 7 + Kerberos enabled ssh servers + Jsch that was already faced
by:
- Ant: https://bz.apache.org/bugzilla/show_bug.cgi?id=53437
- Mule: https://www.mulesoft.org/jira/browse/MULE-6864
and probably others
I think the workaround proposed by Jsch is interesting:
http://sourceforge.net/p/jsch/mailman/message/29359265/
session.setConfig(PreferredAuthentications,
publickey,keyboard-interactive,password);
any objection from people with more knowledge on the topic?
Ideally, I'd like to create a unit-test, because that would really improve
wagon-ssh maintainability, but I need to discover how to create an embedded
Kerberos enabled SSH server: help needed on this :)
And finally, I found https://issues.apache.org/jira/browse/WAGON-355 Expose
PreferredAuthentications property of jsch in some way, which seems highly
desirable since it seems this is a really tricky part that would be useful to
be configurable by end-users to fit their particular needs: any hint on how to
provide this feature?
Notice: I created WAGON-439 https://issues.apache.org/jira/browse/WAGON-439 to
track the issue
Regards,
Hervé
Le dimanche 3 mai 2015 07:23:07 Hervé Boutemy a écrit :
Hi Pengfei,
This is an INFO message, not a failure: it explains why it is switching to
SSH key instead of agent.
Regards,
Hervé
Le jeudi 30 avril 2015 12:01:49 Barrie Treloar a écrit :
Please use the Maven users list for these questions.
On 30 April 2015 at 11:47, Pengfei Deng pengfei.d...@ericsson.com wrote:
Hi all ,
When I try to use maven-release-plugin and use
release:clean release:prepare release:perform I got error below:
[INFO] [INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @
site-deploy-test ---
[INFO] Unable to connect to agent:
com.jcraft.jsch.agentproxy.AgentProxyException: connector is not
available:
[image:
https://eis-jenkins-jcat.rnd.ki.sw.ericsson.se/static/09e72bc8/images/sp
in
ner.gif]
And the source code is like this:
try
{
Connector connector = ConnectorFactory.getDefault().
createConnector();
if ( connector != null )
{
IdentityRepository repo = new RemoteIdentityRepository(
connector );
sch.setIdentityRepository( repo );
}
}
catch ( AgentProxyException e )
{
fireSessionDebug( Unable to connect to agent: +
e.toString()
);
}
Could you please help?
Best Regards,
[image: Ericsson] http://www.ericsson.com/
*PENGFEI DENG *
Software Design Engineer
BURA DURA RCI CBC Tools JCAT and Config
*Ericsson*
No.5 WangJing East Road Chaoyang District Beijing
100102, China
Phone +86 15652957083
Office +86 10 84767195
pengfei.d...@ericsson.com
www.ericsson.com
[image: http://www.ericsson.com/current_campaign]
http://www.ericsson.com/current_campaign
Legal entity: CBC/XIT, registered office in RndP. This Communication is
Confidential. We only send and receive email on the basis of the terms
set
out at www.ericsson.com/email_disclaimer
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Do we want to go for gitpubsub?
Le vendredi 1 mai 2015 15:14:05 Andreas Gudian a écrit : Anyone who has ever done a release of a large plugin like surefire from a european location knows what a pain it is to svn-commit a couple of thousand files. It takes hours, but only if you're lucky and the process is not interrupted by the server. I had to dance around that by zipping up the locally generated site, scp it to people.a.o and commit it from there. Every time I did that, I thought about how cool it would be to just push one git-commit - it would be done in seconds. +1 So I'd be all in favour of that. Depends on how that would be structured, though. Everything in one big repository? Or could it be sliced into parts of the different areas of the sites, like main maven pages, the single-module plugins, and dedicated repositories for the bigger plugins? you're pointing to the key good question There was a discussion last month on infrastructure mailing list about eventually deprecating CMS: that is the starting point of my work on .htaccess and /content vs /components for merging main site content with components documentations (both latest and versioned in *-archives/) And from the discussion I had with infra, having multiple SCM entries (one for the main site and one for each and every component) would cause issues for infra, since it means infra would have to configure a lot of *pubsub listeners: it's not part of infra plan to have so much listeners, and being in the loop every time we add one component. Notice I don't see how versioned content (in *-archives) could be done: but that's another issue, perhaps we could find a strategy. Then if we switched to git, this would be one big git repo with absolutely everything in it: I counted, there are 475 000 files, for 5 GB. Not sure we'll have the performance improvement we expected from git... Notice that we have curently 2 html repos: /content and /components We could migrate /content, ie the main site content, to gitpubsub But I think we would loose the CMS, since CMS doesn't support git, AFAIK Not that I'm a big CMS fan, but what I like is the main site automatic build (not done from personal desktop but from buildbot [1] ), which is part of the CMS workflow Then I fear the dream we all have to improve component documentation publication performance won't come from this But during the discussion with infra, this huge performance issue was clearly shared and there was an idea expressed by Joe Schaefer: Supporting tar/zip files with svnpubsub is straightforward with the built-in hook support. Someone would just need to write a custom hook that expands zip files for websites (a list of where to find these files needs to be supplied or conventionalized). The way I'd envision this working is that, 1) projects add their compressed archives listings to a specific file similar to extpaths for the cms. Each entry would be a target path and a source tarball. 2) when a project commits a new entry with a new tarball, the hook will look at each entry in the tarball file and compare timestamps against what's on disk. If the directory is older than the tarball it nukes the directory and reexpands and resets the timestamp on the base of the tree. This of course has nothing to do with the cms. Everything needed is already possible with svnpubsub and perhaps gitpubsub as well. If somebody is interested to work on this, I can give pointers and work with him: at the moment, i felt too alone on the topic to have energy to do anything... Regards, Hervé [1] http://ci.apache.org/builders/maven-site-staging 2015-04-30 21:16 GMT+02:00 Jason van Zyl ja...@takari.io: My read is this work much like Github pages works. You have a repository with your source and the rendered pages go into a branch. But nothing stops you from having the source in one repo and just pushing the generated content to another repo. This is currently how we do the M2Eclipse site. We have a Jekyll site in one repository, and we have a process that runs Jekyll and produces the website which gets pushed. I think if we did the same it would be cool because we could have the site on Github where we can use Jekyll, let people make pull requests and push it back here for official publishing. On Apr 30, 2015, at 2:55 PM, Michael Osipov micha...@apache.org wrote: Am 2015-04-30 um 00:31 schrieb Stephen Connolly: http://bit.ly/1QLwWGS (Source: https://twitter.com/planetapache/status/593535338074611712) Wouldn't that imply always to clone a private copy of the entire repo with autogerated stuff just to push changes back to the canonical repo? Sounds like an absolute waste of time and resources to me. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Feedback wanted on Checktyle plugin ruleset docs
option 3 is confusing I like option 1, I find it more clear than option 2: I don't think we'll have scalability issues, since the evolution we need to document won't change in the future notice that using Markdown, or perhaps html, you could use colspans to merge content that is the same between version and one idea: instead of Reference, tell provided by Maven Shared Resources or provided by Checkstyle then this doc could explain how to use a ruleset provided by Checkstyle / how to use a ruleset provided by another artifact Regards, Hervé Le samedi 2 mai 2015 16:32:47 Jeff Jensen a écrit : I suggest alternative 2 as 1 doesn't scale well with new versions and 3 is more confusing than 2. On Sat, May 2, 2015 at 4:11 PM, Christopher ctubb...@apache.org wrote: Of the choices, alternative 1 seems the easiest for me. On Sat, May 2, 2015, 16:10 Dennis Lundberg denn...@apache.org wrote: Hi, I'm trying to visualize which version of the Checkstyle plugin includes which predefined rulesets. There's are 3 alternatives for you to look at here: https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/c onfig/index.html Please let me know which alternative you think is the most easy to understand. -- Dennis Lundberg - 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
Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4 (Take 2)
Hi Gary, I haven't expressed that in the VOTE...otherwise i would have given it like this: The vote is open for 72 hours and will succeed by lazy consensus. which i haven't done. Usually we don't use lazy census here on the dev list...(Not that i remember)... Kind regards Karl Heinz Marbaise On 5/3/15 11:15 PM, Gary Gregory wrote: On Sun, May 3, 2015 at 1:12 PM, Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de wrote: Hi Gary, On 5/3/15 9:23 PM, Gary Gregory wrote: And this is a LAZY VOTE? I beg your pardon? Please see https://www.apache.org/foundation/voting.html#LazyConsensus Just curious. Gary Kind regards Karl Heinz Marbaise Gary On Sun, May 3, 2015 at 11:57 AM, Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de mailto:khmarba...@gmx.de mailto:khmarba...@gmx.de wrote: Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574 Staging repo: https://repository.apache.org/content/repositories/maven-1186 https://repository.apache.org/content/repositories/maven-1186/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip Source release checksum(s): maven-fluido-skin-1.4-source-release.zip sha1: 6e2adbf1462ee1f4558a250d316849b7a0dd2d70 Staging site: http://maven.apache.org/skins-archives/maven-fluido-skin-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 mailto:dev-unsubscr...@maven.apache.org mailto:dev-unsubscr...@maven.apache.org mailto:dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org -- E-Mail: garydgreg...@gmail.com mailto:garydgreg...@gmail.com | ggreg...@apache.org mailto:ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com http://garygregory.wordpress.com/ Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Release Plan maven-shared-utils-0.8
Currently surefire is dependent on snapshot version: maven-shared-utils-0.8-SNAPSHOT. When do we plane the release of 0.8 ? Cheers Tibor
Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4 (Take 2)
Hi Gary, On 5/3/15 9:23 PM, Gary Gregory wrote: And this is a LAZY VOTE? I beg your pardon? Kind regards Karl Heinz Marbaise Gary On Sun, May 3, 2015 at 11:57 AM, Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de wrote: Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574 Staging repo: https://repository.apache.org/content/repositories/maven-1186 https://repository.apache.org/content/repositories/maven-1186/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip Source release checksum(s): maven-fluido-skin-1.4-source-release.zip sha1: 6e2adbf1462ee1f4558a250d316849b7a0dd2d70 Staging site: http://maven.apache.org/skins-archives/maven-fluido-skin-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 mailto:dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4 (Take 2)
On Sun, May 3, 2015 at 1:12 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Gary, On 5/3/15 9:23 PM, Gary Gregory wrote: And this is a LAZY VOTE? I beg your pardon? Please see https://www.apache.org/foundation/voting.html#LazyConsensus Just curious. Gary Kind regards Karl Heinz Marbaise Gary On Sun, May 3, 2015 at 11:57 AM, Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de wrote: Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574 Staging repo: https://repository.apache.org/content/repositories/maven-1186 https://repository.apache.org/content/repositories/maven-1186/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip Source release checksum(s): maven-fluido-skin-1.4-source-release.zip sha1: 6e2adbf1462ee1f4558a250d316849b7a0dd2d70 Staging site: http://maven.apache.org/skins-archives/maven-fluido-skin-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 mailto:dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[GitHub] maven-surefire pull request: [SUREFIRE-1154] TestNG should be able...
Github user juherr closed the pull request at: https://github.com/apache/maven-surefire/pull/90 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4 (Take 2)
On Sun, May 3, 2015 at 2:45 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Gary, I haven't expressed that in the VOTE...otherwise i would have given it like this: The vote is open for 72 hours and will succeed by lazy consensus. which i haven't done. Usually we don't use lazy census here on the dev list...(Not that i remember)... Thank you for the clarification. Gary Kind regards Karl Heinz Marbaise On 5/3/15 11:15 PM, Gary Gregory wrote: On Sun, May 3, 2015 at 1:12 PM, Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de wrote: Hi Gary, On 5/3/15 9:23 PM, Gary Gregory wrote: And this is a LAZY VOTE? I beg your pardon? Please see https://www.apache.org/foundation/voting.html#LazyConsensus Just curious. Gary Kind regards Karl Heinz Marbaise Gary On Sun, May 3, 2015 at 11:57 AM, Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de mailto:khmarba...@gmx.de mailto:khmarba...@gmx.de wrote: Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574 Staging repo: https://repository.apache.org/content/repositories/maven-1186 https://repository.apache.org/content/repositories/maven-1186/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip Source release checksum(s): maven-fluido-skin-1.4-source-release.zip sha1: 6e2adbf1462ee1f4558a250d316849b7a0dd2d70 Staging site: http://maven.apache.org/skins-archives/maven-fluido-skin-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 mailto:dev-unsubscr...@maven.apache.org mailto:dev-unsubscr...@maven.apache.org mailto:dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org mailto:dev-h...@maven.apache.org -- E-Mail: garydgreg...@gmail.com mailto:garydgreg...@gmail.com | ggreg...@apache.org mailto:ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com http://garygregory.wordpress.com/ Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: Maven Eclipse Plugin Final Release ?
Le jeudi 30 avril 2015 19:26:54 Daniel Kulp a écrit : 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. :-) in fact, it should be the final 2.x release, with Maven 2 prerequisite: next one will be 3.0.0 with Maven 3 prerequisite Regards, Hervé 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-prerequisite s.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-scm pull request: Scm 775
GitHub user ChrisGWarp opened a pull request: https://github.com/apache/maven-scm/pull/33 Scm 775 This pull requests implements the SCM-775 functionality needed to support workItem/Tasks for scm deliver operations. Currently implemented for Jazz, the base work applied, will allow TFS, ClearCase and others to access work items. There is also a corresponding patch attached to MRELEASE-909. All feedback welcome. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ChrisGWarp/maven-scm SCM-775 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-scm/pull/33.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #33 commit b1ab76eba177ea64e824dc23bca82303497ccb3e Author: ChrisGWarp chrisgw...@gmail.com Date: 2015-04-04T10:33:44Z Change: Added consume commit df117ec3b5867613a221ecc2099143d679e80b09 Author: chrisgw...@gmail.com Date: 2015-04-28T12:56:24Z Changed: Implemented changes necessary to support SCM-775, the adoption of workItem support for Jazz, and the basis for other SCMs. commit cf0fea2993ea87d59acae81f512af1ea918879e3 Author: ChrisGWarp chrisgw...@gmail.com Date: 2015-04-29T11:29:58Z Updated Javadoc. commit cc1a08d6a8cd008f5077127bc72e3b2e291a1771 Author: Chris Graham chrisgw...@gmail.com Date: 2015-05-01T02:10:17Z Changed: Fixed the failing changeset associate test (on unix). commit 88e75c5fcfa5b8ca47d1432d05b91c63398fb39a Author: Chris Graham chrisgw...@gmail.com Date: 2015-05-02T12:49:07Z Changed: Added support for multiple changesets. Changed: Added status calls where necessary to pick up change set aliases as well as workspace/stream names and aliases. Changed: Added additional StatusConsumer test cases. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - 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 ?
Hi Hervé, On 5/3/15 11:24 AM, Hervé BOUTEMY wrote: it is already done http://maven.apache.org/plugins/index.html http://maven.apache.org/issue-tracking.html what is the site part you're looking at, please? I think he means the site of the plugin itself.. http://maven.apache.org/plugins/maven-eclipse-plugin/issue-tracking.html but related to this the majority of the plugins is not uptodate ... Kind regards karl Heinz Marbaise Regards, Hervé Le vendredi 1 mai 2015 09:54:47 Martijn Dashorst a écrit : Would be cool if the site was updated wit the new location of jira issues as well. Martijn On Thu, Apr 30, 2015 at 10: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 ? 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-prerequisite s.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
Re: Maven Eclipse Plugin Final Release ?
it is already done http://maven.apache.org/plugins/index.html http://maven.apache.org/issue-tracking.html what is the site part you're looking at, please? Regards, Hervé Le vendredi 1 mai 2015 09:54:47 Martijn Dashorst a écrit : Would be cool if the site was updated wit the new location of jira issues as well. Martijn On Thu, Apr 30, 2015 at 10: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 ? 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-prerequisite s.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Do we want to go for gitpubsub?
5 gig? wow... I think a whole lot of of the pages is garbage that no one ever really reads. No, not the docs itself ;-) - I'm talking about the many many source xref and javadoc pages (both main and test code) And every single of those pages is updated on every release because they all contain the version number or a timestamp somewhere. If we could stop adding source xrefs and javadocs to the site reports, that would already help a lot. I haven't read any javadoc pages in the browser for years... and when I look for source code, I use the quick search on github or browse through the web-cvs. When I actually use a library, then the sources are downloaded automatically anyway in the IDE - together with the Javadocs if necessary. Or does anyone see that there's still need for those pages? Do we maybe have some statistics on visits to those pages? 2015-05-03 10:52 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr: Le vendredi 1 mai 2015 15:14:05 Andreas Gudian a écrit : Anyone who has ever done a release of a large plugin like surefire from a european location knows what a pain it is to svn-commit a couple of thousand files. It takes hours, but only if you're lucky and the process is not interrupted by the server. I had to dance around that by zipping up the locally generated site, scp it to people.a.o and commit it from there. Every time I did that, I thought about how cool it would be to just push one git-commit - it would be done in seconds. +1 So I'd be all in favour of that. Depends on how that would be structured, though. Everything in one big repository? Or could it be sliced into parts of the different areas of the sites, like main maven pages, the single-module plugins, and dedicated repositories for the bigger plugins? you're pointing to the key good question There was a discussion last month on infrastructure mailing list about eventually deprecating CMS: that is the starting point of my work on .htaccess and /content vs /components for merging main site content with components documentations (both latest and versioned in *-archives/) And from the discussion I had with infra, having multiple SCM entries (one for the main site and one for each and every component) would cause issues for infra, since it means infra would have to configure a lot of *pubsub listeners: it's not part of infra plan to have so much listeners, and being in the loop every time we add one component. Notice I don't see how versioned content (in *-archives) could be done: but that's another issue, perhaps we could find a strategy. Then if we switched to git, this would be one big git repo with absolutely everything in it: I counted, there are 475 000 files, for 5 GB. Not sure we'll have the performance improvement we expected from git... Notice that we have curently 2 html repos: /content and /components We could migrate /content, ie the main site content, to gitpubsub But I think we would loose the CMS, since CMS doesn't support git, AFAIK Not that I'm a big CMS fan, but what I like is the main site automatic build (not done from personal desktop but from buildbot [1] ), which is part of the CMS workflow Then I fear the dream we all have to improve component documentation publication performance won't come from this But during the discussion with infra, this huge performance issue was clearly shared and there was an idea expressed by Joe Schaefer: Supporting tar/zip files with svnpubsub is straightforward with the built-in hook support. Someone would just need to write a custom hook that expands zip files for websites (a list of where to find these files needs to be supplied or conventionalized). The way I'd envision this working is that, 1) projects add their compressed archives listings to a specific file similar to extpaths for the cms. Each entry would be a target path and a source tarball. 2) when a project commits a new entry with a new tarball, the hook will look at each entry in the tarball file and compare timestamps against what's on disk. If the directory is older than the tarball it nukes the directory and reexpands and resets the timestamp on the base of the tree. This of course has nothing to do with the cms. Everything needed is already possible with svnpubsub and perhaps gitpubsub as well. If somebody is interested to work on this, I can give pointers and work with him: at the moment, i felt too alone on the topic to have energy to do anything... Regards, Hervé [1] http://ci.apache.org/builders/maven-site-staging 2015-04-30 21:16 GMT+02:00 Jason van Zyl ja...@takari.io: My read is this work much like Github pages works. You have a repository with your source and the rendered pages go into a branch. But nothing stops you from having the source in one repo and just pushing the generated content to another repo. This is currently how we do the M2Eclipse site. We
Re: Feedback wanted on Checktyle plugin ruleset docs
Hi Dennis, i would prefer Option 2 cause it's extensible... Kind regards Karl Heinz Marbaise On 5/2/15 12:38 PM, Dennis Lundberg wrote: Hi, I'm trying to visualize which version of the Checkstyle plugin includes which predefined rulesets. There's are 3 alternatives for you to look at here: https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/config/index.html Please let me know which alternative you think is the most easy to understand. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Do we want to go for gitpubsub?
Hello, when searching around for special constructs or when I have to need to understand some third party error messages I like to visit Java code on the Web as it safes me the need to check it out and especially it offers (usually) a good search and navigation. So this is by definition not for projects I work in, and typically it is via aggregator sides like grepcode. It is good to have code online for search index to index. But it does not have to be in a site build. (Unfortunatelly the usual web repo browsers are not so good in creating type links). For javadoc-xrefs it is most valuable for samples. Gruss Bernd Am Sun, 3 May 2015 20:22:04 +0200 schrieb Andreas Gudian andreas.gud...@gmail.com: 5 gig? wow... I think a whole lot of of the pages is garbage that no one ever really reads. No, not the docs itself ;-) - I'm talking about the many many source xref and javadoc pages (both main and test code) And every single of those pages is updated on every release because they all contain the version number or a timestamp somewhere. If we could stop adding source xrefs and javadocs to the site reports, that would already help a lot. I haven't read any javadoc pages in the browser for years... and when I look for source code, I use the quick search on github or browse through the web-cvs. When I actually use a library, then the sources are downloaded automatically anyway in the IDE - together with the Javadocs if necessary. Or does anyone see that there's still need for those pages? Do we maybe have some statistics on visits to those pages? 2015-05-03 10:52 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr: Le vendredi 1 mai 2015 15:14:05 Andreas Gudian a écrit : Anyone who has ever done a release of a large plugin like surefire from a european location knows what a pain it is to svn-commit a couple of thousand files. It takes hours, but only if you're lucky and the process is not interrupted by the server. I had to dance around that by zipping up the locally generated site, scp it to people.a.o and commit it from there. Every time I did that, I thought about how cool it would be to just push one git-commit - it would be done in seconds. +1 So I'd be all in favour of that. Depends on how that would be structured, though. Everything in one big repository? Or could it be sliced into parts of the different areas of the sites, like main maven pages, the single-module plugins, and dedicated repositories for the bigger plugins? you're pointing to the key good question There was a discussion last month on infrastructure mailing list about eventually deprecating CMS: that is the starting point of my work on .htaccess and /content vs /components for merging main site content with components documentations (both latest and versioned in *-archives/) And from the discussion I had with infra, having multiple SCM entries (one for the main site and one for each and every component) would cause issues for infra, since it means infra would have to configure a lot of *pubsub listeners: it's not part of infra plan to have so much listeners, and being in the loop every time we add one component. Notice I don't see how versioned content (in *-archives) could be done: but that's another issue, perhaps we could find a strategy. Then if we switched to git, this would be one big git repo with absolutely everything in it: I counted, there are 475 000 files, for 5 GB. Not sure we'll have the performance improvement we expected from git... Notice that we have curently 2 html repos: /content and /components We could migrate /content, ie the main site content, to gitpubsub But I think we would loose the CMS, since CMS doesn't support git, AFAIK Not that I'm a big CMS fan, but what I like is the main site automatic build (not done from personal desktop but from buildbot [1] ), which is part of the CMS workflow Then I fear the dream we all have to improve component documentation publication performance won't come from this But during the discussion with infra, this huge performance issue was clearly shared and there was an idea expressed by Joe Schaefer: Supporting tar/zip files with svnpubsub is straightforward with the built-in hook support. Someone would just need to write a custom hook that expands zip files for websites (a list of where to find these files needs to be supplied or conventionalized). The way I'd envision this working is that, 1) projects add their compressed archives listings to a specific file similar to extpaths for the cms. Each entry would be a target path and a source tarball. 2) when a project commits a new entry with a new tarball, the hook will look at each entry in the tarball file and compare timestamps against what's on disk. If the directory is older than the tarball it nukes the directory
Re: Problems with Jenkins builds of invoker and assembly plugins
Op Fri, 01 May 2015 22:59:05 +0200 schreef Dennis Lundberg denn...@apache.org: Hi, After doing some work on the Checkstyle Plugin today, I noticed that several of our Jenkins jobs for plugins are failing. I looked into it and found a couple of problems. 1. maven-invoker-plugin is added as a module in two different profiles; java-6 and maven-3. The first one because it requires Java 6 and thee second one as a workaround for MNG-3814. The problem is that the invoker plugin gets built if Java 6 OR Maven 3 is used. This fails some of the Jenkins jobs. Is there a way to require Java 6 AND Maven 3 to activate a profile? https://jira.codehaus.org/browse/MNG-4565 fixes AND-activation. I think Dan Tran tried to do a fixed, but discovered too late that the introduced dependency requires Java6. The strategy is already to move the plugin requirements to both Maven3 and JDK6, so this is probably no issue. For now the plugin is in a bad condition, so maybe it is better to revert those last commits and reopen the related issue, since the plugin requires special attention due to maven-compat requirement for Maven3. 2. maven-assembly-plugin fails on Windows, and it fails for me locally on Windows as well. This is due to *nix-style absolute path references in outputDirectory in FileItemAssemblyPhaseTest. Not sure how to solve this. In my own projects I simply changes from outputDirectory//outputDirectory to outputDirectory/outputDirectory, but I dare not change the tests. If it is about path separators, I can have a look. Normally it shouldn't be too hard to let it work for both separators. You could also add an Assumption[1] to the test... Robert [1] http://junit.sourceforge.net/javadoc/org/junit/Assume.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Feedback wanted on Checktyle plugin ruleset docs
I'd prefer option 1 Robert Op Sun, 03 May 2015 11:09:46 +0200 schreef Hervé BOUTEMY herve.bout...@free.fr: option 3 is confusing I like option 1, I find it more clear than option 2: I don't think we'll have scalability issues, since the evolution we need to document won't change in the future notice that using Markdown, or perhaps html, you could use colspans to merge content that is the same between version and one idea: instead of Reference, tell provided by Maven Shared Resources or provided by Checkstyle then this doc could explain how to use a ruleset provided by Checkstyle / how to use a ruleset provided by another artifact Regards, Hervé Le samedi 2 mai 2015 16:32:47 Jeff Jensen a écrit : I suggest alternative 2 as 1 doesn't scale well with new versions and 3 is more confusing than 2. On Sat, May 2, 2015 at 4:11 PM, Christopher ctubb...@apache.org wrote: Of the choices, alternative 1 seems the easiest for me. On Sat, May 2, 2015, 16:10 Dennis Lundberg denn...@apache.org wrote: Hi, I'm trying to visualize which version of the Checkstyle plugin includes which predefined rulesets. There's are 3 alternatives for you to look at here: https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/c onfig/index.html Please let me know which alternative you think is the most easy to understand. -- Dennis Lundberg - 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
[VOTE] Release Apache Maven Fluido Skin Version 1.4 (Take 2)
Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574 Staging repo: https://repository.apache.org/content/repositories/maven-1186 https://repository.apache.org/content/repositories/maven-1186/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip Source release checksum(s): maven-fluido-skin-1.4-source-release.zip sha1: 6e2adbf1462ee1f4558a250d316849b7a0dd2d70 Staging site: http://maven.apache.org/skins-archives/maven-fluido-skin-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
Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4 (Take 2)
And this is a LAZY VOTE? Gary On Sun, May 3, 2015 at 11:57 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574 Staging repo: https://repository.apache.org/content/repositories/maven-1186 https://repository.apache.org/content/repositories/maven-1186/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip Source release checksum(s): maven-fluido-skin-1.4-source-release.zip sha1: 6e2adbf1462ee1f4558a250d316849b7a0dd2d70 Staging site: http://maven.apache.org/skins-archives/maven-fluido-skin-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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
