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
build
plugins
plugin
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
Alexandre Russel wrote:
According to BetterBuildsWithMaven.pdf I switched from
packagingejb/packaging to packagingejb3/packaging. 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:
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
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 fair
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 [EMAIL PROTECTED] wrote:
Actually I didn't want to have a ejb-jar.xml any longer
Alexandre Russel wrote:
According to BetterBuildsWithMaven.pdf I switched from
packagingejb/packaging to packagingejb3/packaging. 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
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
packagingejb/packaging to packagingejb3/packaging.
Unfortunately
change it to jar.
Alex
You mean there is no difference
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
it ( 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, since
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 to
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:vcard
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
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:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
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 an EJB Client
Franz, are you joking?
Do you see any section 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
-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 [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14
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
dependency
groupIdyour_group_id/groupId
artifactIddbserviceejb/artifactId
version${version}/version
typeejb-client/type
/dependency
/dependencies
regards,
Markku
Markus KARG wrote:
Actually I don't want to do that but I want to know and do the
maven-ejb
and 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:51 AM
as 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:
build
plugins
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 manifestEntries and
manifestEntry tags respecitvely. Thus, it is worth a try to see if
the elements that you
need to set. This is basically a mapping of the 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 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
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 to let Mvn2 create an .ear file plus
automatically create an application.xml inside
) manually or in the pom.xml and move on with
life.
Wayne
On 9/15/06, Markus KARG [EMAIL PROTECTED] wrote:
No I do not mean ejb-client but J2EE Client Application:
What you mean is a JAR containing the interfaces of the EJBs, but
what I
mean is a standalone (Swing) application that is to be run
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 the
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
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
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, Markus KARG wrote
, Markus KARG [EMAIL PROTECTED] wrote:
Alexander,
please read J2EE 1.4 specification: The J2EE Client Application
Descriptor is a mandatory part of J2EE 1.4. It is no BEA invention.
Quoted from Java(tm) 2 Platform Enterprise Edition Specification, v1.4
chapter 9.7 J2EE Application Client XML
://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:38 +0200, Markus KARG wrote:
Arik,
I have not customized the version
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
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
ejbModule 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
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
Justification:
Since Version 1.5 of the Java Enterprise Edition, the 2
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't know
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 in the pom.xml and move on with
life.
Wayne
On 9/15/06, Markus KARG
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
that
-- 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, Markus KARG [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote
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 beta
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 and are wondering how the naming schema
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 the
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,
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
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
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 name of the maintainer
(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,
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
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
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!
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,
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 clear commands
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 PROTECTED] wrote
on then the general SPEC level of
compliance (which again, is merely a minimal set of requirements (
e.g. descriptors and their XML schema) to be compliant that can be
implemented several different ways).
Cheers!
-aps
On 9/19/06, *Markus KARG* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote
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
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
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
... 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] wrote:
Which one?
dan tran schrieb:
Please read the doc ;-)
On 9/19/06
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
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
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
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
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 change files
. 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 PROTECTED] wrote
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 else has
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. What else did
you expect
/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 one more reason
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
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
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
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
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
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?
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
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
not possible to change
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:
When you build A you don't know
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, that you
, 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 using -x.y.z versions).
I'll
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
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
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
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
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
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
My project is dependent of some library. I want to always use the latest
bugfix but not any new features. So I added version[1.0,1.1)/version
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
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 the
latest
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 ASCII ! is A
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?
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
forward.
Ron
On 11/02/2012 7:11 AM, Markus KARG wrote:
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
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 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
Maven 3.0.4 is producing application.xml containing module entries for
some dependencies (RAR modules), but which is missing module 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
I've had this problem in the past is forgetting
to specify:
typeejb/type
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 module entries
for some dependencies (RAR modules), but which
extension
On Sunday, 4 March 2012, Markus KARG mar...@headcrashing.eu wrote:
You are right, when adding typeejb/type it is working! I missed
the
fact
that maven coordinates include the packaging, while the default
packaging
is
typejar/type. The odd thing is that dependency resolution
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 addClasspathtrue/addClasspath so the client will
find the needed libraries. When those libraries are SNAPSHOTs, the
created manifest entry contains
, 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 k...@quipsy.de wrote:
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
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
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
Betreff
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, 2012 at 2:27 AM, Markus Karg k
1 - 100 of 167 matches
Mail list logo
