Because ejb type maps to jar extension
On Sunday, 4 March 2012, Markus KARG wrote:
> You are right, when adding ejb it is working! I missed the
fact
> that maven coordinates include the packaging, while the default packaging
is
> jar. The odd thing is that dependency resolution is working
> witho
properties cannot be used where they will affect the build plan.
Therefore the following xpaths are not allowed (it may appear to work,
but it will blow up in your face when you are not looking)
/project/parent/*
/project/groupId
/project/artifactId
/project/version
almost anywhere else is fair
My view is that there are places where stuff can be inferred, such as
groupId and version of children can be inferred *if and only if* the child
is always checked out with the parent (at the specified relative path)...
There are plans to tackle those cases.
There is, though a bit of a dual purpose
On 7 March 2012 20:59, Seth Call wrote:
> Bad smell eh? Ok, here's my bad smell. Version numbers. Stinkier?
> Version *numbers* in source code. More stinky than that? Version numbers
> in source code for projects that are never released to the public.
>
You are confusing two concepts:
* vers
On 15 March 2012 12:11, Joao Silva wrote:
> Hi Anders
>
> Thanks, but I already mentioned that blog post in my email.
> Do you have something to add to that post?
> Because in my opinion, that post does not offer clear cut conclusions
> regarding the inclusion of repositories in pom.xml files:
>>
Always depend on a release version
Keep in mind that the build must be reproducible, so old releases will
build with the parent that was most recent at the time they were released
mvn versions:update-parent
Is your friend
On Friday, 16 March 2012, Daivish Shah wrote:
> Hi,
>
> What if we want
On 20 March 2012 10:49, jackett_dad wrote:
> Anders,
>
> I'll look at that, then. This is in the early stages, and I'm following a
> tutorial on annotation processing, where annotations in code is used to
> generate code that the compiler will compile on a subsequent pass. If I put
> the source
Tue, Mar 20, 2012 at 7:05 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> if you are writing a plugin yourself, you can add the generated code
>> to the compile classpath from your plugin itself once out of the
>> hacking stage
>
>
> Mom
Take a step back and try and explain exactly what the problem is that you
think you are trying to solve.
I have a sneaky feeling you are trying to get functionality similar to
staging/promotion available from the good repository managers (iirc nexus
free does not, but nexus pro and artifactory cer
Iirc the latest version does, but older versions didn't (except with m3
where the older versions might also pull from reactor)
On Wednesday, 28 March 2012, Benson Margulies wrote:
> Does dependency:copy (note, not copy-dependencies) interact with the
> reactor? In a multi-module project, can a pr
d "goodness" has the ability to creep up on us during production
> builds.
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Wednesday, March 28, 2012 2:45 AM
> To: Maven Users List
> Subject: Re: There is a way
best practice is *never* to put in your pom.
best practice is to run a Maven Repository Manager (there are 3 good
ones: [in alphabetical order] archivia, artifactory, nexus)
best practice is to have those present a virtual repository that is an
aggregate of all the repositories you need.
Then i
I suspect we could add that trick to mrm-maven-plugin with a little code...
then you'd have
mvn mrm:stage-start clean deploy mrm:stage-commit
mrm:stage-start would set the altDeploymentRepository property to redirect
the deploy to mrm, and then mrm:stage-commit would push them to the root
pom's d
Profiles per-se are “ok”
Adding dependencies in a profile is not.
The problem is when do those profiles get activated, and hence when will
the dependencies get pulled in.
When people have profiles activated by the presence of a file, and then
that pom is resolved from the local repo and not from
Oh we all know what the issue is.
Hint: You don't know what a valid package name is and you don't understand
some basic concepts of Java.
Trust us, this *is* a java programming issue. This is *not* a maven issue.
On 12 April 2012 00:42, mike digioia wrote:
> Thanks
>
> I see you don't know wha
I use OpenEJB and just fire up a container per test or per test class
On 13 April 2012 16:03, Lucas Persson wrote:
> **
> Hi
>
> I am about to migrate some Ant build system to Maven and have run into the
> JUnitEE ant task. I can not really find any up to date corresponding plugin
> for Maven.
>
On 17 April 2012 05:16, Manfred Moser wrote:
> On Mon, April 16, 2012 2:13 pm, chad.da...@emc.com wrote:
> > Our build has a dependency on the JRE. In order to build our final
> > distribution artifact, we need a JRE. To me, this means that the JRE
> > should be managed as a maven artifact in n
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html
On 19 April 2012 13:33, kenito wrote:
> hello everybody,
> I want to check if my project contain snapshot dependencies exactly like in
> the release:prepare goal. This goal is bind with a phase called
> "check-dependency-sna
I often will create a "local" aggregator project which contains all the
related projects I am working on.
I don't check that "local" aggregator project into source control, and I
throw it away when I am done with that and ready to move onto something
else.
If you go with tis route, then the only
On 24 April 2012 03:02, Andrew Hughes wrote:
> OK, I found a way to confirm...
>
> are always active Exactly what I wanted as documented
> :)
>
> However, the problem persisted... until...
>
> I noticed that builds on the command line worked fine, as did 'install'
> e.t.c from within eclipse
And in the interests of keeping ASF vendor neutral,
There are at leaste three repository managers equally capable of providing
95% of what people need (they disagree on the remaining 5% either being
needed or how to solve)
In alphabetical order, so as not to imply any preference:
Archivia by Apa
My only use for versions specified by property is where the suite of
dependencies are all the same version. Properties is the only way right now
to handle that. Pom v5 should have something better when we get to it
shouldn't it, eh!
On Tuesday, 24 April 2012, Wayne Fay wrote:
> > way is a good id
if you change your batch file to build up a classpath for you, it could add
in any jars in the "patches" directory onto the classpath first. You might
want to have a look at the batch files used to launch some of the common
Java apps, e.g. ANT and Maven. Also take a look at the batch files
generate
You need to see this page:
http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html
You will need to define system properties for each system property you want
to pass through.
Most likely your properties will look like
${foo}
${bar}
Ie you are just passing t
ahem...
are you running on a unix system?
you do know # is the comment start marker for most unix shells
you'd need to escape it with \ or quote the entire -D
On 1 May 2012 16:24, Laird Nelson wrote:
> I have a test class; let's call it TestCaseFoo.
>
> When I run surefire:test with no va
On 1 May 2012 17:36, Laird Nelson wrote:
> On Tue, May 1, 2012 at 12:31 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > you'd need to escape it with \ or quote the entire -D
> >
>
> Yes, I am running on MacOS. Sorry; didn
On 1 May 2012 22:43, Laird Nelson wrote:
> On Tue, May 1, 2012 at 5:30 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > there is your #fail
> >
> > mvn clean install -fae -Pminlog '-Dtest=TestCaseFoo#testBar'
> >
>
>
The Mojo team is pleased to announce the release of Mojo's Cassandra
Maven Plugin version 1.1.0-1.
Mojo's Cassandra Plugin is used when you want to install and control a
test instance of Apache Cassandra from within your Apache Maven build.
The Cassandra Plugin has the following goals.
* cassan
Just so you know, a far far better way to do this is to use toolchains.xml
On 8 May 2012 17:36, wrote:
> Works like a charm (tested with mvn -X), inside the pom:
>
> X
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.2
>
> 1.7
>
On 9 May 2012 06:51, Iordanov, Borislav (CIAO) wrote:
> Hi,
>
> I'm a relatively new Maven user. I found an exact description of my problem
> on StackOverflow, but no solution:
>
> http://stackoverflow.com/questions/10174542/resolving-maven-circular-dependencies-between-test-testhelper-and-projec
Hmmm. I wonder if I were to modify the ship-maven-plugin to allow ship
scripts to be pulled from the plugin's classpath rather than the
filesystem would that solve your issue.
On 9 May 2012 21:49, Raketemensch wrote:
> Well, that's why I'm asking for a best practice, I'm trying to avoid
> antishn
I think I have made the modifications that would make your life
simpler... you probably still would need to change a parent pom, but
that would be the only change... fix will be in ship-maven-plugin
1.0-alpha-2
On 10 May 2012 09:39, Stephen Connolly wrote:
> Hmmm. I wonder if I were to mod
Hi,
The Mojo team is pleased to announce the release of Mojo's Ship
Maven Plugin version 1.0-alpha-2.
Mojo's Ship Plugin is used when you have continuous deployment scripts that you
want to integrate with your Apache Maven build.
The plugin has the following goals.
* ship:ship Resolves the shi
Properties are not supported in the following XPath elements:
/project(/parent)?/(groupId/artifactId/version)
-Stephen
On 14 May 2012 13:42, RAJIV_S wrote:
> I have a project structure like the below
>
> School-parent
> |
> |
> | services-parent
> | |
On 14 May 2012 14:26, RAJIV_S wrote:
> ${project.version}
That is not a property but a reference to the pom.
>
> I thought based on the above example, any property value should be supported
> in version tag using ${...}
not in /project/version or /project/parent/version
>
>
> Any, recommendtio
mvn help:effective-pom
in project b will tell you the answer
On 15 May 2012 13:29, Cédric Teyton wrote:
> Hi everybody,
>
> I have a surely straightforward question for anyone with Maven knowledges,
> but i can't manage to find the right answer.
>
> Assume a project A under Maven with a license
http://svn.codehaus.org/mojo/trunk/mojo/ship-maven-plugin/src/it/plugin-deps/
is the closest to an example I have at this time.
It would be great if you could turn that into a patch for the plugin
docs to explain how it works
On 15 May 2012 21:18, Raketemensch wrote:
> Sorry for the delayed res
have a look at the failsafe maven plugin... (I know you will not be
using it)... but it explains how to do the type of thing you want to
do.
On 17 May 2012 12:35, alexbarter wrote:
> Hi all. I need seems strange case:
> 1) pax exam starting apache servisemix (or fuse esb)
> 2) soap ui maven plugi
MavenProject.getFile()
On Wednesday, 16 May 2012, Dreier Ruediger wrote:
> Hello!
>
> Is it somehow possible to get the name of the POM file (which might not be
> POM.xml if Maven was called with –f) inside a POM file (e.g. as parameter
> for other plugins)?
>
>
> Thanks for any help,
>
> i.A. Rü
On Wednesday, 23 May 2012, hujirong wrote:
> Hi
>
> After working with Maven for a month, I am still not quite understand how
> Maven works. Maybe just like Microsoft technologies, encapsulate too much.
> One key issue is to understand the plugin.
>
> For example, the following example, how can I
On 24 May 2012 13:39, DK wrote:
> Hi,
>
> New to Maven and have a couple of questions around versioning.
>
> Should all projects within a multi-module project have the same version?
Not required, but can usually be helpful.
>
> Should all projects related to each other keep the same version numb
it will prompt with that as the default next version, 1.0.0 as the
default release version, and artifactId-1.0.0 as the default tag
(where artifactId is the artifactId of the root pom you are running
release on) you unless you do -B in which case yes.
On 24 May 2012 15:23, DK wrote:
> So how does
Another rule of thumb is how stable are the tests...
if you have a stable test suite that never fails randomly only to pass
again next run... you can have a 1 hour long build and release that...
it will take 2-3 hours for the release run to go through, but you know
it will go through...
If you ha
The first thing I would do is lock down all the versions of plugins in
all your builds
Then you can try with the newer version of maven, and once that is
working, try updating the plugin versions.
If you have not locked down your plugin versions, your build is not
reproducible and you need to loc
have a look at the jetty:run and tomcat:run mojos... these will
package up the war files into a directory, start a jetty or tomcat
container respectively and serve the webapp in place, The jetty one
supports scanning of the source files and automatic reloading of the
webapp... I think the tomcat o
load the resources through the classloader
Sent from my [rhymes with myPod] ;-)
On 13 Feb 2009, at 17:30, Costin Caraivan wrote:
Hello,
This will be a newbie question, regarding resource relocation at
build time.
It goes like this: I code something, that maybe loads
some .properties and
when you invoke a phase, maven invokes all the phases, in the
lifecycle to which the phase belongs, up to and including the phase
you specified
you are invoking the clean phase, which is part of the clean
lifecycle, so maven will invoke all the mojos attached to the pre-
clean phase, and t
1 give them a test-jar that has the unit tests
2 give them a second war with the test interface
Sent from my [rhymes with myPod] ;-)
On 14 Feb 2009, at 16:54, Subhrajyoti Moitra
wrote:
Hello,
My client wants to "unit test" the core components of this
application.
So, i went about creat
How does surefire decide what order to run unit tests in?
-Stephen
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
It'd be dangerous is it didn't remove the jar mojo from the forked
lifecycle, as the jar mojo is the mojo that forked the lifecycle in
the first place... and if it didn't remove the plugin from the forked
lifecycle, the forked lifecycle would fork again... and again and
again
2009/2/18 Rom
Does it build with 2.0.9?
If it builds with 2.0.9 then you have a point.
If it won't build with 2.0.9 then you have a regression
-Stephen
2009/2/20 Vinicius Borges :
> of course... but the error is in Maven
>
> thanks
>
> 2009/2/20 Rusty Wright :
>> Have you tried the CAS mailing list?
>>
>> h
Sent from my [rhymes with myPod] ;-)
On 22 Feb 2009, at 02:15, jie...@gmail.com wrote:
On Sat, Feb 21, 2009 at 8:52 PM, Wes Wannemacher
wrote:
Brian, right now, the struts project pushes its snapshots over to
people.a.o
when the apache hudson builds them (as often as daily, but usually
I understand what you are trying to do, but you will end up losing the
version range functionality in maven with version numbers in that format
have a look at maven's rules fir comparing version numbers, then look
at my bitchfest with Jason over me wanting five digit support and
Jason sayin
2009/2/22 Steve Cohen
> I am considering"Mavenizing" a pre-existing project.
>
> This project consists of a Web Application (WAR file) and a server side JAR
> module, built from several Eclipse projects, some of which are dependencies
> of both modules, as well as many third party jars, both open
There are ways... they probably involve creating manifest entries
2009/2/22 Google Mail
> Stephen,
>
> another chanllenge,
>
> mytool --version should give
>
> mytool, version 1.0-SNAPSHOT (b476)
> compiled Feb 17 2009, 12:42:22
>
> Is there maven support to supply this three parameters (versi
2009/2/23 Jon Georg Berentsen
>
> "I am considering"Mavenizing" a pre-existing project.
>
> This project consists of a Web Application (WAR file) and a server side
> JAR module, built from several Eclipse projects, some of which are
> dependencies of both modules, as well as many third party jars
Sent from my [rhymes with myPod] ;-)
On 23 Feb 2009, at 20:51, Steve Cohen wrote:
David Weintraub wrote:
Actually, if you don't have a strong build process, you need one --
Maven or no Maven. Builds should be automatic and repeatable.
Thanks. You are preaching to the choir, friend. I'm us
wtf...
you do know running verify followed by deploy is running the lifecycle
twice!
if you are using the freestyle project type (and _I_ do not recommend
the m2 project type as it fecks with your pons behind your back) just
run maven twice, problem solved
Sent from my [rhymes with myPo
hooks in it BEFORE deployment.
Thanks for the response.
Regards,
Randall
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Monday, February 23, 2009 2:19 PM
To: Maven Users List
Cc: Maven Users List
Subject: Re: Disable/Enable tests per plugin/goal
wtf..
but the first version of a plugin used in a reactor is the one that
gets used, so if the parent is part of the same reactor, *and* gets
built first, your override of the version in the child will be ignored
Sent from my [rhymes with myPod] ;-)
On 1 Mar 2009, at 19:59, Rusty Wright wrote:
F
Or you could have a look at versions-maven-plugin... it will still require
you to commit your changes, but it will at least help with changing the
pom.xml files for you
2009/3/2 Jeff MAURY
> LATEST works only for plugins artifacts. I suggest that you use a parent
> POM
> and put the required ver
generated
> during site life cycle.
>
> On Mon, Mar 2, 2009 at 5:24 AM, Stephen Connolly
> wrote:
> > Or you could have a look at versions-maven-plugin... it will still
> require
> > you to commit your changes, but it will at least help with ch
FYI this is what's holding up 1.0-alpha-3
2009/3/2 Stephen Connolly
> I am working on this... there were some issues with integration with doxia
> that I need to resolve
>
> 2009/3/2
>
> I can recommend the versions-maven-plugin
>> (http://mojo.codehaus.org/vers
Ehhh as long as you're not holding it you'll pass out ;-)
2009/3/2
> My breath is now officially bated. :-D
>
> On Mon, Mar 2, 2009 at 8:37 AM, Stephen Connolly
> wrote:
> > I am working on this... there were some issues with integration with
> d
Those dependencies are required to *test* struts they are not required
by your project as struts has already been tested.
-Stephen
2009/3/3 stanlick
>
> Thanks guys --
>
> If you look at the POM for Struts 2.1.6 there are many more dependencies
> than what show up running
> dependency:resol
lawyers even though
> they
> are not "dependencies?"
>
> Peace,
> Scott
>
>
>
> Stephen Connolly-2 wrote:
> >
> > Those dependencies are required to *test* struts they are not
> required
> > by your project as struts has already been
Either refactor your build so that it retrieves these artifacts from the
reactor (this is a good plan anyway... for example replace dependency:copy
with dependecy:copy-dependencies, etc)
Or (if you cannot refactor... maybe one of the plugins you are using is not
written to check the reactor for ar
RELEASE is deprecated, and AFAIK only ever worked for plugins
On 05/03/2009, B Smith-Mannschott wrote:
> On Thu, Mar 5, 2009 at 08:15, Martin Eigenbrodt
> wrote:
>> Thanks for your response Ben,
>> I've considered this workaround, but I need a way to always pick the
>> latest
>> build of a depen
2009/3/6 Martin Eigenbrodt
> >
> > The release plugin *is* clever enough to ask you if you want to
> > replace SNAPSHOT versions in your dependencies with real release
> > versions. Once it's gotten the necessary information from you, it
> > makes the edits on your behalf. A good feature, that.
>
2009/3/7 Juven Xu
> this should a properties file, which is available in your test classpath.
>
> your can retrieve it in your testcase, like:
>
> File testFile = new File("target/test-classes/test.properties");
n
access it as a resource from the classpath
>
>
> Note that all files unde
[1.0,1.1-!)
1.0-SNAPSHOT < 1.0 < 1.1-SNAPSHOT < 1.1
But in ASCII ! is < A
therefore
1.1-! < 1.1-SNAPSHOT < 1.1
1.1-! is also < 1.1-alpha-1
2009/3/7 Markus KARG
> My project is dependent of some library. I want to always use the latest
> bugfix but not any new features. So I added [1.0,1.1)
the only way *I know* is to use versions-maven-plugin in conjuction
with versions locked down completely with properties
I would think that 1.0.1-SNAPSHOT is in the range [1.0,1.1-!)
but there may be some rules that make this less of an issue (like
maven favouring the highest version avail i
2009/3/9 Matthias Dorfner
> Hi everybody,
>
>
>
> I have a multi-moduled project that looks like this:
>
>
>
> -parent
>
> --submodule1
>
> --submodule2
>
> --submodule3
>
>
>
> My questions are now:
>
>
>
> 1. How can I retrieve the name of the compiled jar from submodule2 & 3
> in the parent's
l try it with the dependencies plugin, that solutions sounds good!
>
> What would you suggest for my second concern? Is there a possibility to
> deny deploying on a submodules' level?
>
> Thank you!
> MD
>
>
>
> -Ursprüngliche Nachricht-
> Von: Stephen Co
The core assumption of a maven repository is that once a non-SNAPSHOT
version is available, that artifact will *NEVER* change.
Thus once maven downloads log4j:log4j:1.2.13 it will *NEVER* look for it
again.
This is why you should always keep your pom on a -SNAPSHOT version, as the
only thing that
ehhh what's wrong with "mvn deploy"... that will deploy the current version
(which should be a -SNAPSHOT)... in all other cases you should be using a
qualifier that identifies you as the builder...
for example if I want to deploy my own version of something that is
currently 5.0.0-SNAPSHOT I would
t; human error? Should mvn-deploy not refuse to overwrite an artifact by
> default?
>
> Sahoo
>
>
> Stephen Connolly wrote:
>
>> The core assumption of a maven repository is that once a non-SNAPSHOT
>> version is available, that artifact will *NEVER* change.
>>
&g
edit the version in thepom andjust run mvn deploy
On 10/03/2009, Lachlan Deck wrote:
> On 10/03/2009, at 9:06 PM, Stephen Connolly wrote:
>
>> ehhh what's wrong with "mvn deploy"... that will deploy the current
>> version
>> (which should be a -SNAPSHOT)...
On 11/03/2009, at 9:12 AM, Stephen Connolly wrote:
>
>> edit the version in thepom andjust run mvn deploy
>
> More work? Sure I can create an ant-file that will recursively follow
> the modules down editing all of them to do this - but that's what the
> release plugin do
The short answer is no.
The long answer is that this is a bad idea as it makes the build
non-reproducible.
There are similar reasons why a plugin cannot add depedencies to a build in
progress.
Before any plugin gets to run, Maven parses *all* the pom.xml files, and the
dependencies are determine
OK I found the work-around although I do not think this should be
necessary (at least according to the docs)
But still at least it works now!
2009/3/12 Stephen Connolly
> So we have this legacy build t
So we have this legacy build that uses ANT.
Normally I would just convert the build to Maven... but this one is too
crufty for me... and time is too tight.
So enter maven-ant-tasks...
I'm having problems deploying to our internal repository (which is using
nexus)
To try and resolve this I creat
it's a bug with subversion 1.5.1+ when using the neon transport
against http or https repositories
if you use svn 1.4 you are fine
if you recompile your svn binaries to use the other transport for
http / https you should be fine too
and the solution is just to run svn update and then mvn
I have read reports that svn compiled with serf and not neon works with
tagging no problemo
I'll have a shot at confirming this on monday
-Stephen
2009/3/14 Olivier Lamy
> Hi Folks,
> I have added some proposals here : http://jira.codehaus.org/browse/SCM-262
>
> Comments are welcome !
> Th
You'd probably be better off with 4 modules...
module #1 is all the contents of the jar without persistence.xml
module#2-#4 just have the persistence.xml, they use
dependency:unpack-dependencies to unpack module#1 into target/classes
2009/3/16 Aaron Shettleroe
> I'm trying to build 3 artifacts
have a look at the release profile... but beware the old adage:
less haste, more speed
i.e. In trying to make this short-cut you could make much more work for you
than the short cut removes...
This is akin to those fools who try to only run the unit tests once when
they are using a code coverage
OK, so In am currenty performing a major refactoring of
versions-maven-plugin...
I'm looking for some feedback from anyone using this plugin
Specifically anyone using the update-properties goal...
I have just finished a bit of refactoring (on my branch not trunk) that
associates a property w
google this "animal sniffer Kohsuke"
it should give you what you're after
(just not sure if Kohsuke created the db for jdk 1.4)
On 17/03/2009, Ringo De Smet wrote:
> Dirk,
>
> 2009/3/17 Dirk Olmes :
>>
>> Can't you just configure a JDK1.4 in hudson to use for compiling/running
>> Maven on the jo
how is this different from running mvn -N versions:update-child-modules
2009/3/18 Landais Gabriel
> Hi,
>
> Le Thu, 12 Mar 2009 12:48:23 +0100,
> Landais Gabriel a écrit :
>
> > I want to set the parent version of a generated model through an
> > archetype:generate. It has to be set to the arch
either write a plugin... and how do you get that into their local
repository... or maybe use the exec plugin
2009/3/18 Will Hoover
> Does anyone know how to accomplish this (using local repository)?
>
> -Original Message-
> From: Wendy Smoak [mailto:wsm...@gmail.com]
> Sent: Monday, Marc
AFAIK, There is no single point of contact.
for #1 try contacting ibm
for #2 try contacting bouncycastle
for #3 try contacting eclipse
2009/3/18 Costin Caraivan
>
> Hello,
>
> I would like to contact the administrators of repo1.maven.org for a
> corrupted jars and some incorrect poms on repo1.
Oh, and before I forget, you will not be able to get the bad artifacts
fixed... only superceded with newer versions... once an artifact is in repo1
it's there for good
2009/3/18 Stephen Connolly
> AFAIK, There is no single point of contact.
>
> for #1 try contacting ibm
> for
an
>
> I know that some stuff is just pulled in from elsewhere, but do you want to
> tell me that things get uploaded there with 0 review?
>
> :|
>
>
> Stephen Connolly-2 wrote:
> >
> > AFAIK, There is no single point of contact.
> >
> > for #1 try conta
What you really want is to attach additional artifacts to your build with an
"emma-instrumented" classifier...
[Random but relevant]This will probably break the maven-ear-plugin on your
build... ;-) [/Random but relevant]
My understanding is that issues with instrumented jars using classifiers an
2009/3/19 sebb
> On 19/03/2009, Rusty Wright wrote:
> > Do the imports only have an effect at compile time? For example, if you
> > have
> >
> > package impl.zzz;
> >
> > import api.yyy.Yyy;
> >
> > public class Xyz implements Yyy {
> > }
> >
> > When you run the app the jvm won't need
Please direct your questions to the maven users list. I am not your
personal guru ;-)
-Stephen
2009/3/19
> Hi Stephen,
>
> I've just got this to worry about.
>
> I'm trying to release a project, that has these dependencies in it. It
> works fine for install/package etc, but only when releasing
Known bugs fixed for 1.0-alpha-3... but I'm not ready for that to be
released yet
2009/3/19 Reto Bachmann-Gmür
> Hello
>
>
> The output of mvn versions:display-plugin-updates
>
> [INFO] All plugins are using the latest versions.
> [INFO]
> [WARNING] The following plugins do not have their ve
2009/3/19 sebb
> On 19/03/2009, Stephen Connolly wrote:
> > 2009/3/19 sebb
> >
> >
> > > On 19/03/2009, Rusty Wright wrote:
> > > > Do the imports only have an effect at compile time? For example, if
> you
> > > > have
> &g
2009/3/19 sebb
> On 19/03/2009, Stephen Connolly wrote:
> > 2009/3/19 sebb
> >
> > > On 19/03/2009, Stephen Connolly
> wrote:
> > > > 2009/3/19 sebb
> > > >
> > > >
> > > > > Can I get back to my original qu
No.
e.g.
(I own one-dash.com)
I might roll a custom version of log4j...
I would deploy this as
groupId=com.one-dash
artifactId=log4j
version=1.2.14
Why should I have to change the package names?
2009/3/20 Merv Green
> Is it reasonable to insist that a project's Java package name matches
>
601 - 700 of 2426 matches
Mail list logo
