Hi all,
We have recently created an Archetype for all our developers to use, but
we ran into an issue today...
The project that is being created, should always use the latest version
of our company's parent-POM. The thing here, is that I want to have the
archetype-plugin insert this version
On Mon, Jul 23, 2012 at 12:16 AM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
I'm shade transforming Apache Solr, which has several dependencies and
seems to work.
However the internal class strings are being transformed, eg
'System.getProperty(os.name);' where 'os.name' is being
I don't think that there's any mechanism in place except to release a
new archetype for each new parent version.
If you make a patch to add a feature to the archetype plugin I'll look at it.
-
To unsubscribe, e-mail:
Hi Benson, This is the xml for the transform:
http://pastebin.com/9nx18WiN
Thanks!
On Mon, Jul 23, 2012 at 10:21 AM, Benson Margulies bimargul...@gmail.comwrote:
On Mon, Jul 23, 2012 at 12:16 AM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
I'm shade transforming Apache Solr, which
I don't think that there's any mechanism in place except to release a
new archetype for each new parent version.
If you make a patch to add a feature to the archetype plugin I'll look at it.
Perhaps a simple invocation of the versions-m-p:update-parent after
archetype is done building the new
I was just looking into that plugin... Seems to do what I want, so I'll
probably stick with that.
Thanks for the info, both of you!
On 23.07.2012 16:48, Wayne Fay wrote:
I don't think that there's any mechanism in place except to release a
new archetype for each new parent version.
If you
Hello users,
I have the following problem:
- One system must be compiled with two different JDK.
- I have two test suites, one for smoke test, one for all.
Base scenario:
- Two profiles, 'SmokeTest' activate by default, 'All' activate by
switch -P.
- One additional profile with
If those tests should always run, why have them in a profile??
On 23.07.2012 17:26, Andreas Riedel wrote:
Hello users,
I have the following problem:
- One system must be compiled with two different JDK.
- I have two test suites, one for smoke test, one for all.
Base scenario:
-
Any idea what would be the best way to realize this?
Find a way to simplify things. You're doing too much stuff in one
module. Break it into 2 and maybe more.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
It sounds like you have 2 artifacts at the end.
One that is compiled and built with 1.5 and will run under 1.5 JVM and
probably under 1.6 JVM
One that is compiled and built with 1.6 and will not run under 1.5 JVM.
It seems that these are 2 different artifacts and should have different
Hmm.
You don't have a pattern element, so shade is going hog-wild. I
appreciate that you're asking a specific question about controlling
its behavior for string constants, but is it possible that you could
come up with a pattern that wouldn't hit things like 'os.name'?
On Mon, Jul 23, 2012
For this uber jar, the goal is for it to go hog wild and relocate
everything except what is in the exclude(s). It seems like a bug that
non-classnames such as string constants are also being sent to the
relocator. Given every string literal is being relocated, I can't imagine
a pattern to
everything except what is in the exclude(s). It seems like a bug that
non-classnames such as string constants are also being sent to the
relocator. Given every string literal is being relocated, I can't imagine
a pattern to exclude those.
How should Shade handle code like
On Mon, Jul 23, 2012 at 12:50 PM, Wayne Fay wayne...@gmail.com wrote:
everything except what is in the exclude(s). It seems like a bug that
non-classnames such as string constants are also being sent to the
relocator. Given every string literal is being relocated, I can't imagine
a pattern
Wayne, I agree with your point, however I think the include / exclude it
may make sense for them to accept a type such as include
type=literaljava.lang.Thread/include. This gives better fine grained
control of what is being relocated.
On Mon, Jul 23, 2012 at 12:50 PM, Wayne Fay
Hi all,
Is there a java7 - maven comparability problem with error details/xlint?
Compile error details vanished when I updated to use java7.
I'm wondering if something related to encoding or structure that's causing
the problem. I'm using a tiny quickstart project to explore the problem.
With
Cannot be classifiers, as he needs different dependencies.
May also want to use tool chains rather than hard coding Jdk paths
On Monday, 23 July 2012, Ron Wheeler wrote:
It sounds like you have 2 artifacts at the end.
One that is compiled and built with 1.5 and will run under 1.5 JVM and
Is there a java7 - maven comparability problem with error details/xlint?
Compile error details vanished when I updated to use java7.
Yes, its a known bug:
http://jira.codehaus.org/browse/MCOMPILER-158
Wayne
-
To
On 2012-07-11 11:42, Oleg Estekhin wrote:
Hi,
I am trying to solve the mystery behind
http://code.google.com/p/maven-svn-revision-number-plugin/issues/detail?id=16
with the help of the reporter of the original issue and the developer of
SqlJet library.
So far we have found that at some
Hi,
I am using Maven 3.0.4 along with Jython 2.5.2 and Pygments 1.5 (via an
egg). I have configured the jython-compile-maven-plugin as,
plugin
groupIdnet.sf.mavenjython/groupId
artifactIdjython-compile-maven-plugin/artifactId
version1.2/version
executions
execution
phasepackage/phase
20 matches
Mail list logo