As Jochen pointed out, it can be fixed with a new version. From a QA's PoV you
cannot change a reelased version ever. See, we have relesed own artfiacts using
FOP as dep. If POM or the artifact itsefl would change now, or build is no
longer consistent. Even worse, the build could then be diff
As said, the situation is different on AppServers. Neither jBoss nor WebLogic
complain. IONA's possibly would, but it's abandonned. WebLogic *does* respect
the classpath entry of the EJB artifact itself though.
That's not part of this discussion I think.
We have discussed EJB problems alr
No, the point is, that you're not satisfied with the procedure, how QA works
with Maven's public repo. While I can understand your point (being hit also by
bogous POMs), you're not going to change it. If you want have better control,
setup an own repository from scratch. Look, not even the pe
Then all the Sun JRE's are buggy. Sorry, I am using exactly this artifact for a
long time now without ever noticing that weird classpath entry. The only time
it is respected is when you start the jar as app:
java -jar my.jar
In this case your classpath theory applies. The situation is diffe
the
users/experts around here are the QA. And I assure you that it cannot
be a better QA...
Bruno
On 9/20/06, Markus KARG <[EMAIL PROTECTED]> wrote:
So since bugs once released cannot get fixed without changing the
version (what is problematic with FOP as we have discussed today), this
is
t see that this beeing not possible with something volatile than
software.
Jochen Wiedmann schrieb:
Markus KARG wrote:
So the policy is "A bug cannot be fixed"?!
The policy is "A bug can be fixed in the next version&qu
strictions than maven itself.
Markus
Jörg Schaible schrieb:
Hi Markus,
Markus KARG wrote on Wednesday, September 20, 2006 9:35 AM:
Wayne Fay schrieb:
[snip]
This is your best approach (imo) to get this updated FOP artifact
installed in the Maven Repo. Unless of course someone
. Please search this mail list
(Nabble etc) and Maven Dev to see the entire history of this issue.
Increment version by one, upload it, and allow Maven to find the
updated version the next time your build runs, it will automatically
find and use it.
Wayne
On 9/20/06, Markus KARG <[EMAIL PROTEC
So the policy is "A bug cannot be fixed"?!
Jochen Wiedmann schrieb:
Markus KARG wrote:
If Carlos is able to upload it while I seem not to be, he actually is
in the role of the maintainer.
Where am I going wrong with that assumption?
Your assumption is, that he is able to chang
Barrie Treloar schrieb:
Carlos did tell you who maintains it and the answer is no one.
Carlos is just one of the people who will upload your pom and artifact
if you follow the instructions on the web site.
So you are able to make the necessary changes and get it fixed.
The problem that Jorg
i.e. No on maintains the FOP available in the repo.
It is there as a convenience only.
I might also suggest you adjust your attitude.
Sorry for beeing rude and thank you for telling me.
It wasn't my intention.
But see, I just want to know who is the guy that has write access to the
FOP's po
Wayne Fay schrieb:
As previously mentioned, it is quite honestly not possible to "fix"
that specific version of the pom. For a very brief period of time,
Maven was allowing changes to poms but then realized this was a bad
idea. So instead the proper way to fix issues like this is to actually
rel
That's wrong. Maven automatically creates the correct Class-Path
attributes in the manifest, and it's up to the fop team to
decide what
third party library versions to use.
No! If any library would declare a Class-Path in its deps, you could nearly use
none in combination. Just because
of the thread due to all those that
liked me to help... Strange, isn't it. ;-)
Markus
Wayne Fay schrieb:
He's talking about the release plugin, so that's where I'd start...
Wayne
ps- Maven is a bit of trial by fire... ;-)
On 9/19/06, Markus KARG <[EMAIL PROTECTED]>
it's a common situation that you have to maintain a local repository,
maybe company wide and using a proxy to mirror repo1's contents.
So better you get used to it.
Just think about all those proprietary libs which can't be provided by
repo1 for licensing reasons. Examples are all Sun jars or th
Jörg Schaible schrieb:
Well, probably the development community of the Apache Fop project
can help you. Check the project site [1].
I have asked them.
They don't know.
They even didn't know that FOP is available on that repository.
So someone just put it up there without their knowledg
Carlos Sanchez schrieb:
The repo is mantained in a no guarantees, free time basis, so your
request to get this solved asap because my client needs it doesn't fit
here. There are companies out there that provide commercial support
around maven and will be able to help you in a more commercial
fas
d then set packagin=jboss-ear instead
of ear?
All I'm saying is that packaging for production is more bound by the
PLATFORM the EAR is deployed on then the general SPEC level of
compliance (which again, is merely a minimal set of requirements (
e.g. descriptors and their XML schem
t to
have your own repo to
solve this kind of crisis. Have maven to search artifact first before
going to central
In the mean time, It seems you can fix the problem by fixing the pom
right?
why not submit it back?
-D
On 9/19/06, *Markus KARG* <[EMAIL PROTECTED] <mailto:[EMAIL PR
Which one?
dan tran schrieb:
Please read the doc ;-)
On 9/19/06, *Markus KARG* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
So I shall do mvn -B deploy out what?
Please remind that I am a Maven starter...
If you want me something to try out then I need cl
You want me to submit a new pom.xml for fop-0.20.5 to that JIRA group?
And how do you verify that I didn't do another bug?
I mean, ain't there some kind of quality assurance of repo contents?
dan tran schrieb:
And submit it back to http://jira.codehaus.org/browse/MEV
-D
On 9/19/06, Busch, Hen
Bruno Aranda schrieb:
Well, probably the development community of the Apache Fop project can
help you. Check the project site [1].
I have asked them.
They don't know.
They even didn't know that FOP is available on that repository.
So someone just put it up there without their knowledge!
b
Busch, Hendrik (LNG-MUE) schrieb:
Hi,
This has to be fixed ASAP to make those projects work!
The fix is quite easy, just modify the Class-Path: entry or do "mvn
clean deploy" to push another copy to repo1.maven.org.
The problem is really urgent since we need this and we do not have
write
ac
So I shall do mvn -B deploy out what?
Please remind that I am a Maven starter...
If you want me something to try out then I need clear commands. :-)
dan tran schrieb:
On 9/18/06, Markus KARG <[EMAIL PROTECTED]> wrote:
Dan,
please find my answer inlined.
Thanks a lot
Markus
>
(1) I cannot take care of in my application since I don't know where to
get the dependencies from. The idea behind Maven and Class-Path is that
the user doesn't need to care about.
(2) Why not just correcting the Class-Path in the JAR or the pom.xml? As
you put the the project in the project,
there's no mantainer.
On 9/19/06, Markus KARG <[EMAIL PROTECTED]> wrote:
I need to find out the maintainer of the fop:fop project on
repo1.maven.org.
There is a severe bug in the published JAR that prevents referencing
this project from own projects.
Please either fix the bug or tell me the n
I need to find out the maintainer of the fop:fop project on repo1.maven.org.
There is a severe bug in the published JAR that prevents referencing
this project from own projects.
Please either fix the bug or tell me the name of the maintainer so I can
ask him to fix it!
As there is no JIRA gr
Jörg Schaible schrieb:
The numbering scheme told in BBWM is recommendation only. however,
if you have
-SNAPSHOT at the end, when you deploy it to your internal
repo, who ever
depends on your snapshot artifact will pickup up the latest of your
snapshot automatically depending
your download policy
Franz,
Good day to you, Markus,
For more info regarding maven-release-plugin, you can try and look at [1].
This is the latest (though unreleased) version of that plugin's
documentation. If you have any comments about it, kindly notify us so that
we can improve the documentation.
Thanks,
Fran
Dan,
please find my answer inlined.
Thanks a lot
Markus
This is in contrast to the version scheme told in
"BetterBuildsWithMaven.pdf", so does this mean that the SNAPSHOT
mechanism only checks for the word SNAPSHOT "somewhere" in the
version?
Actually qualifiers will lower
st dash)?
Is there some short description on how to use the release-plugin to
accomplish that (just a code line and a sentence what it does)?
Thanks a lot!
Markus
-D
On 9/18/06, *Markus KARG* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
We are new to Maven2
We are new to Maven2 and are wondering how the naming schema is to be
used correctly. In "BetterBuildsWithMaven.pdf" is told that our schema
shall be "Major.Minor.Fix-Qualifier-Build", (e. g. 1.0.0-beta-1). So we
like to have the qualifier set to "beta-5" now, since we are producing
our fifth b
as an example).
-aps
On 9/18/06, *Markus KARG* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Actually we ARE adding them manually but this thread is about how
we can
make MVN to do that automatically...
Nevertheless, I filed an issue with JIRA in the hope of gett
In "BetterBuildsWithMaven.pdf" I have read the following:
"In the current version scheme, the snapshot (as shown above)
is a special case where the qualifier and build number are both allowed.
In a regular version, you can
provide only the qualifier, or only the build number. It is intended
tha
gt;> work, you will need to be practical about things -- simply add the
>> entry into the application.xml (or whatever file, I'm not familiar
>> with J2EE Client Apps) manually or in the pom.xml and move on with
>> life.
>>
>> Wayne
>>
>> On 9/15/06
Thanks for the URL.
I just filed an issue.
Markus
dan tran schrieb:
or at least open a JIRA against MNG project, documentation component, at
http://jira.codehaus.org, so that we dont
lose track of this issue.
-Dan
On 9/17/06, Markus KARG <[EMAIL PROTECTED]> wrote:
Actually I don&
Actually I don't know how. :-(
dan tran wrote:
> better yet, open a jira and submit a patch
>
> On 9/16/06, Markus KARG <[EMAIL PROTECTED]> wrote:
>>
>> Request:
>>
>> I want to ask to add the following line: JEE / javax.jee / jee
>>
>
I have used the 2.1-SNAPSHOT of the ejb task to create EJB3 JAR.
Since the EAR plugins at the moment doesn't automatically add a
entry for EJB3 JARs (I hope this gets fixed in the next
release), I added the module manually in the pom.xml of my EAR.
But now MVN2 crashes with stack trace and complai
I am currently using the ejb-plugin 2.1-SNAPSHOT since I am using EJB3.
Is there a planned release date for that plugin?
Also I like to know when will there be an EAR plugin release that
supports automatic detection of EJB 3 modules. Currently those are not
detected automatically but need to added
eckout the code from SVN (see
> http://maven.apache.org/plugins/maven-ejb-plugin/source-repository.html)
> 2. build the plugin (issue a "mvn clean install" inside its directory)
> 3. rebuild your project and see if it works
>
> Good luck!
>
> On Sat, 2006-09-16 at 16:3
User list.
>> >> 2. File a JIRA Enhancement report and hope someone looks at your
>> issue
>> >> and decides it is worth spending some time to implement for you.
>> >> 3. Write the code yourself, then file a JIRA with your changes
>> >> attach
was introduced in 2.1-SNAPSHOT which is not yet published.
Is that right?
When will 2.1 be released?
Markus
Arik Kfir wrote:
> Hi Markus,
>
> What version of the plugin are you using? Also, a dump of the complete
> error might be useful too.
>
> On Sat, 2006-09-16 at 11:22 +0200,
Dear Maven Community,
Today I have seen on the Maven web site
(http://maven.apache.org/plugins/maven-ejb-plugin/ejb-mojo.html) that
the ejb plugin is able to package EJB3 compliant JARs. So I wanted to
try that out and have set up a sample project.
Unfortunately it seems it is not working as expe
Dear Maven Community,
Today I asked the Glassfish community (= Java EE 5 Reference
Implementation) to publish a j2ee.jar (= Java EE 5 APIs) on the Maven 2
central repository to allow coders to easily use the Java EE technology
with Maven, without the need to download the complete SDK manually.
A
Request:
I want to ask to add the following line: JEE / javax.jee / jee
Justification:
Since Version 1.5 of the Java Enterprise Edition, the "2" is removed.
The specification officially is called "Java Enterprise Edition" (JEE).
The maven repository should take respect of this decision and add t
.
>>
>> Pick one from above and do it. In the mean time, if you want things to
>> work, you will need to be practical about things -- simply add the
>> entry into the application.xml (or whatever file, I'm not familiar
>> with J2EE Client Apps) manually or i
how, if you want a jar to be included in the application.xml, just
configure the plugin acccordingly (includeInApplicationXml) [1]
Cheers,
Stéphane
[1] http://maven.apache.org/plugins/maven-ear-plugin/howto.html
On 9/15/06, Markus KARG <[EMAIL PROTECTED]> wrote:
I am using the EAR packaging
I am using the EAR packaging to let Mvn2 create an .ear file plus
automatically create an application.xml inside of it.
It detects all my EJB modules, but it doesn't detect that one of the
included JARs is not a utility JAR but in fact a "J2EE Client
Application JAR".
Maybe the packaging type I
methods into xml :-)
Btw Franz, I think you got the jira issue mixed up. The jira issue you
created should probably be for the Jar Plugin, not for the Javadoc plugin
:-)
Hope this helps! :-)
Thanks,
Deng
Markus Karg wrote:
Franz,
I think what Hendrik meant to say is that [1] has a link
Franz,
I think what Hendrik meant to say is that [1] has a link to the
MavenArchiveConfiguration javadoc ([2]). And if you analyze it, it has
addManifestEntries and addManifestEntry for the and
tags respecitvely. Thus, it is worth a try to see if
addManifestSections, and addManifestSection cor
documented here:
http://maven.apache.org/plugins/maven-ejb-plugin/ejb-mojo.html
Regards,
Markku
Markus KARG wrote:
Markku,
thanks a lot for your kind help!
We will try out tomorrow!
Thanks a lot
Markus
Markku Saarela wrote:
Configure you ejb plugin like this:
maven
nd that you can
selectively filter out classes (bean classes, etc.) from the client jar
(but not dependencies carried over from the EJB or any of its transitive
dependencies).
-Daryl
-Original Message-----
From: Markus KARG [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 11:5
> true
>
>
> true
>
>
>
>
>
> then in you module where you have dependency of this ejb client jar :
>
>
>
> your_group_id
> dbserviceejb
> ${version}
> ejb-client
>
>
&
Hendrik and Franz,
thanks a lot for your kind help! I indeed will try out tomorrow.
But please one more question: How is the relationship between javadocs
and pom structure? I did not yet understand how I can guess from the
javadocs to the pom structure actually.
Thanks a lot!
Markus
Hendrik Bu
tion on the maven-ejb-plugin generates a
> pom for the client with way too many dependencies (includes all of the
> EJBs dependencies) and so that we could compile the EJB in 1.5 but
> compile the client under 1.4.
>
>
> -Original Message-
> From: Markus KARG [mail
Franz, are you joking?
Do you see any tags on the URLs you posted?
Maybe I am blind, but I don't see any, actually.
Have Fun
Markus
franz see schrieb:
Markus Karg wrote:
I need to add the following information to the MANIFEST.MF file of a JAR:
Name: S1
N1: V1
Name: S2
N2: V2
Ho
the client under 1.4.
-Original Message-----
From: Markus KARG [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 4:23 AM
To: Maven Users List
Subject: EJB Client JAR
Using Maven2's ejb package, I was able to create an ejb-jar from my
sources.
But not I want Maven to create
I need to add the following information to the MANIFEST.MF file of a JAR:
Name: S1
N1: V1
Name: S2
N2: V2
How can I do that?
I tried it this way but it doesn't work:
org.apache.maven.plugins
maven-jar-plugin
true
t
Great, thanks a lot!
In fact this was exactly I was looking for!
:-)
Markus
Max Bowsher schrieb:
Markus KARG wrote:
I have added a dependency to FOP-0.20.5 (from the maven main
repository) to my project, using "compile" scope.
I can compile and package my jar.
But in the jar t
Using Maven2's ejb package, I was able to create an ejb-jar from my sources.
But not I want Maven to create an "EJB Client JAR", that only contains
the interfaces, and make another JAR dependent of that "EJB Client JAR"
(by means of Class-Path: entry in MANIFEST.MF).
How to do that?
begin:vcar
I have added a dependency to FOP-0.20.5 (from the maven main repository)
to my project, using "compile" scope.
I can compile and package my jar.
But in the jar there is no "Class-Path: fop-0.20.5.jar" entry created by
mvn, so at runtime "java -jar my.jar" will fail since it doesn't know
where t
( without version )
to your designated place.
-Dan
On 9/14/06, *Markus KARG* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
We are running Maven 2 and need to use some third party Java
component.
That component actually is delivered as a windows .dll file, sin
We are running Maven 2 and need to use some third party Java component.
That component actually is delivered as a windows .dll file, since it is
implemented in a native way by JNI.
So we do not have the c++ source code but only the .dll.
The dll is needed for both, compilation and runtime.
How
and as such, the JAR plugin is your best bet! :D
>
> -aps
>
> On 9/8/06, Markus KARG <[EMAIL PROTECTED]> wrote:
>>
>> Alexandre Russel wrote:
>> >>>> According to "BetterBuildsWithMaven.pdf" I switched from
>> >>>> ejb to ej
Alexandre Russel wrote:
According to "BetterBuildsWithMaven.pdf" I switched from
ejb to ejb3. Unfortunately
>>> change it to jar.
>>> Alex
>>>
>> You mean there is no difference between ejb3 and jar? For what is ejb3
>> good then?
>>
> no, I mean the packaging is
ory feature (Glassfish obviously does).
Well, I am not an EJB3 expert, so actually I do not know what EJB 3.0
spec mandates the packaging to be. So is there really no difference to a
simple JAR? For what is that planned ejb3 plugin good then?
>
> -aps
>
> On 9/7/06, Markus KARG <[EM
AFAIK it should be possible to write a plugin that handles .net
flavours, since Maven is 100% pure Java, and Java can use JNI or exec()
to call native tools. So even there might be no such plugin yet, you
might want to contribute one?
Lakshman Srilakshmanan wrote:
> Hi All,
>
> My company has a fa
Actually I didn't want to have a ejb-jar.xml any longer with EJB3.
What about the status of that ejb3 plugin: When will it be finished?
I mean, this is a thing I expect Maven to do for me.
Takashi Nishigaya wrote:
> The maven-ear-plugin does not recognized the jar project as ejb3 module.
> If you
Alexandre Russel wrote:
>> According to "BetterBuildsWithMaven.pdf" I switched from
>> ejb to ejb3. Unfortunately
>>
> change it to jar.
> Alex
>
You mean there is no difference between ejb3 and jar? For what is ejb3
good then?
Markus
smime.p7s
Description: S/MIME Cryptographic Signature
The JCA 1.5 specification allows a RAR not only to contain the
implementation.jar but also to contain an interfaces.jar containing the
implemented interfaces. The interfaces.jar is useful for developers that
just need to have access to the interfaces (like MDB coders) but not to
the implementat
Hi,
I'm new to maven and have some problems, I hope you can help me.
I have migrated my J2EE 1.4 application to JEE 5.
Now I need to migrate my mvn2 pom.xml file.
So I changed the following:
1) Switched compiler from default Java 1.3 to Java 5
org.apache.maven.plug
101 - 171 of 171 matches
Mail list logo
