Strange plugin dependency problem
Hi, I am currently confronted with a strange problem. I am trying to get a Maven project using AspectJ Compile Time Weaving in IntelliJ. The source code level is set to 1.7 and uses some 1.7 language features. The aspectjtools-1.6.11 which is used by the aspectj-maven-plugin per default can't deal with this, therefore we changed the aspectjtools version to 1.7.1. The build is building nicely using maven. The pom fragments look like this: pluginManagement plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId version1.4/version dependencies dependency groupIdorg.aspectj/groupId artifactIdaspectjrt/artifactId version1.7.1/version /dependency dependency groupIdorg.aspectj/groupId artifactIdaspectjtools/artifactId version1.7.1/version /dependency /dependencies configuration avoidFinaltrue/avoidFinal Xlintignore/Xlint complianceLevel1.7/complianceLevel showWeaveInfotrue/showWeaveInfo source1.7/source target1.7/target encodingISO-8859-1/encoding aspectLibraries aspectLibrary groupIdcom.acme/groupId artifactIdmyaspects/artifactId /aspectLibrary /aspectLibraries /configuration /plugin /plugins /pluginManagement and: profile idaspectj-weaving/id activation activeByDefaultfalse/activeByDefault /activation build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId executions execution goals goalcompile/goal /goals /execution /executions /plugin /plugins /build /profile When importing the project to IntelliJ the compiler is automatically set to ajc but the compiler from 1.6.1 is detected and used automatically and I have to manually change this to 1.7.1 (and repeat this now and then after updating the Maven settings). When issueing the following command on the commandline: mvn -P aspectj-weaving dependency:resolve-plugins I can see: [INFO] Plugin Resolved: aspectj-maven-plugin-1.4.jar [INFO] Plugin Dependency Resolved: plexus-utils-2.0.5.jar [INFO] Plugin Dependency Resolved: maven-artifact-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-model-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-project-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-reporting-api-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-plugin-api-2.2.0.jar [INFO] Plugin Dependency Resolved: doxia-site-renderer-1.1.2.jar [INFO] Plugin Dependency Resolved: maven-reporting-impl-2.1.jar [INFO] Plugin Dependency Resolved: aspectjtools-1.6.11.jar There is no mention of a 1.7.1 version ... why and how can I configure Maven to display the 1.7.1 version (I think this is the reason why IntelliJ is automatically detecting 1.7.1 Chris
Re: Maven proxy problem in ubuntu 12.04
if you are typing an url on central, wget is blocked, so that won't work as a diagnostic On 13 February 2013 00:39, Richard Vowles rich...@bluetrainsoftware.comwrote: Take one of those URLs and type wget http://... See if that works On Feb 13, 2013 1:14 PM, dzungdev dzung...@gmail.com wrote: Dear Hanasaki, I would like to say thanks for your detail explanation. I saw that you put the host is: firewall.domain.com but how I can get the information of username/password for it ? Actually I tried to get information of proxy via firefox by go to Edit -- Preference -- Advanced -- Network -- Settings but I saw that the current option is: use System proxy. Then I tried to check my ubuntu 12.04 to see proxy information but when I go to System setting -- network setting -- Proxy, the use mode is None. Thanks and best regards, Dzung -- View this message in context: http://maven.40175.n5.nabble.com/Maven-proxy-problem-in-ubuntu-12-04-tp5746764p5746837.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Assembly plugin - Java 7 classes are missing in the final JAR file
Dear All, I want to inlude one small dependency library together with my JAR file. There is an assembly plugin for this and it works fine. But now my primary project is coded in Java 7 syntax. Netbeans IDE adds a special settings (source/target) for maven-compiler-plugin in my POM file. I don't know if this is the reason, but when this project is built using assembly:single, there is only the content of external libraries in my file, not my Java 7 classes of the primary project. Is it necessary to switch something else on? Thanks, Jan plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.4/version configuration archive manifest mainClass... my main class .../mainClass /manifest /archive descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.4/version configuration source1.7/source target1.7/target /configuration /plugin
Re: Assembly plugin - Java 7 classes are missing in the final JAR file
are you doing a clean build? do you have Compile on safe turned on or off? are the classes in question in target/classes after the build? are they part of the original jar produced by the jar plugin? in general the source/target value in compiler plugin should not have any influence over other plugins. So the reason is probably someplace else. Milos Kleint On Wed, Feb 13, 2013 at 10:49 AM, j.tosov...@email.cz wrote: Dear All, I want to inlude one small dependency library together with my JAR file. There is an assembly plugin for this and it works fine. But now my primary project is coded in Java 7 syntax. Netbeans IDE adds a special settings (source/target) for maven-compiler-plugin in my POM file. I don't know if this is the reason, but when this project is built using assembly:single, there is only the content of external libraries in my file, not my Java 7 classes of the primary project. Is it necessary to switch something else on? Thanks, Jan plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.4/version configuration archive manifest mainClass... my main class .../mainClass /manifest /archive descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.4/version configuration source1.7/source target1.7/target /configuration /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need substitue jar for jsp-api
http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jsp-api%22 /Anders On Wed, Feb 13, 2013 at 8:04 AM, aparti atulpa...@in.com wrote: I have a pom.xmljavax.servletjsp-apiI am looking for Oracle/Sun substitute jar for it.Any help will be appriciated.Regards -- View this message in context: http://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Need substitue jar for jsp-api
try this one as substitute: http://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-jsp-api/ 2013/2/13 aparti atulpa...@in.com: I have a pom.xmljavax.servletjsp-apiI am looking for Oracle/Sun substitute jar for it.Any help will be appriciated.Regards -- View this message in context: http://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853.html Sent from the Maven - Users mailing list archive at Nabble.com. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Assembly plugin - Java 7 classes are missing in the final JAR file
When the Clean build is made, the resulted jar contains all the classes except these from external dependencies. When assemly:single goal is used, I am getting the opposite - only external classes, not primary ones. But in this case there is a suspicious Warning in the log: [assembly:single] Cannot include project artifact: in.drifted.documentation:xmlmodifier:jar: 1.0; it doesn't have an associated file or directory. I googled for similar messages, but it is still not clear how to fix it. It could be related to my problem... -- Původní zpráva -- Od: Milos Kleint mkle...@gmail.com Datum: 13. 2. 2013 Předmět: Re: Assembly plugin - Java 7 classes are missing in the final JAR file are you doing a clean build? do you have Compile on safe turned on or off? are the classes in question in target/classes after the build? are they part of the original jar produced by the jar plugin? in general the source/target value in compiler plugin should not have any influence over other plugins. So the reason is probably someplace else. Milos Kleint On Wed, Feb 13, 2013 at 10:49 AM, j.tosov...@email.cz wrote: Dear All, I want to inlude one small dependency library together with my JAR file. There is an assembly plugin for this and it works fine. But now my primary project is coded in Java 7 syntax. Netbeans IDE adds a special settings (source/target) for maven-compiler-plugin in my POM file. I don't know if this is the reason, but when this project is built using assembly:single, there is only the content of external libraries in my file, not my Java 7 classes of the primary project. Is it necessary to switch something else on? Thanks, Jan plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.4/version configuration archive manifest mainClass... my main class .../mainClass /manifest /archive descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.4/version configuration source1.7/source target1.7/target /configuration /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need substitue jar for jsp-api
Thanks but I am looking for Jar from ORacle or Sun -- View this message in context: http://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853p5746865.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need substitue jar for jsp-api
Not really a Maven question but... I am not sure why Oracle or Sun would make one of these since they have nothing to do with jsp. It is part of the servlet container specification and would be provided by the container project. Apache Tomcat, Jetty, Glassfish,... Here is another one that looks like it was done as part of the Jetty project: dependency groupIdorg.mortbay.jetty/groupId artifactIdservlet-api-3.0/artifactId version7.0.0pre2/version /dependency What container(s) are you targeting? Ron On 13/02/2013 6:13 AM, aparti wrote: Thanks but I am looking for Jar from ORacle or Sun -- View this message in context: http://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853p5746865.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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
Re: Need substitue jar for jsp-api
In any case, the api should be scopeprovided/scope unless *you are building a servlet container*. Given that the servlet and jsp api's are a standard, it should not matter *which* one you choose. I tend to favour the geronimo spec jars though figuring pout the exact one can be tricky and their version numbering is a tad strange. You really just need to know what servlet specification you are targeting as the minimum that your application will run on and pull in any corresponding API with scope=provided On 13 February 2013 13:00, Ron Wheeler rwhee...@artifact-software.comwrote: Not really a Maven question but... I am not sure why Oracle or Sun would make one of these since they have nothing to do with jsp. It is part of the servlet container specification and would be provided by the container project. Apache Tomcat, Jetty, Glassfish,... Here is another one that looks like it was done as part of the Jetty project: dependency groupIdorg.mortbay.jetty/**groupId artifactIdservlet-api-3.0/**artifactId version7.0.0pre2/version /dependency What container(s) are you targeting? Ron On 13/02/2013 6:13 AM, aparti wrote: Thanks but I am looking for Jar from ORacle or Sun -- View this message in context: http://maven.40175.n5.nabble.** com/Need-substitue-jar-for-**jsp-api-tp5746853p5746865.htmlhttp://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853p5746865.html Sent from the Maven - Users mailing list archive at Nabble.com. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-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-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need substitue jar for jsp-api
Servlet 3.1 Not in final form yet. http://jcp.org/en/jsr/detail?id=340 Servlet 3.0 dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-servlet_3.0_spec/artifactId version1.0/version scopeprovided/scope /dependency Servlet 2.5 dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-servlet_2.5_spec/artifactId version1.2/version scopeprovided/scope /dependency Anything before Servlet 2.5 Seriously? Well there should be a servlet 2.4 jar in central under the javax.servlet On 13 February 2013 13:57, Stephen Connolly stephen.alan.conno...@gmail.com wrote: In any case, the api should be scopeprovided/scope unless *you are building a servlet container*. Given that the servlet and jsp api's are a standard, it should not matter *which* one you choose. I tend to favour the geronimo spec jars though figuring pout the exact one can be tricky and their version numbering is a tad strange. You really just need to know what servlet specification you are targeting as the minimum that your application will run on and pull in any corresponding API with scope=provided On 13 February 2013 13:00, Ron Wheeler rwhee...@artifact-software.comwrote: Not really a Maven question but... I am not sure why Oracle or Sun would make one of these since they have nothing to do with jsp. It is part of the servlet container specification and would be provided by the container project. Apache Tomcat, Jetty, Glassfish,... Here is another one that looks like it was done as part of the Jetty project: dependency groupIdorg.mortbay.jetty/**groupId artifactIdservlet-api-3.0/**artifactId version7.0.0pre2/version /dependency What container(s) are you targeting? Ron On 13/02/2013 6:13 AM, aparti wrote: Thanks but I am looking for Jar from ORacle or Sun -- View this message in context: http://maven.40175.n5.nabble.** com/Need-substitue-jar-for-**jsp-api-tp5746853p5746865.htmlhttp://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853p5746865.html Sent from the Maven - Users mailing list archive at Nabble.com. --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-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-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
property expansion in pom.xml of archetype
Hi,
I created my first archetype. In archetype-metadata.xml I specified
requiredProperties
requiredProperty key=mylib.version /
/requiredProperties
When creating a project I want ${mylib.version} in the prototype pom.xml
to be expanded to the specified value:
parent
artifactIdmycore/artifactId
groupIdorg.mycore/groupId
version${mylib.version}/version
/parent
On the command line I see the correct value but it is not used for
pom.xml. Just ${artifactId}, ${groupId} and ${version} seem to get expanded.
How can I achieve this without releasing a new archetype with every
version of mylib?
regards,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency resolution kicks in too early
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
third-party dependency which is not yet available on Maven Central. We
are working with the developer of the library to fix this, but until
this is the case, we need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then
treat them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution in the validate phase
to bootstrap jars that were not available on Maven Central as
suggested in [1]. I needed to do the same thing again today but
noticed that this approach does not seem to work any more with Maven
3. Right after running Maven, dependency resolution kicks in making
the build fail even before the install plugin gets a chance to
install the missing dependency. Here's what I'm doing:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
executions
execution
idboostrap-some-depencency/id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/groupId
artifactIdsome-artifact/artifactId
version${some.artifact.version}/version
packagingjar/packaging
filebootstrap-lib/some-artifact-${some.artifact.version}.jar/file
sourcesbootstrap-lib/some-artifact-${some.artifact.version}-sources.jar/sources
/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/groupId
artifactIdsome-artifact/artifactId
version${some.artifact.version}/version
/dependency
...
properties
some.artifact.version1.2.3/some.artifact.version
/properties
[1]
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over
using a system dependency.
Thanks,
Reinhard
-
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: Dependency resolution kicks in too early
deploy it to your own groupId
On 13 February 2013 14:54, Reinhard Nägele reinhard.naeg...@mgm-tp.comwrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a third-party
dependency which is not yet available on Maven Central. We are working with
the developer of the library to fix this, but until this is the case, we
need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then treat
them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution in the validate phase to
bootstrap jars that were not available on Maven Central as suggested in
[1]. I needed to do the same thing again today but noticed that this
approach does not seem to work any more with Maven 3. Right after running
Maven, dependency resolution kicks in making the build fail even before the
install plugin gets a chance to install the missing dependency. Here's what
I'm doing:
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
execution
idboostrap-some-depencency/**id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file
sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties
[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over using a
system dependency.
Thanks,
Reinhard
--**--**
-
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Assembly plugin - Java 7 classes are missing in the final JAR file
[assembly:single] Cannot include project artifact: in.drifted.documentation:xmlmodifier:jar: 1.0; it doesn't have an associated file or directory. Is this project the one which is currently being built, or a dependency, or a parent, or what? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency resolution kicks in too early
deploy it to your own groupId
Isn't it better if he uses the original groupId and artifactId, but adds a
qualifier to the version indicating that it's their release? Like if he
would have patched an official release.
/Anders
On 13 February 2013 14:54, Reinhard Nägele reinhard.naeg...@mgm-tp.com
wrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a third-party
dependency which is not yet available on Maven Central. We are working
with
the developer of the library to fix this, but until this is the case, we
need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then treat
them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution in the validate phase
to
bootstrap jars that were not available on Maven Central as suggested in
[1]. I needed to do the same thing again today but noticed that this
approach does not seem to work any more with Maven 3. Right after
running
Maven, dependency resolution kicks in making the build fail even
before the
install plugin gets a chance to install the missing dependency. Here's
what
I'm doing:
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
execution
idboostrap-some-depencency/**id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file
sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties
[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over using
a
system dependency.
Thanks,
Reinhard
--**--**
-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency resolution kicks in too early
On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:
deploy it to your own groupId
Isn't it better if he uses the original groupId and artifactId, but adds a
qualifier to the version indicating that it's their release?
Well... the chain you have to go when deploying something into central
under a groupId that you do not own is something like:
1. Show that you have engaged the owning project and that they are not
pushing a version
2. Show blah blah blah
3.
4.
5. Ok, create the bundle and upload it
And given that he said the owning project is working on uploading to
central, he's going to fail on step 1... so if it is urgent the lesser evil
is his own groupId...
That said it would be best to keep the groupId it will end up with.
Like if he
would have patched an official release.
/Anders
On 13 February 2013 14:54, Reinhard Nägele reinhard.naeg...@mgm-tp.com
wrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
third-party
dependency which is not yet available on Maven Central. We are working
with
the developer of the library to fix this, but until this is the case,
we
need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then
treat
them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution in the validate phase
to
bootstrap jars that were not available on Maven Central as suggested
in
[1]. I needed to do the same thing again today but noticed that this
approach does not seem to work any more with Maven 3. Right after
running
Maven, dependency resolution kicks in making the build fail even
before the
install plugin gets a chance to install the missing dependency.
Here's
what
I'm doing:
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
execution
idboostrap-some-depencency/**id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file
sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties
[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over
using
a
system dependency.
Thanks,
Reinhard
--**--**
-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency resolution kicks in too early
Right, I was thinking they would deploy it to their Nexus instance where
they deploy their own oss product.
Having the same jar in two different groupIds in central only confuses
people and causes problems I think. We should try to avoid that.
/Anders
On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:
deploy it to your own groupId
Isn't it better if he uses the original groupId and artifactId, but adds
a
qualifier to the version indicating that it's their release?
Well... the chain you have to go when deploying something into central
under a groupId that you do not own is something like:
1. Show that you have engaged the owning project and that they are not
pushing a version
2. Show blah blah blah
3.
4.
5. Ok, create the bundle and upload it
And given that he said the owning project is working on uploading to
central, he's going to fail on step 1... so if it is urgent the lesser evil
is his own groupId...
That said it would be best to keep the groupId it will end up with.
Like if he
would have patched an official release.
/Anders
On 13 February 2013 14:54, Reinhard Nägele
reinhard.naeg...@mgm-tp.com
wrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
third-party
dependency which is not yet available on Maven Central. We are
working
with
the developer of the library to fix this, but until this is the case,
we
need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then
treat
them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution in the validate
phase
to
bootstrap jars that were not available on Maven Central as
suggested
in
[1]. I needed to do the same thing again today but noticed that
this
approach does not seem to work any more with Maven 3. Right after
running
Maven, dependency resolution kicks in making the build fail even
before the
install plugin gets a chance to install the missing dependency.
Here's
what
I'm doing:
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
execution
idboostrap-some-depencency/**id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file
sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties
[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over
using
a
system dependency.
Thanks,
Reinhard
--**--**
-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is the functionality of the all attribute of the RequireActiveProfile rule commented out?
Ok, I'll have a look, but I'm not the only one who's noticed: http://jira.codehaus.org/browse/MENFORCER-143 -- View this message in context: http://maven.40175.n5.nabble.com/Why-is-the-functionality-of-the-all-attribute-of-the-RequireActiveProfile-rule-commented-out-tp5746380p5746901.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need substitue jar for jsp-api
Thanks For the replyWe are targetting Weblogic -- View this message in context: http://maven.40175.n5.nabble.com/Need-substitue-jar-for-jsp-api-tp5746853p5746903.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: Assembly plugin - Java 7 classes are missing in the final JAR file
Yes, this is the project currently being built. It is Maven based Desktop app dependend on the common library. My procedure: 1) Clean and Build of common library 2) assembly:single of my Desktop app Clean and build of my Desktop app before assembly:single doesn't help. I have almost the same POM file used for another project (no Java 7) and there is no similar warning using the same procedure as described above. It was the main reason why I initially suspected incompatibility in this area. If anybody interested, I can share my code. It is quite simple. Jan -- Původní zpráva -- Od: Wayne Fay wayne...@gmail.com Datum: 13. 2. 2013 Předmět: Re: Re: Assembly plugin - Java 7 classes are missing in the final JAR file [assembly:single] Cannot include project artifact: in.drifted.documentation:xmlmodifier:jar: 1.0; it doesn't have an associated file or directory. Is this project the one which is currently being built, or a dependency, or a parent, or what? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is the functionality of the all attribute of the RequireActiveProfile rule commented out?
Ok, I found the change: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireActiveProfile.java?r1=594911r2=595611diff_format=h It was done by Brian Fox, whom I've copied on this post. Hopefully, he'll shed some light on the subject. -- View this message in context: http://maven.40175.n5.nabble.com/Why-is-the-functionality-of-the-all-attribute-of-the-RequireActiveProfile-rule-commented-out-tp5746380p5746905.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: Assembly plugin - Java 7 classes are missing in the final JAR file
I will bet it works if you type mvn clean package assembly:single On 13 February 2013 15:49, j.tosov...@email.cz wrote: Yes, this is the project currently being built. It is Maven based Desktop app dependend on the common library. My procedure: 1) Clean and Build of common library 2) assembly:single of my Desktop app Clean and build of my Desktop app before assembly:single doesn't help. I have almost the same POM file used for another project (no Java 7) and there is no similar warning using the same procedure as described above. It was the main reason why I initially suspected incompatibility in this area. If anybody interested, I can share my code. It is quite simple. Jan -- Původní zpráva -- Od: Wayne Fay wayne...@gmail.com Datum: 13. 2. 2013 Předmět: Re: Re: Assembly plugin - Java 7 classes are missing in the final JAR file [assembly:single] Cannot include project artifact: in.drifted.documentation:xmlmodifier:jar: 1.0; it doesn't have an associated file or directory. Is this project the one which is currently being built, or a dependency, or a parent, or what? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency resolution kicks in too early
Yes, I agree, but I have had to do it myself some times... in more radical
cases this has evolved into a complete fork for me (e.g. redmine-java-api)
On 13 February 2013 15:33, Anders Hammar and...@hammar.net wrote:
Right, I was thinking they would deploy it to their Nexus instance where
they deploy their own oss product.
Having the same jar in two different groupIds in central only confuses
people and causes problems I think. We should try to avoid that.
/Anders
On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:
deploy it to your own groupId
Isn't it better if he uses the original groupId and artifactId, but
adds
a
qualifier to the version indicating that it's their release?
Well... the chain you have to go when deploying something into central
under a groupId that you do not own is something like:
1. Show that you have engaged the owning project and that they are not
pushing a version
2. Show blah blah blah
3.
4.
5. Ok, create the bundle and upload it
And given that he said the owning project is working on uploading to
central, he's going to fail on step 1... so if it is urgent the lesser
evil
is his own groupId...
That said it would be best to keep the groupId it will end up with.
Like if he
would have patched an official release.
/Anders
On 13 February 2013 14:54, Reinhard Nägele
reinhard.naeg...@mgm-tp.com
wrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
third-party
dependency which is not yet available on Maven Central. We are
working
with
the developer of the library to fix this, but until this is the
case,
we
need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then
treat
them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution in the validate
phase
to
bootstrap jars that were not available on Maven Central as
suggested
in
[1]. I needed to do the same thing again today but noticed that
this
approach does not seem to work any more with Maven 3. Right after
running
Maven, dependency resolution kicks in making the build fail even
before the
install plugin gets a chance to install the missing dependency.
Here's
what
I'm doing:
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
execution
idboostrap-some-depencency/**id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file
sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties
[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over
using
a
system dependency.
Thanks,
Reinhard
--**--**
-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is the functionality of the all attribute of the RequireActiveProfile rule commented out?
Ok, I found the change: ... It was done by Brian Fox, whom I've copied on this post. Hopefully, he'll shed some light on the subject. Yes, I found that and was going to reply back with it but you beat me to it: http://svn.apache.org/viewvc?view=revisionrevision=595611 Based on the commit comment and the other files in the same commit, it seems to me that either: a) the removal of all was unintentional and simply came in with some other changes so it could be fixed easily or b) all was removed and replaced with another enforcer rule, so you just need to specify some additional configuration. Did you look at the rest of the commit changes to see if B is possible? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Way to limit the projects in the reactor of a maven build started with the invoker plugin
The AbstractInvokerMojo#runBuild() [1] is responsible for constructing the request, but there's no option to specify the projectlist. Could be an improvement. Robert http://maven.apache.org/plugins/maven-invoker-plugin/xref/org/apache/maven/plugin/invoker/AbstractInvokerMojo.html#1593 Op Wed, 13 Feb 2013 21:40:02 +0100 schreef christofer.d...@c-ware.de christofer.d...@c-ware.de: Hi, I'm currently trying to use the invoker plugin to start a maven build and to pass the list of projects that should be in the reactor of that build. Unfortunately I couldn't find a way to do so ... so is there a way and if not, how could I start a second maven build from a maven build? Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Way to limit the projects in the reactor of a maven build started with the invoker plugin
I have a method which will summarily be poked at... but it works for the one team that uses it here... They put the [modules] section in profiles... and set a profile to determine which set of modules are included. In general the advice you will get is to never have a profile make a difference in the binaries being built... but it is kind of handy if its an internal project that is well documented. Thanks, Roy Lyons Senior Configuration Engineer On 2/13/13 2:40 PM, christofer.d...@c-ware.de christofer.d...@c-ware.de wrote: Hi, I'm currently trying to use the invoker plugin to start a maven build and to pass the list of projects that should be in the reactor of that build. Unfortunately I couldn't find a way to do so ... so is there a way and if not, how could I start a second maven build from a maven build? Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Generate java source code from existing and circular references
Hi, I like to write a maven plug-in that allow me to generate source java code using reflection. I mean: using reflection Ibrowse some java classes in src/main/java and generate new one (in target/generated...). To read with reflection source classes I think the plug-in must activate after the compile phase i.e. process-classes. But it can be that some others classes in src/main/java depends on generated classes.These won't compile. Any help with this workflow? Modules? Usinga java source code parser ? More projects? Is somethink like jpa enhancer but maded on source code! Thanks in advance for any help! -- *Davide Montesin* - Java - Android - HTML5 - XML - JSON - Open source - Software Project Management - Agile - Bolzano - Bozen - Alto Adige - Südtirol - Italy E-mail : d...@vide.bz mailto:d...@vide.bz Website: www.davide.bz http://www.davide.bz My java projects: source-to-reflection http://www.davide.bz/2-en-source-to-reflection.html: Java Fast High Performance Reflection For J2SE J2EE Android GWT Open Source Project object-xmljson http://www.davide.bz/3-en-object-xmljson.html: Java Fast High Performance XML JSON Converter Mapping Binding J2SE J2EE Android GWT No Annotation Open Source Project seo-friendly-ria-web http://www.davide.bz/4-en-seo-friendly-ria-web.html: Java SEO Friendly RIA HTML5 Open Source Project
AW: Way to limit the projects in the reactor of a maven build started with the invoker plugin
Thanks for your responses. Even if your profile solution should work, I guess the maintenance effort would be enormous (The project I should implement my release tool for has about 80 independent Artifacts, so I would end up with 80+ profiles). Well I guess I'll simply start by taking the current release Plugin as a basis and simply whip up a patched one, as I have to admit I'm completely fed-up with all the problems I am having with the ones available. I know that You don't do sub-releases in Maven but in my case I am working my ass off to satisfy my customer and I simply want this finished. So if the default stuff doesn't do it, I'll make it do it ... perhaps I should call it the pandoras-box-release-plugin or something like that ;-) So I'm finally giving up using standard stuff ... from now I'll go the custom path. Hopefully that will lead me out of this release jungle soon ;-) Chris -Ursprüngliche Nachricht- Von: Lyons, Roy [mailto:roy.ly...@cmegroup.com] Gesendet: Mittwoch, 13. Februar 2013 23:16 An: Maven Users List Betreff: Re: Way to limit the projects in the reactor of a maven build started with the invoker plugin I have a method which will summarily be poked at... but it works for the one team that uses it here... They put the [modules] section in profiles... and set a profile to determine which set of modules are included. In general the advice you will get is to never have a profile make a difference in the binaries being built... but it is kind of handy if its an internal project that is well documented. Thanks, Roy Lyons Senior Configuration Engineer On 2/13/13 2:40 PM, christofer.d...@c-ware.de christofer.d...@c-ware.de wrote: Hi, I'm currently trying to use the invoker plugin to start a maven build and to pass the list of projects that should be in the reactor of that build. Unfortunately I couldn't find a way to do so ... so is there a way and if not, how could I start a second maven build from a maven build? Chris - 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: Generate java source code from existing and circular references
I like to write a maven plug-in that allow me to generate source java code using reflection. I mean: using reflection Perhaps check out the openjpa plugin (or another similar one) hosted by Codehaus Mojo project which produces open source Maven plugins: http://mojo.codehaus.org/plugins.html But it can be that some others classes in src/main/java depends on generated classes.These won't compile. You may or may not have to break those into their own modules which have a dependency on this one. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
