Re: Imports of required classes have classname only without package path within the class compiled by maven
As announced, here a little summary about the experiences with the WebeSphere developer tools for eclipse 4. Positive: It works! Eclipse generates a valid build, as well as does maven! and even debugging is possible. Negative: The marketplace seems to have a problem. At least I was unable to install those WAS-plugins from the marketplace. It required to download the zip and install the app from the local zip. Trying to search for updates neither works. Apparently the url does not point to a site from which updates could be downloaded or versions verified. I had some trouble with xml files validation during an eternity. On pointing to local schema.xsd or disabling validation the problem could be solved so far. I observed helper files from the build being copied into the war and jar files. I.e. org.codehaus.plexus.compiler.javac.JavacCompiler*arguments and javac.bat. This is new and should not be the case, though these files don’t hurt! Question: With this new installation I got 2 new Warnings for which I have not found the way to eliminate them: The Maven standard project settings are not set for the workspace. The target runtime server dependencies should be declared in the POM file. Any hint is welcome. From: brandenber...@commcity.ch To: Maven Users List users@maven.apache.org Date: 06.11.2013 15:32 Subject:Re: Imports of required classes have classname only without package path within the class compiled by maven Exactly those you sent me the URL. I haven't seen yet. Hopefully they work with WAS 8.5.5.0! As far as I know, 8.5.5.1 shall be available on November 11 only! I just searched for an update with the Installation Manager, but nothing seams to be available. I'll try in any case now. Thanks for the hint. From: Anders Hammar and...@hammar.net To: Maven Users List users@maven.apache.org Date: 06.11.2013 15:17 Subject:Re: Imports of required classes have classname only without package path within the class compiled by maven Sent by:anders.g.ham...@gmail.com What WAS plugin for Eclipse are you talking about. The ones in Eclipse marketplace should work with Kepler SR1 (v4.3.1) according to the info there [1] [2]. They were just recently updated (Nov 1). [1] https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-developer-tools-eclipse-4x [2] https://marketplace.eclipse.org/content/ibm-websphere-application-server-v855-liberty-profile-developer-tools-eclipse-4x /Anders On Wed, Nov 6, 2013 at 3:06 PM, brandenber...@commcity.ch wrote: The outcome of the announced tests are: On working with eclipse Kepler, not having any WAS-Plugin installed the classes compiled by maven, either started from command line or through m2e-wtp are correct, the resulting ear can be deployed on the WebSphere App-Server and runs without error! I hope, I must not emphases, absolutely no changes have been applied to the checked out modules. Hence, the problem within the june installation is not due to any odd configuration of maven. This means, I can deploy valid ear's to the nexus maven repository! This are the good news! But the situation is not satisfying, as within eclipse-Kepler I can not debug through a server plugin, and within eclipse-June, I can not deploy any maven build! If you tell me now, this is not a maven issue, I admit you may be right! But my question, what the heck is going on behind the scene is still open and must be allowed. Could this be a WAS-Plugin issue? You being closer to maven maybe can answer this question! From: brandenber...@commcity.ch To: Maven Users List users@maven.apache.org Date: 06.11.2013 09:34 Subject:Re: Imports of required classes have classname only without package path within the class compiled by maven Hi, this is much better. Based on my actual knowledge, yes I believe it must have a relation with the Juno Version of eclipse, but I don't know how and why. The differences between the two flavors of project are minimal and due to the differences of App-Server and Databases used. If Java would have conditional compilation the differences could be handled much easier by this. For instance the server and jsf-implementation related differences requires to have two web.xml files, checked out from separated branches of svn. Or the login / logout methods within one class differs slightly due to the different implementations of the servers, etc. I hardly believe those differences being the cause of the troubles. Fact is: The outcome of the maven compilation is the same for both cases. Either started from the command line or started within the juno IDE. I'm actually checking out the project into an entirely new kepler SP1 workplace, from where I'll try a build from the command line. I'll tell you the outcome. I'll try this before I installing m2e-wtp. Hence, I'll just use subclipse to checkout the project
RE: AW: AW: AW: mvn release:prepare does not update parent version
Robert, no need to teach me about completeness of reports -- I am in the reverse situation day by day as you can imagine. The problem was that I had the problem since I migrated to Maven 3 from day one with even the smallest possible POM (it looked 'obvious' to me) and did not have the idea there might be a fix already already which is not contained in Maven 3 so far. In fact this is why I would love to have the ability to use version ranges in plugin dependencies! ;-) Anyways, as all is fixed now, thanks for the kind help! :-) -Markus -Original Message- From: Robert Scholte [mailto:rfscho...@apache.org] Sent: Freitag, 8. November 2013 18:52 To: Maven Users List Subject: Re: AW: AW: AW: mvn release:prepare does not update parent version Op Fri, 08 Nov 2013 16:30:30 +0100 schreef Markus Karg k...@quipsy.de: I wonder why someone fixed it but didn't close https://jira.codehaus.org/browse/MRELEASE-837...! Well, is was probably already fixed for a long time. Since you only had a description it will take some time to fix it, since it must first be reproducible. That's why attaching a sample project helps, and a patch with a possible fix even more. In this case it was the log-file which triggered me: first update the version of the plugin and see if it has been already been fixed. It is all about being as complete as possible :) Robert - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: AW: AW: AW: mvn release:prepare does not update parent version
From: k...@quipsy.de
To: users@maven.apache.org
Date: Fri, 8 Nov 2013 16:30:30 +0100
Subject: AW: AW: AW: mvn release:prepare does not update parent version
Martin,
thank you for your explanations, but as it turned out the problem is fixed
simply by using version 2.4.2 of the release plugin. I wonder why someone
fixed it but didn't close
https://jira.codehaus.org/browse/MRELEASE-837...!
MGmaven-release-plugin is one of most frequently used plugins used from maven
MGthere are at least 1000+ installations out there still using the 2.1.x
maven-release-plugin
MG1000 installations out there still using 2.2.x maven-release-plugin
MGslightly less than 1000 installations out there using 2.3.x
maven-release-management
MGmany of these installations are secure and disallow autoUpdate from http
URLs for plugins
MGWhy? ...change ${maven.plugin.version} to 2.4.2 and watch the fireworks!
MGthe justification for breaking thru firewall instead of using own nexus
repository is tenuous
MGbut ..secure sites will allow 'point patches'
MG3 items need to be completed:
MG1)fix the doc to say in 2.4.2 parent version will be updated from
development-version
MGThis will get the legalities of What we Say and What we Do in sync...
MG2)backport the 2.4.2 patch to previous 2.1.x, 2.2.x, 2.3.x point patches
specifically:
MG2a) backport 2.4.2 fix to patch 2.1.x and run testcases
MG2b) backport 2.4.2 fix to patch 2.2.x and run testcases
MG2c) backport 2.4.2 fix to patch 2.3.x and run testcases
MG3)once the patch is in place and accepted by all ...close 837!
MGProcess violation was the culprit here ..(Agile Project Champions and
Stakeholders have been alerted!)
Thanks for all
-Markus
MGyou are welcome
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: AW: AW: mvn release:prepare does not update parent version
You may want to upgrade maven itself once more. It is not just maven itself but the combination of plugins that are used and your environment matters. Ensure that each maven goal you plan on using in your environment actually works in your environment before you need it for real. Maven has to work with your vcs, your artifact mgmt (nexus/artifactory/other), your network security policies, etc. all at the same time. When we began upgrading existing projects from mvn-2.0.9 we had to also upgrade numerous plugins. It took some effort to find the combination of plugins/configuration that allowed us to do 'mvn deploy' successfully with mvn-3.0.4. But 'mvn release' did not work in our environment until mvn-3.0.5 was released!!. Underlying plugin(s) had changed. Regards, Gord On Sat, Nov 9, 2013 at 4:55 AM, Markus Karg k...@quipsy.de wrote: Robert, no need to teach me about completeness of reports -- I am in the reverse situation day by day as you can imagine. The problem was that I had the problem since I migrated to Maven 3 from day one with even the smallest possible POM (it looked 'obvious' to me) and did not have the idea there might be a fix already already which is not contained in Maven 3 so far. In fact this is why I would love to have the ability to use version ranges in plugin dependencies! ;-) Anyways, as all is fixed now, thanks for the kind help! :-) -Markus -Original Message- From: Robert Scholte [mailto:rfscho...@apache.org] Sent: Freitag, 8. November 2013 18:52 To: Maven Users List Subject: Re: AW: AW: AW: mvn release:prepare does not update parent version Op Fri, 08 Nov 2013 16:30:30 +0100 schreef Markus Karg k...@quipsy.de: I wonder why someone fixed it but didn't close https://jira.codehaus.org/browse/MRELEASE-837...! Well, is was probably already fixed for a long time. Since you only had a description it will take some time to fix it, since it must first be reproducible. That's why attaching a sample project helps, and a patch with a possible fix even more. In this case it was the log-file which triggered me: first update the version of the plugin and see if it has been already been fixed. It is all about being as complete as possible :) Robert - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Best Regards, Gord Cody Release Manager Zafin Labs Americas Inc. 179 Colonnade Road-Suite 100, Ottawa ON, Canada Phone: +1 (613) 216-2504 Fax: +1 (613) 688-1374 Mobile: +1 613-601-2734 Web: http://zafin.com Email: gordon.c...@zafin.com
Re: AW: AW: AW: mvn release:prepare does not update parent version
I'm pretty sure that by far most projects are released with 2.0, since
this has been the default for Apache Maven for many releases. IIRC this
has been updated for Maven 3.0.3, so if you don't specify the version, 2.0
will be used.
Now let's review this thread:
1. Markus describes his issue
2. Maximiliano asks the most important question (2 thumbs up!)
3. However, Markus answers this with 2.4.2, but in the end this was a
wrong assumption. It was actually 2.0.
Only with the evidence attached to MRELEASE-837 it was easy for me help.
Mark, don't feel bad, because this is by far the most common mistake for
the maven-release-plugin: assuming you're using the latest and greatest (
Maven2 used to pick that one up, right? ) but still relying on a very old
version.
There were enough issues which could be closed by just updating the
version.
@MG I'm a bit lost by your comments
1. Which docs are you talking about?
2. What are you trying to do here? If this is about trying to figure out
where it was actually fixed, Markus should try to release his project with
the versions between 2.0 and 2.4.2, where my guess is 2.4 due to a
complete rewrite of this code as part of MRELEASE-511.
Anyhow, I'm not going to apply a specific patch to older releases.
3. See previous bullet.
What do you mean with the fireworks? The only issues I've seen with the
2.4.x releases were GIT related or credentials related. A reference to a
JIRA issue would help.
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-511
Op Sat, 09 Nov 2013 14:17:57 +0100 schreef Martin Gainty
mgai...@hotmail.com:
From: k...@quipsy.de
To: users@maven.apache.org
Date: Fri, 8 Nov 2013 16:30:30 +0100
Subject: AW: AW: AW: mvn release:prepare does not update parent version
Martin,
thank you for your explanations, but as it turned out the problem is
fixed simply by using version 2.4.2 of the release plugin. I wonder why
someone fixed it but didn't close
https://jira.codehaus.org/browse/MRELEASE-837...!
MGmaven-release-plugin is one of most frequently used plugins used from
maven
MGthere are at least 1000+ installations out there still using the
2.1.x maven-release-plugin
MG1000 installations out there still using 2.2.x maven-release-plugin
MGslightly less than 1000 installations out there using 2.3.x
maven-release-management
MGmany of these installations are secure and disallow autoUpdate
from http URLs for plugins
MGWhy? ...change ${maven.plugin.version} to 2.4.2 and watch the
fireworks!
MGthe justification for breaking thru firewall instead of using own
nexus repository is tenuous
MGbut ..secure sites will allow 'point patches'
MG3 items need to be completed:
MG1)fix the doc to say in 2.4.2 parent version will be updated from
development-version
MGThis will get the legalities of What we Say and What we Do in
sync...
MG2)backport the 2.4.2 patch to previous 2.1.x, 2.2.x, 2.3.x point
patches specifically:
MG2a) backport 2.4.2 fix to patch 2.1.x and run testcases
MG2b) backport 2.4.2 fix to patch 2.2.x and run testcases
MG2c) backport 2.4.2 fix to patch 2.3.x and run testcases
MG3)once the patch is in place and accepted by all ...close 837!
MGProcess violation was the culprit here ..(Agile Project Champions and
Stakeholders have been alerted!)
Thanks for all
-Markus
MGyou are welcome
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Android Maven Plugin 3.8.0 released
The Android Maven Plugin team is pleased to announce the release of version 3.8.0 of the plugin. This release marks a change in the plugin since we now require Apache Maven 3.1.1 (or higher). New features/bug fixes are - Migrated to require Apache Maven 3.1.1 or higher - Updated to builder library 0.6.3 - Fix for har file access in MakefileHelper? - Maven 3.1.1 deployment as part of travis build - Usage of SDK constants instead of hardcoding classes.jar - Create R file for AARs - Support --incremental on dex - Further improvements towards support for aar consumption (still not fully working) When upgrading please ensure to check the change log for further details: http://code.google.com/p/maven-android-plugin/wiki/Changelog 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. Benoit Billington https://github.com/Shusshu Jaime Soriano Pastor https://github.com/jsoriano Manfred Moser http://www.simpligility.com Johan Lindquist https://github.com/johanlindquist Mykola Nikishov https://manandbytes.wordpress.com/ Documentation, issue tracker and more can be found on the plugin website at http://code.google.com/p/maven-android-plugin/ For a primer to use the plugin check out the Android Development chapter in Maven: The Complete Reference http://www.sonatype.com/books/mvnref-book/reference/android-dev.html And checkout the plugin documentation at http://jayway.github.io/maven-android-plugin/ Please join the Maven Android Mailing List for relevant discussions: https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers Enjoy 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
RE: AW: AW: AW: mvn release:prepare does not update parent version
Date: Sat, 9 Nov 2013 08:31:21 -0500
Subject: Re: AW: AW: AW: mvn release:prepare does not update parent version
From: gordon.c...@zafin.com
To: users@maven.apache.org
You may want to upgrade maven itself once more. It is not just maven itself
but the combination of plugins that are used and your environment matters.
Ensure that each maven goal you plan on using in your environment actually
works in your environment before you need it for real. Maven has to work
with your vcs,
MGdev .. svn but in prod.. git was used
your artifact mgmt (nexus/artifactory/other),
MGours was nexus but I can see configuration deltas biting the release manager
your network security policies,
MGwe could download point releases
MGmega updates from http sites located outside the firewall were and are a
no-no
MGand could get you in hot water real quick in a 'secure' environment (such as
a bank)
etc. all at the same time.
When we began upgrading existing projects from mvn-2.0.9 we had to also
upgrade numerous plugins. It took some effort to find the combination of
plugins/configuration that allowed us to do 'mvn deploy' successfully with
mvn-3.0.4. But 'mvn release' did not work in our environment until
mvn-3.0.5 was released!!
MGAnother big delta
MGWhat are the implications for this delta to your dependency object graph?
MGfor child modules What are the implications for this delta to your object
graph?
. Underlying plugin(s) had changed.
MGExactly..What are the implications for your plugins object graph?
MGlook at this dependency from maven-release-plugin
dependency
groupIdorg.apache.maven.release/groupId
artifactIdmaven-release-manager/artifactId
version${project.version}/version
/dependency
MGnotice maven-release-plugin and maven-release-manager are inextricably
linked on same version
MGthe release-manager plugin prompts the user for version specific questions
MGmaven-release-plugin is the plugin that does the work from the questions
asked by release-manager
MGfollow up question: why the separation?
Regards, Gord
MGWell put Gordon!!!
On Sat, Nov 9, 2013 at 4:55 AM, Markus Karg k...@quipsy.de wrote:
Robert,
no need to teach me about completeness of reports -- I am in the reverse
situation day by day as you can imagine. The problem was that I had the
problem since I migrated to Maven 3 from day one with even the smallest
possible POM (it looked 'obvious' to me) and did not have the idea there
might be a fix already already which is not contained in Maven 3 so far. In
fact this is why I would love to have the ability to use version ranges in
plugin dependencies! ;-)
Anyways, as all is fixed now, thanks for the kind help! :-)
-Markus
-Original Message-
From: Robert Scholte [mailto:rfscho...@apache.org]
Sent: Freitag, 8. November 2013 18:52
To: Maven Users List
Subject: Re: AW: AW: AW: mvn release:prepare does not update parent version
Op Fri, 08 Nov 2013 16:30:30 +0100 schreef Markus Karg k...@quipsy.de:
I wonder why someone fixed it but didn't close
https://jira.codehaus.org/browse/MRELEASE-837...!
Well, is was probably already fixed for a long time. Since you only had a
description it will take some time to fix it, since it must first be
reproducible. That's why attaching a sample project helps, and a patch with
a possible fix even more.
In this case it was the log-file which triggered me: first update the
version of the plugin and see if it has been already been fixed.
It is all about being as complete as possible :)
Robert
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Best Regards, Gord Cody
Release Manager Zafin Labs Americas Inc.
179 Colonnade Road-Suite 100, Ottawa ON, Canada
Phone: +1 (613) 216-2504 Fax: +1 (613) 688-1374 Mobile: +1 613-601-2734
Web: http://zafin.com Email: gordon.c...@zafin.com
