You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ken Liu <ke...@gmail.com> on 2008/01/22 20:54:18 UTC
how to manually change a jar from SNAPSHOT to release?
Hi all -
I am getting close to releasing a project and am trying to nail down all the
SNAPSHOT dependencies. I have one plugin (jboss-sar), which was never
released, and only has a 2.0-SNAPSHOT version available. I want to take
this jar and assign a release number to it to be installed in our internal
maven repo.
Is there an "official" way to do this? I have been manually doing the
following:
1) in the jar, editing plugin.xml and replacing the version "2.0-SNAPSHOT"
with "2.0-MINE"
2) in the jar, editing pom.properties and changing the property "
2.0-SNAPSHOT" with "2.0-MINE"
3) in the jar, editing pom.xml and replacing the version "2.0-SNAPSHOT" with
"2.0-MINE"
4) renaming the jar from "jboss-sar-maven-plugin-2.0-SNAPSHOT.jar" to "
jboss-sar-maven-plugin-2.0-MINE.jar"
5) using "mvn install:install-file" to add the jar to my internal repository
Is this sufficient? Did I miss any steps? Is there an easier way to do
this?
Re: Conditionally including a jar file
Posted by Dennis Lundberg <de...@apache.org>.
Hi Jack
Please upgrade your dependency on commons-logging to version 1.1.1. The
1.1 version has errors in its dependencies, pulling in more than is
actually needed. This was fixed in 1.1.1.
Holt, Jack C. wrote:
> I would like to not include the jar file for log4j when producing a WAR
> file but allow it to be used when running my web app in Jetty.
>
> You see, JBoss includes a jar for log4j (a different version than I have
> set up a dependency for in my POM file) and it causes errors when the
> WAR file is deployed in JBoss. I have been manually removing the log4j
> file after the WAR file is generated.
>
> I have the following dependency in my POM file which I believe is the
> reason the log4j jar file is showing:
>
> <dependency>
> <groupId>commons-logging</groupId>
> <artifactId>commons-logging</artifactId>
> <version>1.1</version>
> </dependency>
>
> Do I need to somehow configure this as a dependency of the Jetty plugin
> and remove it as a dependency of the project?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conditionally including a jar file
Posted by Wayne Fay <wa...@gmail.com>.
Commons-logging is a completely different artifact from log4j. But
there is a possibility that c-l is pulling in log4j as a transitive
dependency.
Try adding <scope>provided</scope> to the c-l dep, see what happens,
and report back.
Wayne
On 1/24/08, Holt, Jack C. <JA...@saic.com> wrote:
>
> I would like to not include the jar file for log4j when producing a WAR
> file but allow it to be used when running my web app in Jetty.
>
> You see, JBoss includes a jar for log4j (a different version than I have
> set up a dependency for in my POM file) and it causes errors when the
> WAR file is deployed in JBoss. I have been manually removing the log4j
> file after the WAR file is generated.
>
> I have the following dependency in my POM file which I believe is the
> reason the log4j jar file is showing:
>
> <dependency>
> <groupId>commons-logging</groupId>
> <artifactId>commons-logging</artifactId>
> <version>1.1</version>
> </dependency>
>
> Do I need to somehow configure this as a dependency of the Jetty plugin
> and remove it as a dependency of the project?
>
> ---------------------------------------------------------------------
> 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
Conditionally including a jar file
Posted by "Holt, Jack C." <JA...@saic.com>.
I would like to not include the jar file for log4j when producing a WAR
file but allow it to be used when running my web app in Jetty.
You see, JBoss includes a jar for log4j (a different version than I have
set up a dependency for in my POM file) and it causes errors when the
WAR file is deployed in JBoss. I have been manually removing the log4j
file after the WAR file is generated.
I have the following dependency in my POM file which I believe is the
reason the log4j jar file is showing:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
</dependency>
Do I need to somehow configure this as a dependency of the Jetty plugin
and remove it as a dependency of the project?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how to manually change a jar from SNAPSHOT to release?
Posted by Stephen Connolly <st...@gmail.com>.
Yes.
The maven metadata .xml files
They contain information about what the RELEASE version is and so on.
If you don't update these files correctly, strange things will happen when
maven is pulling the files down from the remote repository.
Similar will happen if you try to copy a file into your local repository
directly.
Never put files into the local or remote repository directly, only ever use
install:install-file or deploy:deploy-file as these maintain the metatdata
files for you.
(At least that is what I was told)
On Jan 24, 2008 2:52 PM, Ken Liu <ke...@gmail.com> wrote:
> Hi Stephen -
>
> I don't understand what you are saying. Can you explain in more detail?
>
> My shared repository is no different than a local workstation repository
> (just a bunch of files in a directory tree). If I ftp the artifact and the
> POM to the server and run install:file, won't the artifact resolve
> properly? Is there something I am missing?
>
> Ken
>
> On 1/23/08, Stephen Connolly <st...@gmail.com> wrote:
> >
> > you should never just FTP or copy the file. deploy:deploy-file will
> > update the metadata. things will go very bad if you don't update the
> > metadata
> >
> > Sent from my iPod
> >
> > On 23 Jan 2008, at 21:43, "Ken Liu" <ke...@gmail.com> wrote:
> >
> >
> >
> > Thanks, I'm going with #1. The source svn repo seems to have gone away
> > (actually I probably can dig around in their svn history to find it, but
> > don't have the time/motivation).
> >
> > Can I use deploy:deploy-file the same ways as install:install-file? I
> > usually just ftp the files to the shared maven repo and then telnet in to
> > run install. I briefly looked at the deploy plugin docs, but it looked
> > really complicated.
> >
> > Ken
> >
> >
> > On 1/22/08, Stephen Connolly < <st...@gmail.com>
> > wrote:
> > >
> > > Well if you are just repackaging the -SNAPSHOT jar, then you don't
> > > need to build from source...
> > >
> > > I'd look at deploy:deploy-file rather than install:install-file as
> > > otherwise how will the other developers on your team get the artifact (of
> > > course you'd need to have your own repo to deploy to in such a case).
> > >
> > > Building from source (if it's a maven project) might actually be
> > > easier:
> > >
> > > 1. pull the source from SCM
> > > 2. Import the source to your SCM
> > > 3. update the <scm> tag in the pom.xml
> > > 4. release:prepare release:perform
> > >
> > > presto-chango, you're done
> > >
> > > On Jan 22, 2008 8:59 PM, Ken Liu < <ke...@gmail.com>
> > > wrote:
> > >
> > > > Hi Stephen -
> > > >
> > > > Thanks for your reply. Those euro-cents are worth a a lot more than
> > > > my $.02.
> > > >
> > > > I'm leaning toward option #1.
> > > >
> > > > To clarify, I wasn't planning on rebuilding the jar from the source,
> > > > just taking the SNAPSHOT jar from the public repo. In fact, I don't intend
> > > > to ever have to do this again because the particular plugin is no longer
> > > > under development (there was never an official, non SNAPSHOT release). But
> > > > point taken, if we were using a different SNAPSHOT plugin, then we might
> > > > want to version a newer SNAPSHOT. I plan on using the version "
> > > > 2.0-mycompany-1".
> > > >
> > > > Are the steps that I described sufficient for changing the version
> > > > number in the jar, or is it really necessary to build from the source? I
> > > > would rather not spend time/effort rebuilding something from the source when
> > > > the artifact is already being used.
> > > >
> > > > Ken
> > > >
> > > > On 1/22/08, Stephen Connolly < <st...@gmail.com> wrote:
> > > > >
> > > > > There are two ways:
> > > > >
> > > > > 1. Give it a new version number (e.g. 2.0-yourcompany-1) because
> > > > > you may
> > > > > want to re-build it if/WHEN you find issues with your build, and
> > > > > if you
> > > > > don't attach a build/version to the version number you'll be in
> > > > > trouble.
> > > > > Also you should prefix the build/version with yourcompany so
> > > > > people know
> > > > > it's you as what did it.
> > > > >
> > > > > 2. Alternatively, change the groupId to
> > > > > com.yourcompany.yourproduct... now
> > > > > you can have any version number you like. For that kind of change
> > > > > I would
> > > > > strongly recommend importing the source code into your SCM, as in
> > > > > reality
> > > > > this is a "fork"
> > > > >
> > > > > For both 1 & 2 I would ensure that you have a snapshot of the
> > > > > source code in
> > > > > SCM, but with option 2, you really will need that snapshot. Also
> > > > > #2 is
> > > > > probably better suited to when you need to patch the source
> > > > > heavily in order
> > > > > to get it to build, whereas #1 is for when they just have not
> > > > > pushed a
> > > > > release as recently as you'd like.
> > > > >
> > > > > Just my €0.02
> > > > >
> > > > > On Jan 22, 2008 7:54 PM, Ken Liu < <ke...@gmail.com>
> > > > > ken.liu@gmail.com > wrote:
> > > > >
> > > > > > Hi all -
> > > > > >
> > > > > > I am getting close to releasing a project and am trying to nail
> > > > > down all
> > > > > > the
> > > > > > SNAPSHOT dependencies. I have one plugin (jboss-sar), which was
> > > > > never
> > > > > > released, and only has a 2.0-SNAPSHOT version available. I want
> > > > > to take
> > > > > > this jar and assign a release number to it to be installed in
> > > > > our internal
> > > > > > maven repo.
> > > > > >
> > > > > > Is there an "official" way to do this? I have been manually
> > > > > doing the
> > > > > > following:
> > > > > > 1) in the jar, editing plugin.xml and replacing the version "
> > > > > 2.0-SNAPSHOT "
> > > > > > with "2.0-MINE"
> > > > > > 2) in the jar, editing pom.properties and changing the property
> > > > > "
> > > > > > 2.0-SNAPSHOT" with "2.0-MINE"
> > > > > > 3) in the jar, editing pom.xml and replacing the version "
> > > > > 2.0-SNAPSHOT"
> > > > > > with
> > > > > > "2.0-MINE"
> > > > > > 4) renaming the jar from "
> > > > > jboss-sar-maven-plugin-2.0-SNAPSHOT.jar" to "
> > > > > > jboss-sar-maven-plugin-2.0-MINE.jar"
> > > > > > 5) using "mvn install:install-file" to add the jar to my
> > > > > internal
> > > > > > repository
> > > > > >
> > > > > > Is this sufficient? Did I miss any steps? Is there an easier
> > > > > way to do
> > > > > > this?
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
Re: how to manually change a jar from SNAPSHOT to release?
Posted by Ken Liu <ke...@gmail.com>.
Hi Stephen -
Thanks for your reply. Those euro-cents are worth a a lot more than my $.02.
I'm leaning toward option #1.
To clarify, I wasn't planning on rebuilding the jar from the source, just
taking the SNAPSHOT jar from the public repo. In fact, I don't intend to
ever have to do this again because the particular plugin is no longer under
development (there was never an official, non SNAPSHOT release). But point
taken, if we were using a different SNAPSHOT plugin, then we might want to
version a newer SNAPSHOT. I plan on using the version "2.0-mycompany-1".
Are the steps that I described sufficient for changing the version number in
the jar, or is it really necessary to build from the source? I would rather
not spend time/effort rebuilding something from the source when the artifact
is already being used.
Ken
On 1/22/08, Stephen Connolly <st...@gmail.com> wrote:
>
> There are two ways:
>
> 1. Give it a new version number (e.g. 2.0-yourcompany-1) because you may
> want to re-build it if/WHEN you find issues with your build, and if you
> don't attach a build/version to the version number you'll be in trouble.
> Also you should prefix the build/version with yourcompany so people know
> it's you as what did it.
>
> 2. Alternatively, change the groupId to com.yourcompany.yourproduct... now
> you can have any version number you like. For that kind of change I would
> strongly recommend importing the source code into your SCM, as in reality
> this is a "fork"
>
> For both 1 & 2 I would ensure that you have a snapshot of the source code
> in
> SCM, but with option 2, you really will need that snapshot. Also #2 is
> probably better suited to when you need to patch the source heavily in
> order
> to get it to build, whereas #1 is for when they just have not pushed a
> release as recently as you'd like.
>
> Just my €0.02
>
> On Jan 22, 2008 7:54 PM, Ken Liu <ke...@gmail.com> wrote:
>
> > Hi all -
> >
> > I am getting close to releasing a project and am trying to nail down all
> > the
> > SNAPSHOT dependencies. I have one plugin (jboss-sar), which was never
> > released, and only has a 2.0-SNAPSHOT version available. I want to take
> > this jar and assign a release number to it to be installed in our
> internal
> > maven repo.
> >
> > Is there an "official" way to do this? I have been manually doing the
> > following:
> > 1) in the jar, editing plugin.xml and replacing the version "
> 2.0-SNAPSHOT"
> > with "2.0-MINE"
> > 2) in the jar, editing pom.properties and changing the property "
> > 2.0-SNAPSHOT" with "2.0-MINE"
> > 3) in the jar, editing pom.xml and replacing the version "2.0-SNAPSHOT"
> > with
> > "2.0-MINE"
> > 4) renaming the jar from "jboss-sar-maven-plugin-2.0-SNAPSHOT.jar" to "
> > jboss-sar-maven-plugin-2.0-MINE.jar"
> > 5) using "mvn install:install-file" to add the jar to my internal
> > repository
> >
> > Is this sufficient? Did I miss any steps? Is there an easier way to do
> > this?
> >
>
Re: how to manually change a jar from SNAPSHOT to release?
Posted by Stephen Connolly <st...@gmail.com>.
There are two ways:
1. Give it a new version number (e.g. 2.0-yourcompany-1) because you may
want to re-build it if/WHEN you find issues with your build, and if you
don't attach a build/version to the version number you'll be in trouble.
Also you should prefix the build/version with yourcompany so people know
it's you as what did it.
2. Alternatively, change the groupId to com.yourcompany.yourproduct... now
you can have any version number you like. For that kind of change I would
strongly recommend importing the source code into your SCM, as in reality
this is a "fork"
For both 1 & 2 I would ensure that you have a snapshot of the source code in
SCM, but with option 2, you really will need that snapshot. Also #2 is
probably better suited to when you need to patch the source heavily in order
to get it to build, whereas #1 is for when they just have not pushed a
release as recently as you'd like.
Just my €0.02
On Jan 22, 2008 7:54 PM, Ken Liu <ke...@gmail.com> wrote:
> Hi all -
>
> I am getting close to releasing a project and am trying to nail down all
> the
> SNAPSHOT dependencies. I have one plugin (jboss-sar), which was never
> released, and only has a 2.0-SNAPSHOT version available. I want to take
> this jar and assign a release number to it to be installed in our internal
> maven repo.
>
> Is there an "official" way to do this? I have been manually doing the
> following:
> 1) in the jar, editing plugin.xml and replacing the version "2.0-SNAPSHOT"
> with "2.0-MINE"
> 2) in the jar, editing pom.properties and changing the property "
> 2.0-SNAPSHOT" with "2.0-MINE"
> 3) in the jar, editing pom.xml and replacing the version "2.0-SNAPSHOT"
> with
> "2.0-MINE"
> 4) renaming the jar from "jboss-sar-maven-plugin-2.0-SNAPSHOT.jar" to "
> jboss-sar-maven-plugin-2.0-MINE.jar"
> 5) using "mvn install:install-file" to add the jar to my internal
> repository
>
> Is this sufficient? Did I miss any steps? Is there an easier way to do
> this?
>