How to get the local repository directory
Hi, I am trying to get the local repository directory with "localRepository" parameter but the result is not the expected: [local] -> file://C:\Documents and Settings\miroslav\.m2\repository The problem is that before the directory there is a prefix "[local] -> file://" which is the problem. Any ideas and help? Thank you in advance. I need of the local repository directory because I would like to start one ant script where I am using "" condition and for that condition I need of third party library "ant-contrib" which I must declare in tag. To do that in "maven-antrun-plugin" I am using dependencies like that: ant-contrib ant-contrib 20020829 This guarantee that the library will be in the local repository. Then I have to use the local repository and taskdef to put on the class path this library to be able to use condition. Is there another way for that? Can I replace "if" condition with something else? Regards, Miro. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jars in the custom ear not getting referenced at compile time
Hi guys,
please help me in getting the solution.
1) i had put many jars like struts1.2.9.jar , junti.jar etc in a lib
folder. then make it as colib.ear.
2) Then try to install as
mvn install:install-file –DgroupId=repackage.oracle.ebilling
–DartifactId=colib –Dversion=6.0 –Dpackaging=ear –Dfile=colib.EAR
3) Then I found colib-6.0.EAR has been created in my repository as
repo3\repackage\oracle\ebilling\ebilling\6.0\ colib-6.0.EAR
4) when i tried to compile with mvn packaging it gives that package
org.apache.struts.action does not exist , though it is in the colib-6.0.ear.
as it does not found the jars in the classpath
5) my pom file as below. and i have attached the pom file.
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
root.project
practice-war
war
1.0
test-webapp
repackage.oracle.ebilling
colib
6.0
ear
provided
target
target/classes
maven2example_testfinalweb
src/main/java
$\{basedir\}/ebilling
ebilling
org.apache.maven.plugins
maven-compiler-plugin
1.6
1.6
org.apache.maven.plugins
maven-jar-plugin
true
lib
org.apache.maven.plugins
maven-war-plugin
2.0.2
true
**/images
WEB-INF/web.xml,index.*
target/war/work
org.apache.maven.plugins
maven-clean-plugin
2.2
auto-clean
validate
clean
org.codehaus.mojo
dependency-maven-plugin
unpack-eBilling-App
process-resources
unpack
repackage.oracle.ebilling
colib
6.0
ear
org.apache.maven.plugins
maven-ear-plugin
eBilling App
(C)Copyright 1999-2007 Oracle(R), Inc. All
Rights Reserved.
6.0
${project.build.directory}/dependency
${project.build.directory}/dependency/META-INF/application.xml
false
repackage.oracle.ebilling
colib
lib
http://www.nabble.com/file/p20008047/pom.xml pom.xml
--
View this message in context:
http://www.nabble.com/jars-in-the-custom-ear-not-getting-referenced-at-compile-time-tp20008047p20008047.ht
Help needed. JSP Pre-compilation gets stuck with maven.
Hi, I am using maven-2.0.8 with java-1.5.0_15 and maven jspc plugin of tomcat5. My pom.xml entry for jspc looks like this: org.codehaus.mojo.jspc jspc-maven-plugin 2.0-alpha-1 compile compile org.codehaus.mojo.jspc jspc-compiler-tomcat5 2.0-alpha-1 1.5 1.5 "mvn install" gets stuck after the following line (sometimes with the warnings and sometimes without) [INFO] Compiling JSP source files to /rhel5pdi/home/bkalathu/fps/workspaces/fpslitev2/platform-apps/cust-service/ target/jsp-source log4j:WARN No appenders could be found for logger (org.apache.jasper.JspC). log4j:WARN Please initialize the log4j system properly. When I see the process status of mvn, "ps aux | grep java", it shows the process in sleeping status. I don't know where I am going wrong. I am using RHEL5. Thanks & Regards, Bhargava
Re: Failure to create a WAR file
I use mvn install. I just mean that when I use war in my POM file my classes for some uncertain reason don't resolve classes from other libraries though I use Wendy Smoak-3 wrote: > > [moved from [EMAIL PROTECTED] > > On Wed, Oct 15, 2008 at 5:58 AM, svenson <[EMAIL PROTECTED]> wrote: > >> I've encountered the following problem. I work on a web project so to >> deploy >> it on a server I need to create a WAR file. My project depends on a few >> libraries and a few projects created by other developers( their projects >> also have dependencies). Whenever I use war in my >> project's POM file, my project doesn't "see" classes from the projects of >> my >> colleagues but when I switch to jar it goes >> perfectly >> fine. What should I do to create a WAR file by Maven ? Thanks in advance. > > What do you mean by your project doesn't "see" classes from the other > projects? What command did you execute, and what error do you get? > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Re%3A-Failure-to-create-a-WAR-file-tp19993976p20007257.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module site descriptor ignored in multi-module project?
Reported http://jira.codehaus.org/browse/MSITE-364.
Thanks again for the help.
brettporter wrote:
>
> If there isn't one already, yes please.
>
> On 16/10/2008, at 7:40 AM, jaxzin wrote:
>
>>
>> I can confirm that downgrading to 2.0-beta-5 fixes my issue and the
>> module's
>> site is generated with it's site descriptor. Thanks Brett! Do you
>> need me
>> to open a JIRA ticket?
>>
>>
>>
>> brettporter wrote:
>>>
>>> Does it happen to work with 2.0-beta-5? I know 2.0-beta-6 regressed
>>> in
>>> this regard, but I thought it was fixed.
>>>
>>> - Brett
>>>
>>> On 16/10/2008, at 7:33 AM, jaxzin wrote:
>>>
No, it's ignoring the module's site descriptor (mymodule/src/site/
site.xml)
completely. We do take advantage of the site descriptor inheritance
and
that's working properly with inheriting the site descriptor from the
top-level project's parent (aka grandparent??) but again the
module's site
is using the top-level's site descriptor and ignoring the apt files
in the
module as well.
More concretely:
Top-level site.xml (src/site/site.xml):
${project.name}
${project.url}
Module's site.xml (mymodule/src/site/site.xml):
${project.name}
${project.url}
If I run 'mvn site' from the top-level dir, then the file
"mymodule/target/site/index.html" has a menu 'Parent Test' and no
menu
'Overview'.
I've tested this with 2.0-beta-7 and 2.0-beta-6.
brettporter wrote:
>
> No, but it's expected that it would be inherited and merged. Is
> that
> what you are seeing?
>
> - Brett
>
> On 16/10/2008, at 7:17 AM, jaxzin wrote:
>
>>
>> I've deployed the site of a multi-module project and found that
>> the
>> sites for
>> the modules are using the site descriptor for the top-level
>> project
>> rather
>> than each modules site descriptor that I've defined. Is that the
>> expected
>> behavior?
>> --
>> View this message in context:
>> http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001779.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>> --
>>> Brett Porter
>>> [EMAIL PROTECTED]
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001932.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p2000.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module site descriptor ignored in multi-module project?
If there isn't one already, yes please.
On 16/10/2008, at 7:40 AM, jaxzin wrote:
I can confirm that downgrading to 2.0-beta-5 fixes my issue and the
module's
site is generated with it's site descriptor. Thanks Brett! Do you
need me
to open a JIRA ticket?
brettporter wrote:
Does it happen to work with 2.0-beta-5? I know 2.0-beta-6 regressed
in
this regard, but I thought it was fixed.
- Brett
On 16/10/2008, at 7:33 AM, jaxzin wrote:
No, it's ignoring the module's site descriptor (mymodule/src/site/
site.xml)
completely. We do take advantage of the site descriptor inheritance
and
that's working properly with inheriting the site descriptor from the
top-level project's parent (aka grandparent??) but again the
module's site
is using the top-level's site descriptor and ignoring the apt files
in the
module as well.
More concretely:
Top-level site.xml (src/site/site.xml):
${project.name}
${project.url}
Module's site.xml (mymodule/src/site/site.xml):
${project.name}
${project.url}
If I run 'mvn site' from the top-level dir, then the file
"mymodule/target/site/index.html" has a menu 'Parent Test' and no
menu
'Overview'.
I've tested this with 2.0-beta-7 and 2.0-beta-6.
brettporter wrote:
No, but it's expected that it would be inherited and merged. Is
that
what you are seeing?
- Brett
On 16/10/2008, at 7:17 AM, jaxzin wrote:
I've deployed the site of a multi-module project and found that
the
sites for
the modules are using the site descriptor for the top-level
project
rather
than each modules site descriptor that I've defined. Is that the
expected
behavior?
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001779.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001932.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module site descriptor ignored in multi-module project?
I can confirm that downgrading to 2.0-beta-5 fixes my issue and the module's
site is generated with it's site descriptor. Thanks Brett! Do you need me
to open a JIRA ticket?
brettporter wrote:
>
> Does it happen to work with 2.0-beta-5? I know 2.0-beta-6 regressed in
> this regard, but I thought it was fixed.
>
> - Brett
>
> On 16/10/2008, at 7:33 AM, jaxzin wrote:
>
>>
>> No, it's ignoring the module's site descriptor (mymodule/src/site/
>> site.xml)
>> completely. We do take advantage of the site descriptor inheritance
>> and
>> that's working properly with inheriting the site descriptor from the
>> top-level project's parent (aka grandparent??) but again the
>> module's site
>> is using the top-level's site descriptor and ignoring the apt files
>> in the
>> module as well.
>>
>> More concretely:
>>
>> Top-level site.xml (src/site/site.xml):
>>
>>
>>
>>${project.name}
>>${project.url}
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Module's site.xml (mymodule/src/site/site.xml):
>>
>>
>>
>>${project.name}
>>${project.url}
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> If I run 'mvn site' from the top-level dir, then the file
>> "mymodule/target/site/index.html" has a menu 'Parent Test' and no menu
>> 'Overview'.
>>
>> I've tested this with 2.0-beta-7 and 2.0-beta-6.
>>
>>
>>
>>
>>
>> brettporter wrote:
>>>
>>> No, but it's expected that it would be inherited and merged. Is that
>>> what you are seeing?
>>>
>>> - Brett
>>>
>>> On 16/10/2008, at 7:17 AM, jaxzin wrote:
>>>
I've deployed the site of a multi-module project and found that the
sites for
the modules are using the site descriptor for the top-level project
rather
than each modules site descriptor that I've defined. Is that the
expected
behavior?
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>> --
>>> Brett Porter
>>> [EMAIL PROTECTED]
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001779.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001932.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module site descriptor ignored in multi-module project?
Does it happen to work with 2.0-beta-5? I know 2.0-beta-6 regressed in
this regard, but I thought it was fixed.
- Brett
On 16/10/2008, at 7:33 AM, jaxzin wrote:
No, it's ignoring the module's site descriptor (mymodule/src/site/
site.xml)
completely. We do take advantage of the site descriptor inheritance
and
that's working properly with inheriting the site descriptor from the
top-level project's parent (aka grandparent??) but again the
module's site
is using the top-level's site descriptor and ignoring the apt files
in the
module as well.
More concretely:
Top-level site.xml (src/site/site.xml):
${project.name}
${project.url}
Module's site.xml (mymodule/src/site/site.xml):
${project.name}
${project.url}
If I run 'mvn site' from the top-level dir, then the file
"mymodule/target/site/index.html" has a menu 'Parent Test' and no menu
'Overview'.
I've tested this with 2.0-beta-7 and 2.0-beta-6.
brettporter wrote:
No, but it's expected that it would be inherited and merged. Is that
what you are seeing?
- Brett
On 16/10/2008, at 7:17 AM, jaxzin wrote:
I've deployed the site of a multi-module project and found that the
sites for
the modules are using the site descriptor for the top-level project
rather
than each modules site descriptor that I've defined. Is that the
expected
behavior?
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001779.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module site descriptor ignored in multi-module project?
No, it's ignoring the module's site descriptor (mymodule/src/site/site.xml)
completely. We do take advantage of the site descriptor inheritance and
that's working properly with inheriting the site descriptor from the
top-level project's parent (aka grandparent??) but again the module's site
is using the top-level's site descriptor and ignoring the apt files in the
module as well.
More concretely:
Top-level site.xml (src/site/site.xml):
${project.name}
${project.url}
Module's site.xml (mymodule/src/site/site.xml):
${project.name}
${project.url}
If I run 'mvn site' from the top-level dir, then the file
"mymodule/target/site/index.html" has a menu 'Parent Test' and no menu
'Overview'.
I've tested this with 2.0-beta-7 and 2.0-beta-6.
brettporter wrote:
>
> No, but it's expected that it would be inherited and merged. Is that
> what you are seeing?
>
> - Brett
>
> On 16/10/2008, at 7:17 AM, jaxzin wrote:
>
>>
>> I've deployed the site of a multi-module project and found that the
>> sites for
>> the modules are using the site descriptor for the top-level project
>> rather
>> than each modules site descriptor that I've defined. Is that the
>> expected
>> behavior?
>> --
>> View this message in context:
>> http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001779.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module site descriptor ignored in multi-module project?
No, but it's expected that it would be inherited and merged. Is that what you are seeing? - Brett On 16/10/2008, at 7:17 AM, jaxzin wrote: I've deployed the site of a multi-module project and found that the sites for the modules are using the site descriptor for the top-level project rather than each modules site descriptor that I've defined. Is that the expected behavior? -- View this message in context: http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Module site descriptor ignored in multi-module project?
I've deployed the site of a multi-module project and found that the sites for the modules are using the site descriptor for the top-level project rather than each modules site descriptor that I've defined. Is that the expected behavior? -- View this message in context: http://www.nabble.com/Module-site-descriptor-ignored-in-multi-module-project--tp20001464p20001464.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
can't rev the version of multi-module project
Hi.
I just converted my project to a Maven build. I started with version
1.8-SNAPSHOT of my project and I'm trying to cut a release for version
1.8.
My project is quite complex: multi-module and modules have
dependencies on one another. So to make it simple, there's the parent
with 3 child modules: child1, child2, and child3. All children inherit
from the parent module. child1 has no dependencies, child2 has a
dependency on child1 and child3 has a dependency on child2.
So, when I cut a release, all pom files are updated to the new
version, 1.8. The child poms, since they don't explicitly declare a
version, are updated to 1.8 by changing the inheritance of the parent
to version 1.8. The dependencies of the child poms are updated because
they're using a property reference, ${project.version}, to declare
their dependencies on their siblings.
But now I try to do a local install and get the "dependency can't be
resolved but has been found in the reactor" message and the build
fails because child3 can't resolve its dependency on child1 version
1.8.
Is my issue the same as http://jira.codehaus.org/browse/MNG-3685 ?
If so, how do I get Maven 2.0.11 installed? If not, how am I supposed
to cut a release? Is my project set up wrong?
Thanks in advance.
-Ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-release-plugin not able to locate extensions
Wendy Smoak wrote: On Wed, Oct 15, 2008 at 3:50 AM, Sahoo <[EMAIL PROTECTED]> wrote: As you can see, it uses a packaging type called distribution-fragment, which is understood by our own extension called org.glassfish.build:maven-glassfish-extension. We build the extension as part of the same reactor. Try configuring the release plugin to run all the way through 'install' rather than through 'integration-test' which is the default. This isn't ideal, as you're building the artifact with the released version in the filename _before_ the 'perform release' step, but there are certain situations where it can't find things in the reactor. First of all, thank you very much for taking the time to read my email and suggesting something. I tried your suggestion as shown below: mvn -o release:prepare -DautoVersionSubmodules=true -DdryRun=true -DpreparationGoals="clean install" , but it fails with same error. Thanks, Sahoo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-release-plugin not able to locate extensions
On Wed, Oct 15, 2008 at 3:50 AM, Sahoo <[EMAIL PROTECTED]> wrote: > As you can see, it uses a packaging type called distribution-fragment, which > is understood by our own extension called > org.glassfish.build:maven-glassfish-extension. We build the extension as > part of the same reactor. Try configuring the release plugin to run all the way through 'install' rather than through 'integration-test' which is the default. This isn't ideal, as you're building the artifact with the released version in the filename _before_ the 'perform release' step, but there are certain situations where it can't find things in the reactor. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Help Required] [Fwd: maven-release-plugin not able to locate extensions]
Hi,
Appreciate any suggestion to solve this problem. I am stuck because of
this issue.
Thanks,
Sahoo
--- Begin Message ---
Hi,
I am having problems using maven-release-plugin and I need some help
urgently. While doing a release:prepare, maven is not able to locate an
extension. I am using maven 2.0.7 on JDK 1.5. Given below are the
essential details of the pom.xml that's facing the issue:
org.glassfish.ejb
ejb
3.0-Prelude
3.0-Prelude
ejb-timer-databases
distribution-fragment
org.glassfish.build
maven-glassfish-extension
${project.version}
As you can see, it uses a packaging type called distribution-fragment,
which is understood by our own extension called
org.glassfish.build:maven-glassfish-extension. We build the extension as
part of the same reactor. For some other reason, we don't use
true in our plugin configuration. I am able to
do a normal build successfully, but when I am trying to prepare a
release using maven-release-plugin, it fails with following error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.glassfish.build
-DartifactId=maven-glassfish-extension \
-Dversion=3.0-Prelude -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy
the file there: mvn deploy:deploy-file
-DgroupId=org.glassfish.build -DartifactId=maven-glassfish-extension \
-Dversion=3.0-Prelude -Dpackaging=jar
-Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude
2)
org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
--
1 required artifact is missing.
for artifact:
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude
What is surprising is that it fails even when I have built the extension
separately and installed it in my local repository. How can I avoid this
error?
Thanks,
Sahoo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk/tags/branches: root vs. project level
On Wed, Oct 15, 2008 at 08:53, Andy Law <[EMAIL PROTECTED]> wrote: > hilco wrote: >>> If your projects genuinely are stand-alone projects then I would suggest >>> that you create separate repositories for each of them, although that may >>> be >>> harder to do if you already have history within an existing repository. I >>> have not done so, but I imagine that it must be possible to clone a >>> repository and then remove extra stuff from each copy such that you >>> reduce >>> to 1 project per repo? >> >> You shouldn't create multiple repositories without *very* good >> reasons. Multiple repositories just means having to duplicate >> authentication, backup setup, etcetera. Moreover, any kind of copying >> between projects is much harder that way. If you are working on >> multiple projects you'll eventually run into refactoring cases where >> you want multiple projects to reuse some shared code. That's a >> no-brainer in one repository but all but impossible (i.e. without >> losing history) in multiple repositories. > > No problem with authentication and backup in our hands - its perfectly > possible to run multiple repositories within the same setup on the same > machine. I didn't say it was impossible, I said it was more work for no gain. > Some would also suggest that your use case of shared code screams out for a > new artifact in its own independent space and shared across the projects > that way. Obviously, I agree. It's just that our definition of "independent space" differs. :-) > hilco wrote: >> And what do you gain? There's little advantage to having a repository >> per project. > > Independence of code, security from accidental updates whilst the entire > repository is checked out :o} Code independence has nothing to do with repositories. If you need a dependency in your code then whether said dependency is in a separate repository isn't relevant. I don't understand the accidental update argument. You check out entire repositories??? And what's an "accidental" update? You may have a seriously weird way of working that I simply have never considered. ;-) > Like perl, there's always more than one way to do it in the maven and > subversion world. And no way is right or wrong as long as it works for you > (or doesn't). Sure, I'm just trying to save people some work. But I don't have to do their work so it's all fine with me. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk/tags/branches: root vs. project level
On Wed, Oct 15, 2008 at 08:59, Graham Leggett <[EMAIL PROTECTED]> wrote: > Hilco Wijbenga wrote: >> And what do you gain? There's little advantage to having a repository >> per project. > > One of the key advantages of having one repository per project is the > ability to take a particular project offline and archive it at some point in > the future. Smells like YAGNI except for the "disk space at a premium" below. > This is important in setups where disk space use is likely to be significant > over time, such as when working with graphics within a project, or other > binary data that cannot be efficiently stored as diffs. That's the only good reason I can see: projects that are so inherently different that sharing is not going to happen. > This can also be important where disk space is at a premium, such as when > disk space is hosted by a third party. Fair enough (although I would be very uncomfortable having the crown jewels under the control of some 3rd party). You mention a very special use case for which I would agree with your assessment. Usually, Subversion stores code in a local environment and multiple repositories don't make sense there. It's just more work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk/tags/branches: root vs. project level
Hilco Wijbenga wrote: You shouldn't create multiple repositories without *very* good reasons. Multiple repositories just means having to duplicate authentication, backup setup, etcetera. Moreover, any kind of copying between projects is much harder that way. If you are working on multiple projects you'll eventually run into refactoring cases where you want multiple projects to reuse some shared code. That's a no-brainer in one repository but all but impossible (i.e. without losing history) in multiple repositories. And what do you gain? There's little advantage to having a repository per project. One of the key advantages of having one repository per project is the ability to take a particular project offline and archive it at some point in the future. This is important in setups where disk space use is likely to be significant over time, such as when working with graphics within a project, or other binary data that cannot be efficiently stored as diffs. This can also be important where disk space is at a premium, such as when disk space is hosted by a third party. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: trunk/tags/branches: root vs. project level
hilco wrote: > >> If your projects genuinely are stand-alone projects then I would suggest >> that you create separate repositories for each of them, although that may >> be >> harder to do if you already have history within an existing repository. I >> have not done so, but I imagine that it must be possible to clone a >> repository and then remove extra stuff from each copy such that you >> reduce >> to 1 project per repo? > > You shouldn't create multiple repositories without *very* good > reasons. Multiple repositories just means having to duplicate > authentication, backup setup, etcetera. Moreover, any kind of copying > between projects is much harder that way. If you are working on > multiple projects you'll eventually run into refactoring cases where > you want multiple projects to reuse some shared code. That's a > no-brainer in one repository but all but impossible (i.e. without > losing history) in multiple repositories. > > No problem with authentication and backup in our hands - its perfectly possible to run multiple repositories within the same setup on the same machine. Some would also suggest that your use case of shared code screams out for a new artifact in its own independent space and shared across the projects that way. hilco wrote: > > And what do you gain? There's little advantage to having a repository > per project. > > Independence of code, security from accidental updates whilst the entire repository is checked out :o} Like perl, there's always more than one way to do it in the maven and subversion world. And no way is right or wrong as long as it works for you (or doesn't). Later, Andy -- View this message in context: http://www.nabble.com/trunk-tags-branches%3A--root-vs.--project-level-tp19989397p19996403.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk/tags/branches: root vs. project level
On Wed, Oct 15, 2008 at 04:41, Andy Law <[EMAIL PROTECTED]> wrote: > Stefan Fritz-2 wrote: > The main clincher is that we generally run all our sub-modules as children > of a parent super-module. That's only possible with the root approach. Nonsense, you can create any kind of combination using svn:externals. It might even be advisable to always create a project (trunk/tags/branches) per module (allowing you to release separate parts should the need arise) and create an extra umbrella project (using a modules build) using svn:externals when and where that makes sense. But you could go the other way as well. It's mostly a matter of personal preference. As long as all projects/modules are in the same repository going back and forth is easy. See what works and adjust accordingly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk/tags/branches: root vs. project level
On Wed, Oct 15, 2008 at 06:16, Andy Law <[EMAIL PROTECTED]> wrote: > Stefan Fritz-2 wrote: >> The main clincher is that we generally run all our sub-modules as > children of a parent super-module. That's only possible with the root approach. >> >> or you define trunk/tags/branches per module-group instead of per project >> as you would do for standalone projects ;-) > > If your projects genuinely are stand-alone projects then I would suggest > that you create separate repositories for each of them, although that may be > harder to do if you already have history within an existing repository. I > have not done so, but I imagine that it must be possible to clone a > repository and then remove extra stuff from each copy such that you reduce > to 1 project per repo? You shouldn't create multiple repositories without *very* good reasons. Multiple repositories just means having to duplicate authentication, backup setup, etcetera. Moreover, any kind of copying between projects is much harder that way. If you are working on multiple projects you'll eventually run into refactoring cases where you want multiple projects to reuse some shared code. That's a no-brainer in one repository but all but impossible (i.e. without losing history) in multiple repositories. And what do you gain? There's little advantage to having a repository per project. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failure to create a WAR file
[moved from [EMAIL PROTECTED] On Wed, Oct 15, 2008 at 5:58 AM, svenson <[EMAIL PROTECTED]> wrote: > I've encountered the following problem. I work on a web project so to deploy > it on a server I need to create a WAR file. My project depends on a few > libraries and a few projects created by other developers( their projects > also have dependencies). Whenever I use war in my > project's POM file, my project doesn't "see" classes from the projects of my > colleagues but when I switch to jar it goes perfectly > fine. What should I do to create a WAR file by Maven ? Thanks in advance. What do you mean by your project doesn't "see" classes from the other projects? What command did you execute, and what error do you get? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: skip tests in a single goal
Hi Martin, thanks for your answer, that helped a bit, now I have a build section and a reporting section in my pom with this configurations (see below), works fine, but the problem really was is that my cobertura plugin which by default, executes the tests again...I didn't realize that before... Anyone knows howto avoid this? When setting true in the build section or -Dmaven.test.skip=true ALL tests are skipped, in the deploy goal and the site goal. Greetings, Simon. ... org.apache.maven.plugins maven-surefire-report-plugin 2.4.3 ... AND ... org.apache.maven.plugins maven-surefire-report-plugin 2.4.3 report-only org.codehaus.mojo cobertura-maven-plugin 2.2 xml html ... -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Baptiste MATHUS Gesendet: Mittwoch, 15. Oktober 2008 13:23 An: Maven Users List Betreff: Re: skip tests in a single goal Or maybe configuring the report "report-only" (corresponding to mvn surefire-report:report-only) could do the trick. It was specifically developed to workaround the double execution : http://maven.apache.org/plugins/maven-surefire-report-plugin/report-only-moj o.html Cheers. 2008/10/15 aXXa <[EMAIL PROTECTED]> > > Have you tried > $>mvn deploy -Dmaven.test.skip=true > > -Martin > > > von Janowsky, Simon wrote: > > > > Hello, > > on our CI-Server (Hudson) we execute three goals per module: clean, > > deploy, site. > > Now the tests get executed twice, which is a correct behaviour, but > > can cost lots of time... > > Is there a way to disable tests for one single goal? > > > > Greetings, > > Simon. > > > > > > > > -- > View this message in context: > http://www.nabble.com/skip-tests-in-a-single-goal-tp19990895p19991066. > html Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! smime.p7s Description: S/MIME cryptographic signature
Re: Disable artifact install or deploy to the repository.
On Tue, Oct 14, 2008 at 10:18 PM, sean chen(陈思淼) <[EMAIL PROTECTED]> wrote: > I have some project such as war, it is a intermediate project which a ear > project depends on . and when I run mvn install. I don't want it to be > install to local repository, or deploy to remote repository.how can I to > disable it? You can configure the deploy plugin to skip deploying individual modules. http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip -- Wendy
Re: trunk/tags/branches: root vs. project level
Stefan Fritz-2 wrote: > >>>The main clincher is that we generally run all our sub-modules as children >>>of a parent super-module. That's only possible with the root approach. > > or you define trunk/tags/branches per module-group instead of per project > as you would do for standalone projects ;-) > > If your projects genuinely are stand-alone projects then I would suggest that you create separate repositories for each of them, although that may be harder to do if you already have history within an existing repository. I have not done so, but I imagine that it must be possible to clone a repository and then remove extra stuff from each copy such that you reduce to 1 project per repo? Later, Andy -- View this message in context: http://www.nabble.com/trunk-tags-branches%3A--root-vs.--project-level-tp19989397p19993273.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk/tags/branches: root vs. project level
The main clincher is that we generally run all our sub-modules as children of a parent super-module. That's only possible with the root approach. or you define trunk/tags/branches per module-group instead of per project as you would do for standalone projects ;-) Thanks Stefan Andy Law wrote: Stefan Fritz-2 wrote: Hi all, we are in the process of restructuring a subversion repository and "Mavenize" all projects. The main discussion at the moment is whether to have trunk/tags/branches on the root level or once per project. root: trunk/project1/pom.xml trunk/project2/pom.xml branches/branch1/project1/pom.xml project level project1/trunk/project1/pom.xml project1/branches/branch1/project1/pom.xml First comment: Subversion doesn't care. You need to come up with something that fits the way that you work best (I know that's no help!) Secondly: FWIW, *we* use the root approach (with an extra level of parent module). I have never had problems with checkin at the root level, although some of my colleagues occasionally grumble about it. I think that this is more a Netbeans-subversion issue rather than a subversion issue. The main clincher is that we generally run all our sub-modules as children of a parent super-module. That's only possible with the root approach. I can't see anything that you can do with the project approach that you can't do with the root approach but the opposite is not true (see above). And there is nothing in your project approach that wouldn't stop someone checking out and committing at the root level anyway. Later, Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: skip tests in a single goal
mvn install -DskipTests 2008/10/15 von Janowsky, Simon <[EMAIL PROTECTED]> > Yes, but then all tests in all goals will get skipped > > > -Ursprüngliche Nachricht- > Von: aXXa [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 15. Oktober 2008 12:48 > An: users@maven.apache.org > Betreff: Re: skip tests in a single goal > > > Have you tried > $>mvn deploy -Dmaven.test.skip=true > > -Martin >
AW: skip tests in a single goal
Yes, but then all tests in all goals will get skipped -Ursprüngliche Nachricht- Von: aXXa [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 15. Oktober 2008 12:48 An: users@maven.apache.org Betreff: Re: skip tests in a single goal Have you tried $>mvn deploy -Dmaven.test.skip=true -Martin smime.p7s Description: S/MIME cryptographic signature
Re: skip tests in a single goal
Or maybe configuring the report "report-only" (corresponding to mvn surefire-report:report-only) could do the trick. It was specifically developed to workaround the double execution : http://maven.apache.org/plugins/maven-surefire-report-plugin/report-only-mojo.html Cheers. 2008/10/15 aXXa <[EMAIL PROTECTED]> > > Have you tried > $>mvn deploy -Dmaven.test.skip=true > > -Martin > > > von Janowsky, Simon wrote: > > > > Hello, > > on our CI-Server (Hudson) we execute three goals per module: clean, > > deploy, > > site. > > Now the tests get executed twice, which is a correct behaviour, but can > > cost > > lots of time... > > Is there a way to disable tests for one single goal? > > > > Greetings, > > Simon. > > > > > > > > -- > View this message in context: > http://www.nabble.com/skip-tests-in-a-single-goal-tp19990895p19991066.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: trunk/tags/branches: root vs. project level
Stefan Fritz-2 wrote: > > Hi all, > > we are in the process of restructuring a subversion repository and > "Mavenize" all projects. > The main discussion at the moment is whether to have trunk/tags/branches > on the root level or once per project. > > root: > trunk/project1/pom.xml > trunk/project2/pom.xml > branches/branch1/project1/pom.xml > > project level > project1/trunk/project1/pom.xml > project1/branches/branch1/project1/pom.xml > > > First comment: Subversion doesn't care. You need to come up with something that fits the way that you work best (I know that's no help!) Secondly: FWIW, *we* use the root approach (with an extra level of parent module). I have never had problems with checkin at the root level, although some of my colleagues occasionally grumble about it. I think that this is more a Netbeans-subversion issue rather than a subversion issue. The main clincher is that we generally run all our sub-modules as children of a parent super-module. That's only possible with the root approach. I can't see anything that you can do with the project approach that you can't do with the root approach but the opposite is not true (see above). And there is nothing in your project approach that wouldn't stop someone checking out and committing at the root level anyway. Later, Andy -- View this message in context: http://www.nabble.com/trunk-tags-branches%3A--root-vs.--project-level-tp19989397p19991813.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-release-plugin not able to locate extensions
Hi,
I am having problems using maven-release-plugin and I need some help
urgently. While doing a release:prepare, maven is not able to locate an
extension. I am using maven 2.0.7 on JDK 1.5. Given below are the
essential details of the pom.xml that's facing the issue:
org.glassfish.ejb
ejb
3.0-Prelude
3.0-Prelude
ejb-timer-databases
distribution-fragment
org.glassfish.build
maven-glassfish-extension
${project.version}
As you can see, it uses a packaging type called distribution-fragment,
which is understood by our own extension called
org.glassfish.build:maven-glassfish-extension. We build the extension as
part of the same reactor. For some other reason, we don't use
true in our plugin configuration. I am able to
do a normal build successfully, but when I am trying to prepare a
release using maven-release-plugin, it fails with following error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.glassfish.build
-DartifactId=maven-glassfish-extension \
-Dversion=3.0-Prelude -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy
the file there: mvn deploy:deploy-file
-DgroupId=org.glassfish.build -DartifactId=maven-glassfish-extension \
-Dversion=3.0-Prelude -Dpackaging=jar
-Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude
2)
org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
--
1 required artifact is missing.
for artifact:
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude
What is surprising is that it fails even when I have built the extension
separately and installed it in my local repository. How can I avoid this
error?
Thanks,
Sahoo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: skip tests in a single goal
Have you tried $>mvn deploy -Dmaven.test.skip=true -Martin von Janowsky, Simon wrote: > > Hello, > on our CI-Server (Hudson) we execute three goals per module: clean, > deploy, > site. > Now the tests get executed twice, which is a correct behaviour, but can > cost > lots of time... > Is there a way to disable tests for one single goal? > > Greetings, > Simon. > > > -- View this message in context: http://www.nabble.com/skip-tests-in-a-single-goal-tp19990895p19991066.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Want to exclude extra jars from war.
you have to add excludes sections to each of the dependencies that are dragging them in... of course, these dependencies should be dragging them in for a reason (such as being required in order to function) so one has to conclude either: * you are trying to exclude them incorrectly or * the poms are listing optional dependencies as non-optional 2008/10/15 Nitin B <[EMAIL PROTECTED]>: > > yes, these are the transitive dependancies. How can I prevent them? > > Thanks, > Nitin B > > -- > View this message in context: > http://www.nabble.com/Want-to-exclude-extra-jars-from-war.-tp19990177p19990769.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
skip tests in a single goal
Hello, on our CI-Server (Hudson) we execute three goals per module: clean, deploy, site. Now the tests get executed twice, which is a correct behaviour, but can cost lots of time... Is there a way to disable tests for one single goal? Greetings, Simon. smime.p7s Description: S/MIME cryptographic signature
Re: Want to exclude extra jars from war.
yes, these are the transitive dependancies. How can I prevent them? Thanks, Nitin B -- View this message in context: http://www.nabble.com/Want-to-exclude-extra-jars-from-war.-tp19990177p19990769.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Want to exclude extra jars from war.
sounds like transitive dependencies 2008/10/15 Nitin B <[EMAIL PROTECTED]>: > > My project is depends on around 48 jars while in maven generated war file > there are 143 jars. > So I believe sourceExclude of Maven war plugin is not a good choice. > > Thanks, > Nitin > > > -- > View this message in context: > http://www.nabble.com/Want-to-exclude-extra-jars-from-war.-tp19990177p19990528.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Want to exclude extra jars from war.
My project is depends on around 48 jars while in maven generated war file there are 143 jars. So I believe sourceExclude of Maven war plugin is not a good choice. Thanks, Nitin -- View this message in context: http://www.nabble.com/Want-to-exclude-extra-jars-from-war.-tp19990177p19990528.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
inactivate/don't run plugins in pom-packaging super projects
Hola! Pre conditions: I have a number of similar projects, i.e. a number of maven plugins are identically configured. I have solved this by putting all (most) plugins in a super-project (pom-packaging), partly in a profile, partly in pluginManagement: super pom generatesources ... ... plugin_1 definition and its configuration ... super ... child_1 jar plugin_1 definition and NO config ... Everything is working fine if I, when I execute the child_1-project, activate the profile "generatesources": ~/dev/child_1$>mvn install -P generatesources BUT to be able to sell the concept of Maven to the organisation I think one should not need to activate profiles as default, but rather like "-Dmaven.test.skip=true" and "-o" DEACTIVATE features. One way to achieve this would be: super generatesources true ... The problem occurs when I build the super-project and the profile is active, i.e. tries to act on stuff not present in the super-project. In Maven 2.0.10 there is apparently a flag "!" to be used to inactivate profiles: ~/dev/super$>mvn install -P !generatesources but how to achieve this (or like the subject of this message implies) before 2.0.10 is released? regards -Martin -- View this message in context: http://www.nabble.com/inactivate-don%27t-run-plugins-in-pom-packaging-super-projects-tp19990522p19990522.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: trunk/tags/branches: root vs. project level
Hi Stefan, we use one repository per project, and within the project there are several modules and all of them have a trunk/branches/tags directory. Our structure is like this: repository project 1: module1/branches module1/tags module1/trunk/pom.xml module2/branches module2/tags module2/trunk/pom.xml repository project 2: module1/branches module1/tags module1/trunk/pom.xml module2/branches module2/tags module2/trunk/pom.xml With kind regards, Simon von Janowsky -Ursprüngliche Nachricht- Von: Stefan Fritz [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 15. Oktober 2008 10:49 An: Maven Users List Betreff: trunk/tags/branches: root vs. project level Hi all, we are in the process of restructuring a subversion repository and "Mavenize" all projects. The main discussion at the moment is whether to have trunk/tags/branches on the root level or once per project. root: trunk/project1/pom.xml trunk/project2/pom.xml branches/branch1/project1/pom.xml project level project1/trunk/project1/pom.xml project1/branches/branch1/project1/pom.xml root level: pro: all branch/patch related projects in one location easy to navigate easy to update cons: does mvn release:branch work ? mergin can get hard if somebody commits at root level project level. pro: easy to work with mvn release merging should be easy cons: complex for scenarios where you have to deal with multiple projects at once Would be curious about your opinions/comments! Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Want to exclude extra jars from war.
Where do these JARs come from ? Are they dependencies or do they come from your web application source folder. In the last case, you can use the sourceExclude parameter of the Maven war plugin. Jeff MAURY On Wed, Oct 15, 2008 at 11:44 AM, Nitin B <[EMAIL PROTECTED]> wrote: > > Hi, > > I am trying to create a .war file using maven. While creating war while > maven adds extra jars in war which I have not specified in dependancies. > I dont want to add them in war, as these extra jars are creating a problem > at the time of deployment. > > Thanks, > Nitin B > -- > View this message in context: > http://www.nabble.com/Want-to-exclude-extra-jars-from-war.-tp19990177p19990177.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal Mes CDs à récupérer: http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en
Want to exclude extra jars from war.
Hi, I am trying to create a .war file using maven. While creating war while maven adds extra jars in war which I have not specified in dependancies. I dont want to add them in war, as these extra jars are creating a problem at the time of deployment. Thanks, Nitin B -- View this message in context: http://www.nabble.com/Want-to-exclude-extra-jars-from-war.-tp19990177p19990177.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
trunk/tags/branches: root vs. project level
Hi all, we are in the process of restructuring a subversion repository and "Mavenize" all projects. The main discussion at the moment is whether to have trunk/tags/branches on the root level or once per project. root: trunk/project1/pom.xml trunk/project2/pom.xml branches/branch1/project1/pom.xml project level project1/trunk/project1/pom.xml project1/branches/branch1/project1/pom.xml root level: pro: all branch/patch related projects in one location easy to navigate easy to update cons: does mvn release:branch work ? mergin can get hard if somebody commits at root level project level. pro: easy to work with mvn release merging should be easy cons: complex for scenarios where you have to deal with multiple projects at once Would be curious about your opinions/comments! Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
The functionality provided by xsltc-m-p is sufficiently different from xml-m-p that it should probably not be removed without at least discussing things. Here's more documentation on XSLTC, many people are unaware of it: http://xml.apache.org/xalan-j/xsltc_usage.html In short, you include a XSLT file in your source code, then use XSLTC to compile it to a Java class which you can then invoke to execute the XSLT against a given XML file/node, and it is quite fast as it is compiled Java bytecode and can easily be cached etc. For people who are doing "a lot" of XSL transforms in their codebase, it is quite a nice tool. XSLTC helped us address some performance issues we had a while back in a particular project that ballooned from just a handful of users to hundreds of users in a very short period of time. Wayne On Wed, Oct 15, 2008 at 12:43 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > xml-maven-plugin is the official one. > > I will remove the one in sandbox > > -D > > On Wed, Oct 15, 2008 at 12:40 AM, Nick Stolwijk <[EMAIL PROTECTED]> wrote: >> There is also an xsltc maven plugin in the sandbox, but that hasn't >> been updated for a while. See >> https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ >> >> What is the state of this plugin? >> >> Hth >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >>> http://mojo.codehaus.org/xml-maven-plugin/ >>> >>> >>> On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: http://mojo.codehaus.org/xslt-maven-plugin ? On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi <[EMAIL PROTECTED]> wrote: > Hi everybody, > In my project I need to use the XSLTC and I want to integrate it in my > Maven build, but I haven't found any official documentation's page. Is > there any release of it? > Thanks in advance, > Simone > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
Hi Wayne, thanks, I checked-out the code and I'm currently installing it into my local repo - and I'm also reading the code to understand how to use it. I just need to compile a single XSLT in a java class, so I'll reuse it in my application. Thank you very much for your help! Simone 2008/10/15 Wayne Fay <[EMAIL PROTECTED]>: > Matt Whitlock wrote the original xsltc-m-p. Then when I wanted to use > it on a project, I tweaked some features and updated the code in svn. > The xsltc-m-p compiles xslt stylesheets into Xalan translets. > > As of now, there is no official release per-se of this plugin, as it > still lives in the sandbox. Based on the relatively low interest in > the plugin, I'm honestly unsure if it will ever make it out of the > sandbox. > > To Simone -- what exactly do you want to do with the plugin? There's > not much documentation, but it is a pretty simple plugin with > literally 1 file of Java source code. > > For now, you will need to check it out of svn and "mvn install" it > locally yourself. > > Wayne > > On Wed, Oct 15, 2008 at 12:48 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >> oops, dont know about xsltc-maven-plugin's status >> >> -D >> >> On Wed, Oct 15, 2008 at 12:43 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >>> xml-maven-plugin is the official one. >>> >>> I will remove the one in sandbox >>> >>> -D >>> >>> On Wed, Oct 15, 2008 at 12:40 AM, Nick Stolwijk <[EMAIL PROTECTED]> wrote: There is also an xsltc maven plugin in the sandbox, but that hasn't been updated for a while. See https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ What is the state of this plugin? Hth Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > http://mojo.codehaus.org/xml-maven-plugin/ > > > On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >> http://mojo.codehaus.org/xslt-maven-plugin ? >> >> On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi >> <[EMAIL PROTECTED]> wrote: >>> Hi everybody, >>> In my project I need to use the XSLTC and I want to integrate it in my >>> Maven build, but I haven't found any official documentation's page. Is >>> there any release of it? >>> Thanks in advance, >>> Simone >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- My LinkedIn profile: http://www.linkedin.com/in/simonetripodi My GoogleCode profile: http://code.google.com/u/simone.tripodi/ My Picasa: http://picasaweb.google.com/simone.tripodi/ My Tube: http://www.youtube.com/user/stripodi My Del.icio.us: http://del.icio.us/simone.tripodi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
Matt Whitlock wrote the original xsltc-m-p. Then when I wanted to use it on a project, I tweaked some features and updated the code in svn. The xsltc-m-p compiles xslt stylesheets into Xalan translets. As of now, there is no official release per-se of this plugin, as it still lives in the sandbox. Based on the relatively low interest in the plugin, I'm honestly unsure if it will ever make it out of the sandbox. To Simone -- what exactly do you want to do with the plugin? There's not much documentation, but it is a pretty simple plugin with literally 1 file of Java source code. For now, you will need to check it out of svn and "mvn install" it locally yourself. Wayne On Wed, Oct 15, 2008 at 12:48 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > oops, dont know about xsltc-maven-plugin's status > > -D > > On Wed, Oct 15, 2008 at 12:43 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >> xml-maven-plugin is the official one. >> >> I will remove the one in sandbox >> >> -D >> >> On Wed, Oct 15, 2008 at 12:40 AM, Nick Stolwijk <[EMAIL PROTECTED]> wrote: >>> There is also an xsltc maven plugin in the sandbox, but that hasn't >>> been updated for a while. See >>> https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ >>> >>> What is the state of this plugin? >>> >>> Hth >>> >>> Nick Stolwijk >>> ~Java Developer~ >>> >>> Iprofs BV. >>> Claus Sluterweg 125 >>> 2012 WS Haarlem >>> www.iprofs.nl >>> >>> >>> >>> On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: http://mojo.codehaus.org/xml-maven-plugin/ On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > http://mojo.codehaus.org/xslt-maven-plugin ? > > On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi > <[EMAIL PROTECTED]> wrote: >> Hi everybody, >> In my project I need to use the XSLTC and I want to integrate it in my >> Maven build, but I haven't found any official documentation's page. Is >> there any release of it? >> Thanks in advance, >> Simone >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
Hi Dan, Nick, thank you very much for your quick reply! Best regards, Simone 2008/10/15 Dan Tran <[EMAIL PROTECTED]>: > oops, dont know about xsltc-maven-plugin's status > > -D > > On Wed, Oct 15, 2008 at 12:43 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >> xml-maven-plugin is the official one. >> >> I will remove the one in sandbox >> >> -D >>Hi>> On Wed, Oct 15, 2008 at 12:40 AM, Nick Stolwijk <[EMAIL PROTECTED]> >>wrote: >>> There is also an xsltc maven plugin in the sandbox, but that hasn't >>> been updated for a while. See >>> https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ >>> >>> What is the state of this plugin? >>> >>> Hth >>> >>> Nick Stolwijk >>> ~Java Developer~ >>> >>> Iprofs BV. >>> Claus Sluterweg 125 >>> 2012 WS Haarlem >>> www.iprofs.nl >>> >>> >>> >>> On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: http://mojo.codehaus.org/xml-maven-plugin/ On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > http://mojo.codehaus.org/xslt-maven-plugin ? > > On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi > <[EMAIL PROTECTED]> wrote: >> Hi everybody, >> In my project I need to use the XSLTC and I want to integrate it in my >> Maven build, but I haven't found any official documentation's page. Is >> there any release of it? >> Thanks in advance, >> Simone >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- My LinkedIn profile: http://www.linkedin.com/in/simonetripodi My GoogleCode profile: http://code.google.com/u/simone.tripodi/ My Picasa: http://picasaweb.google.com/simone.tripodi/ My Tube: http://www.youtube.com/user/stripodi My Del.icio.us: http://del.icio.us/simone.tripodi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
oops, dont know about xsltc-maven-plugin's status -D On Wed, Oct 15, 2008 at 12:43 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > xml-maven-plugin is the official one. > > I will remove the one in sandbox > > -D > > On Wed, Oct 15, 2008 at 12:40 AM, Nick Stolwijk <[EMAIL PROTECTED]> wrote: >> There is also an xsltc maven plugin in the sandbox, but that hasn't >> been updated for a while. See >> https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ >> >> What is the state of this plugin? >> >> Hth >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >>> http://mojo.codehaus.org/xml-maven-plugin/ >>> >>> >>> On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: http://mojo.codehaus.org/xslt-maven-plugin ? On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi <[EMAIL PROTECTED]> wrote: > Hi everybody, > In my project I need to use the XSLTC and I want to integrate it in my > Maven build, but I haven't found any official documentation's page. Is > there any release of it? > Thanks in advance, > Simone > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
xml-maven-plugin is the official one. I will remove the one in sandbox -D On Wed, Oct 15, 2008 at 12:40 AM, Nick Stolwijk <[EMAIL PROTECTED]> wrote: > There is also an xsltc maven plugin in the sandbox, but that hasn't > been updated for a while. See > https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ > > What is the state of this plugin? > > Hth > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > > > > On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >> http://mojo.codehaus.org/xml-maven-plugin/ >> >> >> On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >>> http://mojo.codehaus.org/xslt-maven-plugin ? >>> >>> On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi >>> <[EMAIL PROTECTED]> wrote: Hi everybody, In my project I need to use the XSLTC and I want to integrate it in my Maven build, but I haven't found any official documentation's page. Is there any release of it? Thanks in advance, Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable artifact install or deploy to the repository.
refactor how you aggregate your build. or use mvn verify mvn verify will build using the reactor without pushing to the local repository the only difference between verify and install is that install puts the dependency into the local repository. if a plugin you are using is pulling artifacts from the local repo without checking first to see if they are in the reactor, then that is a bug with the plugin (or you're using the wrong goal of the dependency plugin) You should be able to do a full build with mvn verify Seriously, the answer is to change the phase you are targetting -Stephen 2008/10/15 sean chen(陈思淼) <[EMAIL PROTECTED]>: > first. it's time consuming to install the war to the local repository or > deploy it to the remote repository, when project's grows to more than 50 > scale, thats lot of time.second, there are some project just like > Test-project which depends on all the projects and run the junit test. > install or deploy it is unnessesary. > So i want to skip the install:install mojo. > > 2008/10/15 Nick Stolwijk <[EMAIL PROTECTED]> > >> But when you don't run mvn install, your ear project won't be able to >> find it, because that project will look in the local repository. >> Otherwise, if you don't run mvn deploy, other developers that wan't to >> build your ear project won't be able to find it, because they look in >> your remote repository. >> >> Why exactly don't you want it to appear in your local or remote >> repository? It is after all just an artifact and those are the places >> where maven will look for artifacts. >> >> Hth, >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Oct 15, 2008 at 7:53 AM, Stephen Connolly >> <[EMAIL PROTECTED]> wrote: >> > don't run mvn install ;-) >> > >> > just run mvn package >> > >> > mvn install means install into local repository >> > >> > Sent from my iPod >> > >> > On 15 Oct 2008, at 06:18, "sean chen(陈思淼)" <[EMAIL PROTECTED]> wrote: >> > >> >> I have some project such as war, it is a intermediate project which a >> ear >> >> project depends on . and when I run mvn install. I don't want it to be >> >> install to local repository, or deploy to remote repository.how can I to >> >> disable it? >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >
Re: xsltc plugin
There is also an xsltc maven plugin in the sandbox, but that hasn't been updated for a while. See https://svn.codehaus.org/mojo/trunk/sandbox/xsltc-maven-plugin/ What is the state of this plugin? Hth Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Oct 15, 2008 at 9:34 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > http://mojo.codehaus.org/xml-maven-plugin/ > > > On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: >> http://mojo.codehaus.org/xslt-maven-plugin ? >> >> On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi >> <[EMAIL PROTECTED]> wrote: >>> Hi everybody, >>> In my project I need to use the XSLTC and I want to integrate it in my >>> Maven build, but I haven't found any official documentation's page. Is >>> there any release of it? >>> Thanks in advance, >>> Simone >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable artifact install or deploy to the repository.
first. it's time consuming to install the war to the local repository or deploy it to the remote repository, when project's grows to more than 50 scale, thats lot of time.second, there are some project just like Test-project which depends on all the projects and run the junit test. install or deploy it is unnessesary. So i want to skip the install:install mojo. 2008/10/15 Nick Stolwijk <[EMAIL PROTECTED]> > But when you don't run mvn install, your ear project won't be able to > find it, because that project will look in the local repository. > Otherwise, if you don't run mvn deploy, other developers that wan't to > build your ear project won't be able to find it, because they look in > your remote repository. > > Why exactly don't you want it to appear in your local or remote > repository? It is after all just an artifact and those are the places > where maven will look for artifacts. > > Hth, > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > > > > On Wed, Oct 15, 2008 at 7:53 AM, Stephen Connolly > <[EMAIL PROTECTED]> wrote: > > don't run mvn install ;-) > > > > just run mvn package > > > > mvn install means install into local repository > > > > Sent from my iPod > > > > On 15 Oct 2008, at 06:18, "sean chen(陈思淼)" <[EMAIL PROTECTED]> wrote: > > > >> I have some project such as war, it is a intermediate project which a > ear > >> project depends on . and when I run mvn install. I don't want it to be > >> install to local repository, or deploy to remote repository.how can I to > >> disable it? > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: xsltc plugin
http://mojo.codehaus.org/xml-maven-plugin/ On Wed, Oct 15, 2008 at 12:32 AM, Dan Tran <[EMAIL PROTECTED]> wrote: > http://mojo.codehaus.org/xslt-maven-plugin ? > > On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi > <[EMAIL PROTECTED]> wrote: >> Hi everybody, >> In my project I need to use the XSLTC and I want to integrate it in my >> Maven build, but I haven't found any official documentation's page. Is >> there any release of it? >> Thanks in advance, >> Simone >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsltc plugin
http://mojo.codehaus.org/xslt-maven-plugin ? On Wed, Oct 15, 2008 at 12:28 AM, Simone Tripodi <[EMAIL PROTECTED]> wrote: > Hi everybody, > In my project I need to use the XSLTC and I want to integrate it in my > Maven build, but I haven't found any official documentation's page. Is > there any release of it? > Thanks in advance, > Simone > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xsltc plugin
Hi everybody, In my project I need to use the XSLTC and I want to integrate it in my Maven build, but I haven't found any official documentation's page. Is there any release of it? Thanks in advance, Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable artifact install or deploy to the repository.
But when you don't run mvn install, your ear project won't be able to find it, because that project will look in the local repository. Otherwise, if you don't run mvn deploy, other developers that wan't to build your ear project won't be able to find it, because they look in your remote repository. Why exactly don't you want it to appear in your local or remote repository? It is after all just an artifact and those are the places where maven will look for artifacts. Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Oct 15, 2008 at 7:53 AM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > don't run mvn install ;-) > > just run mvn package > > mvn install means install into local repository > > Sent from my iPod > > On 15 Oct 2008, at 06:18, "sean chen(陈思淼)" <[EMAIL PROTECTED]> wrote: > >> I have some project such as war, it is a intermediate project which a ear >> project depends on . and when I run mvn install. I don't want it to be >> install to local repository, or deploy to remote repository.how can I to >> disable it? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
system-scoped dependency must specify systemPath
Hello,
When releasing the multimodule project and one of the transitive
dependencies is tools.jar a fatal error occurs.
mvn release:prepare -DgenerateReleasePoms=true
...
[INFO] Executing: mvn clean verify --no-plugin-updates -P proxy
[INFO] Scanning for projects...
[INFO] NOTE: Using release-pom:
C:\eclipse\workspace\trident-project\release-pom.xml in reactor build.
[INFO] NOTE: Using release-pom:
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml in
reactor build.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: com.interseek:trident-admin
POM Location:
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
Validation Messages:
[0] For dependency Dependency {groupId=com.sun, artifactId=tools,
version=1.5.0, type=jar}: system-scoped dependency must specify systemPath.
Reason: Failed to validate POM for project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for
project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to
validate POM for project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
[INFO]
[INFO] Total time: < 1 second
[INFO] Finished at: Wed Oct 08 11:14:22 CEST 2008
[INFO] Final Memory: 1M/2M
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Maven execution failed, exit code: '1'
This only happens if -DgenerateReleasePoms=true is present.
I filed this at http://jira.codehaus.org/browse/MNG-3784
Any clues?
Regards,
Borut
Re: New to Maven - need help
On Wednesday 15 October 2008 Jan K wrote: > What are the mandatory fields(tags) to be used for settings.xml? You don't need a settings.xml file at all. A good overview is available at http://maven.apache.org/settings.html hth, - martin signature.asc Description: This is a digitally signed message part.
Re: New to Maven - need help
What are the mandatory fields(tags) to be used for settings.xml? Arnaud HERITIER wrote: > > You'll have more information in : > - http://www.sonatype.com/community/definitive_guide.html > - http://www.exist.com/better-build-maven > > Arnaud > > On Tue, Oct 14, 2008 at 12:54 PM, Jan K <[EMAIL PROTECTED]> wrote: > >> >> I am very new to maven.I have downloaded apache-maven-2.0.9.I read the >> doc's >> and installed maven. I executed the following commands in command >> prompt, >> >> mvn archetype:create \ >> -DarchetypeGroupId=org.apache.maven.archetypes \ >> -DgroupId=com.mycompany.app \ >> -DartifactId=my-app >> >> >> I got a folder as my-app in my local path.I can see the pom.xml.Please >> help >> me what should i do next?How to change it the project i am willing to >> run? >> >> -- >> View this message in context: >> http://www.nabble.com/New-to-Maven---need-help-tp19971205p19971205.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> > > > > -- > .. > Arnaud HERITIER > .. > OCTO Technology - aheritier AT octo DOT com > www.octo.com | blog.octo.com > .. > ASF - aheritier AT apache DOT org > www.apache.org | maven.apache.org > ... > > -- View this message in context: http://www.nabble.com/New-to-Maven---need-help-tp19971205p19988056.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
