Re: Maven assembly plugin : includeBaseDirectory not correctly used
Do you think this is feasible ? we maintain the generator, so anything is feasible if it's valid java :) one hard part is to demonstrate the code you intend to generate before hacking the generator, because hacking the generator is always hard And I didn't really get the idea yet. There is still the issue of the boolean datatype. notice the issue is in fact for any data type that is not String: interpolation requires to happen on String, and data type conversion has to to be done after interpolation which takes us to the demo before hacking the generator IMHO, we should create a little demo project with interpolation, let the code generate and hack generated code to show how interpolation support can be added Regards, Hervé Le samedi 6 décembre 2014 19:29:09 Kristian Rosenvold a écrit : I have been thinking about adding a generateSuperclasses option to modello that would actually put the generated classes in a subpackage generated and let the actual implementation be up to the client (so in this case I would implement the class org.apache.maven.plugin.assembly.model.Assembly which would extend the class org.apache.maven.plugin.assembly.model.generated.Assembly generated by modello. AssemblyXpp3Reader would instantiate org.apache.maven.plugin.assembly.model.Assembly). So I would have custom code in org.apache.maven.plugin.assembly.model.Assembly that could extend the generated code Do you think this is feasible ? There is still the issue of the boolean datatype. Changing 30 booleans to strings leads to a huge and undesirable footprint in the code. Using custom-written subclasses could solve some of this (and a few other problems of code generation too!) If we were able to make modello classes extend regular classes, I think it would be easy to make a *Xpp3Reader that supports interpolation. Is there any way we could do this ? (Maybe make a modello-client module that can contain modello base classes ?) Kristian 2014-12-06 17:11 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr: I don't think this is a good idea: in general, a modello generated model doesn't support interpolation. but you're right: something should be done in case of a model with interpolation support Regards, Hervé Le samedi 6 décembre 2014 12:28:20 Kristian Rosenvold a écrit : Reading my own suggestion: I was suggesting to change modello to always back boolean fields with strings. 2014-12-06 12:21 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com: Looking at the implications of changing all the 30+ boolean fields of the assembly plugin to String, I really start thinking what is the point of code generation. It looks to me like we should at least just globally change the backing datatype of boolean to String, and generate overloads setXXX(String stringValue), setXXX(boolean booleanValue), String getXXX() and boolean isXXX(). That should work, or not ? It's no secret I dislike code generation, but then again I have not made a commitment to love everything in our code base :) Alternately I think this would be a suitable point in time to just sever the entire modello binding and move the generated classes to src/main. Kristan 2014-12-05 21:48 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr: Robert beat me at it :) Regards, Hervé Le vendredi 5 décembre 2014 18:55:55 Robert Scholte a écrit : Hi Kristian, AFIAK this is indeed the only way to solve this. Visit http://maven.apache.org/ref/3.2.3/maven-model/maven.html and search for Boolean. You'll find elements which are actually a Boolean, but are a String for technical reasons. e.g. make it possible to interpolate them. Robert Op Fri, 05 Dec 2014 16:36:46 +0100 schreef Kristian Rosenvold kristian.rosenv...@zenior.no: You should create an issue at http://jira.codehaus.org/browse/MASSEMBLY Hervé/Others: Since the attachement made it through, I took a quick look. The problem is that the modello-generated assembly descriptor has a boolean type for this value. Since the assembly descriptor interpolation happens after the AssemblyXpp3Reader has done its job, the only solution I can think of is to change the datatype of this field to string; which would preserve the original expression long enough for the interpolator to get hold of it. Is there any other way ? (Hmm. I could interpolate the assembly descriptor as an xml string *before* feeding it to AssemblyXpp3Reader, does that make sense ?) Kristian 2014-12-05 15:46 GMT+01:00 Jean-Eric Cuendet j...@jesc.ch: Hi, It's the first time I post a bug on a maven plugin. If that's the wrong way, please let me know where to do it. I found the issue tracker but I'm unable to create new issue. My problem:
Re: maven-eclipe-plugin build failing due to Could not generate DH keypair
I removed the testcase in r1643665. If anyone wants to work on the failing test feel free to revert my commit and fix it. The implications of having all the builds red for any length of time is usually more fallout. Kristian 2014-12-07 8:30 GMT+01:00 Anders Hammar and...@hammar.net: I think we should retire it. There hasn't been a release for almost three years and there has just been very little code activity since then. Retiring it would give the community a clear (and honest) indication that we will not fix any issues in it. /Anders On Sun, Dec 7, 2014 at 1:05 AM, Barrie Treloar baerr...@gmail.com wrote: On 7 December 2014 at 10:24, Jörg Schaible joerg.schai...@gmx.de wrote: Benson Margulies wrote: Well, the only users would be either people using old versions of Eclipse, or very stubborn people trying to use it in the teeth of m2e. Or users that explicitly remove m2e from their Eclipse installation because even without it current Eclipse is quite unstable and extremely resource hungry. There was a call a while ago to retire it, but there were enough people stuck in the past and had no choice, or preferred its use that it stayed. Perhaps it's time for a new home instead? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: maven-eclipe-plugin build failing due to Could not generate DH keypair
at the bank the Sun Provider would occasionaly fubar our security installation we mitigated by switching the provider to bouncycastle Kristian...where is the testcase? Martin- Nota Bene: in maven-elcipse-plugin someone *should* correct multymodule to multimodule Date: Sun, 7 Dec 2014 13:07:05 +0100 Subject: Re: maven-eclipe-plugin build failing due to Could not generate DH keypair From: kristian.rosenv...@gmail.com To: dev@maven.apache.org I removed the testcase in r1643665. If anyone wants to work on the failing test feel free to revert my commit and fix it. The implications of having all the builds red for any length of time is usually more fallout. Kristian 2014-12-07 8:30 GMT+01:00 Anders Hammar and...@hammar.net: I think we should retire it. There hasn't been a release for almost three years and there has just been very little code activity since then. Retiring it would give the community a clear (and honest) indication that we will not fix any issues in it. /Anders On Sun, Dec 7, 2014 at 1:05 AM, Barrie Treloar baerr...@gmail.com wrote: On 7 December 2014 at 10:24, Jörg Schaible joerg.schai...@gmx.de wrote: Benson Margulies wrote: Well, the only users would be either people using old versions of Eclipse, or very stubborn people trying to use it in the teeth of m2e. Or users that explicitly remove m2e from their Eclipse installation because even without it current Eclipse is quite unstable and extremely resource hungry. There was a call a while ago to retire it, but there were enough people stuck in the past and had no choice, or preferred its use that it stayed. Perhaps it's time for a new home instead? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Integrate Maven Site reporting with maven plugin that externally create report html page.
notice given our useful discussion, I just opened
http://jira.codehaus.org/browse/MSHARED-389 and fixed it
Regards,
Hervé
Le samedi 6 décembre 2014 17:44:33 Hervé BOUTEMY a écrit :
in AbstractCloverageMojo.java,
@Parameter(defaultValue = ${basedir}/target/coverage)
protected File reportOutputDirectory;
should be replaced by
@Parameter(defaultValue = ${project.reporting.outputDirectory}/coverage)
protected File reportOutputDirectory;
to have the content generated inside the site
and
private static final String OUTPUT_NAME = indexx;
should be
private static final String OUTPUT_NAME = coverage/indexx;
to make the menu link point to the generated content.
Regards,
Hervé
Le jeudi 4 décembre 2014 08:48:25 animator a écrit :
Here is my mojo:
https://github.com/lgadawski/cloverage-maven-plugin/blob/master/src/main/j
av a/com/gadawski/maven/plugins/cloverage/goals/HtmlMojo.java
which, as U can see, extends following class:
https://github.com/lgadawski/cloverage-maven-plugin/blob/master/src/main/j
av a/com/gadawski/maven/plugins/cloverage/goals/AbstractCloverageMojo.java
While invoking #executeReport(...) it calls external clojure library that
performs instrumentation on test project and produces html report in
'${project}/coverage/index.html'. l would like link those externally
generated report to my maven site reports section..
Here is test project: https://github.com/lgadawski/test-polyglot-project
--
View this message in context:
http://maven.40175.n5.nabble.com/Integrate-Maven-Site-reporting-with-maven
- plugin-that-externally-create-report-html-page-tp5817068p5817929.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
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
Re: problem with AAR dependency
## Cross posting to Maven Dev list One solution to this would be to change the POM specification to require the type element for dependencies. That would allow Maven and MavenCentral to immediately fail POMs based upon dependencies that are missing the type element. Yes, it goes against convention over configuration, but Maven is now used by many more build types than just plain Java builds so maybe we need to consider that the convention is no longer to assume jar dependencies. I would rather require a little more configuration to ensure that builds are more deterministic. If we want to shrink the size of the POM then the new POM format is a better solution. William On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote: I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got troubles declaring an aar dependency. Here is the pom.xml declaration: dependency groupIdcom.android.support/groupId artifactIdsupport-v13/artifactId version21.0.2/version typeaar/type /dependency Just about any Maven command, even mvn dependency:tree yields: [ERROR] Failed to execute goal on project wallet: Could not resolve dependencies for project de.schildbach.wallet:wallet:apk:4.13-test: Failure to find com.android.support:support-v4:jar:21.0.2 in file:///home/aschildbach/dev/android-sdk/extras/android/m2repository was cached in the local repository, resolution will not be reattempted until the update interval of android-support has elapsed or updates are forced - [Help 1] Where does that .jar type in the error message stem from? I declared aar. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
