Re: MSHADE-88

2010-11-09 Thread ant elder 
Still no comments, is this the wrong mailing list to ask about the shade plugin?

I'm thinking now of forking the plugin to add the fix and doing a
release from Tuscany to get a fixed release of it that we can use,
seems a hassle though, are there any alternatives anyone can suggest?

   ...ant

On Sun, Oct 24, 2010 at 8:02 AM, ant elder  wrote:
> Ping? Any comments? Anyone know when the next release of the Shade
> plugin is likely to be or if there could be one done now to get this
> fix in?
>
>   ...ant
>
> On Wed, Oct 20, 2010 at 12:45 PM, ant elder  wrote:
>> I've raised http://jira.codehaus.org/browse/MSHADE-88 about a problem
>> using the shade plugin with pom type dependencies, would anyone be
>> able to review and comment on the patch in that?
>>
>> TIA,
>>
>>  ...ant
>>
>> (Apologies if this email ends up duplicated, the original appears held
>> up in moderation)
>>
>

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

Re: running net start fails from Maven but succeeds from Ant

2010-11-09 Thread Dennis Lundberg 
On 2010-11-09 22:58, Hahn, Christopher (SAN DIEGO) wrote:
>  Hello,
> 
> I will discuss upgrading our antrun plugin with my group,
> but some dependencies seem to be up to date
> 
> Thank you for taking the time.
> 
> Chris
> 
> P.S. Here is the plugin config:

Hmm, I don't see any execution in here that tells us what Ant code you
are invoking. Do you embed the code int the POM or are you referring to
an external build.xml file?

>  
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.2
> 
>   
> ant
> ant-nodeps
> 1.6.5
>   
>   
>   
> jakarta-regexp
> jakarta-regexp
> 1.4
>   
>   
> ant
> ant-jakarta-regexp
> 1.6.1
>   
>   
> com.sun
> tools
> 1.5.0
> system
> ${java.home}/../lib/tools.jar
>   
>   
> 
> ant-contrib
> ant-contrib
> 1.0b3
>   
>   
> 
> ant
> ant-trax
> 1.6.5
>   
>   
> 
> net.sf.saxon
> saxon
> 8.7
>   
> 
>   
> 
> -Original Message-
> From: Dennis Lundberg [mailto:denn...@apache.org] 
> Sent: Tuesday, November 09, 2010 11:49 AM
> To: Maven Developers List
> Subject: Re: running net start fails from Maven but succeeds from Ant
> 
> On 2010-11-09 20:23, Hahn, Christopher (SAN DIEGO) wrote:
>> Hi,
>>
>> Thank you for getting back to me.
>>
>> I am seeing version 1.2 of the plugin.
> 
> This is rather old. The latest version is 1.6. Please try that one.
> 
>> The weird thing is that the ant I used (1.8) was only installed,
>> by me, in order to drive the "ant only" command line test.
>>
>> I could not find an ant install on this box, and am thinking
>> that Maven is using its own plugins to run this within Maven.
> 
> The Maven plugin has its own internal copy of Ant. It doesn't use the
> one that you installed.
> 
>> what seems odd to me is that I am using the simplest aspects
>> of this capability.  ...i.e. a straight exec with args.
>>
>> no conditionals or such.
> 
> What does your plugin config look like?
> 
>>
>> Thanks again,
>>
>> Chris
>>
>> -Original Message-
>> From: Dennis Lundberg [mailto:denn...@apache.org] 
>> Sent: Tuesday, November 09, 2010 11:04 AM
>> To: Maven Developers List
>> Subject: Re: running net start fails from Maven but succeeds from Ant
>>
>> Hi
>>
>> I assume that you are using the Maven AntRun Plugin to run the snippet,
>> but you didn't tell us which version of the plugin you are using.
>> Different versions of the plugin uses/supports different versions of Ant.
>>
>> http://maven.apache.org/plugins/maven-antrun-plugin/
>>
>> On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
>>> Hello all,
>>>
>>>  
>>>
>>> I am looking into why an Ant task is failing from Maven, but succeeding
>>>
>>> when called directly using ant.
>>>
>>>  
>>>
>>> We have in a build.xml this block:
>>>
>>> ===
>>>
>>>   
>>>
>>> 
>>>
>>>   
>>>
>>> 
>>>
>>> 
>>>
>>>   
>>>
>>> 
>>>
>>>   
>>>
>>> ===
>>>
>>>  
>>>
>>> I added this target as a dependency to an oracle load target and
>>>
>>> am getting this error:
>>>
>>> ===
>>>
>>> [concat] restartora:
>>> [concat] [INFO]
>>> 
>>> [concat] [ERROR] BUILD ERROR
>>> [concat] [INFO]
>>> 
>>> [concat] [INFO] An Ant BuildException has occured: The following error
>>> occurred while executing this line:
>>> [concat] /build.xml:121: Execute failed: java.io.IOException:
>>> Cannot run program "C:/Windows/system32/net.exe" (in directory
>>> ""): error=2, No such file or directory
>>> [concat] [INFO]
>>> 
>>>
>>> ===
>>>
>>>  
>>>
>>> However, when run from the command line using Ant, I see:
>>>
>>> ===
>>>
>>> D:\d:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora
>>>
>>> Buildfile: D:\\build.xml
>>>
>>>  
>>>
>>> restartora:
>>>
>>>  [exec] The OracleServiceORCL service is stopping...
>>>
>>>  [exec] The OracleServiceORCL service was stopped successfully.
>>>
>>>  [exec]
>>>
>>>  [exec] The OracleServiceORCL service is starting
>>>
>>>  [exec] The OracleServiceORCL service was started successfully.
>>>
>>>  [exec]
>>>
>>>  
>>>
>>> BUILD SUCCESSFUL
>>>
>>> Total time: 30 seconds
>>>
>>> D:\ 
>>>
>>> ===
>

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Rex Hoffman 
Fully understood.  A built in limitation of osgi is package level control,
as opposed to class.

I'm leaning to using the (javadoc) annotations Mark pointed out, They seem a
better way to modify the default clirr/sigtest severity behavior.

http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm

Where the annotation would be able to push the severity of the addition of a
method to an interface down from "backwards breaking" to "enhancement" with
@noextends and @noimplement.  Any change would be ignored with a
@noreference.  @nooverride would probably have no meaning for
now. @noinstantiate could make changes to a constructor a no-op.

What do you think?  Rigid default behavior with these as the escape hatch?
 I'll ping the eclipse folks and see what they think, see if they have
advice on the use of these  I think I'll implement this as a
separate jar that filters the results of the java-version-delta, not part of
the default behavior.  That way it could be used with an osgi-version-delta,
provided the OsgiDelta class extends the JavaDelta class (represents one
change to one class) , and other filters could replace it if this is found
to be lacking.  I could also a default @noextends and @noimplement filter to
allow existing opensource api projects to adopt this without issue.

I think we've hashed it out (and grew the scope) enough.  This'll chew up
all my free time for the next two-three weeks.

As soon as I have all the interfaces built out and playing nice together (at
least printing out the deltas) I'll post it to github or
something similar and update this thread if anyone is interested in looking
at it, so it can benefit from early criticism.

Rex


On Tue, Nov 9, 2010 at 2:47 PM, Jesse Glick  wrote:

> On 11/09/2010 02:21 PM, Rex Hoffman wrote:
>
>> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
>>
>
> Take note of the distinction made on pp. 5-6 between "interface" and
> "package". Without some special annotations, it is not possible for a tool
> to mechanically decide whether a given interface is intended to be used by a
> consumer and implemented by a provider, or vice-versa (or some more complex
> combination).
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Rex
(415) 273-9438
http://www.e-hoffman.org

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Jesse Glick 

On 11/09/2010 02:21 PM, Rex Hoffman wrote:

http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf


Take note of the distinction made on pp. 5-6 between "interface" and "package". Without some special annotations, it is not possible for a tool to mechanically decide 
whether a given interface is intended to be used by a consumer and implemented by a provider, or vice-versa (or some more complex combination).



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

RE: running net start fails from Maven but succeeds from Ant

2010-11-09 Thread Hahn, Christopher (SAN DIEGO) 
 Hello,

I will discuss upgrading our antrun plugin with my group,
but some dependencies seem to be up to date

Thank you for taking the time.

Chris

P.S. Here is the plugin config:

 
org.apache.maven.plugins
maven-antrun-plugin
1.2

  
ant
ant-nodeps
1.6.5
  
  
  
jakarta-regexp
jakarta-regexp
1.4
  
  
ant
ant-jakarta-regexp
1.6.1
  
  
com.sun
tools
1.5.0
system
${java.home}/../lib/tools.jar
  
  

ant-contrib
ant-contrib
1.0b3
  
  

ant
ant-trax
1.6.5
  
  

net.sf.saxon
saxon
8.7
  

  

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org] 
Sent: Tuesday, November 09, 2010 11:49 AM
To: Maven Developers List
Subject: Re: running net start fails from Maven but succeeds from Ant

On 2010-11-09 20:23, Hahn, Christopher (SAN DIEGO) wrote:
> Hi,
> 
> Thank you for getting back to me.
> 
> I am seeing version 1.2 of the plugin.

This is rather old. The latest version is 1.6. Please try that one.

> The weird thing is that the ant I used (1.8) was only installed,
> by me, in order to drive the "ant only" command line test.
> 
> I could not find an ant install on this box, and am thinking
> that Maven is using its own plugins to run this within Maven.

The Maven plugin has its own internal copy of Ant. It doesn't use the
one that you installed.

> what seems odd to me is that I am using the simplest aspects
> of this capability.  ...i.e. a straight exec with args.
> 
> no conditionals or such.

What does your plugin config look like?

> 
> Thanks again,
> 
> Chris
> 
> -Original Message-
> From: Dennis Lundberg [mailto:denn...@apache.org] 
> Sent: Tuesday, November 09, 2010 11:04 AM
> To: Maven Developers List
> Subject: Re: running net start fails from Maven but succeeds from Ant
> 
> Hi
> 
> I assume that you are using the Maven AntRun Plugin to run the snippet,
> but you didn't tell us which version of the plugin you are using.
> Different versions of the plugin uses/supports different versions of Ant.
> 
> http://maven.apache.org/plugins/maven-antrun-plugin/
> 
> On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
>> Hello all,
>>
>>  
>>
>> I am looking into why an Ant task is failing from Maven, but succeeding
>>
>> when called directly using ant.
>>
>>  
>>
>> We have in a build.xml this block:
>>
>> ===
>>
>>   
>>
>> 
>>
>>   
>>
>> 
>>
>> 
>>
>>   
>>
>> 
>>
>>   
>>
>> ===
>>
>>  
>>
>> I added this target as a dependency to an oracle load target and
>>
>> am getting this error:
>>
>> ===
>>
>> [concat] restartora:
>> [concat] [INFO]
>> 
>> [concat] [ERROR] BUILD ERROR
>> [concat] [INFO]
>> 
>> [concat] [INFO] An Ant BuildException has occured: The following error
>> occurred while executing this line:
>> [concat] /build.xml:121: Execute failed: java.io.IOException:
>> Cannot run program "C:/Windows/system32/net.exe" (in directory
>> ""): error=2, No such file or directory
>> [concat] [INFO]
>> 
>>
>> ===
>>
>>  
>>
>> However, when run from the command line using Ant, I see:
>>
>> ===
>>
>> D:\d:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora
>>
>> Buildfile: D:\\build.xml
>>
>>  
>>
>> restartora:
>>
>>  [exec] The OracleServiceORCL service is stopping...
>>
>>  [exec] The OracleServiceORCL service was stopped successfully.
>>
>>  [exec]
>>
>>  [exec] The OracleServiceORCL service is starting
>>
>>  [exec] The OracleServiceORCL service was started successfully.
>>
>>  [exec]
>>
>>  
>>
>> BUILD SUCCESSFUL
>>
>> Total time: 30 seconds
>>
>> D:\ 
>>
>> ===
>>
>>  
>>
>> I fully qualified the references, and so do not think that this is
>>
>> an environment issue(but this is still what I suspect, as my
>>
>> Ant might be too-much newer than my Maven)
>>
>>  
>>
>> I am using:
>>
>> ===
>>
>> D:\p4\SM\7.10\7.11\server\test\smsetup>set MAVEN_OPTS=-Xmx1024m -Xms128m
>>
>> Maven version: 2.0.10
>>
>> Java version: 1.5.0_19
>>
>> OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
>>
>>

[VOTE] Release Maven Linkcheck Plugin version 1.1 and Doxia Tools 1.2

2010-11-09 Thread Dennis Lundberg 
Hi,

We solved 6 + 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12100&styleName=Html&version=16748
http://jira.codehaus.org/browse/DOXIA-410
http://jira.codehaus.org/browse/DOXIA-412
http://jira.codehaus.org/browse/DOXIA-414

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=12100&status=1
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DOXIA+AND+resolution+%3D+Unresolved+AND+component+%3D+%22Doxia+Tools%22+ORDER+BY+priority+DESC&mode=hide

Staging repo:
https://repository.apache.org/content/repositories/maven-051/

Staging sites:
http://maven.apache.org/plugins/maven-linkcheck-plugin-1.1/
http://maven.apache.org/doxia/doxia-tools-1.2/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-- 
Dennis Lundberg

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

Re: running net start fails from Maven but succeeds from Ant

2010-11-09 Thread Dennis Lundberg 
On 2010-11-09 20:23, Hahn, Christopher (SAN DIEGO) wrote:
> Hi,
> 
> Thank you for getting back to me.
> 
> I am seeing version 1.2 of the plugin.

This is rather old. The latest version is 1.6. Please try that one.

> The weird thing is that the ant I used (1.8) was only installed,
> by me, in order to drive the "ant only" command line test.
> 
> I could not find an ant install on this box, and am thinking
> that Maven is using its own plugins to run this within Maven.

The Maven plugin has its own internal copy of Ant. It doesn't use the
one that you installed.

> what seems odd to me is that I am using the simplest aspects
> of this capability.  ...i.e. a straight exec with args.
> 
> no conditionals or such.

What does your plugin config look like?

> 
> Thanks again,
> 
> Chris
> 
> -Original Message-
> From: Dennis Lundberg [mailto:denn...@apache.org] 
> Sent: Tuesday, November 09, 2010 11:04 AM
> To: Maven Developers List
> Subject: Re: running net start fails from Maven but succeeds from Ant
> 
> Hi
> 
> I assume that you are using the Maven AntRun Plugin to run the snippet,
> but you didn't tell us which version of the plugin you are using.
> Different versions of the plugin uses/supports different versions of Ant.
> 
> http://maven.apache.org/plugins/maven-antrun-plugin/
> 
> On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
>> Hello all,
>>
>>  
>>
>> I am looking into why an Ant task is failing from Maven, but succeeding
>>
>> when called directly using ant.
>>
>>  
>>
>> We have in a build.xml this block:
>>
>> ===
>>
>>   
>>
>> 
>>
>>   
>>
>> 
>>
>> 
>>
>>   
>>
>> 
>>
>>   
>>
>> ===
>>
>>  
>>
>> I added this target as a dependency to an oracle load target and
>>
>> am getting this error:
>>
>> ===
>>
>> [concat] restartora:
>> [concat] [INFO]
>> 
>> [concat] [ERROR] BUILD ERROR
>> [concat] [INFO]
>> 
>> [concat] [INFO] An Ant BuildException has occured: The following error
>> occurred while executing this line:
>> [concat] /build.xml:121: Execute failed: java.io.IOException:
>> Cannot run program "C:/Windows/system32/net.exe" (in directory
>> ""): error=2, No such file or directory
>> [concat] [INFO]
>> 
>>
>> ===
>>
>>  
>>
>> However, when run from the command line using Ant, I see:
>>
>> ===
>>
>> D:\d:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora
>>
>> Buildfile: D:\\build.xml
>>
>>  
>>
>> restartora:
>>
>>  [exec] The OracleServiceORCL service is stopping...
>>
>>  [exec] The OracleServiceORCL service was stopped successfully.
>>
>>  [exec]
>>
>>  [exec] The OracleServiceORCL service is starting
>>
>>  [exec] The OracleServiceORCL service was started successfully.
>>
>>  [exec]
>>
>>  
>>
>> BUILD SUCCESSFUL
>>
>> Total time: 30 seconds
>>
>> D:\ 
>>
>> ===
>>
>>  
>>
>> I fully qualified the references, and so do not think that this is
>>
>> an environment issue(but this is still what I suspect, as my
>>
>> Ant might be too-much newer than my Maven)
>>
>>  
>>
>> I am using:
>>
>> ===
>>
>> D:\p4\SM\7.10\7.11\server\test\smsetup>set MAVEN_OPTS=-Xmx1024m -Xms128m
>>
>> Maven version: 2.0.10
>>
>> Java version: 1.5.0_19
>>
>> OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
>>
>> ===
>>
>>  
>>
>> Any kicks in the head appreciated,
>>
>>  
>>
>> Chris
>>
>>  
>>
>> 
>>
>> cid:image001.png@01CAF080.AD65F1E0
>>
>>  
>>
>> *Christopher Hahn*
>> The Dude
>>
>> Software Production Engineering
>> R&D Services, Hewlett-Packard
>> Phone: 858-655-4096
>> Cell: 619-630-9791
>> ch...@hp.com 
>>
>>  
>>
>> */Visit our SPE Portal/*
>> *//*
>>
>> 
>>
>>  
>>
>>  
>>
> 
> 


-- 
Dennis Lundberg

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

RE: running net start fails from Maven but succeeds from Ant

2010-11-09 Thread Hahn, Christopher (SAN DIEGO) 
Hi,

Thank you for getting back to me.

I am seeing version 1.2 of the plugin.

The weird thing is that the ant I used (1.8) was only installed,
by me, in order to drive the "ant only" command line test.

I could not find an ant install on this box, and am thinking
that Maven is using its own plugins to run this within Maven.

what seems odd to me is that I am using the simplest aspects
of this capability.  ...i.e. a straight exec with args.

no conditionals or such.

Thanks again,

Chris

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org] 
Sent: Tuesday, November 09, 2010 11:04 AM
To: Maven Developers List
Subject: Re: running net start fails from Maven but succeeds from Ant

Hi

I assume that you are using the Maven AntRun Plugin to run the snippet,
but you didn't tell us which version of the plugin you are using.
Different versions of the plugin uses/supports different versions of Ant.

http://maven.apache.org/plugins/maven-antrun-plugin/

On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
> Hello all,
> 
>  
> 
> I am looking into why an Ant task is failing from Maven, but succeeding
> 
> when called directly using ant.
> 
>  
> 
> We have in a build.xml this block:
> 
> ===
> 
>   
> 
> 
> 
>   
> 
> 
> 
> 
> 
>   
> 
> 
> 
>   
> 
> ===
> 
>  
> 
> I added this target as a dependency to an oracle load target and
> 
> am getting this error:
> 
> ===
> 
> [concat] restartora:
> [concat] [INFO]
> 
> [concat] [ERROR] BUILD ERROR
> [concat] [INFO]
> 
> [concat] [INFO] An Ant BuildException has occured: The following error
> occurred while executing this line:
> [concat] /build.xml:121: Execute failed: java.io.IOException:
> Cannot run program "C:/Windows/system32/net.exe" (in directory
> ""): error=2, No such file or directory
> [concat] [INFO]
> 
> 
> ===
> 
>  
> 
> However, when run from the command line using Ant, I see:
> 
> ===
> 
> D:\d:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora
> 
> Buildfile: D:\\build.xml
> 
>  
> 
> restartora:
> 
>  [exec] The OracleServiceORCL service is stopping...
> 
>  [exec] The OracleServiceORCL service was stopped successfully.
> 
>  [exec]
> 
>  [exec] The OracleServiceORCL service is starting
> 
>  [exec] The OracleServiceORCL service was started successfully.
> 
>  [exec]
> 
>  
> 
> BUILD SUCCESSFUL
> 
> Total time: 30 seconds
> 
> D:\ 
> 
> ===
> 
>  
> 
> I fully qualified the references, and so do not think that this is
> 
> an environment issue(but this is still what I suspect, as my
> 
> Ant might be too-much newer than my Maven)
> 
>  
> 
> I am using:
> 
> ===
> 
> D:\p4\SM\7.10\7.11\server\test\smsetup>set MAVEN_OPTS=-Xmx1024m -Xms128m
> 
> Maven version: 2.0.10
> 
> Java version: 1.5.0_19
> 
> OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
> 
> ===
> 
>  
> 
> Any kicks in the head appreciated,
> 
>  
> 
> Chris
> 
>  
> 
> 
> 
> cid:image001.png@01CAF080.AD65F1E0
> 
>   
> 
> *Christopher Hahn*
> The Dude
> 
> Software Production Engineering
> R&D Services, Hewlett-Packard
> Phone: 858-655-4096
> Cell: 619-630-9791
> ch...@hp.com 
> 
>  
> 
> */Visit our SPE Portal/*
> *//*
> 
> 
> 
>  
> 
>  
> 


-- 
Dennis Lundberg

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


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

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Rex Hoffman 
Very cool.  I'll have to check that out as well to determine how BND decided
to calculate version numbers, though it's not directly applicable as osgi
creates versions at the package level.

Osgi semantic 
versioning
seems
to extend the ideas in the apache apr, and uses the terms: consumes and
provides to make clear the role an package plays at runtime.

At the very least this indicates the need to support several different
versioning standards (apr and osgi semantic versionsing).   I really like
the idea that an api can have consumers and providers, and that they are not
mutually exclusive in the same artifact.  From the bnd guy
himself
.

Makes me think about maven scopes, perhaps allow for "consumes" and
"provides", and default the current compile scope to be both.  Or maybe not.
 OSGi seems to need more info than maven can provide to auto build the
manifests.

Just makes me believe Jesse is correct about interfaces/abstract classes.
 Default to any change being a break in backwards compatibility, but provide
ability to be more lax for api jar files by letting developers alter
default behavior.

Rex

On Tue, Nov 9, 2010 at 9:51 AM, David Jencks  wrote:

> The BND tool used in the (misnamed) felix maven-bundle-plugin has, in
> recent versions not yet used in the maven-bundle plugin, some logic to
> determine whether an Import-Package constraint is "uses" or "implements" and
> decides which segment of the version number to increment based on that.
>
> might be useful...
> david jencks
>
> On Nov 9, 2010, at 4:58 AM, Jesse Glick wrote:
>
> > On 11/08/2010 02:21 AM, Rex Hoffman wrote:
> >> project: java-version-delta
> >
> > By the way, you should look at https://sigtest.dev.java.net/ if you have
> not done so already. I'm not sure if the license & feature set suits your
> needs but it would make a potentially useful alternate impl. This is the
> tool used by some of Oracle's teams to check (primarily binary)
> compatibility of Java APIs.
> >
> > My background: for netbeans.org API modules we run this tool to check
> for compatible & incompatible changes among packages marked public.
> Currently we have an idiosyncratic Ant build (is there any other kind?) so
> comparisons are done against the modules as they existed in the last product
> release, but of course in a Maven setup we would use the policy you are
> proposing: x.y -> x.(y+1) may have compatible but not incompatible changes,
> etc.
> >
> >> The apache portable runtime version standard does want the name of a
> library
> >> to include it's major version number, so for ubuntu/debian xerces look
> like:
> >> libxerces2-java_2.9.0-1_all.deb
> >
> > Not sure this is applicable to most Java development. If you are using a
> container (such as OSGi) which supports class loader isolation, *and* this
> container permits multiple components with the same ID (but possibly
> different versions) to be loaded in parallel, then it is unnecessary.
> Containers with isolation but which enforce uniqueness on loaded IDs might
> benefit, so long as it really makes sense to load two copies of the
> component - true for plain old class libraries, not necessarily true for
> "active" components which might register services of some sort. Apps not
> using a container are unlikely to benefit since you could only use multiple
> versions of a library in case the package hierarchy was also renamed.
> Anyway, I agree that this is not likely something that an API compatibility
> plugin should address (a separate enforcer rule would suffice).
> >
> >> the default would be to
> >> assume that a client of an artifact is not expected to implement [any
> interfaces]
> >
> > This seems like a poor default - directly contradicts the longstanding
> Java compatibility policy. (*) If anything, I would place the burden on API
> designers who publish interfaces (or abstract classes) they expect no one
> else to implement, despite there being no such enforcement from the Java
> language. (**) An annotation for this purpose makes some sense, but it would
> have to be hosted in a very generic place quite unrelated to a Maven plugin.
> In the short term, plugin configuration to exclude implements checking on
> certain types or packages may be a better workaround.
> >
> > (*) For binary compatibility it is permitted to add an interface method
> without breaking existing implementers, so long as this method is never
> called - but that condition is unlikely, since why would there be a method
> no one is calling? You cannot even check whether a given object implements a
> new method or not without using reflection. Better to just introduce a new
> interface (possibly extending the old one) when you want to change
> signatures.
> >
> > (**) If the API designer wants, it is possible to expose an abstract
> class which can be implemented only within the same component. JSR 294 would
> be very helpful

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Rex Hoffman 
Sweet.  Very much what I was looking for.  May also create a set of java 5
annotations mirroring these.

Rex

On Tue, Nov 9, 2010 at 8:51 AM, Mark Hobson  wrote:

> On 9 November 2010 16:30, Rex Hoffman  wrote:
> > My thoughts exactly on the annotation ie. hosted in a generic context.
>  The
> > concern I have is the number of useful open source projects that expose
> > interfaces that clients are not required to implement.  Ultimately since
> > this style of checking is primarily used by the devs of the project, I
> can
> > have them define the annotation, and whether it marks an interface as
> > "client implements", or "client does not implement".  Those might not be
> the
> > best names for the annotation, as it really would mean 'Client implements
> it
> > and my code will break binary compatibility, by calling it at runtime".
>
> Note that Eclipse's PDE has Javadoc tags for these notions:
>
>
> http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: running net start fails from Maven but succeeds from Ant

2010-11-09 Thread Dennis Lundberg 
Hi

I assume that you are using the Maven AntRun Plugin to run the snippet,
but you didn't tell us which version of the plugin you are using.
Different versions of the plugin uses/supports different versions of Ant.

http://maven.apache.org/plugins/maven-antrun-plugin/

On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
> Hello all,
> 
>  
> 
> I am looking into why an Ant task is failing from Maven, but succeeding
> 
> when called directly using ant.
> 
>  
> 
> We have in a build.xml this block:
> 
> ===
> 
>   
> 
> 
> 
>   
> 
> 
> 
> 
> 
>   
> 
> 
> 
>   
> 
> ===
> 
>  
> 
> I added this target as a dependency to an oracle load target and
> 
> am getting this error:
> 
> ===
> 
> [concat] restartora:
> [concat] [INFO]
> 
> [concat] [ERROR] BUILD ERROR
> [concat] [INFO]
> 
> [concat] [INFO] An Ant BuildException has occured: The following error
> occurred while executing this line:
> [concat] /build.xml:121: Execute failed: java.io.IOException:
> Cannot run program "C:/Windows/system32/net.exe" (in directory
> ""): error=2, No such file or directory
> [concat] [INFO]
> 
> 
> ===
> 
>  
> 
> However, when run from the command line using Ant, I see:
> 
> ===
> 
> D:\d:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora
> 
> Buildfile: D:\\build.xml
> 
>  
> 
> restartora:
> 
>  [exec] The OracleServiceORCL service is stopping...
> 
>  [exec] The OracleServiceORCL service was stopped successfully.
> 
>  [exec]
> 
>  [exec] The OracleServiceORCL service is starting
> 
>  [exec] The OracleServiceORCL service was started successfully.
> 
>  [exec]
> 
>  
> 
> BUILD SUCCESSFUL
> 
> Total time: 30 seconds
> 
> D:\ 
> 
> ===
> 
>  
> 
> I fully qualified the references, and so do not think that this is
> 
> an environment issue(but this is still what I suspect, as my
> 
> Ant might be too-much newer than my Maven)
> 
>  
> 
> I am using:
> 
> ===
> 
> D:\p4\SM\7.10\7.11\server\test\smsetup>set MAVEN_OPTS=-Xmx1024m -Xms128m
> 
> Maven version: 2.0.10
> 
> Java version: 1.5.0_19
> 
> OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
> 
> ===
> 
>  
> 
> Any kicks in the head appreciated,
> 
>  
> 
> Chris
> 
>  
> 
> 
> 
> cid:image001.png@01CAF080.AD65F1E0
> 
>   
> 
> *Christopher Hahn*
> The Dude
> 
> Software Production Engineering
> R&D Services, Hewlett-Packard
> Phone: 858-655-4096
> Cell: 619-630-9791
> ch...@hp.com 
> 
>  
> 
> */Visit our SPE Portal/*
> *//*
> 
> 
> 
>  
> 
>  
> 


-- 
Dennis Lundberg

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

Possible regression in Assembly Plugin 2.2

2010-11-09 Thread Dennis Lundberg 
Hi

I created an issue in JIRA [1] for what I think is a regression in
version 2.2 of the Assembly Plugin. When digging deeper in JIRA I found
more related, but not identical, issues [2].

What I would like to know is whether the change was a deliberate or not.
If it was deliberate then we need to update the docs as per
MASSEMBLY-516 [3].


[1] http://jira.codehaus.org/browse/MASSEMBLY-527

[2] http://jira.codehaus.org/browse/MASSEMBLY-519
http://jira.codehaus.org/browse/MASSEMBLY-520

[3] http://jira.codehaus.org/browse/MASSEMBLY-516

-- 
Dennis Lundberg

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

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread David Jencks 
The BND tool used in the (misnamed) felix maven-bundle-plugin has, in recent 
versions not yet used in the maven-bundle plugin, some logic to determine 
whether an Import-Package constraint is "uses" or "implements" and decides 
which segment of the version number to increment based on that.  

might be useful...
david jencks
 
On Nov 9, 2010, at 4:58 AM, Jesse Glick wrote:

> On 11/08/2010 02:21 AM, Rex Hoffman wrote:
>> project: java-version-delta
> 
> By the way, you should look at https://sigtest.dev.java.net/ if you have not 
> done so already. I'm not sure if the license & feature set suits your needs 
> but it would make a potentially useful alternate impl. This is the tool used 
> by some of Oracle's teams to check (primarily binary) compatibility of Java 
> APIs.
> 
> My background: for netbeans.org API modules we run this tool to check for 
> compatible & incompatible changes among packages marked public. Currently we 
> have an idiosyncratic Ant build (is there any other kind?) so comparisons are 
> done against the modules as they existed in the last product release, but of 
> course in a Maven setup we would use the policy you are proposing: x.y -> 
> x.(y+1) may have compatible but not incompatible changes, etc.
> 
>> The apache portable runtime version standard does want the name of a library
>> to include it's major version number, so for ubuntu/debian xerces look like:
>> libxerces2-java_2.9.0-1_all.deb
> 
> Not sure this is applicable to most Java development. If you are using a 
> container (such as OSGi) which supports class loader isolation, *and* this 
> container permits multiple components with the same ID (but possibly 
> different versions) to be loaded in parallel, then it is unnecessary. 
> Containers with isolation but which enforce uniqueness on loaded IDs might 
> benefit, so long as it really makes sense to load two copies of the component 
> - true for plain old class libraries, not necessarily true for "active" 
> components which might register services of some sort. Apps not using a 
> container are unlikely to benefit since you could only use multiple versions 
> of a library in case the package hierarchy was also renamed. Anyway, I agree 
> that this is not likely something that an API compatibility plugin should 
> address (a separate enforcer rule would suffice).
> 
>> the default would be to
>> assume that a client of an artifact is not expected to implement [any 
>> interfaces]
> 
> This seems like a poor default - directly contradicts the longstanding Java 
> compatibility policy. (*) If anything, I would place the burden on API 
> designers who publish interfaces (or abstract classes) they expect no one 
> else to implement, despite there being no such enforcement from the Java 
> language. (**) An annotation for this purpose makes some sense, but it would 
> have to be hosted in a very generic place quite unrelated to a Maven plugin. 
> In the short term, plugin configuration to exclude implements checking on 
> certain types or packages may be a better workaround.
> 
> (*) For binary compatibility it is permitted to add an interface method 
> without breaking existing implementers, so long as this method is never 
> called - but that condition is unlikely, since why would there be a method no 
> one is calling? You cannot even check whether a given object implements a new 
> method or not without using reflection. Better to just introduce a new 
> interface (possibly extending the old one) when you want to change signatures.
> 
> (**) If the API designer wants, it is possible to expose an abstract class 
> which can be implemented only within the same component. JSR 294 would be 
> very helpful here, but it is possible today so long as all the 
> implementations are in the same package, *or* the component uses a format 
> (such as OSGi bundle) which permits restrictions on the exported types or 
> packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing 
> with a more fine-grained system but for now it requires javac from JDK 7.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Jesse Glick 

On 11/09/2010 11:30 AM, Rex Hoffman wrote:

The only current problem is that it's not in the maven repo.


True. Probably not hard to fix, if that is the only obstacle; take it off list 
if interested.


I don't suppose your teams usage of it is based off on an open source ant task?


Currently we are using it via http://hg.netbeans.org/apitest/ which seems to inline the original project's code (not sure why offhand). Probably not relevant to use from 
a Maven plugin.



Though cutting a new interface is generally better programming, I don't
want this tool to force developers to do that. I want this to be easily
adopted by as many projects as possible.


Agreed, I just think the _default_ policy should be binary compatibility as defined by http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html - you should 
need to declare alternate policies somehow. (It is also safer to flag a change as incompatible, and have the developer indicate that it is OK in order to fix the build, 
than to silently claim that changes were compatible when the developer was not even aware of the possible breakage.)



Would the ability to configure the annotation and whether the plugin should
use binary or source compatibility when evaluating the interface/abstract
class meet your needs for QualifiedPublic?


No, @QualifiedPublic works differently. (Again, @QP is just an idle experiment 
at this point.)


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

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Mark Hobson 
On 9 November 2010 16:30, Rex Hoffman  wrote:
> My thoughts exactly on the annotation ie. hosted in a generic context.  The
> concern I have is the number of useful open source projects that expose
> interfaces that clients are not required to implement.  Ultimately since
> this style of checking is primarily used by the devs of the project, I can
> have them define the annotation, and whether it marks an interface as
> "client implements", or "client does not implement".  Those might not be the
> best names for the annotation, as it really would mean 'Client implements it
> and my code will break binary compatibility, by calling it at runtime".

Note that Eclipse's PDE has Javadoc tags for these notions:

http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm

Mark

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

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Rex Hoffman 
Thanks for the insightful comments!

I'll definitely take a look at sigtest.  The gpl v2 w/ classpath exception
should be fine.  The only current problem is that it's not in the maven
repo.  I don't suppose your teams usage of it is based off on an open source
ant task?

Simply based on the activity of the project (recent releases) it might be a
better call than clirr.  Also good to have a dev team to report bugs to.

My thoughts exactly on the annotation ie. hosted in a generic context.  The
concern I have is the number of useful open source projects that expose
interfaces that clients are not required to implement.  Ultimately since
this style of checking is primarily used by the devs of the project, I can
have them define the annotation, and whether it marks an interface as
"client implements", or "client does not implement".  Those might not be the
best names for the annotation, as it really would mean 'Client implements it
and my code will break binary compatibility, by calling it at runtime".

I've seen code that uses reflection to deal to deal with enhanced apis,
calls the method if it exists, otherwise not call it and carry on.  It was a
pretty nifty way of handling the problem.  And with tools like
fest-reflect,
wasn't incredibly ugly.  So I want to make sure the toolset handles this
case. Though cutting a new interface is generally better programming, I dont
want this tool to force developers to do that.   I want this to be easily
adopted by as many projects as possible.

Would the ability to configure the annotation and whether the plugin should
use binary or source compatibility when evaluating the interface/abstract
class meet your needs for QualifiedPublic?

  something like

  
  org.blah.ClientImplementsAllMethods

 
false
  

  or

  
  org.blah.ClientMayNotImplementAllMethods

 
true
  

Where the annotation class is optional and as no default, and
the clientsExpectedToImplementAllMethods is false.

Rex

On Tue, Nov 9, 2010 at 4:58 AM, Jesse Glick  wrote:

> On 11/08/2010 02:21 AM, Rex Hoffman wrote:
>
>> project: java-version-delta
>>
>
> By the way, you should look at https://sigtest.dev.java.net/ if you have
> not done so already. I'm not sure if the license & feature set suits your
> needs but it would make a potentially useful alternate impl. This is the
> tool used by some of Oracle's teams to check (primarily binary)
> compatibility of Java APIs.
>
> My background: for netbeans.org API modules we run this tool to check for
> compatible & incompatible changes among packages marked public. Currently we
> have an idiosyncratic Ant build (is there any other kind?) so comparisons
> are done against the modules as they existed in the last product release,
> but of course in a Maven setup we would use the policy you are proposing:
> x.y -> x.(y+1) may have compatible but not incompatible changes, etc.
>
>
>  The apache portable runtime version standard does want the name of a
>> library
>> to include it's major version number, so for ubuntu/debian xerces look
>> like:
>> libxerces2-java_2.9.0-1_all.deb
>>
>
> Not sure this is applicable to most Java development. If you are using a
> container (such as OSGi) which supports class loader isolation, *and* this
> container permits multiple components with the same ID (but possibly
> different versions) to be loaded in parallel, then it is unnecessary.
> Containers with isolation but which enforce uniqueness on loaded IDs might
> benefit, so long as it really makes sense to load two copies of the
> component - true for plain old class libraries, not necessarily true for
> "active" components which might register services of some sort. Apps not
> using a container are unlikely to benefit since you could only use multiple
> versions of a library in case the package hierarchy was also renamed.
> Anyway, I agree that this is not likely something that an API compatibility
> plugin should address (a separate enforcer rule would suffice).
>
>  the default would be to
>> assume that a client of an artifact is not expected to implement [any
>> interfaces]
>>
>
> This seems like a poor default - directly contradicts the longstanding Java
> compatibility policy. (*) If anything, I would place the burden on API
> designers who publish interfaces (or abstract classes) they expect no one
> else to implement, despite there being no such enforcement from the Java
> language. (**) An annotation for this purpose makes some sense, but it would
> have to be hosted in a very generic place quite unrelated to a Maven plugin.
> In the short term, plugin configuration to exclude implements checking on
> certain types or packages may be a better workaround.
>
> (*) For binary compatibility it is permitted to add an interface method
> without breaking existing implementers, so long as this method is never
> called - but that condition is unlikely, since why would there be a method
> no one is calling? You cannot even check whether a

Re: Auto apache version standard as an enforcer rule?

2010-11-09 Thread Jesse Glick 

On 11/08/2010 02:21 AM, Rex Hoffman wrote:

project: java-version-delta


By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license & feature set suits your needs but it would make 
a potentially useful alternate impl. This is the tool used by some of Oracle's teams to check (primarily binary) compatibility of Java APIs.


My background: for netbeans.org API modules we run this tool to check for compatible & incompatible changes among packages marked public. Currently we have an 
idiosyncratic Ant build (is there any other kind?) so comparisons are done against the modules as they existed in the last product release, but of course in a Maven setup 
we would use the policy you are proposing: x.y -> x.(y+1) may have compatible but not incompatible changes, etc.



The apache portable runtime version standard does want the name of a library
to include it's major version number, so for ubuntu/debian xerces look like:
libxerces2-java_2.9.0-1_all.deb


Not sure this is applicable to most Java development. If you are using a container (such as OSGi) which supports class loader isolation, *and* this container permits 
multiple components with the same ID (but possibly different versions) to be loaded in parallel, then it is unnecessary. Containers with isolation but which enforce 
uniqueness on loaded IDs might benefit, so long as it really makes sense to load two copies of the component - true for plain old class libraries, not necessarily true 
for "active" components which might register services of some sort. Apps not using a container are unlikely to benefit since you could only use multiple versions of a 
library in case the package hierarchy was also renamed. Anyway, I agree that this is not likely something that an API compatibility plugin should address (a separate 
enforcer rule would suffice).



the default would be to
assume that a client of an artifact is not expected to implement [any 
interfaces]


This seems like a poor default - directly contradicts the longstanding Java compatibility policy. (*) If anything, I would place the burden on API designers who publish 
interfaces (or abstract classes) they expect no one else to implement, despite there being no such enforcement from the Java language. (**) An annotation for this purpose 
makes some sense, but it would have to be hosted in a very generic place quite unrelated to a Maven plugin. In the short term, plugin configuration to exclude implements 
checking on certain types or packages may be a better workaround.


(*) For binary compatibility it is permitted to add an interface method without breaking existing implementers, so long as this method is never called - but that 
condition is unlikely, since why would there be a method no one is calling? You cannot even check whether a given object implements a new method or not without using 
reflection. Better to just introduce a new interface (possibly extending the old one) when you want to change signatures.


(**) If the API designer wants, it is possible to expose an abstract class which can be implemented only within the same component. JSR 294 would be very helpful here, 
but it is possible today so long as all the implementations are in the same package, *or* the component uses a format (such as OSGi bundle) which permits restrictions on 
the exported types or packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing with a more fine-grained system but for now it requires javac from JDK 7.



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