You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by sv...@explicit.dk on 2004/06/29 10:48:25 UTC
WAR file versioning (Maven RC4)
Hi,
I just used the war plugin, it seems that it does not attach a version to the
generated war file. I am using Maven RC4.
I'd expect that a testapp-1.0.war would be generated in the target directory, I
only get a testapp.war
I reproduced it quite easily:
1) generate a new application with maven genapp
2) invoke "maven war"
You get an unversioned war file.
Anyone else seen this ?
br,
/Sverre
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: WAR file versioning (Maven RC4)
Posted by Brett Porter <br...@gmail.com>.
the version is correctly attached when it is put into the repository,
but it is not appended to the build so that it can be dropped into a
container without extra information and do the expected thing.
If you want to modify it, I believe you can alter maven.war.final.name.
Regards,
Brett
On Tue, 29 Jun 2004 09:07:27 -0400, Brill Pappin <br...@stabilia.com> wrote:
> Yes I know, but it would be a disaster in our particular case. We use
> the tomcat foo.xml for development, but deploy the war remotely via the
> manager interface. not only that but it means another point of failure
> for us with two files to maintain.
>
> Anyway, someone mentioned using the properties file, which is the best
> solution I think and solves the problem from both ends.
>
> - Brill
>
>
>
> Martijn Dashorst wrote:
>
> > Brill Pappin wrote:
> >
> >> I don't know how others are deploying, but I definitely *do not* want
> >> the version appended to the war file.
> >> The reason for this is that most containers name the context after
> >> the name of the war file and having a version on the end would mean
> >> that the context changed every time a new version was deployed.
> >>
> > Several webapplication containers *do* support supplying additional
> > information regarding the context in which the application is deployed.
> > * Tomcat: supply a foo.xml for your foo-1.0.war in which you define
> > the Context with as base the war file name
> > * JBoss: supply next to the web.xml a jboss-web.xml file with the
> > context name.
> >
> > These also allow for automatic configuration of the server.xml (or
> > whatever configuration mechanism your server uses).
> >
> > With regards,
> >
> > Martijn Dashorst
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> --
> "Any sufficiently advanced magic is indistinguishable from technology."
> - Arthur C Anticlarke
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: IDEA project files from IDEA plugin
Posted by Brett Porter <br...@gmail.com>.
Actually, this should probably only be done when you run
idea:multiproject, and then only for projects in that build rather
than automatically assuming you will import your external project
modules.
But wither way, definitely file a JIRA issue for this.
Cheers,
Brett
On Tue, 29 Jun 2004 15:46:44 +0200, sverre@explicit.dk
<sv...@explicit.dk> wrote:
> Hi Again,
>
> I've done some digging into the plugin and found, that the module.jelly which
> generates the .iml file *does* sort the jar files into external and internal
> module vs. module-libraries.
>
> I would suggest a plugin property which should be tested against in the
> module.jelly file, so it is possible to select wether jar files with same
> groupId as the current project are registered as module or module-library in
> the generated .iml file.
>
> The property could be something like
>
> maven.idea.project.groupmodules=<true | false>
>
> The default value for the property could leave the plugin with the current
> behaviour, thus backward compability is secured.
>
> How sounds ?
>
> Br,
> /Sverre Eplov
>
> Citat sverre@explicit.dk:
>
>
>
> > Hi all,
> >
> > I'm using the IDEA plugin to generate the IDEA IDE project files.
> >
> > The projects we're doing consists of a number of artifacts (jar, war, ejb-jar
> >
> > files e.t.c.) grouped by groupId to indicate that they belong to the same
> > application.
> >
> > When the IDEA plugin generates the .iml file, it seems to distinguish between
> >
> > artifacts belonging to the same groupId as the project itself and artifacts
> > from other groupId's.
> >
> > A dependency to a jar file "cabin-utility" with the same groupId as the
> > project
> > itself generates following entry in the .iml file:
> >
> > <orderEntry type="module" module-name="cabin-utility">
> > </orderEntry>
> >
> > whereas a dependency on a jar file with a groupId different from the project
> >
> > generates this entry:
> >
> > <orderEntry type="module-library">
> > <library name="ejb">
> > <CLASSES>
> > <root
> > url="jar://c:/java_devenv/maven/repository\ejb\jars\ejb-2.0.jar!/">
> > </root>
> > </CLASSES>
> > <JAVADOC>
> > </JAVADOC>
> > <SOURCES>
> > </SOURCES>
> > </library>
> > </orderEntry>
> >
> > The problem is, that any dependency on any jar file should be treated
> > as "external", since projects with same groupId is not checked out at the
> > developer workstation, thus resulting in IDEA missing jar files when the
> > project is opened.
> >
> > Any ideas ?
> >
> > br,
> > /Sverre Eplov
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: IDEA project files from IDEA plugin
Posted by sv...@explicit.dk.
Hi Again,
I've done some digging into the plugin and found, that the module.jelly which
generates the .iml file *does* sort the jar files into external and internal
module vs. module-libraries.
I would suggest a plugin property which should be tested against in the
module.jelly file, so it is possible to select wether jar files with same
groupId as the current project are registered as module or module-library in
the generated .iml file.
The property could be something like
maven.idea.project.groupmodules=<true | false>
The default value for the property could leave the plugin with the current
behaviour, thus backward compability is secured.
How sounds ?
Br,
/Sverre Eplov
Citat sverre@explicit.dk:
> Hi all,
>
> I'm using the IDEA plugin to generate the IDEA IDE project files.
>
> The projects we're doing consists of a number of artifacts (jar, war, ejb-jar
>
> files e.t.c.) grouped by groupId to indicate that they belong to the same
> application.
>
> When the IDEA plugin generates the .iml file, it seems to distinguish between
>
> artifacts belonging to the same groupId as the project itself and artifacts
> from other groupId's.
>
> A dependency to a jar file "cabin-utility" with the same groupId as the
> project
> itself generates following entry in the .iml file:
>
> <orderEntry type="module" module-name="cabin-utility">
> </orderEntry>
>
> whereas a dependency on a jar file with a groupId different from the project
>
> generates this entry:
>
> <orderEntry type="module-library">
> <library name="ejb">
> <CLASSES>
> <root
> url="jar://c:/java_devenv/maven/repository\ejb\jars\ejb-2.0.jar!/">
> </root>
> </CLASSES>
> <JAVADOC>
> </JAVADOC>
> <SOURCES>
> </SOURCES>
> </library>
> </orderEntry>
>
> The problem is, that any dependency on any jar file should be treated
> as "external", since projects with same groupId is not checked out at the
> developer workstation, thus resulting in IDEA missing jar files when the
> project is opened.
>
> Any ideas ?
>
> br,
> /Sverre Eplov
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
IDEA project files from IDEA plugin
Posted by sv...@explicit.dk.
Hi all,
I'm using the IDEA plugin to generate the IDEA IDE project files.
The projects we're doing consists of a number of artifacts (jar, war, ejb-jar
files e.t.c.) grouped by groupId to indicate that they belong to the same
application.
When the IDEA plugin generates the .iml file, it seems to distinguish between
artifacts belonging to the same groupId as the project itself and artifacts
from other groupId's.
A dependency to a jar file "cabin-utility" with the same groupId as the project
itself generates following entry in the .iml file:
<orderEntry type="module" module-name="cabin-utility">
</orderEntry>
whereas a dependency on a jar file with a groupId different from the project
generates this entry:
<orderEntry type="module-library">
<library name="ejb">
<CLASSES>
<root url="jar://c:/java_devenv/maven/repository\ejb\jars\ejb-2.0.jar!/">
</root>
</CLASSES>
<JAVADOC>
</JAVADOC>
<SOURCES>
</SOURCES>
</library>
</orderEntry>
The problem is, that any dependency on any jar file should be treated
as "external", since projects with same groupId is not checked out at the
developer workstation, thus resulting in IDEA missing jar files when the
project is opened.
Any ideas ?
br,
/Sverre Eplov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: WAR file versioning (Maven RC4)
Posted by Brill Pappin <br...@stabilia.com>.
Yes I know, but it would be a disaster in our particular case. We use
the tomcat foo.xml for development, but deploy the war remotely via the
manager interface. not only that but it means another point of failure
for us with two files to maintain.
Anyway, someone mentioned using the properties file, which is the best
solution I think and solves the problem from both ends.
- Brill
Martijn Dashorst wrote:
> Brill Pappin wrote:
>
>> I don't know how others are deploying, but I definitely *do not* want
>> the version appended to the war file.
>> The reason for this is that most containers name the context after
>> the name of the war file and having a version on the end would mean
>> that the context changed every time a new version was deployed.
>>
> Several webapplication containers *do* support supplying additional
> information regarding the context in which the application is deployed.
> * Tomcat: supply a foo.xml for your foo-1.0.war in which you define
> the Context with as base the war file name
> * JBoss: supply next to the web.xml a jboss-web.xml file with the
> context name.
>
> These also allow for automatic configuration of the server.xml (or
> whatever configuration mechanism your server uses).
>
> With regards,
>
> Martijn Dashorst
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
"Any sufficiently advanced magic is indistinguishable from technology."
- Arthur C Anticlarke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: WAR file versioning (Maven RC4)
Posted by Martijn Dashorst <ma...@dashorst.dds.nl>.
Brill Pappin wrote:
> I don't know how others are deploying, but I definitely *do not* want
> the version appended to the war file.
> The reason for this is that most containers name the context after the
> name of the war file and having a version on the end would mean that
> the context changed every time a new version was deployed.
>
Several webapplication containers *do* support supplying additional
information regarding the context in which the application is deployed.
* Tomcat: supply a foo.xml for your foo-1.0.war in which you define the
Context with as base the war file name
* JBoss: supply next to the web.xml a jboss-web.xml file with the
context name.
These also allow for automatic configuration of the server.xml (or
whatever configuration mechanism your server uses).
With regards,
Martijn Dashorst
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: WAR file versioning (Maven RC4)
Posted by Brill Pappin <br...@stabilia.com>.
I don't know how others are deploying, but I definitely *do not* want
the version appended to the war file.
The reason for this is that most containers name the context after the
name of the war file and having a version on the end would mean that the
context changed every time a new version was deployed.
We do version our wars however... we added the version to the web.xml in
the description element so that we can see what version of a webapp we
have deployed. I've been thinking about using the old ant "Filter" task
to update it automatically fro the maven version, but haven't added the
preGoal yet.
- Brill Pappin
sverre@explicit.dk wrote:
>Hi,
>
>
>I just used the war plugin, it seems that it does not attach a version to the
>generated war file. I am using Maven RC4.
>
>I'd expect that a testapp-1.0.war would be generated in the target directory, I
>only get a testapp.war
>
>I reproduced it quite easily:
>
>1) generate a new application with maven genapp
>2) invoke "maven war"
>
>You get an unversioned war file.
>
>Anyone else seen this ?
>
>br,
> /Sverre
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
"Any sufficiently advanced magic is indistinguishable from technology."
- Arthur C Anticlarke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org