How to manage from snapshot to release? When should we use automated builds?

[baz themail]

Hi,

I have been searching the maven website and articles but not sure if i
get the best practice for managing snapshots and release.
Specifically, if continuous builds produce maven snapshot builds, then
when will i produce maven release builds using maven release plug-in?

Will I ever produce a maven release build via an automated build job
that runs daily for example? The problem with that is: Because maven
plugin is incrementing pom.xml, and the automated build job will
always detect changes even tho there is no changes in the produce
software code. Does it even make sense? Or, release build should be
run manually depending on the release schedule?

Thank you.

A.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to manage from snapshot to release? When should we use automated builds?

[Baptiste MATHUS]

Well, for example, we don't release automatically. We  launch manually it
via a special release plugin through hudson, itself launching a maven
release through the maven-release-plugin.

This makes it easier to keep a clean release environment. Releasing from a
development machine would add risk since it (1) might be less close to the
production system and (2) might contain things depending on the dev box that
wasn't added to the SCM.

Snapshot builds are totally sufficient for us to handle testing purposes.

Cheers

2010/9/15 baz themail 

> Hi,
>
> I have been searching the maven website and articles but not sure if i
> get the best practice for managing snapshots and release.
> Specifically, if continuous builds produce maven snapshot builds, then
> when will i produce maven release builds using maven release plug-in?
>
> Will I ever produce a maven release build via an automated build job
> that runs daily for example? The problem with that is: Because maven
> plugin is incrementing pom.xml, and the automated build job will
> always detect changes even tho there is no changes in the produce
> software code. Does it even make sense? Or, release build should be
> run manually depending on the release schedule?
>
> Thank you.
>
> A.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: How to manage from snapshot to release? When should we use automated builds?

[Bengt Rodehav]

We've had similar questions where I work. The question has been related to
how and when to create tags in CVS (preferrably using the
maven-release-plugin).

Some people advocate tagging every build so that it can be recreated in case
it was fit for delivery. This is a problem when using CVS since huge number
of tags are not handled very well.

However, builds that could potentially become a released version must be
recreatable somehow which implies a tag in the version control system.
Whenever a "release candidate" is built, doesn't it have to be tagged - and
therefore released?

When we enter a system testing period close to the release of a new version.
We normally build and deploy new versions automatically every day. At some
point we decide that it's good enough to release. It is then imperative that
the latest build (which we have used for testing) is the one we package and
tag.

What are the best practices around this? I'm very curious to know how other
organisations handle this using maven.

/Bengt


2010/9/15 Baptiste MATHUS 

> Well, for example, we don't release automatically. We  launch manually it
> via a special release plugin through hudson, itself launching a maven
> release through the maven-release-plugin.
>
> This makes it easier to keep a clean release environment. Releasing from a
> development machine would add risk since it (1) might be less close to the
> production system and (2) might contain things depending on the dev box
> that
> wasn't added to the SCM.
>
> Snapshot builds are totally sufficient for us to handle testing purposes.
>
> Cheers
>
> 2010/9/15 baz themail 
>
> > Hi,
> >
> > I have been searching the maven website and articles but not sure if i
> > get the best practice for managing snapshots and release.
> > Specifically, if continuous builds produce maven snapshot builds, then
> > when will i produce maven release builds using maven release plug-in?
> >
> > Will I ever produce a maven release build via an automated build job
> > that runs daily for example? The problem with that is: Because maven
> > plugin is incrementing pom.xml, and the automated build job will
> > always detect changes even tho there is no changes in the produce
> > software code. Does it even make sense? Or, release build should be
> > run manually depending on the release schedule?
> >
> > Thank you.
> >
> > A.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

Re: How to manage from snapshot to release? When should we use automated builds?

[Baptiste MATHUS]

Yes, this is a typical, almost specific CVS problem that's understandable.
As the versioning is done at the file level, and not at the repo one, it can
be necessary to tag to be able to identify the code corresponding to a
snapshot (even if, imo, if you're depending on a snapshot revision, and try
debugging a snapshot version that's not the dev version, you have a problem
in your dev process).

This problem doesn't exist with SVN. For example, we use the
buildnumber-maven-plugin and add the svn repository revision number to the
manifest for each build. So finding corresponding code for a jar is no
problem at all for us, but we actually hardly need it.

For the dev process, only in my opinion, I think automatically releasing
every nights isn't a very good pratice. I rather think the release process
should be actually 100% standalone, but *manually* initiated (giving the new
version and so).

Cheers

2010/9/15 Bengt Rodehav 

> We've had similar questions where I work. The question has been related to
> how and when to create tags in CVS (preferrably using the
> maven-release-plugin).
>
> Some people advocate tagging every build so that it can be recreated in
> case
> it was fit for delivery. This is a problem when using CVS since huge number
> of tags are not handled very well.
>
> However, builds that could potentially become a released version must be
> recreatable somehow which implies a tag in the version control system.
> Whenever a "release candidate" is built, doesn't it have to be tagged - and
> therefore released?
>
> When we enter a system testing period close to the release of a new
> version.
> We normally build and deploy new versions automatically every day. At some
> point we decide that it's good enough to release. It is then imperative
> that
> the latest build (which we have used for testing) is the one we package and
> tag.
>
> What are the best practices around this? I'm very curious to know how other
> organisations handle this using maven.
>
> /Bengt
>
>
> 2010/9/15 Baptiste MATHUS 
>
> > Well, for example, we don't release automatically. We  launch manually it
> > via a special release plugin through hudson, itself launching a maven
> > release through the maven-release-plugin.
> >
> > This makes it easier to keep a clean release environment. Releasing from
> a
> > development machine would add risk since it (1) might be less close to
> the
> > production system and (2) might contain things depending on the dev box
> > that
> > wasn't added to the SCM.
> >
> > Snapshot builds are totally sufficient for us to handle testing purposes.
> >
> > Cheers
> >
> > 2010/9/15 baz themail 
> >
> > > Hi,
> > >
> > > I have been searching the maven website and articles but not sure if i
> > > get the best practice for managing snapshots and release.
> > > Specifically, if continuous builds produce maven snapshot builds, then
> > > when will i produce maven release builds using maven release plug-in?
> > >
> > > Will I ever produce a maven release build via an automated build job
> > > that runs daily for example? The problem with that is: Because maven
> > > plugin is incrementing pom.xml, and the automated build job will
> > > always detect changes even tho there is no changes in the produce
> > > software code. Does it even make sense? Or, release build should be
> > > run manually depending on the release schedule?
> > >
> > > Thank you.
> > >
> > > A.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: package question

[Daniel Rindt]

Am Dienstag, den 14.09.2010, 21:37 +0200 schrieb per-henrik hedman:
> And given that it's within Tomcat it probably exists at Central, so
> you won't need to add a repository declaration to your pom.xml.

Hey per,

thanks for your reply. Yes i am talking about a jar, i mentioned as
package. So the package is always installed on all runtimes. So how can
i integrate it into my pom.xml properly? 
The jar resides in /usr/share/java/javamail.jar.

Thanks
Daniel


signature.asc
Description: This is a digitally signed message part

Re: package question

[per-henrik hedman]

Hello Daniel,
you only need to define your dependency in your pom.xml and then maven
will take care of it, but you will have to define it for yourself, as
the version of the javamail needs to be correct, and only you know
what version you are using, right?

Cheers,
Per-Henrik

On Wed, Sep 15, 2010 at 10:11 AM, Daniel Rindt  wrote:
> Am Dienstag, den 14.09.2010, 21:37 +0200 schrieb per-henrik hedman:
>> And given that it's within Tomcat it probably exists at Central, so
>> you won't need to add a repository declaration to your pom.xml.
>
> Hey per,
>
> thanks for your reply. Yes i am talking about a jar, i mentioned as
> package. So the package is always installed on all runtimes. So how can
> i integrate it into my pom.xml properly?
> The jar resides in /usr/share/java/javamail.jar.
>
> Thanks
> Daniel
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: package question

[Anders Hammar]

1. Get yourself a repo manager. I suggest Nexus, but there are others.
2. Deploy the jar to a repo in the manager.
3. Declare the dependency in your pom the normal Maven way.

This has been discussed several times on the list and there are also
numerous blog posts. Here's one:
http://www.sonatype.com/people/2010/08/benefits-of-a-repository-manager-part-ii-caching-and-collaborating/

/Anders

On Wed, Sep 15, 2010 at 10:11, Daniel Rindt  wrote:

> Am Dienstag, den 14.09.2010, 21:37 +0200 schrieb per-henrik hedman:
> > And given that it's within Tomcat it probably exists at Central, so
> > you won't need to add a repository declaration to your pom.xml.
>
> Hey per,
>
> thanks for your reply. Yes i am talking about a jar, i mentioned as
> package. So the package is always installed on all runtimes. So how can
> i integrate it into my pom.xml properly?
> The jar resides in /usr/share/java/javamail.jar.
>
> Thanks
> Daniel
>

Mixing local repo and managed repo

[Em DauPhu]

Hi,

I came across a continuous integration server hosting both an Hudson
and an Archiva (as a proxy to our central).
The settings.xml used in maven builds declare as the local repo the
managed repository of the archiva (same directory).
Is that wrong to use as a local repository (declared in the maven
settings.xml) the actual managed repository of the repository manager?
Can it leads to any trouble (it apparently does)?

I'm about to change that anyway but I could use some explanations as
"the local and remote repositories are structured the same way" if it
causes any trouble.

Thank you,
Em.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: package question

[Daniel Rindt]

Am Mittwoch, den 15.09.2010, 10:20 +0200 schrieb per-henrik hedman:
> you only need to define your dependency in your pom.xml and then maven
> will take care of it, but you will have to define it for yourself, as
> the version of the javamail needs to be correct, and only you know
> what version you are using, right?
I understand that maven takes care about. But how to define this
external jar file? So first i have to import it into my ~/.m2 repo?
Sorry but a repository and nexus stuff is to much for me.
The version i use is classpathx-mail-1.1.1. 
Can you please give me a example?

many TIA
Daniel


signature.asc
Description: This is a digitally signed message part

Re: Mixing local repo and managed repo

[Baptiste MATHUS]

Hi,

Yes, first local and remote maven repository doesn't contain the same
metadata.
And by the way, accessing a local repository by many instances isn't
concurrent-safe (at least, in maven 2, I don't know precisely what's been
done for maven 3, particularly along the parallel build evolution). So, both
must be avoided.

You also better want to isolate every hudson build from each other, having a
local repository by job. And wiping those jobs regularly.
http://www.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/
And
a specific setting for hudson on my blog:
http://batmat.net/blog/post/2009/10/09/[Hudson]-How-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them
.

Cheers

2010/9/15 Em DauPhu 

> Hi,
>
> I came across a continuous integration server hosting both an Hudson
> and an Archiva (as a proxy to our central).
> The settings.xml used in maven builds declare as the local repo the
> managed repository of the archiva (same directory).
> Is that wrong to use as a local repository (declared in the maven
> settings.xml) the actual managed repository of the repository manager?
> Can it leads to any trouble (it apparently does)?
>
> I'm about to change that anyway but I could use some explanations as
> "the local and remote repositories are structured the same way" if it
> causes any trouble.
>
> Thank you,
> Em.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: package question

[Baptiste MATHUS]

Hi,

Setting up a nexus is two minutes work, and then makes you easier the
ongoing config/add every days.

But anyway, yes, you can install properly a resource into the local
repository. Just google install:install-file to find doc about that goal.
Before doing that, you should triple-check on the web that this jar hasn't
already been deployed to central maven repository under some path.
Because if so, you deploy it locally in another path and someone uses the
version on the public path, you're gonna end up in classpath-hell.

Cheers

2010/9/15 Daniel Rindt 

> Am Mittwoch, den 15.09.2010, 10:20 +0200 schrieb per-henrik hedman:
> > you only need to define your dependency in your pom.xml and then maven
> > will take care of it, but you will have to define it for yourself, as
> > the version of the javamail needs to be correct, and only you know
> > what version you are using, right?
> I understand that maven takes care about. But how to define this
> external jar file? So first i have to import it into my ~/.m2 repo?
> Sorry but a repository and nexus stuff is to much for me.
> The version i use is classpathx-mail-1.1.1.
> Can you please give me a example?
>
> many TIA
> Daniel
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

New Eclipse Plugin - hot Deployment for application servers

[Ralph Soika]

 Hi,

I have started a new Eclipse Plugin project to support hot deployment 
and incremental deployment of Multi-Module Projects into App servers 
like Glassfish or JBoss. In most cases when the maven project contains 
more than one ejb or web modules the deployment from Eclipse WTP Plugin 
fails.

So try out the manik-hot-deploy plugin:

http://code.google.com/p/manik-hot-deploy/

It can increase your development speed!
Your feedback is welcome.

==
Ralph

Re: package question

[Stephen Connolly]

if you get the md5 sum of the jar file, then a nexus instance that is
configured will let you search by md5 or sha1 sum for the artifact.

for example if you go to repository.sonatype.org, click on advanced search
and then change to checksum search you can get it to search for the jar on
central.

-Stephen


On 15 September 2010 10:26, Baptiste MATHUS  wrote:

> Hi,
>
> Setting up a nexus is two minutes work, and then makes you easier the
> ongoing config/add every days.
>
> But anyway, yes, you can install properly a resource into the local
> repository. Just google install:install-file to find doc about that goal.
> Before doing that, you should triple-check on the web that this jar hasn't
> already been deployed to central maven repository under some path.
> Because if so, you deploy it locally in another path and someone uses the
> version on the public path, you're gonna end up in classpath-hell.
>
> Cheers
>
> 2010/9/15 Daniel Rindt 
>
> > Am Mittwoch, den 15.09.2010, 10:20 +0200 schrieb per-henrik hedman:
> > > you only need to define your dependency in your pom.xml and then maven
> > > will take care of it, but you will have to define it for yourself, as
> > > the version of the javamail needs to be correct, and only you know
> > > what version you are using, right?
> > I understand that maven takes care about. But how to define this
> > external jar file? So first i have to import it into my ~/.m2 repo?
> > Sorry but a repository and nexus stuff is to much for me.
> > The version i use is classpathx-mail-1.1.1.
> > Can you please give me a example?
> >
> > many TIA
> > Daniel
> >
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

Re: How to manage from snapshot to release? When should we use automated builds?

[Bengt Rodehav]

Thanks for your input Baptiste,

Yes, we have been debating the relase process a bit here. Keeping the relase
process separate would e g mean that we know beforehand that we want to
build a release candidate. We could then start with the tagging and then
checkout on this tag for the build of the release candidate.

Not quite sure what you mean by:

(even if, imo, if you're depending on a snapshot revision, and try

debugging a snapshot version that's not the dev version, you have a problem

in your dev process)


Our central, nightly builds do not use published snapshots but always checks
out from CVS and then build from source. I agree that if a central build
(that could be a release candidate) was built using published snapshots, we
would have a problem.

/Bengt


2010/9/15 Baptiste MATHUS 

> Yes, this is a typical, almost specific CVS problem that's understandable.
> As the versioning is done at the file level, and not at the repo one, it
> can
> be necessary to tag to be able to identify the code corresponding to a
> snapshot (even if, imo, if you're depending on a snapshot revision, and try
> debugging a snapshot version that's not the dev version, you have a problem
> in your dev process).
>
> This problem doesn't exist with SVN. For example, we use the
> buildnumber-maven-plugin and add the svn repository revision number to the
> manifest for each build. So finding corresponding code for a jar is no
> problem at all for us, but we actually hardly need it.
>
> For the dev process, only in my opinion, I think automatically releasing
> every nights isn't a very good pratice. I rather think the release process
> should be actually 100% standalone, but *manually* initiated (giving the
> new
> version and so).
>
> Cheers
>
> 2010/9/15 Bengt Rodehav 
>
> > We've had similar questions where I work. The question has been related
> to
> > how and when to create tags in CVS (preferrably using the
> > maven-release-plugin).
> >
> > Some people advocate tagging every build so that it can be recreated in
> > case
> > it was fit for delivery. This is a problem when using CVS since huge
> number
> > of tags are not handled very well.
> >
> > However, builds that could potentially become a released version must be
> > recreatable somehow which implies a tag in the version control system.
> > Whenever a "release candidate" is built, doesn't it have to be tagged -
> and
> > therefore released?
> >
> > When we enter a system testing period close to the release of a new
> > version.
> > We normally build and deploy new versions automatically every day. At
> some
> > point we decide that it's good enough to release. It is then imperative
> > that
> > the latest build (which we have used for testing) is the one we package
> and
> > tag.
> >
> > What are the best practices around this? I'm very curious to know how
> other
> > organisations handle this using maven.
> >
> > /Bengt
> >
> >
> > 2010/9/15 Baptiste MATHUS 
> >
> > > Well, for example, we don't release automatically. We  launch manually
> it
> > > via a special release plugin through hudson, itself launching a maven
> > > release through the maven-release-plugin.
> > >
> > > This makes it easier to keep a clean release environment. Releasing
> from
> > a
> > > development machine would add risk since it (1) might be less close to
> > the
> > > production system and (2) might contain things depending on the dev box
> > > that
> > > wasn't added to the SCM.
> > >
> > > Snapshot builds are totally sufficient for us to handle testing
> purposes.
> > >
> > > Cheers
> > >
> > > 2010/9/15 baz themail 
> > >
> > > > Hi,
> > > >
> > > > I have been searching the maven website and articles but not sure if
> i
> > > > get the best practice for managing snapshots and release.
> > > > Specifically, if continuous builds produce maven snapshot builds,
> then
> > > > when will i produce maven release builds using maven release plug-in?
> > > >
> > > > Will I ever produce a maven release build via an automated build job
> > > > that runs daily for example? The problem with that is: Because maven
> > > > plugin is incrementing pom.xml, and the automated build job will
> > > > always detect changes even tho there is no changes in the produce
> > > > software code. Does it even make sense? Or, release build should be
> > > > run manually depending on the release schedule?
> > > >
> > > > Thank you.
> > > >
> > > > A.
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Baptiste  MATHUS - http://batmat.net
> > > Sauvez un arbre,
> > > Mangez un castor !
> > >
> >
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

Re: Mixing local repo and managed repo

[Em DauPhu]

Didn't know metadata were different, as I quoted from maven website:
"the local and remote repositories are structured the same way".

Thank you for the great answer, couldn't expect less from an ig2k student ;)
Em.

On Wed, Sep 15, 2010 at 11:16 AM, Baptiste MATHUS  wrote:
> Hi,
>
> Yes, first local and remote maven repository doesn't contain the same
> metadata.
> And by the way, accessing a local repository by many instances isn't
> concurrent-safe (at least, in maven 2, I don't know precisely what's been
> done for maven 3, particularly along the parallel build evolution). So, both
> must be avoided.
>
> You also better want to isolate every hudson build from each other, having a
> local repository by job. And wiping those jobs regularly.
> http://www.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/
> And
> a specific setting for hudson on my blog:
> http://batmat.net/blog/post/2009/10/09/[Hudson]-How-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them
> .
>
> Cheers
>
> 2010/9/15 Em DauPhu 
>
>> Hi,
>>
>> I came across a continuous integration server hosting both an Hudson
>> and an Archiva (as a proxy to our central).
>> The settings.xml used in maven builds declare as the local repo the
>> managed repository of the archiva (same directory).
>> Is that wrong to use as a local repository (declared in the maven
>> settings.xml) the actual managed repository of the repository manager?
>> Can it leads to any trouble (it apparently does)?
>>
>> I'm about to change that anyway but I could use some explanations as
>> "the local and remote repositories are structured the same way" if it
>> causes any trouble.
>>
>> Thank you,
>> Em.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

A wsdl file as an artifact

[Anders Hammar]

How do people manage wsdl files in their repo. Do you manage them in a jar
artifact or any other way?

Re: A wsdl file as an artifact

[Olivier Lamy]

Hi,
You can probably try to share this with Maven Remote Resources Plugin.

2010/9/15 Anders Hammar :
> How do people manage wsdl files in their repo. Do you manage them in a jar
> artifact or any other way?
>



-- 
Olivier
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A wsdl file as an artifact

[Jörg Schaible]

Hi ANders

Anders Hammar wrote:

> How do people manage wsdl files in their repo. Do you manage them in a jar
> artifact or any other way?

Use the build-helper plugin. We manage xsd files as artifacts:

== %< == 
 
  org.codehaus.mojo
  build-helper-maven-plugin
  
   
xml-schema

 attach-artifact


 
  
   src/main/schema/UserGroup.xsd
   xsd
  
 

   
  
 
== %< ==

The packaging type of the project is "pom". We can reference the xsd 
artifact later as normal dependency with type xsd.

Hope this helps,
Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A wsdl file as an artifact

[Anders Hammar]

Thanks!

Jörg's approach is what I was thinking of. The only drawback is
bad/incorrect metadata (pom packaging). That could be fixed though.
The nice thing is that this would also work great with a ws registry
containing wsdl files, which could quite easily be proxied by a repo manager
as a maven repo.

Any drawback not packing it as a jar that someone could think of?

/Anders

On Wed, Sep 15, 2010 at 12:31, Jörg Schaible  wrote:

> Hi ANders
>
> Anders Hammar wrote:
>
> > How do people manage wsdl files in their repo. Do you manage them in a
> jar
> > artifact or any other way?
>
> Use the build-helper plugin. We manage xsd files as artifacts:
>
> == %< ==
>  
>  org.codehaus.mojo
>  build-helper-maven-plugin
>  
>   
>xml-schema
>
> attach-artifact
>
>
> 
>  
>   src/main/schema/UserGroup.xsd
>   xsd
>  
> 
>
>   
>  
>  
> == %< ==
>
> The packaging type of the project is "pom". We can reference the xsd
> artifact later as normal dependency with type xsd.
>
> Hope this helps,
> Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Mixing local repo and managed repo

[Baptiste MATHUS]

I'm not totally sure, but I think this sentence refers to the structure
(groupId(dots replaced with subdirs)/artifactId/version), not compulsorily
the attached metadata. I just checked on my box and on our internal archiva
instance, for example, maven-metadata.xml on the server is renamed locally
maven-metadata-[repositoryId].xml. Sure, repository manager like nexus or
archiva are able to recreate re-index those directories, but I think it
might be complicated for it to also handle the potentially highly concurrent
access aspect of the problem (hudson jobs + deployment: in your case reading
a file locally, and writing to this very file after having gone through the
http stack or so while deploying :-/).

Cheers

2010/9/15 Em DauPhu 

> Didn't know metadata were different, as I quoted from maven website:
> "the local and remote repositories are structured the same way".
>
> Thank you for the great answer, couldn't expect less from an ig2k student
> ;)
>

Ig2k forever :-).


> Em.
>
> On Wed, Sep 15, 2010 at 11:16 AM, Baptiste MATHUS  wrote:
> > Hi,
> >
> > Yes, first local and remote maven repository doesn't contain the same
> > metadata.
> > And by the way, accessing a local repository by many instances isn't
> > concurrent-safe (at least, in maven 2, I don't know precisely what's been
> > done for maven 3, particularly along the parallel build evolution). So,
> both
> > must be avoided.
> >
> > You also better want to isolate every hudson build from each other,
> having a
> > local repository by job. And wiping those jobs regularly.
> >
> http://www.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/
> > <
> http://www.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/
> >And
> > a specific setting for hudson on my blog:
> >
> http://batmat.net/blog/post/2009/10/09/[Hudson]-How-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them
> > .
> >
> > Cheers
> >
> > 2010/9/15 Em DauPhu 
> >
> >> Hi,
> >>
> >> I came across a continuous integration server hosting both an Hudson
> >> and an Archiva (as a proxy to our central).
> >> The settings.xml used in maven builds declare as the local repo the
> >> managed repository of the archiva (same directory).
> >> Is that wrong to use as a local repository (declared in the maven
> >> settings.xml) the actual managed repository of the repository manager?
> >> Can it leads to any trouble (it apparently does)?
> >>
> >> I'm about to change that anyway but I could use some explanations as
> >> "the local and remote repositories are structured the same way" if it
> >> causes any trouble.
> >>
> >> Thank you,
> >> Em.
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: A wsdl file as an artifact

[Jörg Schaible]

Hi Anders,

Anders Hammar wrote:

> Thanks!
> 
> Jörg's approach is what I was thinking of. The only drawback is
> bad/incorrect metadata (pom packaging). That could be fixed though.
> The nice thing is that this would also work great with a ws registry
> containing wsdl files, which could quite easily be proxied by a repo
> manager as a maven repo.
> 
> Any drawback not packing it as a jar that someone could think of?

Why do you need a jar? With packaging pom you will have a pom and a wsdl in 
repository afterwards. The packaging is more of interest for automated 
classpath processing.

- Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A wsdl file as an artifact

[Anders Hammar]

I don't necessarily want a jar. I'm just wondering if anyone have run into
issues using either one of the approaches. I'm thinking about classpaths,
plugins etc.

The packaging type is metadata and should be correct. For the this project
the wsdl file is the primary artifact, but if the packing says 'pom' we're
saying that the pom is the artifact. It's not a major issue, but could cause
some problems for tools using the metadata (like a repo manager).

How do you handle your schemas. Do the artifact's version follow the version
of the schema?

/Anders
On Wed, Sep 15, 2010 at 14:54, Jörg Schaible  wrote:

> Hi Anders,
>
> Anders Hammar wrote:
>
> > Thanks!
> >
> > Jörg's approach is what I was thinking of. The only drawback is
> > bad/incorrect metadata (pom packaging). That could be fixed though.
> > The nice thing is that this would also work great with a ws registry
> > containing wsdl files, which could quite easily be proxied by a repo
> > manager as a maven repo.
> >
> > Any drawback not packing it as a jar that someone could think of?
>
> Why do you need a jar? With packaging pom you will have a pom and a wsdl in
> repository afterwards. The packaging is more of interest for automated
> classpath processing.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: package question

[Daniel Rindt]

Am Mittwoch, den 15.09.2010, 11:04 +0100 schrieb Stephen Connolly:
> if you get the md5 sum of the jar file, then a nexus instance that is
> configured will let you search by md5 or sha1 sum for the artifact.
I have done this:
=== 8< ===
$ md5sum /usr/share/java/javamail.jar
c091017514d3e3704865765816afed35  /usr/share/java/javamail.jar
=== >8 ===
Then i invoked a checksum search on the Repository you mentioned, no
summary.

So i guess i have to add it manually to me ~/.m2 repo.

Thanks
Daniel


signature.asc
Description: This is a digitally signed message part

Running Findbugs with Maven fails

[Perez Ronen]

Hi,
I am trying to analyze a Maven project with Findbugs, as follows:
mvn org.codehaus.mojo:findbugs-maven-plugin:2.3.1:findbugs
The build is successful, but there is no trace of the analysis reports and I 
also get the following output:
[INFO] [findbugs:findbugs {execution: default-cli}]
[INFO] Locale is en
 [java] BCEL class compatability error.
 [java] The version of class org.apache.bcel.generic.ObjectType found was not 
compatible with
 [java] FindBugs.  Please remove any BCEL libraries that may be interfering.  
This may happen
 [java] if you have an old version of BCEL or a library that includes an old 
version of BCEL
 [java] in an "endorsed" directory.
 [java] Java Result: 1
I scanned my entire computer and there is no BCEL jar in an endorsed dir. I 
also removed all BCEL jars I had (7 jars) and even in a BCEL-free system the 
problem happen.
Any idea?
Ronen.



"This e-mail message may contain confidential, commercial or privileged 
information that constitutes proprietary information of Comverse Technology or 
its subsidiaries. If you are not the intended recipient of this message, you 
are hereby notified that any review, use or distribution of this information is 
absolutely prohibited and we request that you delete all copies and contact us 
by e-mailing to: secur...@comverse.com. Thank You."

scm problems wtih release plugin

[Thomas Markus]

 hi,

i have a multi module project (40 projects) with cvs as scm. when i try 
to create a release i got the error


[INFO] Tagging release with the label xxx-5_6_986...
[INFO] 


[ERROR] BUILD FAILURE
[INFO] 


[INFO] The scm url is invalid.
  - The connection string contains too few tokens.


but my scm url is valid. a new version is committed. in another mult 
module projects this works fine.


these steps work fine:
- checkout local copy
- assign release version
- commit poms with release
- release:rollback

i use org.apache.maven.plugins:maven-release-plugin:2.0

any hints?

regards
Thomas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A wsdl file as an artifact

[Daniel Kulp]

On Wednesday 15 September 2010 7:26:04 am Anders Hammar wrote:
> Thanks!
> 
> Jörg's approach is what I was thinking of. The only drawback is
> bad/incorrect metadata (pom packaging). That could be fixed though.
> The nice thing is that this would also work great with a ws registry
> containing wsdl files, which could quite easily be proxied by a repo
> manager as a maven repo.
> 
> Any drawback not packing it as a jar that someone could think of?

Some thing to think about:

1) Are the schemas and such referenced in the WSDL completely inlined?   
Alternatively, are they fully resolvable address?   If so, attaching the wsdl 
works fine.   If not, it get's MUCH more complex as there may be issues 
resolving imports/includes and such.   

2) What are the "plans" for the WSDL?   CXF's codegen plugin was recently 
updated to support specifying a artifact in the repo for code generation.  It 
would automatically grab the wsdl and run the wsdl2java stuff on it.  HOWEVER, 
the issue in #1 is still an issue.

3) With a "jar", you can have the schema imports and such and  things pretty 
much will work with imports and such.

4) The CXF "java2wsdl" maven plugin, which generates inline schema, now has a 
flag to attach the wsdl.   In our normal use case that we've seen, the jar 
containing the java code is still the primary artifact, but the wsdl gets 
attached with a "wsdl" classifier (which then also works great with the 
codegen plugin mentioned in 2).



Dan



> 
> /Anders
> 
> On Wed, Sep 15, 2010 at 12:31, Jörg Schaible  wrote:
> > Hi ANders
> > 
> > Anders Hammar wrote:
> > > How do people manage wsdl files in their repo. Do you manage them in a
> > 
> > jar
> > 
> > > artifact or any other way?
> > 
> > Use the build-helper plugin. We manage xsd files as artifacts:
> > 
> > == %< ==
> > 
> >  
> >  org.codehaus.mojo
> >  build-helper-maven-plugin
> >  
> >  
> >   
> >   
> >xml-schema
> >
> >
> > attach-artifact
> >
> >
> >
> >
> > 
> > 
> >  
> >  
> >   src/main/schema/UserGroup.xsd
> >   xsd
> >  
> >  
> > 
> > 
> >
> >
> >   
> >   
> >  
> >  
> >  
> > 
> > == %< ==
> > 
> > The packaging type of the project is "pom". We can reference the xsd
> > artifact later as normal dependency with type xsd.
> > 
> > Hope this helps,
> > Jörg
> > 
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org

-- 
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Release Notes Plugin

[Felipe Roos]

Hi Folks,


Does anyone knows about a plugin that can attach/generate an internal release 
notes?
For instance, I'm trying to generate a report based on SVN changelog filtering, 
as that might be interesting for testers that use the component to perform 
system testing. I've looked at some approaches using maven changelog pluging, 
but that requires me to know in advance what range of revisions/date I need. 
What I'm looking for is an automated way of getting the change log since last 
version.


How do you guys deal with release notes in general when using maven? 

Regards,

 Felipe Roos
http://www.linkedin.com/in/feliperoos


Achar desculpas para os nossos 
defeitos não nos torna melhores





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Release Notes Plugin

[Yanko, Curtis]

Site? 




Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
CT039-05C |  office: 860.702.9059 | email: c...@uhc.com | intranet: cis.uhc.com
Making IT Happen, one build at a time

-Original Message-
From: Felipe Roos [mailto:feliper...@yahoo.com] 
Sent: Wednesday, September 15, 2010 12:57 PM
To: users@maven.apache.org
Subject: Release Notes Plugin

Hi Folks,


Does anyone knows about a plugin that can attach/generate an internal release 
notes?
For instance, I'm trying to generate a report based on SVN changelog filtering, 
as that might be interesting for testers that use the component to perform 
system testing. I've looked at some approaches using maven changelog pluging, 
but that requires me to know in advance what range of revisions/date I need. 
What I'm looking for is an automated way of getting the change log since last 
version.


How do you guys deal with release notes in general when using maven? 

Regards,

 Felipe Roos
http://www.linkedin.com/in/feliperoos


Achar desculpas para os nossos
defeitos não nos torna melhores



  

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Release Notes Plugin

[Dennis Lundberg]

We use the Changes Plugin, which has goals for creating and emailing
announcements for releases. The contents of the release notes can
currently come in 3 flavors: a (hand edited) changes.xml file or from
one of the issue trackers JIRA or Trac.

On 2010-09-15 18:56, Felipe Roos wrote:
> Hi Folks,
> 
> 
> Does anyone knows about a plugin that can attach/generate an internal release 
> notes?
> For instance, I'm trying to generate a report based on SVN changelog 
> filtering, 
> as that might be interesting for testers that use the component to perform 
> system testing. I've looked at some approaches using maven changelog pluging, 
> but that requires me to know in advance what range of revisions/date I need. 
> What I'm looking for is an automated way of getting the change log since last 
> version.
> 
> 
> How do you guys deal with release notes in general when using maven? 
> 
> Regards,
> 
>  Felipe Roos
> http://www.linkedin.com/in/feliperoos
> 
> 
> Achar desculpas para os nossos 
> defeitos não nos torna melhores
> 
> 
> 
>   
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A wsdl file as an artifact

[Jörg Schaible]

Hi Anders,

Anders Hammar wrote:

> I don't necessarily want a jar. I'm just wondering if anyone have run into
> issues using either one of the approaches. I'm thinking about classpaths,
> plugins etc.
> 
> The packaging type is metadata and should be correct. For the this project
> the wsdl file is the primary artifact, but if the packing says 'pom' we're
> saying that the pom is the artifact. It's not a major issue, but could
> cause some problems for tools using the metadata (like a repo manager).
> 
> How do you handle your schemas. Do the artifact's version follow the
> version of the schema?

Yes. The nice thing is that after rel,ease it is possible to access it 
directly from a Maven repo.

If we need the file for further processing (e.g. XMLBeans) we simply add it 
to the deps and use the dependencies plugin to pull it off the repo:

 
  maven-dependency-plugin
  
   
schema
initialize

 copy-dependencies


 target/xsd
 false
 true
 xsd
 provided

   
  
 


However, as Danial said, this is fine for self-containing files and can be 
difficult if is is XML and contains includes.

- Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A wsdl file as an artifact

[Anders Hammar]

Ok, thank you all for your input!

/Anders

On Wed, Sep 15, 2010 at 20:05, Jörg Schaible  wrote:

> Hi Anders,
>
> Anders Hammar wrote:
>
> > I don't necessarily want a jar. I'm just wondering if anyone have run
> into
> > issues using either one of the approaches. I'm thinking about classpaths,
> > plugins etc.
> >
> > The packaging type is metadata and should be correct. For the this
> project
> > the wsdl file is the primary artifact, but if the packing says 'pom'
> we're
> > saying that the pom is the artifact. It's not a major issue, but could
> > cause some problems for tools using the metadata (like a repo manager).
> >
> > How do you handle your schemas. Do the artifact's version follow the
> > version of the schema?
>
> Yes. The nice thing is that after rel,ease it is possible to access it
> directly from a Maven repo.
>
> If we need the file for further processing (e.g. XMLBeans) we simply add it
> to the deps and use the dependencies plugin to pull it off the repo:
>
>  
>  maven-dependency-plugin
>  
>   
>schema
>initialize
>
> copy-dependencies
>
>
> target/xsd
> false
> true
> xsd
> provided
>
>   
>  
>  
>
>
> However, as Danial said, this is fine for self-containing files and can be
> difficult if is is XML and contains includes.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[PLEASE TEST] Apache Maven 3.0-RC1

[Benjamin Bentmann]

Hi,

in preparation for the release of Apache Maven 3.0, the Maven team is 
seeking your help to discover regressions since Maven 2.x. Everybody 
interested in taking a preview of the upcoming release for a test drive 
can get source and binary bundles from this URL:


https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/

Before reporting any issues found during testing, please be sure to have 
a close look at the compatibility notes for Maven 3.x:


https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes

If you encounter unexpected build issues, please fill a report in JIRA 
that provides sufficient information to reproduce and analyze the issue:


http://jira.codehaus.org/browse/MNG

The fixes contained in this release candidate since the 3.0-beta-3 
release can also be seen in JIRA:


http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=PRIR5ueW-i&version=13142&styleName=Text&projectId=10500&Create=Create

Thanks,


-The Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to manage from snapshot to release? When should we use automated builds?

[Ron Wheeler]

 Does anyone have a "Best Practice" already written for this?

From what I understand:
a) since releases are immutable, you can only deploy a release once.
b) you are allowed to deploy snapshots as often as you want
c) a human being needs to decide when you are starting to build releases.
d) you can use alpha, beta, release candidates RC1, RC2, RC3, etc. to 
identify releases prior to a cleanly numbered release. Someone once 
wrote a forum note about this, I think.
e) different parts of an application can be at different stages in a 
release but this does create a need for careful management and some 
consideration in a continuous build environment.
We got tired of (and ran out of time for) changing release numbers on 
modules that did not change as fast as the application. For example, our 
release 1.10 of the overall application depends on messaging utility 
1.8.3 since the messaging utility has not changed since 1.8.3 was 
released.  We have over 60 projects in our portal application and only 3 
people in development so we can not change and rebuild and rerelease 55 
projects just because 5 modules got upgraded going from 1.9 to 1.10.
As we moved more functionality into services, we got more stability in 
the modules and it appeared that we were spending too much time 
redeploying modules with new versions and the same functionality.
We decided that it was alright for release 1.9 of the ContractAdmin war 
to have a dependency on 1.8.3 of the messaging system jar.
We do have some aggregation jars that help manage this by creating a 
single 1.10 OurLibraries jar that has the right dependencies of the 
utilities such as messaging.


It does require a bit of planning and coordination where a decision to 
add a function to the messaging utility to accommodate a new function in 
a dependent module has to be addressed by the entire team and those 
modules that use the messaging utility need to have their dependencies 
changed and also need more testing than they might have got if they were 
not changing or their dependencies were not changing.


 Not sure how this relates to other environments and I do not think 
that this is a candidate for a "Best Practice" until others have used it 
and found that it solves a problem in a certain development environment. 
It is probably not suitable for large teams where the cost of 
coordination exceeds the cost of upgrading releases. For a small team, 
where rereleasing 55 modules can be avoided
by a few extra question in 30 minute planning session and a 15 minute 
review prior to going into test and a short conference or e-mail when a 
module has to be changed that was not on the original list for the 
release, this appears to work.


Ron

On 15/09/2010 6:09 AM, Bengt Rodehav wrote:

Thanks for your input Baptiste,

Yes, we have been debating the relase process a bit here. Keeping the relase
process separate would e g mean that we know beforehand that we want to
build a release candidate. We could then start with the tagging and then
checkout on this tag for the build of the release candidate.

Not quite sure what you mean by:

(even if, imo, if you're depending on a snapshot revision, and try

debugging a snapshot version that's not the dev version, you have a problem

in your dev process)


Our central, nightly builds do not use published snapshots but always checks
out from CVS and then build from source. I agree that if a central build
(that could be a release candidate) was built using published snapshots, we
would have a problem.

/Bengt


2010/9/15 Baptiste MATHUS


Yes, this is a typical, almost specific CVS problem that's understandable.
As the versioning is done at the file level, and not at the repo one, it
can
be necessary to tag to be able to identify the code corresponding to a
snapshot (even if, imo, if you're depending on a snapshot revision, and try
debugging a snapshot version that's not the dev version, you have a problem
in your dev process).

This problem doesn't exist with SVN. For example, we use the
buildnumber-maven-plugin and add the svn repository revision number to the
manifest for each build. So finding corresponding code for a jar is no
problem at all for us, but we actually hardly need it.

For the dev process, only in my opinion, I think automatically releasing
every nights isn't a very good pratice. I rather think the release process
should be actually 100% standalone, but *manually* initiated (giving the
new
version and so).

Cheers

2010/9/15 Bengt Rodehav


We've had similar questions where I work. The question has been related

to

how and when to create tags in CVS (preferrably using the
maven-release-plugin).

Some people advocate tagging every build so that it can be recreated in
case
it was fit for delivery. This is a problem when using CVS since huge

number

of tags are not handled very well.

However, builds that could potentially become a released version must be
recreatable somehow which implies a tag in the version control 

Re: archetype-catalog.xml and its properties and goals elements, what populates them?

[lukewpatterson]

Anyone have any info/background on the  and  sections of
archetype-catalog.xml ?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/archetype-catalog-xml-and-its-properties-and-goals-elements-what-populates-them-tp2799170p2841463.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org