RE: Bug 46326 - StarTeam: Use Cache Agent for Checkouts

[Ballment, John]

Hi Paul,

 

I've attached the new code that includes the new interface
StarTeamLogOnProvider and three implementations classes
StarTeamDefaultLogOn, StarTeamAutoLogOn and StarTeamEncryptLogOn.  This
interface should allow developers to create their own log on mechanisms
and plug them into the ANT class path without having to add them to the
ANT source/distro.

 

The source code can be downloaded from
http://users.tpg.com.au/dkunder/ant-starteam-src.zip and the complied
jar file for ANT 1.7.0 can be download from
http://users.tpg.com.au/dkunder/ant-starteam.zip. 

 

PS. Sorry for the last couple of messages, the corporate mail server
wouldn't let any of the files through.

 

Regards, 

__  

Pacific National
John Ballment BIT(IS) 
Senior Systems Analyst 

john_ballm...@pacificnational.com.au
 
Phone: (02) 9893 2618 
Fax: (02) 9893 2698 
Mobile: 0418 740 871 
http://www.pacificnational.com.au/

Level 4, 2-12 Macquarie Street
Parramatta NSW 2150 Australia



From: Ballment, John 
Sent: Tuesday, 16 June 2009 11:51
To: 'Paul Coste'
Subject: RE: Bug 46326 - StarTeam: Use Cache Agent for Checkouts

 

Hi Paul,

 

That cool.  Just to let you know, I've just gone back and read the email
from Joe Schulz and it states:

 

As for using my EncryptPassword utility, you are definitely more than
welcome to call it within the ANT tasks.  If you'd like, I can repackage
the required classes in any way that would facilitate the work you're
doing.  Just let me know if there is anything I can do to help.

 

If I read this correctly he's allowing us to call his package from ANT
and if any repackaging is required he will do it for us but he is not
making the code available for addition to ANT/apache code base.

 

In saying this I've created an extendable Interface that allows
different StarTeam log on methods to be plugged into classpath
dynamically.  I should have this ready in the next day or so.

 

Regards, 

__  

Pacific National
John Ballment BIT(IS) 
Senior Systems Analyst 

john_ballm...@pacificnational.com.au
 
Phone: (02) 9893 2618 
Fax: (02) 9893 2698 
Mobile: 0418 740 871 
http://www.pacificnational.com.au/

Level 4, 2-12 Macquarie Street
Parramatta NSW 2150 Australia



From: Paul Coste [mailto:paulyphon...@gmail.com] 
Sent: Tuesday, 16 June 2009 00:09
To: Ballment, John
Subject: Re: Bug 46326 - StarTeam: Use Cache Agent for Checkouts

 

Hi John,

Unfortunately the person who was testing it no longer works for us and
I've been so busy I haven't had a chance to pick this up again.  But it
is still on my radar.

Paul

On Mon, Jun 15, 2009 at 3:07 AM, Ballment, John
 wrote:

Paul,

 

Sorry I haven't got back to you on this one, how are you going with the
enhancement overall?  Could you please an update to dev@ant.apache.org
with what you have tested successfully.  

 

What I'd like to see is Borland make the password encryption routine
used by BCO available within the SDK removing the need for a separate
package altogether.  I'll look at integrating the current mechanism as
soon as possible.

 

Regards, 

__  

Pacific National
John Ballment BIT(IS) 
Senior Systems Analyst 

john_ballm...@pacificnational.com.au
 

Phone: (02) 9893 2618 
Fax: (02) 9893 2698 
Mobile: 0418 740 871 

http://www.pacificnational.com.au/

Level 4, 2-12 Macquarie Street
Parramatta NSW 2150 Australia



From: Paul Coste [mailto:paulyphon...@gmail.com] 
Sent: Wednesday, 22 April 2009 23:14


To: Ballment, John
Subject: Re: Bug 46326 - StarTeam: Use Cache Agent for Checkouts

 

Hi John,

Okay.  While I don't necessary think it would be a huge issue to include
the code as-is (I've simply changed the EncryptPassword.cmd file to use
ant.jar, and changed the package name of the class), it might be biting
off more than we should chew to try and create a generic Ant task at
this point -- I would think it could potentially complicate the approval
process for getting this code out there.  It is a worthy idea though.
Do you think this would make it complicated to get the StarTeam tasks
updated if we had a generic interface for encryption?  We've actually
already created generic password encryption and decryption tasks for Ant
properties to encode in a file, which is what we have been using as a
workaround for StarTeam Ant task encryption, so I could take a look to
see if they are appropriate as a starting point for this.  The only
thing I found in the core tasks was GenKey but this didn't seem like it
would be appropriate at first glance.

One more question about your comment: do you see it being problematic to
have to launch a separate command to encrypt the password?  I can't
think of

Recall: Bug 46326 - StarTeam: Use Cache Agent for Checkouts

[Ballment, John]

Ballment, John would like to recall the message, "Bug 46326 - StarTeam: Use 
Cache Agent for Checkouts".


**
This e-mail and any attachments may contain confidential and
privileged information. If you are not the intended recipient,
please notify the sender immediately by return e-mail, delete this
e-mail and destroy any copies. Any dissemination or use of this
information by a person other than the intended recipient is
unauthorized and may be illegal.
Opinions, conclusions, views and other information in this
message
that do not relate to the official business of Pacific National
are the views of the individual sender and shall be understood as
neither given nor endorsed by Pacific National.
**

Re: discussion about conditional structures

[Jeffrey E Care]

We've already discussed various schemes for expanding the conditional 
execution of targets, most recently by allowing conditions as top-level 
children of targets. Check the archives.


 

Jeffrey E. (Jeff) Care 
ca...@us.ibm.com 
IBM WebSphere Application Server 
WAS Release Engineering 





Benjamin de Dardel  wrote on 06/22/2009 
05:54:32 PM:

> [image removed] 
> 
> discussion about conditional structures
> 
> Benjamin de Dardel 
> 
> to:
> 
> Ant Developers List
> 
> 06/22/2009 05:55 PM
> 
> Please respond to "Ant Developers List"
> 
> Hi all,
> 
> I suppose that there have been a lot of discussion about conditional
> structures, but I would like to open another one.
> For now, I notice two solutions :
> 
> >> solution 1 : ant approach, using if and unless parameters.
> 
> 
>  
> Disadvantages : 
> - not as simple as it should be
> - property evaluation is not possible (or I don't know how to do this) 
> 
> >> solution 2 : ant-contrib
> 
> 
> 
> Disadvantages :
> - verbose solution
> - project still maintain ?
> - solution not integrated in the ant project
> 
> >> solution 3
> I would like to discuss about another solution, based upon 
> et  tasks.
> 
> 
> 
> 
> 
> Target would be executed if condition succeeded.
> 
> Advantages :
> + use an existing task :  by adding a nested element
> => quiet easy to implement (see attached file) 
> + use all  possibilities 
> 
> What do you think about this idea ?
> 
> Best regards,
> Benjaminpackage net.sourceforge.ant4hg.contrib;
> 
> import org.apache.tools.ant.BuildException;
> import org.apache.tools.ant.taskdefs.CallTarget;
> import org.apache.tools.ant.taskdefs.condition.Condition;
> import org.apache.tools.ant.taskdefs.condition.ConditionBase;
> 
> public class CallTarget2 extends CallTarget {
> 
> // //
> // INNER CLASS
> // //
> /**
>  * @see org.apache.tools.ant.taskdefs.Exit
>  */
> private static class NestedCondition extends ConditionBase 
> implements Condition {
> public boolean eval() {
> if (countConditions() != 1) {
> throw new BuildException("A single nested condition 
> is required.");
> }
> return ((Condition) (getConditions().nextElement())).eval();
> }
> }
> 
> // //
> // ATTRIBUTES
> // //
> /**
>  * @see org.apache.tools.ant.taskdefs.Exit
>  */
> private NestedCondition nestedCondition;
> 
> /**
>  * @see org.apache.tools.ant.taskdefs.Exit
>  */
> public ConditionBase createCondition() {
> if (nestedCondition != null) {
> throw new BuildException("Only one nested condition is 
allowed.");
> }
> nestedCondition = new NestedCondition();
> return nestedCondition;
> }
> 
> // //
> // CONSTRUCTORS
> // //
> public CallTarget2() {
> super();
> setTaskName("antcall");
> }
> 
> // //
> // OVERRIDEN METHODS
> // //
> public void execute() throws BuildException {
> if (!nestedCondition.eval()) {
> return;
> }
> super.execute();
> }
> 
> }
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org

discussion about conditional structures

[Benjamin de Dardel]

Hi all,

I suppose that there have been a lot of discussion about conditional 
structures, but I would like to open another one.

For now, I notice two solutions :

>> solution 1 : ant approach, using if and unless parameters.

   //
   //
   //

Disadvantages :
- not as simple as it should be
- property evaluation is not possible (or I don't know how to do this)

>> solution 2 : ant-contrib

   //
   //
   //

Disadvantages :
- verbose solution
- project still maintain ?
- solution not integrated in the ant project

>> solution 3
I would like to discuss about another solution, based upon  et 
 tasks.


   //
   //
   //
   //
   //

Target would be executed if condition succeeded.

Advantages :
+ use an existing task :  by adding a nested element
=> quiet easy to implement (see attached file)
+ use all  possibilities

What do you think about this idea ?

Best regards,
Benjamin
package net.sourceforge.ant4hg.contrib;

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.taskdefs.CallTarget;
import org.apache.tools.ant.taskdefs.condition.Condition;
import org.apache.tools.ant.taskdefs.condition.ConditionBase;

public class CallTarget2 extends CallTarget {

// //
// INNER CLASS
// //
/**
 * @see org.apache.tools.ant.taskdefs.Exit
 */
private static class NestedCondition extends ConditionBase implements Condition {
public boolean eval() {
if (countConditions() != 1) {
throw new BuildException("A single nested condition is required.");
}
return ((Condition) (getConditions().nextElement())).eval();
}
}

// //
// ATTRIBUTES
// //
/**
 * @see org.apache.tools.ant.taskdefs.Exit
 */
private NestedCondition nestedCondition;

/**
 * @see org.apache.tools.ant.taskdefs.Exit
 */
public ConditionBase createCondition() {
if (nestedCondition != null) {
throw new BuildException("Only one nested condition is allowed.");
}
nestedCondition = new NestedCondition();
return nestedCondition;
}

// //
// CONSTRUCTORS
// //
public CallTarget2() {
super();
setTaskName("antcall");
}

// //
// OVERRIDEN METHODS
// //
public void execute() throws BuildException {
if (!nestedCondition.eval()) {
return;
}
super.execute();
}

}


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

Re: Manifest Classpath ( programmatically generated but messedup).

[Dominique Devienne]

On Mon, Jun 22, 2009 at 11:58 AM, Garima Bathla wrote:
> That exactly is what  I am doing, using Ant's Manifest class. Problem
> happens to be that my classpath is too big and Manifest file has limit of 72
> characters per line, so even though it spits out my configured classpath ,
> it ain't set correctly (as I have listed in the orginial thread).
>
> Any help is highly appreciated, it must not be this tricky to set long
> classpaths programmatically?

Manifest can break a CP longer than 72 char on several lines correctly,
using the proper rules, and has been doing it correctly for years.

Very few bugs reported against it turned out to be real bugs in fact.
So I strongly suggest you take a second look, assuming it does the
correct thing. Note though that line breaks is only the beginning.

The Class-Path: attribute also needs to use the proper file and path separators,
be absolute or relative to the jar, and for this you should depend on
ManifestClasspath,
another Ant class that can take a Path and again format it correctly. --DD

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

Re: Manifest Classpath ( programmatically generated but messedup).

[Garima Bathla]

That exactly is what  I am doing, using Ant's Manifest class. Problem
happens to be that my classpath is too big and Manifest file has limit of 72
characters per line, so even though it spits out my configured classpath ,
it ain't set correctly (as I have listed in the orginial thread).

Any help is highly appreciated, it must not be this tricky to set long
classpaths programmatically?



On Mon, Jun 22, 2009 at 7:10 AM, Dominique Devienne wrote:

> On Mon, Jun 22, 2009 at 12:33 AM, Garima Bathla
> wrote:
> > I am in the process of generating MANIFEST.MF file programmatically by
> > Extending Jar Task; I am almost there, but the class-path that Jar task
> > prints in the Manifest file isn't formatted correctly.
>
> Have you looked at Ant's own Manifest and ManifestClassPath classes? --DD
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

EasyAnt 0.6 released !

[Jean-Louis BOUDART]

The EasyAnt project is pleased to announce its 0.6 version.

Easyant is a build system, that is based on Apache Ant and Apache Ivy.

Our goals are :
* to leverage popularity and flexibility of Ant.
* to integrate Apache Ivy, such that the build system combines a
ready-to-use dependency manager.
* to simplify standard build types, such as building web applications,
JARs etc, by providing ready to use builds.
* to provide conventions and guidelines.
* to make plugging-in of fresh functionalities easy as writing simple
Ant scripts as Easyant plugins.

To still remain adaptable,
* Though Easyant comes with a lot of conventions, we never lock you in.
* Easyant allows you to easily extend existing modules or create and use
your own modules.
* Easyant makes migration from Ant very simple. Your legacy Ant scripts
could still be leveraged with Easyant.

This version focus on :
* a better support for multi module projects
* adding support to build configurations (similar to profile in maven
world see http://easyant.org/doc/howto/BuildConfigurations.html for more
details)
* a new core offering api that can work in embebbed mode
* a cleaner repository structure used to store easyant plugins / build
types
* introducing a way to skip an entire module
* adding support for variables replacements inside module.ivy
* a module for antunit test
* a module to generate plugin documentation
* documentation / javadoc
* a few tests to enhance easyant-core stability
* several bug fixes on plugins

For recall, as the project is still in an early phase, easyant plugins are
still unstable and can move on next releases.

Issues should be reported to:
http://www.easyant.org/trac/

Retrieve sources from the 0.6 release files at:
http://svn.easyant.org/tags/0.6/

Or download the 0.6 release files at:
http://www.easyant.org/trac/downloads

Online documentation is now accessible through :
http://www.easyant.org/doc/

More information can be found on the Easyant website:
http://www.easyant.org/

Regards,
Jean Louis Boudart

Re: Manifest Classpath ( programmatically generated but messedup).

[Dominique Devienne]

On Mon, Jun 22, 2009 at 12:33 AM, Garima Bathla wrote:
> I am in the process of generating MANIFEST.MF file programmatically by
> Extending Jar Task; I am almost there, but the class-path that Jar task
> prints in the Manifest file isn't formatted correctly.

Have you looked at Ant's own Manifest and ManifestClassPath classes? --DD

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