[GitHub] maven-surefire pull request: SUREFIRE [1048] Surefire does not use...
Github user Tibor17 closed the pull request at: https://github.com/apache/maven-surefire/pull/34 --- 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
[GitHub] maven-surefire pull request: Avoid invalid link ids in surefire-re...
GitHub user kermit-the-frog opened a pull request: https://github.com/apache/maven-surefire/pull/36 Avoid invalid link ids in surefire-report If you are using the Maven Surefire Report Plugin to view your jasmine test results (generated with Jasmine Maven Plugin) as HTML. The generated HTML-Pages look quite good in different browsers but the links on failed tests don't work at all. The XML containing the jasmine results has whitespace and special chars in the names of the testcases. Theses names are not allowed for HTML-Ids, so the names have to be modified before using them as ids/targets for anchors/links in the generated HTML. This is only done halfway in the current version of Maven Surefire Report Plugin. The anchors have a modified id. Because the SurefireReportGenerator.java uses sink.anchor() to generate the anchor tags. That function uses DoxiaUtils.encodeId() to encode any illegal character. But the link targets are wrong. SurefireReportGenerator.java uses it's own function toHtmlId() which does not implement the same logic as DoxiaUtils.encodeId(). Fixes included in this commit: + Call toHtmlId() everytime before using testCase.getFullName() as anchor id or link target. + Use DoxiaUtils.encodeId() in toHtmlId(), to avoid problems with any illegal char. Regards, kermit-the-frog You can merge this pull request into a Git repository by running: $ git pull https://github.com/kermit-the-frog/maven-surefire master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/36.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 #36 commit 3f5b1fb2bcebb7ae96b7ce8e747d1732b4759353 Author: kermit-the-frog Date: 2014-03-13T08:42:17Z avoid invalid link ids Call toHtmlId() everytime before using testCase.getFullName() as anchor id or link target. Use DoxiaUtils.encodeId() in toHtmlId(), to avoid problems with any illegal char. --- 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: MRELEASE-431
Hi Rob!
I honestly need to access to latest released physical artifact,
because I need to wrap a tool which is able to detect bytecode
differences between the latest released artifact and the current
ongoing "to be released", then gives an estimation on which version
number should be released.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte wrote:
> Hi Simone,
>
> for that reason I've added the Metadata, from which you can get the latest
> released artifact.
> I really hope you don't need the ArtifactResolver.
>
> Robert
>
> Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
> :
>
>
>> Hi again Robert,
>>
>> in one of my VersionPolicy implementations, I need to resolve the
>> latest release artifact - then I have a tool to compare the bytecodes
>> and automatically understand which is the release number.
>>
>> Question is: while I need an ArtifactResolver, I also need
>> ArtifactRepository for local/remotes that, inside a MOJO, would be get
>> via the code below... what are the related Plexus annotations, in
>> order to obtain the same components?
>>
>> TIA, all the best!
>> -Simo
>>
>> @Parameter(required = true, defaultValue = "${localRepository}",
>> readonly = true)
>> private ArtifactRepository localRepository;
>>
>> @Parameter(required = true, defaultValue =
>> "${project.remoteArtifactRepositories}", readonly = true)
>> private List remoteRepositories;
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte
>> wrote:
>>>
>>> Hi Simone,
>>>
>>> I still have to find a solution for the VersionParseException which can
>>> be
>>> thrown with the current implementation of DefaultVersionInfo. I probably
>>> have to add it to both methods of VersionPolicy
>>>
>>> Your custom implementation will look something like:
>>>
>>> @Component( role = VersionPolicy.class, hint = "tripodi" )
>>> public class TripodiVersionPolicy implements VersionPolicy {
>>> // your stuff
>>> }
>>>
>>> The plugin will get parameters like projectVersionPolicyId and/or
>>> dependencyVersionPolicyId.
>>> At least, that's my idea right now to split it up per type. This way
>>> implementations can stay as clean as possible.
>>>
>>> Robert
>>>
>>> Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
>>> :
>>>
>>>
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte
wrote:
> Hi Simone,
>
> I've added a new module for Maven release policies including my idea of
> how the API should look like.
> Although one of my suggestions to specify this as an implementation in
> the
> plugin configuration, I now prefer to use it as a component. Downside
> is
> that you can't use a pojo, you'll need to add Plexus annotations and
> generate the descriptor. However, now you can inject other components
> a.k.a
> requirements. Since this might become quite complicated, injection is
> probably the preferred way.
> I probably need more info in the PolicyRequest to support the current
> behavior, but this is just a start.
> This should be a good start for you too. Let me know if this will work
> with your requirements.
>
> best,
> Robert
>
> Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi <
> simonetrip...@apache.org>:
>
>
> Hi Rob! :)
>>
>>
>> indeed it has been a very long while, so sorry for that :(
>>
>> OK I understand your PoV, count on me if you want to co-operate - I
>> need
>> that feature as well in order to make the release-plugin able to
>> generate
>> that version using a tool, but without exposing such APIs that allow
>> me
>> plugging different versioning systems, I cannot do it :)
>>
>> Many thanks in advance and have a nice weekend!
>> All the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte > >wrote:
>>
>> Hi Simone,
>>>
>>>
>>>
>>> It's been a while, so I'll need to have another look at this.
>>> At first glance I'm not yet happy with the suggested API.
>>> I'd need to make some time so come with a final solution.
>>>
>>> Robert
>>>
>>> Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi <
>>> simonetrip...@apache.org>:
>>>
>>>
>>> Hi all mates,
>>>
Re: MRELEASE-431
Hi again Robert,
sorry for bugging - I hope I don't :P - but I notice Metadata also has
a very limited subset of informations about the ongoing released
artifact.
IMHO informations such us packaging and classifier should be part of
that data set - maybe I am wrong and work around that?
TIA, All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte wrote:
> Hi Simone,
>
> for that reason I've added the Metadata, from which you can get the latest
> released artifact.
> I really hope you don't need the ArtifactResolver.
>
> Robert
>
> Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
> :
>
>
>> Hi again Robert,
>>
>> in one of my VersionPolicy implementations, I need to resolve the
>> latest release artifact - then I have a tool to compare the bytecodes
>> and automatically understand which is the release number.
>>
>> Question is: while I need an ArtifactResolver, I also need
>> ArtifactRepository for local/remotes that, inside a MOJO, would be get
>> via the code below... what are the related Plexus annotations, in
>> order to obtain the same components?
>>
>> TIA, all the best!
>> -Simo
>>
>> @Parameter(required = true, defaultValue = "${localRepository}",
>> readonly = true)
>> private ArtifactRepository localRepository;
>>
>> @Parameter(required = true, defaultValue =
>> "${project.remoteArtifactRepositories}", readonly = true)
>> private List remoteRepositories;
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte
>> wrote:
>>>
>>> Hi Simone,
>>>
>>> I still have to find a solution for the VersionParseException which can
>>> be
>>> thrown with the current implementation of DefaultVersionInfo. I probably
>>> have to add it to both methods of VersionPolicy
>>>
>>> Your custom implementation will look something like:
>>>
>>> @Component( role = VersionPolicy.class, hint = "tripodi" )
>>> public class TripodiVersionPolicy implements VersionPolicy {
>>> // your stuff
>>> }
>>>
>>> The plugin will get parameters like projectVersionPolicyId and/or
>>> dependencyVersionPolicyId.
>>> At least, that's my idea right now to split it up per type. This way
>>> implementations can stay as clean as possible.
>>>
>>> Robert
>>>
>>> Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
>>> :
>>>
>>>
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte
wrote:
> Hi Simone,
>
> I've added a new module for Maven release policies including my idea of
> how the API should look like.
> Although one of my suggestions to specify this as an implementation in
> the
> plugin configuration, I now prefer to use it as a component. Downside
> is
> that you can't use a pojo, you'll need to add Plexus annotations and
> generate the descriptor. However, now you can inject other components
> a.k.a
> requirements. Since this might become quite complicated, injection is
> probably the preferred way.
> I probably need more info in the PolicyRequest to support the current
> behavior, but this is just a start.
> This should be a good start for you too. Let me know if this will work
> with your requirements.
>
> best,
> Robert
>
> Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi <
> simonetrip...@apache.org>:
>
>
> Hi Rob! :)
>>
>>
>> indeed it has been a very long while, so sorry for that :(
>>
>> OK I understand your PoV, count on me if you want to co-operate - I
>> need
>> that feature as well in order to make the release-plugin able to
>> generate
>> that version using a tool, but without exposing such APIs that allow
>> me
>> plugging different versioning systems, I cannot do it :)
>>
>> Many thanks in advance and have a nice weekend!
>> All the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte > >wrote:
>>
>> Hi Simone,
>>>
>>>
>>>
>>> It's been a while, so I'll need to have another look at this.
>>> At first glance I'm not yet happy with the suggested API.
>>> I'd need to make some time so come with a final solution.
>>>
>>> Robert
>>>
>>> Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi <
>>> simonetrip...@apache.org>:
>>>
>>>
>>> Hi all mates,
>>>
I am in a phase where
Re: MRELEASE-431
To say it in your own words: IMHO I think you're wrong here ;)
Version policy is about calculating the next version based on an input
version.
These are valid examples:
default policy:
getReleaseVersion("1-SNAPSHOT") = 1
getReleaseVersion("1.0-SNAPSHOT") = 1.0
getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0
getDevelopmentVersion("1") = 2-SNAPSHOT
getDevelopmentVersion("1.0") = 1.1-SNAPSHOT
getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT
odd-even
getReleaseVersion("1.0-SNAPSHOT") = 1.1
getDevelopmentVersion("1.1") = 1.2-SNAPSHOT
the metadata gives the following opportunity:
suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 ->
3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT
I think it's weird to depend the policy on the GAV. Just choose a proper
policy for your project.
I also think that the ArtifactResolver is not required here.
It's like instead of passing a string-based version, you'd like to pass an
artifact and extract it's version.
My idea is the other way around: extract the version from the artifact
first and pass that to the policy.
I would expect it to be the version in the pom.xml. If you want to check
it, use an enforcer rule or something like that.
We should try to keep the task of this class as simple as possible.
Robert
Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi
:
Hi again Robert,
sorry for bugging - I hope I don't :P - but I notice Metadata also has
a very limited subset of informations about the ongoing released
artifact.
IMHO informations such us packaging and classifier should be part of
that data set - maybe I am wrong and work around that?
TIA, All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte
wrote:
Hi Simone,
for that reason I've added the Metadata, from which you can get the
latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = "${localRepository}",
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
"${project.remoteArtifactRepositories}", readonly = true)
private List remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte
wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which
can
be
thrown with the current implementation of DefaultVersionInfo. I
probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = "tripodi" )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for
putting
effort on that!
I maybe missed something but I didn't notice how they are integrated
in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte
wrote:
Hi Simone,
I've added a new module for Maven release policies including my
idea of
how the API should look like.
Although one of my suggestions to specify this as an implementation
in
the
plugin configuration, I now prefer to use it as a component.
Downside
is
that you can't use a pojo, you'll need to add Plexus annotations and
generate the descriptor. However, now you can inject other
components
a.k.a
requirements. Since this might become quite complicated, injection
is
probably the preferred way.
I probably need more info in the PolicyRequest to support the
current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will
work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi <
simonetrip...@apache.org>:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you wan
[ANN] Apache Maven Checkstyle Plugin 2.12 Released
The Maven team is pleased to announce the release of the Apache Maven Checkstyle Plugin, version 2.12 Generates a report on violations of code style and optionally fails the build if violations are detected. http://maven.apache.org/plugins/maven-checkstyle-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-checkstyle-plugin 2.12 Release Notes - Apache Maven Checkstyle Plugin - Version 2.12 Task * [MCHECKSTYLE-222] Resource-only project is not checked * [MCHECKSTYLE-221] ResourceIncludes default value is wrong * [MCHECKSTYLE-219] When no license is specified, ALv2 from maven-checkstyle-plugin is used * [MCHECKSTYLE-218] Put file anchor directly on the h2 tag * [MCHECKSTYLE-213] Upgrade Doxia dependencies * [MCHECKSTYLE-212] Upgrade to Checkstyle 5.7 * [MCHECKSTYLE-211] allow inline configuration for checkstyle plugin * [MCHECKSTYLE-210] Resource bundles have wrong file encoding * [MCHECKSTYLE-209] Correct grammar, make icons and text consistent in the report * [MCHECKSTYLE-208] Plugin generates reports incompatible with the 'maven-jxr-plugin' version 2.4 * [MCHECKSTYLE-207] file handle leak - leading to failed builds * [MCHECKSTYLE-205] NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression * [MCHECKSTYLE-190] Add user property for checkstyle:consoleOutput * [MCHECKSTYLE-182] Use Maven log levels when logging to console * [MCHECKSTYLE-169] Suppressions property is incorrectly set if suppressions file is on classpath Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.17
+1 (non-binding) tested with several small projects (including multi-module) and jacoco-master all with JDK7 and Maven 3.2.1 Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Wed, Mar 12, 2014 at 10:52 PM, Andreas Gudian wrote: > Hi, > > long ago since we released the last Surefire version. It's about time we > change that ;-). > > We solved 16 issues: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=19536 > > There are still lots of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1012 > https://repository.apache.org/content/repositories/maven-1012/org/apache/maven/plugins/maven-surefire-plugin/2.17/maven-surefire-plugin-2.17-sources.jar > https://repository.apache.org/content/repositories/maven-1012/org/apache/maven/plugins/maven-failsafe-plugin/2.17/maven-failsafe-plugin-2.17-sources.jar > Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag > surefire-2.17_vote-1 > > Staging site: > http://maven.apache.org/surefire-archives/surefire-2.17/maven-surefire-plugin/index.html > http://maven.apache.org/surefire-archives/surefire-2.17/maven-failsafe-plugin/index.html > http://maven.apache.org/surefire-archives/surefire-2.17/maven-surefire-report-plugin/index.html > > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.17
+1 Tested on few projects. Thanks! Olivier On 13 March 2014 08:52, Andreas Gudian wrote: > Hi, > > long ago since we released the last Surefire version. It's about time we > change that ;-). > > We solved 16 issues: > > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=19536 > > There are still lots of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1012 > > https://repository.apache.org/content/repositories/maven-1012/org/apache/maven/plugins/maven-surefire-plugin/2.17/maven-surefire-plugin-2.17-sources.jar > > https://repository.apache.org/content/repositories/maven-1012/org/apache/maven/plugins/maven-failsafe-plugin/2.17/maven-failsafe-plugin-2.17-sources.jar > Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag > surefire-2.17_vote-1 > > Staging site: > > http://maven.apache.org/surefire-archives/surefire-2.17/maven-surefire-plugin/index.html > > http://maven.apache.org/surefire-archives/surefire-2.17/maven-failsafe-plugin/index.html > > http://maven.apache.org/surefire-archives/surefire-2.17/maven-surefire-report-plugin/index.html > > > 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 Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy
How to import a Maven jar file as library to a Non-Maven project
Hello, I'm developing an Android Application (Non-Maven) and I'd like to use a Maven Project as library. Is this possible? How to import a Maven jar file as library to a Non-Maven project? original-MavenOBD-0.0.1-SNAPSHOT.jar Thanks, BR *André Camargo AgapitoCel: 55 (11) 90309-1221 <55%20%2811%29%2090309-1221>São Paulo/spagapito.an...@gmail.com *
Using Maven Project (JAR) as library for non-Maven Android project
Hello, I'm developing an Android Application (Non-Maven) and I'd like to use a Maven Project as library. Is this possible? How to import a Maven jar file as library to a Non-Maven project? original-MavenOBD-0.0.1-SNAPSHOT.jar Thanks, BR *André Camargo AgapitoCel: 55 (11) 90309-1221São Paulo/spagapito.an...@gmail.com *
RE: Using Maven Project (JAR) as library for non-Maven Android project
I would suggest implementing your Android Application with maven-android-plugin https://code.google.com/p/maven-android-plugin/ Obrigado! Martín __ > Date: Thu, 13 Mar 2014 20:31:10 -0300 > Subject: Using Maven Project (JAR) as library for non-Maven Android project > From: agapito.an...@gmail.com > To: dev@maven.apache.org > > Hello, > I'm developing an Android Application (Non-Maven) and I'd like to use a > Maven Project as library. Is this possible? How to import a Maven jar file > as library to a Non-Maven project? > > original-MavenOBD-0.0.1-SNAPSHOT.jar > > Thanks, > BR > > > > > *André Camargo AgapitoCel: 55 (11) 90309-1221São > Paulo/spagapito.an...@gmail.com *
Re: Using Maven Project (JAR) as library for non-Maven Android project
Agreed ;-) You will need to build your Android app somehow. And either way.. you can use the jar no matter how it was built. Maven or not. Manually manaing the jar will be more painful than using Maven... or Gradle if you want to use that (but then you should ask for more help elsewhere ;-) manfred Martin Gainty wrote on 13.03.2014 18:03: > I would suggest implementing your Android Application with > maven-android-plugin > https://code.google.com/p/maven-android-plugin/ > > > > Obrigado! > Martín > __ > > > > > > >> Date: Thu, 13 Mar 2014 20:31:10 -0300 >> Subject: Using Maven Project (JAR) as library for non-Maven Android project >> From: agapito.an...@gmail.com >> To: dev@maven.apache.org >> >> Hello, >> I'm developing an Android Application (Non-Maven) and I'd like to use a >> Maven Project as library. Is this possible? How to import a Maven jar file >> as library to a Non-Maven project? >> >> original-MavenOBD-0.0.1-SNAPSHOT.jar >> >> Thanks, >> BR >> >> >> >> >> *André Camargo AgapitoCel: 55 (11) 90309-1221São >> Paulo/spagapito.an...@gmail.com * > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
