I think I found a bug in Maven, but I am not sure. Maybe I am doing something
wrong, so Maven Committers, please judge the following case:
A version range in a dependency like...
org.glassfish.jersey.core
jersey-server
[2.0.0, 3.0.0)
mvn dependency:tree
...results in a correct
lti module build (so project
> ordering/inter dependencies should remain correct), then yes, maven
> should "know" about it, should be dependency, but then again the
> plugin itself should declare custom packaging (my 1st mail), and that is the
> proper solution IMO.
>
&g
that is the proper solution IMO.
T
On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg
wrote:
> That might work, but my intention is not to play with arbitrary
> experimental PRs, but is to find a consensus, what such a future
> feature should look like to get it accepted b
s path to, as follows:
> * For a JAR or zip file that contains class files, the class path
> ends with the name of the zip or JAR file.
>
>
> Maven should comply, no? Or could maven do something about "zip file
> that contains class files"?
>
> T
>
> O
T
On Fri, Jun 10, 2022 at 11:28 AM [Quipsy] Markus Karg
wrote:
> Thanks for the quick tip.
>
> While it might solve the actual problem I did have this morning, it is
> neither a clean nor a general solution for everybody and for always,
> as it still implies that all ZIPs shall
c/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
HTH
T
On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
wrote:
> How can I keep a dependency out of all classpaths?
>
> I do have a dependency in my project that produces a ZIP full of
> resources. None of those resour
How can I keep a dependency out of all classpaths?
I do have a dependency in my project that produces a ZIP full of resources.
None of those resources is actually of any use for the Java compiler; they
solely serve as an input to third party plugins (not dealing with Java at all).
Unfortunately
like this before it worked
https://repository.apache.org/service/local/repositories/maven-XXX/content/.
But can't remember what XXX it was as I've got ~10 in my settings.xml commented
out.
John
On Mon, 26 Oct 2020 at 10:53, Markus Karg wrote:
>
> When I am using this plugin
When I am using this plugin
https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails because
it apparently cannot find needed runtime files on Maven Central. This
limitation is not told on that page. Is that a bug or am I doing something
wrong?
-Markus
Using Maven since 10+ years, we have a strange problem with MVN 3.5.0.
What we want to achieve is to ensure that all dependencies are latest version,
even if somebody did a bad thing and replaced a release version in Nexus.
So we type:
mvn dependency:purge-local-repository
This fails to re-res
Maven update Classpath and settings in
IntelliJ how Classpath by Maven is prioritized among other Jars/paths on
Classpath?
regards,
Lin
On Mon, Mar 23, 2015 at 2:07 AM, Markus Karg wrote:
> With "at runtime" I mean "when Eclipse is performing the 'organize import&#
the
import package statements could be recognized and resolved in IDE?
regards,
Lin
On Mon, Mar 23, 2015 at 12:29 AM, Markus Karg wrote:
> Lin,
>
> there is no magic involved. Maven produces a Class Path at runtime
> made up from the declared dependencies in the effective POM (i. e
Lin,
there is no magic involved. Maven produces a Class Path at runtime made up from
the declared dependencies in the effective POM (i. e. your explicit POM and any
explicit and implicit parent POMs, and any implied POMs due to dependencies).
Eclipse uses that Class Path as part of the one it c
Hello,
>
> It sounds more like a download as it does not ask again. You can wipe your
> local repo cache (or use a different one in settings.xml) and try to
> reproduce the problem. If you run with -X and actually keep the maven log
> output you should be able to see the acces
ask again. You can wipe your
local repo cache (or use a different one in settings.xml) and try to reproduce
the problem. If you run with -X and actually keep the maven log output you
should be able to see the access in question.
Gruss
Bernd
Am 18.03.2015 14:02 schrieb "Markus Karg" :
Dear Maven Experts,
just did "svn checkout" to get trunk of maven-dependency-plugin, and wanted to
build it using "mvn clean package". What then happened is really scary:
* It complained about missing access on that path where my USB stick
stores the encrypted password for my local Nex
y plugin, since we'd definitely want this to be done in
> the same manner.
>
> Kristian
>
>
> 2015-03-17 9:49 GMT+01:00 Markus Karg :
> > Great, thanks a lot! :-)
> >
> > But let's negotiate one thing upfront: If we provide code that adds
> to maven-de
configure maven-dependency-plugin's encoding used for
unpack?
I'm not kidding about anything. I reopened the issue.
If you make a patch that applies encoding to zip files I can review that.
Kristian
2015-03-17 8:27 GMT+01:00 Markus Karg :
> Kristian,
>
> you're ki
mars 2015 08:19:20 Markus Karg a écrit :
> (1) "Normal users" (non-comitters) do not have permission to reopen
> issues so I really beg for your kind help to reopen this issue for me!
> :-)
no, please don't reopen the issue: open another issue
> (2) Despite all the qui
in has any support for encoding in
pack or unpack. Where did you see that ?
Kristian
2015-03-16 15:04 GMT+01:00 Markus Karg :
> Kristian,
>
> can you please reopen the item then? I mean, it simply is not fixed,
> because UTF-8 ZIPs are not a solution: Windows cannot correctly
>
not sure which issue you are referring to, I know there is one for
assembly-plugin (http://jira.codehaus.org/browse/MASSEMBLY-748) since the
encoding feature should be fixed to work for "unpack" too.
Kristian
2015-03-16 15:04 GMT+01:00 Markus Karg :
> Kristian,
>
> can yo
t very specific situation, it's not
very likely someone else will spend time to fix it.
HTH
Cheers
2015-03-16 15:04 GMT+01:00 Markus Karg :
> Kristian,
>
> can you please reopen the item then? I mean, it simply is not fixed,
> because UTF-8 ZIPs are not a solution: Windows cann
tickets, if you feel this is not OK, feel free to
> comment/reopen/create the ones you want.
> But also beware that without a patch, in that very specific situation,
> it's not very likely someone else will spend time to fix it.
>
> HTH
> Cheers
>
> 2015-03-16 15:
t;
> kristian.rosenv...@gmail.com> wrote:
>
> > I dont believe there is support for specifying encoding to unzip. At
> least
> > assembly only provides config to zip. Call it a bug, call it a
> > feature :(
> >
> > Kristian
> >
> >
> > 2015-0
To preserve German umlauts in file names within a ZIP, we are using...
CP850
...in the maven-assembly-plugin configuration, which is working well. :)
Next we want to use maven-dependency-plugin to unpack that ZIP.
How can we configure maven-dependency-plugin:unpack so it will apply CP850 when
I uploaded lots of not-even-Mavenized prebuilt JARs to Maven Central and can
tell you that you simply misunderstood these terms as "essential" requirements
-- in fact most of them are only "best practices". You do neither need to have
the Sonatype POM, it will just make things easier, nor do you
rt 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 :
> I wonder why someone fixed it but didn
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...!
Thanks for all
-Markus
Martin,
thanks for your ideas, but...
>MG the previous email was an attempt to explain prepare-mojo will update
>current or children artifacts but not parent artifacts
I agree that the docs do not say anything about the parent, but my question is
not about the docs, it is about this question t
es/releases
snapshots
http://nexus.quipsy.local/nexus/content/repositories/snapshots
Preparing and performing the release:
C:\Users\Markus Karg\workspace\artifact\my-artifact>mvn release:prepare
release:p
As a Maven user I think that everybody who is working on a project should
behave the same. Hence, I would say, PMC members should rather certainly
demonstrate how to live the community rules.
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Gesend
which version of Maven and Maven-Release-Plugin are you using?
> >
> > On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg wrote:
> >
> > > I'm driving nuts with mvn release:prepare...:
> > >
> > > When I do mvn release:prepare, Maven asks whether I want
s.
>
> Chris
>
>
> -Ursprüngliche Nachricht-
> Von: jieryn [mailto:jie...@gmail.com]
> Gesendet: Montag, 22. Juli 2013 20:36
> An: Maven Users List
> Betreff: Re: mvn release:prepare does not update parent version
>
> Greetings,
>
> On Mon, Jul 22, 2013 a
2013 at 8:25 AM, Markus Karg wrote:
> When I do mvn release:prepare, Maven asks whether I want to update all
> SNAPSHOT version referenced in the POM.
I don't think the language says that at all. I ran a quick build and I'm not
seeing where it says it will update every single SNAPSHOT
Thanks for picking this up. Please find answers inlined. :-)
> > When I do mvn release:prepare, Maven asks whether I want to update
> all
> > SNAPSHOT version referenced in the POM.
>
> I don't think the language says that at all. I ran a quick build and
> I'm not seeing where it says it will upd
Thanks for picking up this thread!
I am using: Maven 3.0.4 and maven-release-plugin 2.4.1
-Markus
> Hi, which version of Maven and Maven-Release-Plugin are you using?
>
> On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg wrote:
>
> > I'm driving nuts with mvn release:prepar
I'm driving nuts with mvn release:prepare...:
When I do mvn release:prepare, Maven asks whether I want to update all
SNAPSHOT version referenced in the POM.
I say "yes" and confirm all suggested replacement versions unchanged.
When Maven is done, I check the POM.xml.
It is correctly rewritten for
I'm driving nuts with mvn release:prepare...:
When I do mvn release:prepare, Maven asks whether I want to update all
SNAPSHOT version referenced in the POM.
I say "yes" and confirm all suggested replacement versions unchanged.
When Maven is done, I check the POM.xml.
It is correctly rewritte
My project is dependent on a third-party JAR file which will be
installed on the target machine by a mechanism other than Maven. Hence,
I have no influence on its actual file name.
As I want Maven to automatically build the MANIFEST's Class-Path entry,
I have put the same third-party JAR into m
I am using xml-maven-plugin to generate Java code from XML:
org.codehaus.mojo
xml-maven-plugin
1.0
generate-sources
transform
T
java.library.path?
dont think maven can do that ( surefire understand jars but not dll/so ). I am
facing the same issue and the best I can come up ATM is to configure every
single project
-D
On Mon, Mar 25, 2013 at 12:58 AM, Markus Karg wrote:
> Dan,
>
> thank you for this tip. I is wor
2013 at 6:58 AM, Markus Karg wrote:
> My POM declared a dependency to a DLL:
>
>
>
>
>
> net.sf.jacob-project
>
> jacob-runtime
>
> dll
>
> x64
>
> 1.17-M2
>
>
ed it myself.
Any CI problems are not related to this; I was just focusing on the Eclipse
part of the problem.
/Anders
On Thu, Feb 28, 2013 at 11:08 AM, Markus Karg wrote:
> Who said that I do not use the EclEmma Eclipse plugin? Actually I do.
> :-)
>
> But that does neither solve
, Dan Tran wrote:
> I think that would work if you invoke 'maven install' using m2e.
> However, if you use eclispe's unit test, that may not possible since I
> too could not working. I basically configure eclispe or put the dlls
> in my system path
>
> -D
>
&
spe's unit test, that may not possible since I too
could not working. I basically configure eclispe or put the dlls in my system
path
-D
On Wed, Feb 27, 2013 at 11:21 PM, Markus Karg wrote:
> I fact these are not "my " DLLs but are ready-to-use artifacts of the JACOCO
&g
I fact these are not "my " DLLs but are ready-to-use artifacts of the JACOCO
project on SourceForge. So I will *never* build them on my own. But I need to
have it working m2e. Do you think your solution will convince m2e to add lib to
java.library.path?
-Ursprüngliche Nachricht-
Von: Da
Possibly. Because in fact, I need other tools to understand the need for
java.library.path, too, mosty the m2e Eclipse plugin, which I doubt will
understand any manual PATH changes in the surefire config (does it?).
-Ursprüngliche Nachricht-
Von: Wayne Fay [mailto:wayne...@gmail.com]
Ge
; From: Jörg Schaible [mailto:joerg.schai...@scalaris.com]
> Sent: Mittwoch, 27. Februar 2013 18:03
> To: users@maven.apache.org
> Subject: Re: How to tell Maven to put DLL dependency into
> java.library.path?
>
> Hi Marcus,
>
> Markus Karg wrote:
into the
> download directory
>
> Good luck
>
> -D
>
> On Wed, Feb 27, 2013 at 6:58 AM, Markus Karg wrote:
> > My POM declared a dependency to a DLL:
> >
> >
> >
> >
> >
> > net.sf.jacob-project
> >
> >
My POM declared a dependency to a DLL:
net.sf.jacob-project
jacob-runtime
dll
x64
1.17-M2
runtime
(1)How can I tell Maven that when doing "mvn test", that DLL shall
be found on java.
Jason,
thank you for that concise information. It would be great if you could also
publish a quarterly sampled line graph on the same stats, so one could
easily identify and trends in this. :-)
Regards
Markus
From: Jason van Zyl [mailto:ja...@tesla.io]
Sent: Donnerstag, 27. September
If there is a real interest in my participation I would be glad to join. But to
tell it frankly, I enjoyed lots of forums and lists where people talked and
talked and talked (I am an EG member and know how long companies can talk just
to not being forced to change one code line) and did never co
Strub,
thank you for your comments. Unfortunately (as I already wrote two times
before) this thread started by the exact problem of overloading a JRE class
(Resource annotation) by javaee6.jar... so it just don't work (otherwise I
wouldn't have started this thread).
Anyway, thanks for chiming in!
> > I did never suggest to modify the POM and said no word about any
> > future form of the POM, so I skip your comments about that and right
> > go on with the idea of a Platform:
> >
> >> I like some of your idea about the concept of a platform but this is
> >> not as trivial as you think.
> >>
>
ng packaged into a .ear for each platform that you want to
> deploy the .ear onto... on older platforms you might need the newer
> version of JSF, on TomEE you may need additional dependencies because
> it is implementing one profile, etc]
>
> IOW I think the concept of a pl
he jvm version it targets... A
> dep can be fine until it gets added to the jvm spec.
> 3. It should probably more correctly be endorsed 4.
> Where would you package an endorsed dependency within a .war or .ear
> file?
>
> And don't get me started on the fact that to change
> Claves
>
> -Original Message-
> From: Markus Karg [mailto:k...@quipsy.de]
> Sent: 20 September 2012 09:22
> To: users@maven.apache.org
> Subject: How to put a dependency in the classpath BEFORE jre.jar?
>
> I have a dependency on javaee.jar, which provides newer
n config:
> -Djava.endorsed.dirs=blabla
>
> Should be possible to do something similar for test executions with
> surefire as well.
>
> /Anders
>
> On Thu, Sep 20, 2012 at 10:21 AM, Markus Karg wrote:
> > I have a dependency on javaee.jar, which provides newer versio
I have a dependency on javaee.jar, which provides newer versions for
classes found in JRE's jre.jar (particularly the @Resource annotation).
But javaee.jar is always appended to the classpath, while to be able to
load the newer version, I need to PREFIX it before jre.jar instead. How
can I configur
This is a known bug. See:
http://jira.codehaus.org/browse/MJAR-156
http://jira.codehaus.org/browse/MACR-4
Please comment and vote these bugs that you also suffer from this problem
and want to see it fixed.
> -Original Message-
> From: it-media.k...@daimler.com [mailto:it-media.k...@daim
For security reasons it is a good idea to have the passwords encrypted on a
USB stick, see http://maven.apache.org/guides/mini/guide-encryption.html
> -Original Message-
> From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com]
> Sent: Mittwoch, 15. August 2012 14:41
> To: maven users
> Su
ggest binding to the pre-integration-test phase as there is no
> guarantee that the dependency plugin will always execute before
> failsafe if you are binding to the integration-test phase
>
> On 30 July 2012 11:12, Markus Karg wrote:
>
> > Thanks to all for all the kind
Thanks to all for all the kind help!
In fact I made it work, and the solution is as simple as using the dependency
plugin:
maven-dependency-plugin
2.4
copy
integration-test
Hello Maven Community,
I have a complex setup to do for an end-to-end integration test. For
this, I am using the Maven Failsafe plugin. As the test needs some
resources to run (which I plan to put into Nexus as this feels just
natural), I want to tell Maven that when the integration test is
run
he repository id in your project is missing in the current
> metadata, a new attempt will be made to download it. if it fails, the
> build fails as well. That way maven shoudl enforce that your project is
> always buildable with given pom content.
>
> Milos
>
> On Wed, Jul
Even if I remove *all* hamcrest-core artifacts from my Nexus and local repo,
Maven 3.0.4 again pulls some artifacts, but does not use 1.3 when I say
[1.3]. But I want exactly 1.3. So what next to try? Can you give me an idea
how a test case should be made up to let you reproduce this?
> -Origi
I have a very strange problem with Maven 3.0.4 running on JDK 1.6.0_26
on Win 7 Pro SP1 (64 Bit):
When I want to compile, Maven says that it cannot resolve a dependency:
"No versions available for org.hamcrest:hamcrest-core:jar:[1.3,1.3]
within specified range". But actually, Maven in fact succ
Just found it... It's a bit small and hidden due to the black colour.
> -Original Message-
> From: Markus KARG [mailto:mar...@headcrashing.eu]
> Sent: Sonntag, 15. Juli 2012 09:17
> To: 'Maven Users List'; d...@maven.apache.org
> Subject: RE: Issue-wise C
Would be good if each funding item would contain a link to the particular
item in the project's tracker, so it is easier to learn about the issue's
details.
> -Original Message-
> From: tony Tony [mailto:t...@freedomsponsors.com]
> Sent: Freitag, 13. Juli 2012 22:38
> To: users@maven.apach
of RAR
packaging.
> -Original Message-
> From: Laird Nelson [mailto:ljnel...@gmail.com]
> Sent: Montag, 25. Juni 2012 15:49
> To: Maven Users List
> Subject: Re: How to correctly make an EJB module dependend of the
> interface JAR of a RAR?
>
> On Mon, Jun 25,
Any other opinions? Any solutions? I cannot believe that an EAR must not only
contain the RAR but also a duplicate (!) of the RA' public interface.
-Ursprüngliche Nachricht-
Von: Markus KARG [mailto:mar...@headcrashing.eu]
Gesendet: Dienstag, 19. Juni 2012 22:26
An: Markus Karg
Be
Ideally for this, Maven (and such, the JVM) would be contained as an itegral
part of the popular operating systems like Windows, MacOS and Linux. What a
perfect world. ;-)
> -Original Message-
> From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com]
> Sent: Donnerstag, 21. Juni 2012 21:54
oject to recreate the issue.
> Also, if you're not using Maven 3, try to build with that as well to
> see if that solves the problem.
>
> /Anders
>
> On Mon, Mar 12, 2012 at 10:06, Markus Karg wrote:
> > I am using the ear and acr plugins to build an ear t
I am using the ear and acr plugins to build an ear that contains an
app-client. It all works well but one thing is always wrong:
The car must use true so the client will
find the needed libraries. When those libraries are SNAPSHOTs, the
created manifest entry contains not "SNAPSHOT" but the lat
gt;
> 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
>
one reason I've had this problem in the past is forgetting
> to specify:
>
> ejb
>
> in the dependency declarations for EJB jars.
>
>
> On 04/03/2012, at 2:33 AM, Markus KARG wrote:
>
> > Maven 3.0.4 is producing application.xml containing entries
Maven 3.0.4 is producing application.xml containing entries for
some dependencies (RAR modules), but which is missing entries for
other dependencies (EJB modules). This is weird as the pom more or less is
empty. It just contains the dependencies (RAR modules and EJB modules) and
Java EE version (
I have set up a typical EAR scenario, where a EJB module and a RAR
module are packaged into a EAR module (using the respective package
types of ear, ejb and rar). To be able to compile the EJB module, I have
to make it dependend of the interface JAR (which is later packed into
the RAR) with compile
What is Maven 3's best practice to deal with "Maintenance Branches"
(non-feature, bug-fix-only line of development)?
Our company needs to maintain a second development line besides "trunk",
which we call " The Maintenance Branch", for those customers having signed a
maintenance contract for one
y moved to 1.1.1 since they are not
> affected by the bug fix while some of the modules would be a 1.1.0-
> SNAPSHOT until they had passed the testing.
>
> I hope that this moves the conversation forward.
>
> Ron
>
>
>
>
> On 11/02/2012 7:11 AM, Markus KARG wro
What is Maven 3's best practice to deal with "Maintenance Branches"
(non-feature, bug-fix-only line of development)?
Our company needs to maintain a second development line besides "trunk",
which we call " The Maintenance Branch", for those customers having signed a
maintenance contract for one
I am writing a plugin which needs to copy files. Since the File.rename()
command can fail if source and target are on different drives, and since I
don't want to write my own byte mover loop, I wonder whether there is an
out-of-the-box file copy / file move library that I can just call?
Will that prevent usage of 1.0.1-SNAPSHOT but allow 1.0.1-alpha-1 through
1.0.-zzz-99 ?
> how about [1.0,1.1-SNAPSHOT) ?
>
> > So this means that there is no *real* solution to get alphas but not
> > SNAPSHOTs?
> >
> > > [1.0,1.1-!)
> > > 1.0-SNAPSHOT < 1.0 < 1.1-SNAPSHOT < 1.1
> > > But in
So this means that there is no *real* solution to get alphas but not
SNAPSHOTs?
> [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
> > My project is dependent of some library. I want to always use t
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)
which allows me to use all bugfixes of the 1.0 release. But when I check the
actually used version, I see that 1.1-SNAPSHOT is getting used! How can I
prevent this? Is ther
I have developed an empty plugin, that does nothing, just to learn how to do
it. It works well directly but is not executed in the default @phase?!
The mojo echos a message to the user, and it is annotated as "@phase
generate-resources" which seems to be done correctly as the resulting
plugin.x
I need to create a JAR file that has Extension-List: entries inside,
since it is dependent of several "Java Optional Extensions" installed in
jre/lib/ext.
How can I tell Maven2 that my project is dependent not of another Maven
project, but of a standard extension (so that it does not create
Cla
We have just set up our own repository server in our department and
deployed several artefacts into it.
Now I need to tell my project that it has to look for a dependency not
only at Ibiblio, but also in my our department's repository.
Since the department's repository shall be the central place
Maven is 100% pure Java.
So if you have Java on your AS400 (which is available from IBM AFAIK)
why not just giving it a try and let us all know? ;-)
Have Fun
Markus
Johan Vogelzang schrieb:
Does Maven run on AS400 machine's?
Thanx
begin:vcard
fn:Markus KARG
n:KARG;Markus
org:QUIPSY QUALI
Dear Maven Community,
currently Maven's support for third party JARs (i. e., JARs not built
with Maven that do not have the version found in their file name) is
problematic. If you have followed the FOP discussion lately happened in
this list, you will understand that there is a need to improv
Jörg,
No need to, it will be rejected. See, how could Maven ever locate and download
a unique artifact without a version? That's one of the critical poiints
providing a POM for a library that is not build with Maven. First you have to
look at the provided docs to learn about the deps and thei
On 9/21/06, Markus KARG <[EMAIL PROTECTED]> wrote:
Actually I don't know it myself, since I am a beginner.
But there must be a Maven way to solve the problem (otherwise this would
make install:install-file totally useless, since least pre-packaged
binary are named in the correct way us
Jörg Schaible schrieb:
Markus KARG wrote on Thursday, September 21, 2006 9:27 AM:
Carlos,
I don't know if you ALSO read the part where I said that I will
provide another pom.xml instead of another binary (it was your
solution proposal, actually)?
When do *you* get it, tha
nother thread to ask for help on this.
Thanks
Markus
Carlos Sanchez schrieb:
ok, provide the pom, and explain the reasons in a jira, because for
what I read till now I don't see how the heck are you gonna solve it
in a maven way.
On 9/20/06, Markus KARG <[EMAIL PROTECTED]> wrote:
&g
s, so your proposed solution is not acceptable..
On 9/20/06, Markus KARG <[EMAIL PROTECTED]> wrote:
Carlos Sanchez schrieb:
> fop 0.20.5 pom was provided by Joerg Schaible
> http://jira.codehaus.org/browse/MEV-386
> That was at the point we allowed changing poms in the repo, now it is
When you build A you don't know anything about C-2.0.1 because it does
not exist.
Versions in repository explicitly define what versions the have been
released against or tested with. If I release A 2.0 depending in C 2.0
and then I want to say i'm compatible with C 2.0.1 I have to update
myself
Wendy Smoak schrieb:
On 9/20/06, diroussel <[EMAIL PROTECTED]> wrote:
Now, I'm not a .NET expect, so correct me if I'm wrong. But
according to
the CLR book [1] one of the ways the CLR is better than the java JVM
is the
handling of versions and version meta-data.
...
Does that make sense?
Carlos Sanchez schrieb:
To make clear to all maven users, this is the current repository policy:
We don't allow pom changes that can alter reproducibility, which means
DEPENDENCIES IN POMS WILL NOT BE CHANGED.
The repo is only a way to distribute other people work. We don't
repackage their wor
Carlos Sanchez schrieb:
fop 0.20.5 pom was provided by Joerg Schaible
http://jira.codehaus.org/browse/MEV-386
That was at the point we allowed changing poms in the repo, now it is
not possible to change that pom.
Jörg, why do you discuss things with me under this topic but not telling
me that
But it would be beneficial for you since I would change it in
a way that
FOP is valid for everyone, so you can remove your workarounds.
Since in your case the Class-Path isn't taken into account anyways as
you wrote, what have you lost?
Reproducability! If we deploy our final release to a
1 - 100 of 171 matches
Mail list logo
