Re: [LOGO] site with Fluido skin and owl logo
If the vote is successful I'll commit the SVG originals, and we can slice and dice, eg maybe keep the owl out of the top bar, add an owl favicon, and rework the overly busy front page. I also think we should remove the side-bars (and perhaps switch to a top bar menu) as they hinder mobile accessibility. We can use hopscotch to let people know where the stuff is, much like clicking the Take a tour button on the junit.org site revamp I did. On Wednesday, 26 November 2014, Hervé BOUTEMY herve.bout...@free.fr wrote: I created a branch in svn to test in my own browser https://svn.apache.org/repos/asf/maven/site/branches/fluido/ and here is the mvn site result: http://people.apache.org/~hboutemy/site-fluido-owl/ HTH Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: Using the Maven Indexer
On Tue, Nov 25, 2014 at 12:22 PM, Tamas Cservenak ta...@cservenak.net wrote: Hi there, 1) yes, indexing context retains the artefact “origin” (ie. repo), so you need context per origin. Sadly, the 1 index per context is current limitation of maven indexer, but this problem is known. Created http://jira.codehaus.org/browse/MINDEXER-93 2) Yes, merged context is basically delegating to member contexts. under the hud, it uses Lucene’s MultiReader to actually perform the search. I have solved the search problem for now by using the SearchEngine component and issuing an IteratorSearchRequest on a list of IndexingContexts to get paginated results. Will have to see how that works on the long run. Thanks, Eduard Re ranging, there are already issues (or problem spread across multiple issues), most notably this one http://jira.codehaus.org/browse/MINDEXER-8 3) I think yes. Currently, indexer is being transitioned from Plexus to JSR330, and as you see in examples, it should work with any container supporting it. re “manually wiring”, in latest releases you might be able to do it, but in older ones probably not, as Plexus supported field injection only, and some of those member was not exposed via getter/setter. See http://jira.codehaus.org/browse/MINDEXER-80 -- Thanks, ~t~ On 21 Nov 2014 at 18:08:26, Eduard Moraru (enygma2...@gmail.com) wrote: Hi, I have recently started playing with the maven indexer [1], following the examples [2], and I have some questions (since AFAIS, documentation is practically unexistent on the matter): 1) From what I can understand, you need an IndexingContext for each repository you plan to index. This makes you end up with n lucene indexes, one for each repository. Is there any way that I could have just 1 lucene index, with all my repositories indexed in the same place? If the main purpose is searchig, why scatter the indexed information across n indexes and make the whole process dificult? Maybe I`m missing something. 2) On the same line as the first question, when it comes to searching, it seems that I can use a MergedIndexingContext to perform a search on multiple (all) indexed repositories (IndexingContexts). How does this merge the search results? I assume it takes each lucene index and queries it individually, but this probably means that the lucene scores of these merged results are completely messed up and ureliable, right? Any suggestions on how to properly perform search over multiple indexed repositories? 3) About the Plexus Container: Am I forced to initialize and use one, or can I/should manually instantiate the default implementations and use them instead? I`ll probably come up with more questions along the way, hope someone will find the time to guide me on the right path. Thanks, Eduard -- [1] https://github.com/apache/maven-indexer/ [2] https://github.com/apache/maven-indexer/tree/master/indexer-examples/indexer-examples-basic
[ANN] Apache Maven Assembly Plugin 2.5.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Assembly Plugin, version 2.5.2. The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. Most notable for this release are: Rewritten duplicate handling strategy, revised documentation. Please note that previously documented strategy was mostly wishful thinking, the currently documented strategy is hard reality :) See http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.5.2/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5.2 ** Bug * [MASSEMBLY-478] - allow overwriting newer files with older files contained within fileset * [MASSEMBLY-558] - Assembly does not include runtime-dependency if test-dependency with shorter path exists * [MASSEMBLY-565] - jar-with-dependencies: class from the source in project does NOT override the class in jar dependency * [MASSEMBLY-569] - The numbering of the items in the FAQ on the site is messed up * [MASSEMBLY-580] - dependencySet ignores directoryMode descriptor * [MASSEMBLY-583] - DependencySet elements appear not to be able to target the same outputDirectory * [MASSEMBLY-597] - Duplicate files added to archive when present in both dependencyset and fileset of the same assembly * [MASSEMBLY-601] - http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html seems to have the components of a filter element in the wrong order * [MASSEMBLY-609] - Misbehavior on multi-module projects, outputDirectory not being interpolated properly * [MASSEMBLY-655] - Archive file resolution does not work as documented * [MASSEMBLY-671] - Cryptic debug warning message needs improvement and/or documentation * [MASSEMBLY-725] - Fix phase ordering * [MASSEMBLY-726] - Fix artifact inclusion/exclusion filtering * [MASSEMBLY-728] - Assembly plugin = 2.5 thinks my group ID is too big * [MASSEMBLY-729] - lineEnding ignored when file is not filtered * [MASSEMBLY-730] - jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE * [MASSEMBLY-731] - Assembly plugin bundles symlinks as emtpy folders when directoryMode is set on fileset * [MASSEMBLY-732] - baseDirectory is ignored with files entries * [MASSEMBLY-733] - Plugin no longer prepends final name when packaging files specified using 'files/file' elements. ** Improvement * [MASSEMBLY-702] - Add default values for directoryMode / fileMode * [MASSEMBLY-708] - predefined descriptors lack of permission definition for unix (directoryMode/fileMode) Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [LOGO] site with Fluido skin and owl logo
On Wed, Nov 26, 2014 at 08:25:56AM +, Stephen Connolly wrote: [snip] I also think we should remove the side-bars (and perhaps switch to a top bar menu) as they hinder mobile accessibility. Aha! This may explain why, at the very moment that 16:9 monitors are becoming ubiquitous, websites are all being redesigned as a skinny rivulet of text down the center of a broad snowfield. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature
Bug? maven-ear-plugin 2.9.1 behaves different to 2.9
Hi! I'm using the maven-ear-plugin to create an EAR with a skinny WAR. This worked fine till I did an update from version 2.9 to version 2.9.1. The actual problem is quite hard to explain, so I'll try and start with an abstract and provide details below. The problem is, the skinny WAR contains a lot more JARs than it should, but not all that are in the original WAR artifact. So it seems the m-ear-p does build a skinny WAR but the decisions what JARs to pack into the WAR are wrong. Changing the used m-ear-p back to version 2.9 fixes the problem, so this is definitely a regression in v2.9.1. The really strange thing is, this does not happen always! It only happens when I build my project the first time a day and a recent version of dependency of the project was not locally installed but was obtained from our local nexus. So it seems version information (or timestamps as all versions are SNAPSHOTs) of the dependencies matters. A concrete example to make this more clear: * My Project E is the EAR. * E depends on an artifact W, a WAR. * E and W have a common dependency D which is also a project of mine. * E, W and D are all built by a CI-server (jenkins) and SNAPSHOTs are deployed to nexus during the night. In the WAR there is D.jar packaged in WEB-INF/lib. In the EAR there is D.jar packaged in lib/ and the skinny WAR should no longer contain D.jar. With m-ear-p 2.9 this worked as expected. With version 2.9.1 when I build E with mvn clean install and D was not locally installed earlier this day, the skinny WAR is not skinny. It contains D.jar! Thus, D.jar is located twice in the EAR which is a bug. As soon as I do a mvn clean install for D, the building of E starts to work and the WAR is skinny again... till a nightly deploy provides a newer SNAPSHOT of D. Any ideas what could be wrong here? I'd be happy to provide a sample project but I'm not sure how to provide this as it also seems to depend on the infrastructure. TIA, - martin PS: I reported a (maybe) related issue half a year ago without any feedback. Not sure if this could provide some extra info: http://maven.40175.n5.nabble.com/bug-in-maven-ear-plugin-with-skinny-war-td5792646.html signature.asc Description: PGP signature
Re: Maven use for integration
Ok, I might give that a try Thank you for your help Ron Alejandro Endo | Software Designer/Concepteur de logiciels From: Ron Wheeler rwhee...@artifact-software.com To: users@maven.apache.org, Date: 2014-11-25 09:39 PM Subject:Re: Maven use for integration On 25/11/2014 4:26 PM, alejandro.e...@grassvalley.com wrote: No, not a zip. I just need the bundles to be in the file system so that when the server packaging starts, they get packaged. The job of the integrator is just to download the artifacts from nexus and leave them in the filesystem of the server's image. The fact that i want to use the info in the poms to minimize maintenance of the integration list is kind of orthogonal, i could do everything just with wget, but i would need a list of every single bundle to download. Maybe a bit of description of how building the server work will make it clearer. We download all the bundles from nexus (this is the part I do with maven), compile kernel drivers unrelated to the bundles, prepare OS configuration scripts, etc etc and then the whole system is packaged into an image that gets deployed to the client. This packaging into an image has nothing to do with maven, only the artifact download is done by maven at the server creation job (and not even for all the artifacts, just for OSGi bundle artifacts) And yes, you're right that for non-osgi artifacts this wouldn't work due to the classloader, so I definitely understand the default behaviour of maven, but this is in an OSGi context. Is there any way to bypass this core behaviour? a system property, flag?? it is very convenient to do integrations with maven due to the rich info in the poms. But obviously, the pom data could be used outside of maven so maybe what I'm missing is a different tool altogether. Another option would be a maven-plugin that creates its own dependency graph and doesn't rely on the one provided by maven core, which supports only a single version of a given artifact (at least that's what it looks like) Yes. that is what I was suggesting or build something that uses the core bits of Maven that you need. Ron Alejandro Endo | Software Designer/Concepteur de logiciels From: Ron Wheeler rwhee...@artifact-software.com To: users@maven.apache.org, Date: 2014-11-25 03:07 PM Subject:Re: Maven use for integration It is still a bit unclear about what you will end up with if your idea works. Are you just hoping to get a zip file of OSGi artifacts that you can unzip to deploy? Multiple versions of non-OSGi artifacts will not work since the classloader will only load the first version that it finds. On 25/11/2014 1:45 PM, alejandro.e...@grassvalley.com wrote: Hi Ron, #1. I don't understand your question. You mean the poms of the artifacts deployed in nexus? they each have their own pom and instructions on how to build itself, just like a regular maven artifact So I have an artifact A that gets deployed to nexus with groupId foo.bar and artifactId A and version 1.0 and then six months later A gets updated to version 2.0 All this has nothing to do with integration Now the integration job will say, bring all the artifacts and their dependencies to be able to run. One of them will be A 1.0. Once a 2.0 is released, i don't want to integrate ONLY 2.0. I want to integrate 1.0 and 2.0. So in my integration pom i have two dependencies, one foo.bar:A:1.0 and another dependency foo.bar:A:2.0. This is were maven core complains and ends up resolving one over the other, hence when i do a copy-dependencies it only ends up integrating one of them So the 2 versions of A are on a list that you manually maintain in an integration file. Could you not keep that outside a pom and just get each version from the repo and use the pom of foo.bar:A:1.0 and foo.bar:A:2.0 to get their respective dependencies to build a list of the other artifacts. As long as you are talking about OSGi, you are OK. #2. Yes, I am. The problem is that via the nexus API there's no way to have a list of ONLY entry points where i can say explicitly in a list (that i'm trying to keep as small as possible) integrate A and that would imply B and C if A depends on B and C. When I do it with maven, in my integration pom I only declare a dependency on A and the dependency plugin will copy transitive dependencies. This allows me to keep the manually maintained list as small as possible and never forgetting to update it when i introduce new dependencies since those new dependencies will be pulled by the dependency plugin just because the POM already contains the relationship information So once you have resolved the dependencies, you can get the Artifacts and repeat the resolution using these new dependencies eliminating duplicates if you find any. I hope everything is clearer now, let me know You can use the Maven code to build the dependency resolution but
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Mojo Appassembler Maven Plugin Version 1.9 Released
Hi, The Mojo team is pleased to announce the release of the Appassembler Maven Plugin version 1.9. The Application Assembler Plugin is a Maven plugin for generating scripts for starting java applications. All dependencies and the artifact of the project itself are placed in a generated Maven repository in a defined assemble directory. All artifacts (dependencies + the artifact from the project) are added to the classpath in the generated bin scripts. http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId version1.9/version /plugin Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11780version=20608 Bug: * [MAPPASM-238] - wrapperLogFile Improvements: * [MAPPASM-239] - Update version of plexus-archiver to 2.5 * [MAPPASM-240] - Update version of plexus-archiver to 2.6.3 * [MAPPASM-241] - Upgrade plexus-utils to 3.0.20 * [MAPPASM-242] - Upgrade to plexus-archiver 2.7.1 * [MAPPASM-243] - Upgrade plexus-interpolation to 1.21 * [MAPPASM-244] - Upgrade to mojo parent version 34 * [MAPPASM-246] - Use maven-dependency-plugin version which is defined by the parent. * [MAPPASM-247] - Upgrade maven-filtering to 1.3 * [MAPPASM-248] - Wrapper script fails on Solaris / SunOS 5.2 when the LC_TYPE is set to a non-single byte locale Task: * [MAPPASM-236] - Removing plexus-container-default dependency Enjoy, The Mojo team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [LOGO] site with Fluido skin and owl logo
On 26 November 2014 at 18:55, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I also think we should remove the side-bars (and perhaps switch to a top bar menu) as they hinder mobile accessibility. I think the total number of people using a mobile phone to visit the maven website would be zero. I think the left side bars is useful, but too cluttered. The right side bar is also useful because it has all the related links but takes up a lot of room. At the moment the focus is on a new user, which most people are once in their Maven experience. We should make it easy for the new user to find the landing page for download and the new user tour, and then redesign the front page for the most common purpose of using Maven. The develop Maven page should be pushed onto another landing page too. This would allow the use of larger, more readable fonts as well as there is less clutter. I'm no web design guru, but all the online courses I've been reading over the last 6 months have had the Maven site redesign in mind.
Re: Bug? maven-ear-plugin 2.9.1 behaves different to 2.9
Hi Martin, first can you create a project which reproduces the problem...otherwise it's really hard to drill down the issue... Furthermore have you defined the dependencies in your ear module which should be skinnyfied... Does you ear module contain other dependencies which could have the jars you don't like to have in your ear as a transitive dependency? Can you post your pom file ? On 11/26/14 3:31 PM, Martin Hoeller wrote: Hi! I'm using the maven-ear-plugin to create an EAR with a skinny WAR. This worked fine till I did an update from version 2.9 to version 2.9.1. The actual problem is quite hard to explain, so I'll try and start with an abstract and provide details below. The problem is, the skinny WAR contains a lot more JARs than it should, but not all that are in the original WAR artifact. So it seems the m-ear-p does build a skinny WAR but the decisions what JARs to pack into the WAR are wrong. Changing the used m-ear-p back to version 2.9 fixes the problem, so this is definitely a regression in v2.9.1. The really strange thing is, this does not happen always! It only happens when I build my project the first time a day and a recent version of dependency of the project was not locally installed but was obtained from our local nexus. So it seems version information (or timestamps as all versions are SNAPSHOTs) of the dependencies matters. A concrete example to make this more clear: * My Project E is the EAR. * E depends on an artifact W, a WAR. * E and W have a common dependency D which is also a project of mine. * E, W and D are all built by a CI-server (jenkins) and SNAPSHOTs are deployed to nexus during the night. In the WAR there is D.jar packaged in WEB-INF/lib. In the EAR there is D.jar packaged in lib/ and the skinny WAR should no longer contain D.jar. With m-ear-p 2.9 this worked as expected. With version 2.9.1 when I build E with mvn clean install and D was not locally installed earlier this day, the skinny WAR is not skinny. It contains D.jar! Thus, D.jar is located twice in the EAR which is a bug. That sound really strange cause maven-ear-plugin itself does not download artifacts...but we should try to drill down the problem... As soon as I do a mvn clean install for D, the building of E starts to work and the WAR is skinny again... till a nightly deploy provides a newer SNAPSHOT of D. Any ideas what could be wrong here? I'd be happy to provide a sample project but I'm not sure how to provide this as it also seems to depend on the infrastructure. Hm...you say on one side it's a bug of maven-ear-plugin but here you say different... ?... TIA, - martin PS: I reported a (maybe) related issue half a year ago without any feedback. Not sure if this could provide some extra info: http://maven.40175.n5.nabble.com/bug-in-maven-ear-plugin-with-skinny-war-td5792646.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Mojo Appassembler Maven Plugin Version 1.9 Released
Thanks Karl Dont think you can get rid of plexus-container-default easily :-) It still shows up as transitive dependency [1] due to the need from maven-2.2.1 -D [1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/dependencies.html On Wed, Nov 26, 2014 at 11:21 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, The Mojo team is pleased to announce the release of the Appassembler Maven Plugin version 1.9. The Application Assembler Plugin is a Maven plugin for generating scripts for starting java applications. All dependencies and the artifact of the project itself are placed in a generated Maven repository in a defined assemble directory. All artifacts (dependencies + the artifact from the project) are added to the classpath in the generated bin scripts. http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId version1.9/version /plugin Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11780version=20608 Bug: * [MAPPASM-238] - wrapperLogFile Improvements: * [MAPPASM-239] - Update version of plexus-archiver to 2.5 * [MAPPASM-240] - Update version of plexus-archiver to 2.6.3 * [MAPPASM-241] - Upgrade plexus-utils to 3.0.20 * [MAPPASM-242] - Upgrade to plexus-archiver 2.7.1 * [MAPPASM-243] - Upgrade plexus-interpolation to 1.21 * [MAPPASM-244] - Upgrade to mojo parent version 34 * [MAPPASM-246] - Use maven-dependency-plugin version which is defined by the parent. * [MAPPASM-247] - Upgrade maven-filtering to 1.3 * [MAPPASM-248] - Wrapper script fails on Solaris / SunOS 5.2 when the LC_TYPE is set to a non-single byte locale Task: * [MAPPASM-236] - Removing plexus-container-default dependency Enjoy, The Mojo team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [LOGO] site with Fluido skin and owl logo
Probably few if any will visit it to download maven on their phone. But a lot of people are reading this on their phones or tablets. And if there's a link in an email I am not going to fetch my laptop to visit it. Raphael On Wed, Nov 26, 2014, 20:33 Barrie Treloar baerr...@gmail.com wrote: On 26 November 2014 at 18:55, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I also think we should remove the side-bars (and perhaps switch to a top bar menu) as they hinder mobile accessibility. I think the total number of people using a mobile phone to visit the maven website would be zero. most common purpose of using Maven. The develop Maven page should be pushed onto another landing page too. This would allow the use of larger, more readable fonts as well as there is less clutter. I'm no web design guru, but all the online courses I've been reading over the last 6 months have had the Maven site redesign in mind.
Re: [LOGO] site with Fluido skin and owl logo
The very first thing I did when I say the link from Hervé was open it on my phone... We should make it readable when you do that ;-) On Wednesday, November 26, 2014, Raphael Ackermann raphael.ackerm...@gmail.com wrote: Probably few if any will visit it to download maven on their phone. But a lot of people are reading this on their phones or tablets. And if there's a link in an email I am not going to fetch my laptop to visit it. Raphael On Wed, Nov 26, 2014, 20:33 Barrie Treloar baerr...@gmail.com javascript:; wrote: On 26 November 2014 at 18:55, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: I also think we should remove the side-bars (and perhaps switch to a top bar menu) as they hinder mobile accessibility. I think the total number of people using a mobile phone to visit the maven website would be zero. most common purpose of using Maven. The develop Maven page should be pushed onto another landing page too. This would allow the use of larger, more readable fonts as well as there is less clutter. I'm no web design guru, but all the online courses I've been reading over the last 6 months have had the Maven site redesign in mind. -- Sent from my phone
Re: [LOGO] site with Fluido skin and owl logo
On Nov 26, 2014 2:33 PM, Barrie Treloar baerr...@gmail.com wrote: On 26 November 2014 at 18:55, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I also think we should remove the side-bars (and perhaps switch to a top bar menu) as they hinder mobile accessibility. I think the total number of people using a mobile phone to visit the maven website would be zero. At least one anyway. I, myself often read docs on my phone browser, hence a strong proponent of responsive UIs. I can also confirm that the site doesn't work very well due to layout issues on my phone. I think the left side bars is useful, but too cluttered. The right side bar is also useful because it has all the related links but takes up a lot of room. At the moment the focus is on a new user, which most people are once in their Maven experience. We should make it easy for the new user to find the landing page for download and the new user tour, and then redesign the front page for the most common purpose of using Maven. The develop Maven page should be pushed onto another landing page too. This would allow the use of larger, more readable fonts as well as there is less clutter. I'm no web design guru, but all the online courses I've been reading over the last 6 months have had the Maven site redesign in mind.
What dos it mean: [WARNING ] Skipping because it does not denote a directory
My application is working perfectly but I have been facing a lot of Warning in Spring Tool Suite like: [WARNING ] Skipping [C:\Users\e049447\.m2\repository\org\apache\httpcomponents\httpcore\4.1\httpcore-4.1.jar] because it does not denote a directory What does it mean? I can see the jars in the correct place and I can run the code which depends on httpcore normally.
Re: What dos it mean: [WARNING ] Skipping because it does not denote a directory
Am Wed, 26 Nov 2014 18:55:54 -0200 schrieb Deme Carv demec...@gmail.com: My application is working perfectly but I have been facing a lot of Warning in Spring Tool Suite like: [WARNING ] Skipping [C:\Users\e049447\.m2\repository\org\apache\httpcomponents\httpcore\4.1\httpcore-4.1.jar] because it does not denote a directory What does it mean? I can see the jars in the correct place and I can run the code which depends on httpcore normally. The path above, is it a file or a directory or not existing at all? What is Spring Tool Suite? What maven goal did you run to get this warning? What plugin was running before the line? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What dos it mean: [WARNING ] Skipping because it does not denote a directory
STS is Eclipse already loaded up with everything you need for Java development (and a lot of other things) including m2e. On 26/11/2014 4:05 PM, Bernd Eckenfels wrote: Am Wed, 26 Nov 2014 18:55:54 -0200 schrieb Deme Carv demec...@gmail.com: My application is working perfectly but I have been facing a lot of Warning in Spring Tool Suite like: [WARNING ] Skipping [C:\Users\e049447\.m2\repository\org\apache\httpcomponents\httpcore\4.1\httpcore-4.1.jar] because it does not denote a directory What does it mean? I can see the jars in the correct place and I can run the code which depends on httpcore normally. The path above, is it a file or a directory or not existing at all? What is Spring Tool Suite? What maven goal did you run to get this warning? What plugin was running before the line? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Android Maven Plugin 4.0.0 released
The Android Maven Plugin team is pleased to announce the release of version 4.0.0 of the plugin: plugin groupIdcom.simpligility.maven.plugins/groupId artifactIdandroid-maven-plugin/artifactId version4.0.0/version /plugin A celebratory blog post with some background is available at http://www.simpligility.com/2014/11/android-maven-plugin-4-0-0-ships/ -New features/bug fixes for the specific release are -Migrated some documentation from the old Google Code site -Fix for aar and jar dependency mix and related resolving -Fixes to proguard and multidex related processing -Documentation for shading commons-codec to allow usage of newer version -Custom exclude filter to ProGuardMojo -Fixes to resource files in sample projects to allow builds to pass with new SDK -Always honor dexArguments parameters -Downgraded runtime requirements to Maven 3.0.4 -Examples documentation -Moved Emma analysis to process-classes phase When upgrading please ensure to check the changelog for further details: https://github.com/simpligility/android-maven-plugin/blob/master/src/site/asciidoc/changelog.adoc We would like to thank the contributors to this release for their valuable help and invite you all to help us out as well: Specifically for this release we would like to thank the following contributors for their awesome work. Core Committers -Benoit Billington https://github.com/Shusshu -Manfred Moser http://www.simpligility.com -Malachi de AElfweald https://github.com/malachid -Johan Lindquist https://github.com/johanlindquist -William Ferguson http://github.com/william-ferguson-au Committers for this release -Manfred Moser http://www.simpligility.com -Hoyt Summers Pittman https://github.com/secondsun -Łukasz Suski https://github.com/lsuski -Matthias Stevens https://github.com/mstevens83 -Csaba Kozák https://github.com/WonderCsabo -Dmitry Berezhnoy https://github.com/deadmoto We would also like to thank for the help we received from the Maven community members and everybody else out there for any help we received in our issue tracker and beyond. All merges and release builds and a whole bunch of other changes done by Manfred Moser http://www.simpligility.com Documentation, issue tracker and more can be found on the plugin websites at https://github.com/simpligility/android-maven-plugin/ http://simpligility.github.io/android-maven-plugin/ http://code.google.com/p/maven-android-plugin/ Specifically look at our samples project, which are now located in the plugin codebase itself in /src/test/projects http://simpligility.github.io/android-maven-plugin/examples.html Please join the Maven Android Mailing List for relevant discussions: https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers Enjoy and congratulations to everyone involved. Manfred Moser http://www.simpligility.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
