test

[CS0020]

test

Consorsbank und DAB BNP Paribas sind eingetragene Marken der BNP Paribas S.A. 
Niederlassung Deutschland (AG nach franz. Recht).

Sitz der BNP Paribas S.A. Niederlassung Deutschland: Bahnhofstraße 55, 90402 
Nürnberg, HRB Nürnberg 31129, USt-IdNr. DE191528929
Fon +49 (0) 911 / 369-0, Fax +49 (0) 911 / 369-10 00, i...@consorsbank.de, 
www.consorsbank.de

weiterer Standort: Landsberger Str. 300 , 80687 München
Fon +49 (0) 89 / 50068-0, Fax +49 (0) 89 / 50068-630, informat...@dab.com, 
www.dab.com

Sitz der BNP Paribas S.A.: 16, boulevard des Italiens, 75009 Paris, Frankreich, 
Registergericht: R.C.S. Paris 662 042 449
Président du Conseil d‘Administration (Präsident des Verwaltungsrates): Jean 
Lemierre, Directeur Général (Generaldirektor): Jean-Laurent Bonnafé

Question on test configuration dependencies

[David Bernazal]

Hi Everyone,

I'm new to Ivy and I have a question regarding dependencies associated with
the test configuration. I have 2 modules, Module A and Module B. I have
non-standard configurations java-test and java. Java test gets mapped
to the test configuration in Ivy. I have dependencies listed in Module A
and Module B has a dependency on Module A. Module A also has certain
test-support dependencies which are required in Module B.

When I compile Module B, all of the dependencies get resolved except for
those specified under the java-test configuration. I believe this is
because of the test configuration and it being private. Is this correct?

How does one usually handle test-support dependencies such as this in a
project?

Thanks!!
~D.

RE: Published jars for test, pilot, and production environments?

[Vonnahme, Paul]

 Vonnahme, Paul wrote on 05/19/2009 01:26 PM:
  I'm hoping someone else is in a similar situation. We have some 
  utility jars used by multiple projects. These jars have three 
  different versions: one each for our test, pilot, and production 
  environments. Therefore I believe each of the versions needs to be 
  published so it will be available for multiple apps to use.
 
 
 Is there any reason not to use varying statuses for the 
 different environments?
 
 http://ant.apache.org/ivy/history/trunk/settings/statuses.html
 
 You could either use the default 
 release/milestone/integration statuses to map to your 
 environments, or use your own.
 
 In your ivy.xml,
 
dependency org=principal name=utility_jar 
 rev=latest.${ivy.build.env}/

[OT] I wasn't aware you could use ant variables in the ivy.xml files.  Very 
good to know, and I'm sure it will come in handy as I continue to experiment 
with ivy.

 
 and run in test environment:
ant -Divy.build.env=integration compile
 
 You can even default the property in ivysettings.xml, with an 
 override=false setting, to ensure your command-line param 
 takes precedence.
 
 Now just publish your utility modules with the appropriate 
 statuses, and everything should Just Work, right?

I tried this out, and at first it seemed like the answer I had been looking 
for.  However, then I noticed a few resolves that weren't happening how I 
expected.  I found this in the documentation 
(http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html):
latest.[any status]
selects the latest revision of the dependency module with **at least the 
specified status**.  (Emphasis mine)

For our environment if I run:
ant -Divy.build.env=pilot compile
I would need it to compile only with dependencies that have a pilot status.  
Since ivy statuses are hierarchical, I would run the risk of pulling a 
dependency from a higher status.  

One way I could guarantee the status would be to put
status name=${ivy.build.env} integration=false/
as my highest level status.  

I will continue to experiment more with this option as well the option of 
multiple repositories.

Thanks to all for your responses.

Paul



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

Re: Published jars for test, pilot, and production environments?

[Mitch Gitman]

Few responses inline.

On Thu, May 21, 2009 at 10:37 AM, Vonnahme, Paul 
vonnahme.p...@principal.com wrote:

 [OT] I wasn't aware you could use ant variables in the ivy.xml files.  Very
 good to know, and I'm sure it will come in handy as I continue to experiment
 with ivy.


Small correction. You can use Ant properties (not variables) in
ivysettings.xml files, *not *ivy.xml files as you say.


 
  and run in test environment:
 ant -Divy.build.env=integration compile
 
  You can even default the property in ivysettings.xml, with an
  override=false setting, to ensure your command-line param
  takes precedence.
 
  Now just publish your utility modules with the appropriate
  statuses, and everything should Just Work, right?

 I tried this out, and at first it seemed like the answer I had been looking
 for.  However, then I noticed a few resolves that weren't happening how I
 expected.  I found this in the documentation (
 http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html
 ):
 latest.[any status]
 selects the latest revision of the dependency module with **at least the
 specified status**.  (Emphasis mine)

 For our environment if I run:
ant -Divy.build.env=pilot compile
 I would need it to compile only with dependencies that have a pilot status.
  Since ivy statuses are hierarchical, I would run the risk of pulling a
 dependency from a higher status.


If I were you and I really insisted on (A) having one Ivy repository for all
my different statuses/stages and (B) not distinguishing between integration
and milestone/release via the revision value itself, then I would ask
myself, Isn't this default rule really what I want after all?

Suppose I have a web service project that is depending on a domain project
and I know I haven't had to make any changes to the domain project since its
last release to support the new pilot of your web service, then that at
least the specified status rule makes perfect sense. You don't want to have
to produce a new pilot version of your domain project to support a new pilot
version of your web service project.

Beyond that, if you found out after all that you were happy with that rule,
you might as well just make pilot correspond to the built-in milestone
status, although integration/milestone/release vs. integration/pilot/release
is a trivial matter.



 One way I could guarantee the status would be to put
status name=${ivy.build.env} integration=false/
 as my highest level status.


It sounds like to accomplish this, you would have to dynamically import an
Ivy settings fragment into your main Ivy settings, like
ivysettings-statuses-${ivy.build.env}.xml. Then if the build env is
integration, the imported file defines only one status, integration. If the
build env is pilot, the imported file defines two status, integration and
pilot. Etc.

So it sounds like this could be done, although I would still question the
motivation.



 I will continue to experiment more with this option as well the option of
 multiple repositories.

 Thanks to all for your responses.

 Paul



 -Message Disclaimer-

 This e-mail message is intended only for the use of the individual or
 entity to which it is addressed, and may contain information that is
 privileged, confidential and exempt from disclosure under applicable law.
 If you are not the intended recipient, any dissemination, distribution or
 copying of this communication is strictly prohibited. If you have
 received this communication in error, please notify us immediately by
 reply email to conn...@principal.com and delete or destroy all copies of
 the original message and attachments thereto. Email sent to or from the
 Principal Financial Group or any of its member companies may be retained
 as required by law or regulation.

 Nothing in this message is intended to constitute an Electronic signature
 for purposes of the Uniform Electronic Transactions Act (UETA) or the
 Electronic Signatures in Global and National Commerce Act (E-Sign)
 unless a specific statement to the contrary is included in this message.

 While this communication may be used to promote or market a transaction
 or an idea that is discussed in the publication, it is intended to provide
 general information about the subject matter covered and is provided with
 the understanding that The Principal is not rendering legal, accounting,
 or tax advice. It is not a marketed opinion and may not be used to avoid
 penalties under the Internal Revenue Code. You should consult with
 appropriate counsel or other advisors on all matters pertaining to legal,
 tax, or accounting obligations and requirements.

Published jars for test, pilot, and production environments?

[Vonnahme, Paul]

I'm hoping someone else is in a similar situation.  We have some utility jars 
used by multiple projects.  These jars have three different versions: one each 
for our test, pilot, and production environments.  Therefore I believe each of 
the versions needs to be published so it will be available for multiple apps to 
use.

When an app builds, it should get the latest version of the jar depending on 
the environment.  The ivy.xml would contain:
dependency org=principal name=utility_jar 
rev=latest.integration/  .

I'd like to do something like:
ant compile -Denv=test
for it to build with the latest test jar, -Denv=pilot to build with the latest 
pilot jar, etc.

My idea is to have three different versions of the settings file, and just 
change the root of a resolver based on the environment.
  property name=ivy.shared.default.root 
value=/IvyRepository/test/ would specify the root of the 'shared' resolver 
for the test environment.  /IvyRepository/pilot would exist for pilot, etc.

The problem I see with this is that the local cache would contain versions from 
all environments (depending on which one you built with last) and would have to 
be cleared out every time.

Am I overthinking the problem?  Is there a way to only have one repository but 
still be able to specify the latest jar from a specific environment?

Thanks,
Paul







-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

Re: Published jars for test, pilot, and production environments?

[Kirby Files]

Vonnahme, Paul wrote on 05/19/2009 01:26 PM:

I'm hoping someone else is in a similar situation. We have some
utility jars used by multiple projects. These jars have three
different versions: one each for our test, pilot, and production
environments. Therefore I believe each of the versions needs to be
published so it will be available for multiple apps to use.

When an app builds, it should get the latest version of the jar depending on 
the environment.  The ivy.xml would contain:
 dependency org=principal name=utility_jar 
rev=latest.integration/   .

I'd like to do something like:
 ant compile -Denv=test
for it to build with the latest test jar, -Denv=pilot to build with the latest 
pilot jar, etc.

My idea is to have three different versions of the settings file,
and just change the root of a resolver based on the environment.
   property name=ivy.shared.default.root 
value=/IvyRepository/test/
would specify the root of the 'shared' resolver for the test
environment.  /IvyRepository/pilot would exist for pilot, etc.


Is there any reason not to use varying statuses for the different 
environments?


http://ant.apache.org/ivy/history/trunk/settings/statuses.html

You could either use the default release/milestone/integration 
statuses to map to your environments, or use your own.


In your ivy.xml,

  dependency org=principal name=utility_jar 
rev=latest.${ivy.build.env}/


and run in test environment:
  ant -Divy.build.env=integration compile

You can even default the property in ivysettings.xml, with an 
override=false setting, to ensure your command-line param takes 
precedence.


Now just publish your utility modules with the appropriate statuses, 
and everything should Just Work, right?


Thanks,


Kirby Files
Software Architect
Masergy Communications
kfi...@masergy.com

Re: Published jars for test, pilot, and production environments?

[Alan Hohn]

On Tue, 19 May 2009, Kirby Files wrote:

Is there any reason not to use varying statuses for the different 
environments?


http://ant.apache.org/ivy/history/trunk/settings/statuses.html



This is a good solution if you can have separate downstream projects that 
fetch the JARs for each environment. If your situation is more complicated 
and you need to fetch different versions of an upstream JAR into the same 
downstream project for different purposes (unit test, deployment, etc.), 
look into Ivy configurations. They're designed to do exactly what you 
want.


In our project we have a unit testing version of some of our projects 
(uses in-memory database support, etc.) and Ivy configurations let us grab 
one version of the JAR to run tests in the downstream and then grab a 
different version when it's time to package an EAR file.


http://ant.apache.org/ivy/history/2.1.0-rc1/tutorial/conf.html

Best regards,
Alan

Re: Published jars for test, pilot, and production environments?

[Mitch Gitman]

Alan, I agree that configurations are a powerful--indeed a
necessary--feature of Ivy. But I would also maintain that Ivy confs are
about features, not about the problem Paul is trying to address, which is
distinguishing between integration and release builds. For that problem I
believe the techniques at hand come down to some combination of:

   - Depending on status=latest.integration, etc. And Kirby above offers a
   good technique for changing latest.${...} on the fly.
   - Maintaining separate integration and release Ivy repositories.
   - Establishing versioning conventions (probably in concert with the
   version control system) that lead to integration publications having
   distinctly different revisions than release publications. That is, you can
   tell just by looking at the form of rev=... whether it's integration or
   release.

Consider it this way. Even if you have an Ivy conf to give you your
in-memory database, you're still going to need the other Ivy conf to give
you your real database--*even for your continuous integration builds*. Now
you could say, What about the database connection strings? Wouldn't they
qualify for different Ivy confs, so you would need one Ivy conf for dev and
another for QA and yet another for production? I would maintain that even
here you're blurring the line, but then application configuration is a whole
'nuther topic in its own right.

On Tue, May 19, 2009 at 2:11 PM, Alan Hohn li...@anvard.org wrote:


 On Tue, 19 May 2009, Kirby Files wrote:

  Is there any reason not to use varying statuses for the different
 environments?

 http://ant.apache.org/ivy/history/trunk/settings/statuses.html


 This is a good solution if you can have separate downstream projects that
 fetch the JARs for each environment. If your situation is more complicated
 and you need to fetch different versions of an upstream JAR into the same
 downstream project for different purposes (unit test, deployment, etc.),
 look into Ivy configurations. They're designed to do exactly what you want.

 In our project we have a unit testing version of some of our projects (uses
 in-memory database support, etc.) and Ivy configurations let us grab one
 version of the JAR to run tests in the downstream and then grab a different
 version when it's time to package an EAR file.

 http://ant.apache.org/ivy/history/2.1.0-rc1/tutorial/conf.html

 Best regards,
 Alan

RE: Test failures in SVN

[Kanjo, Samer]

When I checked out the trunk earlier today there was only one test failure. It 
was IBiblioResolverTest.testMaven2Listing that failed. The resolution of 
commons-lang was returning two module entries rather than the expected one. The 
expected module entry was named commons-lang but an additional module entry 
named maven2 was unexpectedly returned. I didn't look into any further than 
that. I bypassed the test in order to complete the build.
 
I just did an update from the trunk and got a few changes since my checkout 
earlier in the day and ran the tests again. All passed. I checked the logs and 
see that you checked in four sets of changes after I did my checkout. I guess 
the merge from RC2 fixed the problem.




From: Maarten Coene [mailto:[EMAIL PROTECTED]
Sent: Wed 10/29/2008 5:37 PM
To: ivy-user@ant.apache.org
Subject: Re: Test failures in SVN



Yesterday, I had a problem with Ibiblio also and committed a fix for it into 
SVN trunk.
Could you give it a try and see if the tests succeed now?

Maarten




- Original Message 
From: Jim White [EMAIL PROTECTED]
To: ivy-user@ant.apache.org
Sent: Monday, October 27, 2008 5:49:40 PM
Subject: Test failures in SVN

Speaking of iBiblio, some related tests are failing for me with the
current SVN head:

http://pastebin.com/m63ca1e7

Jim


 

Re: Test failures in SVN

[Jim White]

Works for me now.

Jim

Maarten Coene wrote:


Yesterday, I had a problem with Ibiblio also and committed a fix for it into 
SVN trunk.
Could you give it a try and see if the tests succeed now?

Maarten




- Original Message 
From: Jim White [EMAIL PROTECTED]
To: ivy-user@ant.apache.org
Sent: Monday, October 27, 2008 5:49:40 PM
Subject: Test failures in SVN

Speaking of iBiblio, some related tests are failing for me with the 
current SVN head:


http://pastebin.com/m63ca1e7

Jim


  

Test failures in SVN

[Jim White]

Speaking of iBiblio, some related tests are failing for me with the 
current SVN head:


http://pastebin.com/m63ca1e7

Jim