Re: transitive provided dependencies: a little question
Hi Marco,
It is very simple. Maven stops searching for the dependency when it finds
provided scope and maven assumes the dependency will be provided
externally. Best example being server library jars like servlet-api jar.
Below link will give you clear picture
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
On Tue, Jul 17, 2012 at 2:44 PM, Marco Speranza wrote:
> Hi all...
>
> a friend of mine and I have experienced a compilation error when we
> have tried to compile this project:
>
> prj.a:
> public class A extends B{}
>
> prj.b:
> public class B extends C{}
>
> prj.c:
> public class C{}
>
> where their pom are:
>
> prj.a -> prj.b (provided scope)
>
> prj.b -> prj.c (provided scope)
>
> our compilation fails because C is not included in A's compile
> classpath as shown in the table [1]
>
> My question is... why the transitive 'provided' dependencies of a
> 'provided' dependency are not transitive and the transitive
> *'runtime'* dependencies of a 'provided' dependency is transitive?
>
> IMHO would be better that provided dependencies are transitive and
> runtime dependencies not, it isn't?
>
>
> have a nice day... :-)
>
>
> [1]:
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
>
> --
> Marco Speranza
> Google Code: http://code.google.com/u/marco.speranza79/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
'mvn deploy' complaining that it cannot find what it is deploying
I am running 'mvn deploy' with 3.0.4 on a very simple war overlay project. The target is a nexus instance. There is no traffic in the nexus logs. The problem is specific to one repository; if I target another of my repositories, it works fine. Command-line: mvn deploy -DupdateReleaseInfo=true [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ sencha-extjs --- Uploading: http://maven.basistech.net/nexus/content/repositories/thirdpary/com/basistech/thirdparty/sencha-extjs/4.1/sencha-extjs-4.1.war Uploading: http://maven.basistech.net/nexus/content/repositories/thirdpary/com/basistech/thirdparty/sencha-extjs/4.1/sencha-extjs-4.1.pom [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.054s [INFO] Finished at: Wed Jul 18 08:57:48 EDT 2012 [INFO] Final Memory: 17M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project sencha-extjs: Failed to deploy artifacts: Could not find artifact com.basistech.thirdparty:sencha-extjs:war:4.1 in basistech.3rdparty (http://maven.basistech.net/nexus/content/repositories/thirdpary/) -> [Help 1] - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 'mvn deploy' complaining that it cannot find what it is deploying
The bottom of the stack trace is: Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact com.basistech.thirdparty:sencha-extjs:war:4.1 in basistech.3rdparty (http://maven.basistech.net/nexus/content/repositories/thirdpary/) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:947) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:941) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:837) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) ... 26 more On Wed, Jul 18, 2012 at 9:01 AM, Benson Margulies wrote: > I am running 'mvn deploy' with 3.0.4 on a very simple war overlay > project. The target is a nexus instance. There is no traffic in the > nexus logs. > > The problem is specific to one repository; if I target another of my > repositories, it works fine. > > > Command-line: > > mvn deploy -DupdateReleaseInfo=true > > [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ sencha-extjs --- > Uploading: > http://maven.basistech.net/nexus/content/repositories/thirdpary/com/basistech/thirdparty/sencha-extjs/4.1/sencha-extjs-4.1.war > Uploading: > http://maven.basistech.net/nexus/content/repositories/thirdpary/com/basistech/thirdparty/sencha-extjs/4.1/sencha-extjs-4.1.pom > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 5.054s > [INFO] Finished at: Wed Jul 18 08:57:48 EDT 2012 > [INFO] Final Memory: 17M/81M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy > (default-deploy) on project sencha-extjs: Failed to deploy artifacts: > Could not find artifact com.basistech.thirdparty:sencha-extjs:war:4.1 > in basistech.3rdparty > (http://maven.basistech.net/nexus/content/repositories/thirdpary/) -> > [Help 1] - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
Hi Benson Then I think that all will be well indeed. Building that kind of relationship with ASF is very much aligned with our goals. Right now we're working on multiple fronts to improve our service and get a small scale operation going, so we can make the necessary tweaks to make the model actually work. When the time comes, I believe approaching ASF (and Codehaus, JBoss, etc) will come very naturally. And donating part of what we get just makes a lot of sense (even if we were thinking as investors). FreedomSponsors is made by developers who love open source, and our main goal is to serve the OSS community, while also being able to work on the open source projects that we love ourselves! But those are still dreams for the future. Now is the time for us to do the best we can to get there. So... Wish us luck! :-) Thanks for getting involved! Tony Lâmpada PS: Speaking of OSS, just as a side note: We are going to open source FreedomSponsor's website code as well (there's some code cleanup we have to do first, though) On 17 July 2012 15:41, Benson Margulies wrote: > It is extremely unlikely that the Foundation will be interested in any > participation except to gratefully accept any unrestricted donations > your organization might happen to make. If you want to state on your > website that you are going to donate something to the ASF when the > issue is an ASF project JIRA, and you conform the ASF trademark and > branding guidelines, I predict (speaking without wearing any official > ASF hat) that all will be well. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: How to add a directory first on the classpath using launch4j and maven?
> com.akathist.maven.plugins.launch4j > launch4j-maven-plugin ... > What I was hoping that would happen is that the 'config' directory would be > first on the classpath, but the jar that contains my main class is always > put first on the classpath. I want to put the config dir first, so it is > easy to overwrite certain config files that are also in the main jar. Probably you need to talk to the publisher of this plugin about an enhancement to support your requirements. Or if it is open source, adjust the code yourself. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to add a directory first on the classpath using launch4j and maven?
It is open source, but I think launch4j itself cannot do it after investigating launch4j and the source code of the plugin. I asked a question in the launch4j help forum, hopefully, they can guide me further. 2012/7/18 Wayne Fay > > com.akathist.maven.plugins.launch4j > > launch4j-maven-plugin > ... > > What I was hoping that would happen is that the 'config' directory would > be > > first on the classpath, but the jar that contains my main class is always > > put first on the classpath. I want to put the config dir first, so it is > > easy to overwrite certain config files that are also in the main jar. > > Probably you need to talk to the publisher of this plugin about an > enhancement to support your requirements. Or if it is open source, > adjust the code yourself. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
The biggest danger is that projects will get funded that do not fit into the strategic direction being followed by the ASF committers. When the funded artifacts are turned over to the ASF team (assuming that they are not doing the work) and they refuse to incorporate the changes into an official release, there will be a fork in the project which will be supported by the companies that paid for the enhancement. ASF will have to be very careful not to let egos interfere with good long-term management. On the whole, this could be a good thing for ASF, if it is handled properly. Ron On 18/07/2012 9:19 AM, Tony Lâmpada wrote: Hi Benson Then I think that all will be well indeed. Building that kind of relationship with ASF is very much aligned with our goals. Right now we're working on multiple fronts to improve our service and get a small scale operation going, so we can make the necessary tweaks to make the model actually work. When the time comes, I believe approaching ASF (and Codehaus, JBoss, etc) will come very naturally. And donating part of what we get just makes a lot of sense (even if we were thinking as investors). FreedomSponsors is made by developers who love open source, and our main goal is to serve the OSS community, while also being able to work on the open source projects that we love ourselves! But those are still dreams for the future. Now is the time for us to do the best we can to get there. So... Wish us luck! :-) Thanks for getting involved! Tony Lâmpada PS: Speaking of OSS, just as a side note: We are going to open source FreedomSponsor's website code as well (there's some code cleanup we have to do first, though) On 17 July 2012 15:41, Benson Margulies wrote: It is extremely unlikely that the Foundation will be interested in any participation except to gratefully accept any unrestricted donations your organization might happen to make. If you want to state on your website that you are going to donate something to the ASF when the issue is an ASF project JIRA, and you conform the ASF trademark and branding guidelines, I predict (speaking without wearing any official ASF hat) that all will be well. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
hi when i run command *C:\apache-maven-3.0.4\bin>mvn -v* *it gives following output* Apache Maven 3.0.4 (r1232337; 2012-01-17 14:14:56+0530) Maven home: C:\apache-maven-3.0.4 Java version: 1.6.0_21, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_21\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" *C:\apache-maven-3.0.4\bin>*mvn archetype:generate this time it give proper output means it create proper directory and pom.xml Now please tell me how to create directory of a project outside the bin folder or run maven application from anywhere Thanks for consideration Regards Rahul Bhalla (9953225211)
mvn clean is giving error
Hi, I am using eclipse 3.7 and created new project maven through eclipse. but when i am running mvn clean , i m getting following error. Please guide me. [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of its d ependencies could not be resolved: Failed to read artifact descriptor for org.ap ache.maven.plugins:maven-clean-plugin:jar:2.4.1: Failure to find org.apache.mave n.plugins:maven-clean-plugin:pom:2.4.1 in http://mirrors.dotsrc.org/maven2was c ached in the local repository, resolution will not be reattempted until the upda te interval of dotsrc.org has elapsed or updates are forced -> [Help 1] [ERROR] -- With Regards Atul Parti
Re: 'mvn deploy' complaining that it cannot find what it is deploying
On 18/07/2012, at 6:05 AM, Benson Margulies wrote: > (http://maven.basistech.net/nexus/content/repositories/thirdpary/) I think you have mis-spelt "thirdparty". - Brett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
> Now please tell me how to create directory of a project outside the bin > folder or run maven application from anywhere You've been told more than once. Ensure "mvn -v" works in any directory, not just Maven's bin dir. Then run "mvn archetype:generate" to build a project anywhere you want. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: transitive provided dependencies: a little question
Hi
thanks for your reply... I read the maven dependency mechanism and I
understud how it's works...
The definition of 'provided' scope is that "is only available on the
compilation and test classpath" and the user should provide the
dependency at runtime.
And the definition of 'runtime' scopoe is that "the dependency is not
required for compilation"
so my question is: why the provided transitive dependency is NOT
included in 'compile' classpath and the 'runtime' transitive
dependency IS included in the compile classpath?
Furthermore IMHO this behavior could break some builds (see my little
example) because if the project A needs B at compile time and the
project B needs C at compile time.. for the 'transitivity' theorem
also A might need of C at compile time, isn't it?.
thanks
ciao
--
Marco Speranza
Google Code: http://code.google.com/u/marco.speranza79/
2012/7/18 abhijith tn :
> Hi Marco,
>
> It is very simple. Maven stops searching for the dependency when it finds
> provided scope and maven assumes the dependency will be provided
> externally. Best example being server library jars like servlet-api jar.
>
> Below link will give you clear picture
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
> On Tue, Jul 17, 2012 at 2:44 PM, Marco Speranza
> wrote:
>
>> Hi all...
>>
>> a friend of mine and I have experienced a compilation error when we
>> have tried to compile this project:
>>
>> prj.a:
>> public class A extends B{}
>>
>> prj.b:
>> public class B extends C{}
>>
>> prj.c:
>> public class C{}
>>
>> where their pom are:
>>
>> prj.a -> prj.b (provided scope)
>>
>> prj.b -> prj.c (provided scope)
>>
>> our compilation fails because C is not included in A's compile
>> classpath as shown in the table [1]
>>
>> My question is... why the transitive 'provided' dependencies of a
>> 'provided' dependency are not transitive and the transitive
>> *'runtime'* dependencies of a 'provided' dependency is transitive?
>>
>> IMHO would be better that provided dependencies are transitive and
>> runtime dependencies not, it isn't?
>>
>>
>> have a nice day... :-)
>>
>>
>> [1]:
>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>
>>
>> --
>> Marco Speranza
>> Google Code: http://code.google.com/u/marco.speranza79/
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
Hi Benson, thankings for bringing that subject up. We have been giving a lot of thought into questions like 1) What problem-scenarios might arise when a lot of people starts using FreedomSponsors? 2) And what would be the best way to address those problems? 3) How should FreedomSponsors evolve to best serve the open source community? And forking is one of our concerns as well. It surely fits (1) We believe that, generally speaking, forking is a bad thing. Please take a look at this "Feedback issue" (which is curently an improvement under develeopment) --> http://www.freedomsponsors.org/core/issue/7/add-two-checkboxes-to-the-offer-form-1-no-forking-2-require-release We want to encourage sponsors to fund the original projects - so the "No forking" checkbox will come checked by default in the "Sponsor Issue" screen. If the user unchecks it, a popup window will be displayed, explaining the bad effects of forking, and maybe that decision should be reconsidered. Hopefully what will happen is that most offers will have "no_forking = true" on their acceptance criteria. Developers then will have to actually get involved with the already well-established OSS communities to have access to bounties. If you have more thoughts regarding (1), (2) or (3), we're listening! :-) Thanks Tony Lâmpada On 18 July 2012 11:09, Ron Wheeler wrote: > The biggest danger is that projects will get funded that do not fit into > the strategic direction being followed by the ASF committers. > When the funded artifacts are turned over to the ASF team (assuming that > they are not doing the work) and they refuse to incorporate the changes > into an official release, there will be a fork in the project which will be > supported by the companies that paid for the enhancement. > > ASF will have to be very careful not to let egos interfere with good > long-term management. > > On the whole, this could be a good thing for ASF, if it is handled > properly. > > Ron > > > > > On 18/07/2012 9:19 AM, Tony Lâmpada wrote: > >> Hi Benson >> >> Then I think that all will be well indeed. >> Building that kind of relationship with ASF is very much aligned with our >> goals. >> >> Right now we're working on multiple fronts to improve our service and get >> a >> small scale operation going, so we can make the necessary tweaks to make >> the model actually work. >> When the time comes, I believe approaching ASF (and Codehaus, JBoss, etc) >> will come very naturally. And donating part of what we get just makes a >> lot >> of sense (even if we were thinking as investors). >> >> FreedomSponsors is made by developers who love open source, and our main >> goal is to serve the OSS community, while also being able to work on the >> open source projects that we love ourselves! >> >> But those are still dreams for the future. Now is the time for us to do >> the >> best we can to get there. >> >> So... Wish us luck! :-) >> >> Thanks for getting involved! >> Tony Lâmpada >> >> PS: Speaking of OSS, just as a side note: We are going to open source >> FreedomSponsor's website code as well (there's some code cleanup we have >> to >> do first, though) >> >> >> On 17 July 2012 15:41, Benson Margulies wrote: >> >> It is extremely unlikely that the Foundation will be interested in any >>> participation except to gratefully accept any unrestricted donations >>> your organization might happen to make. If you want to state on your >>> website that you are going to donate something to the ASF when the >>> issue is an ASF project JIRA, and you conform the ASF trademark and >>> branding guidelines, I predict (speaking without wearing any official >>> ASF hat) that all will be well. >>> >>> --**--** >>> - >>> To unsubscribe, e-mail: >>> users-unsubscribe@maven.**apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: transitive provided dependencies: a little question
On 18/07/2012 12:23 PM, Marco Speranza wrote:
Hi
thanks for your reply... I read the maven dependency mechanism and I
understud how it's works...
The definition of 'provided' scope is that "is only available on the
compilation and test classpath" and the user should provide the
dependency at runtime.
And the definition of 'runtime' scopoe is that "the dependency is not
required for compilation"
so my question is: why the provided transitive dependency is NOT
included in 'compile' classpath and the 'runtime' transitive
dependency IS included in the compile classpath?
Furthermore IMHO this behavior could break some builds (see my little
example) because if the project A needs B at compile time and the
project B needs C at compile time.. for the 'transitivity' theorem
also A might need of C at compile time, isn't it?.
Why would the compiler even care about C when compiling A?
It only has references to B that it needs to resolve.
Lets say that I use Apache's log4j. My code only refers to log4j objects
and my code does not have any references to the objects that log4j uses.
At runtime, my code will run just fine as long as the log4j.jar has in
it all of the things that log4j requires to perform its functions.
Remember:
The current system works for thousands of projects every day with tens
of thousands of developers using "provided" and "compile" scopes
successfully.
Ron
thanks
ciao
--
Marco Speranza
Google Code: http://code.google.com/u/marco.speranza79/
2012/7/18 abhijith tn :
Hi Marco,
It is very simple. Maven stops searching for the dependency when it finds
provided scope and maven assumes the dependency will be provided
externally. Best example being server library jars like servlet-api jar.
Below link will give you clear picture
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
On Tue, Jul 17, 2012 at 2:44 PM, Marco Speranza wrote:
Hi all...
a friend of mine and I have experienced a compilation error when we
have tried to compile this project:
prj.a:
public class A extends B{}
prj.b:
public class B extends C{}
prj.c:
public class C{}
where their pom are:
prj.a -> prj.b (provided scope)
prj.b -> prj.c (provided scope)
our compilation fails because C is not included in A's compile
classpath as shown in the table [1]
My question is... why the transitive 'provided' dependencies of a
'provided' dependency are not transitive and the transitive
*'runtime'* dependencies of a 'provided' dependency is transitive?
IMHO would be better that provided dependencies are transitive and
runtime dependencies not, it isn't?
have a nice day... :-)
[1]:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
--
Marco Speranza
Google Code: http://code.google.com/u/marco.speranza79/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
Sorry it gives C:\Users\sahil>mvn --v 'mvn' is not recognized as an internal or external command, operable program or batch file. -- Regards Rahul Bhalla
Re: transitive provided dependencies: a little question
Hi Ron...
yes I understood your point.. but some days ago I tried to compile a
project like this:
prj.a:
public class A extends B{}
prj.b:
public class B extends C{}
prj.c:
public class C{}
where their pom are:
prj.a -> prj.b (provided scope)
prj.b -> prj.c (provided scope)
is strange... but the build fails because A extends B and A needs to
know also C at compile time..
Could you try to compile my example?
thank a lot...
regards
--
Marco Speranza
Google Code: http://code.google.com/u/marco.speranza79/
2012/7/18 Ron Wheeler :
> On 18/07/2012 12:23 PM, Marco Speranza wrote:
>>
>> Hi
>>
>> thanks for your reply... I read the maven dependency mechanism and I
>> understud how it's works...
>>
>> The definition of 'provided' scope is that "is only available on the
>> compilation and test classpath" and the user should provide the
>> dependency at runtime.
>> And the definition of 'runtime' scopoe is that "the dependency is not
>> required for compilation"
>>
>> so my question is: why the provided transitive dependency is NOT
>> included in 'compile' classpath and the 'runtime' transitive
>> dependency IS included in the compile classpath?
>>
>> Furthermore IMHO this behavior could break some builds (see my little
>> example) because if the project A needs B at compile time and the
>> project B needs C at compile time.. for the 'transitivity' theorem
>> also A might need of C at compile time, isn't it?.
>
>
> Why would the compiler even care about C when compiling A?
> It only has references to B that it needs to resolve.
> Lets say that I use Apache's log4j. My code only refers to log4j objects and
> my code does not have any references to the objects that log4j uses.
>
> At runtime, my code will run just fine as long as the log4j.jar has in it
> all of the things that log4j requires to perform its functions.
>
> Remember:
> The current system works for thousands of projects every day with tens of
> thousands of developers using "provided" and "compile" scopes successfully.
>
>
> Ron
>
>
>>
>> thanks
>> ciao
>> --
>> Marco Speranza
>> Google Code: http://code.google.com/u/marco.speranza79/
>>
>>
>> 2012/7/18 abhijith tn :
>>>
>>> Hi Marco,
>>>
>>> It is very simple. Maven stops searching for the dependency when it finds
>>> provided scope and maven assumes the dependency will be provided
>>> externally. Best example being server library jars like servlet-api jar.
>>>
>>> Below link will give you clear picture
>>>
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>>
>>> On Tue, Jul 17, 2012 at 2:44 PM, Marco Speranza
>>> wrote:
>>>
Hi all...
a friend of mine and I have experienced a compilation error when we
have tried to compile this project:
prj.a:
public class A extends B{}
prj.b:
public class B extends C{}
prj.c:
public class C{}
where their pom are:
prj.a -> prj.b (provided scope)
prj.b -> prj.c (provided scope)
our compilation fails because C is not included in A's compile
classpath as shown in the table [1]
My question is... why the transitive 'provided' dependencies of a
'provided' dependency are not transitive and the transitive
*'runtime'* dependencies of a 'provided' dependency is transitive?
IMHO would be better that provided dependencies are transitive and
runtime dependencies not, it isn't?
have a nice day... :-)
[1]:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
--
Marco Speranza
Google Code: http://code.google.com/u/marco.speranza79/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency entry changes runtime
I posted this in Weblogic's forum and waited. But nothing useful came out of it. If I restart WLS (without having the dependency tag in POM file), the problem goes away... This is the post in Weblogic's forum: https://forums.oracle.com/forums/thread.jspa?threadID=2413507&tstart=0 -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: July-11-12 3:14 PM To: Maven Users List Subject: Re: Dependency entry changes runtime > Now that I think again, the problem is not that the class is not > found. The error says "java.lang.IllegalArgumentException: Object: > com.xxx.entities.XyzEntity@3a18c1 is not a known entity type" which is > coming from EclipseLink in WebLogic. > > But I wonder why making a trivial change (as it seems) in POM file > should make this behave differently. I gotta be an issue in JPA. So out of > this list's scope. I think there must be some additional difference(s) between the "working" and "not working" state that you have simply not found -- but not necessarily in the Jar files you are producing now, perhaps in some other piece/component. If you sort it out, come back and give us more details, if for no reason other than to benefit future Google searchers who run into similar problems with EclipseLink. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
At this point, you need to find someone local to you who can come over to your desk, sit down at your PC and help you make this work. You've exhausted the resources of this list, I think. Wayne On Wed, Jul 18, 2012 at 12:01 PM, rahul bhalla wrote: > Sorry > > it gives > > C:\Users\sahil>mvn --v > 'mvn' is not recognized as an internal or external command, > operable program or batch file. > > -- > Regards > Rahul Bhalla - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
hey Wayne Fay Do you have any idea where did i do mistake?? -- Regards Rahul Bhalla
Re: BUILD FAILURE to create project structure
what kind of resource list you are talking -- Regards Rahul Bhalla (9953225211)
RE: BUILD FAILURE to create project structure
This list. The maven list. The one to which you are asking your questions. Take step back. Go to the maven home page and start from scratch and install maven following the instructions provided on the maven home page. > -Original Message- > From: rahul bhalla [mailto:urcoolfrien...@gmail.com] > Sent: Wednesday, July 18, 2012 1:22 PM > To: Maven Users List > Subject: Re: BUILD FAILURE to create project structure > > what kind of resource list you are talking > > > -- > Regards > Rahul Bhalla > (9953225211) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
I installed maven once again but same problem enconters On Wed, Jul 18, 2012 at 10:54 PM, Thiessen, Todd (Todd) wrote: > This list. The maven list. The one to which you are asking your questions. > > Take step back. Go to the maven home page and start from scratch and > install maven following the instructions provided on the maven home page. > > > -Original Message- > > From: rahul bhalla [mailto:urcoolfrien...@gmail.com] > > Sent: Wednesday, July 18, 2012 1:22 PM > > To: Maven Users List > > Subject: Re: BUILD FAILURE to create project structure > > > > what kind of resource list you are talking > > > > > > -- > > Regards > > Rahul Bhalla > > (9953225211) > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Regards Rahul Bhalla (9953225211)
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
On Wed, Jul 18, 2012 at 12:27 PM, Tony Lâmpada wrote: > Hi Benson, > > thankings for bringing that subject up. > > We have been giving a lot of thought into questions like Tony, I'm just one Foundation member. This isn't the list to be communicating with if you want to engage with the Foundation in a more formal way. Anything I write here is just my opinion. The community development project would be better. It seems to me that this model of yours has the least risk of community problems when the issues are relatively small and compact -- 'fix this bug.' Often, though not always, a bug is a bug, and a clean patch for a bugfix, complete with test case, will be gratefully committed. However, even this has room for entertainment. When I commit patches, sometimes I do some pretty serious rework on them. If I thought that the poster was going to get paid as a result of my efforts, I might be troubled. Even bug fixes can be the subject of design and architecture disagreement. If someone has money riding on getting a patch committed, I could see some additional friction. I don't see the fuss about forks. The person either putting up the money either wants the change integrated into the trunk or not. If they are happy with a fix made in their very own fork, why should anyone else care? The AL is fork-friendly. The other side of this coin is that forking, as a development strategy, is a great way to fail to get your work into the trunk, especially forking without community engagement. The Apache approach works best with small, incremental, changes. If the posted bounty is for some gigantic feature, this creates friction. The person doing the work only gets paid for the whole thing, but the process will extend over time and might bog down in the middle. The Foundation has a very strong set of values around volunteer status. Yes, people get paid for their work on ASF projects. However, they interact with with the projects as individuals, not as employees or contractors. Once again, for small stuff, this is fine. Contributing a patch works fine so long as the contributor is willing to work with the community. For a bigger, strategic, contribution, the expectation is that someone is going to earn the respect of the community on small stuff before proposing something major. People who show up and say, 'I'd like to add this giant thing' often are met with some resistance. > > 1) What problem-scenarios might arise when a lot of people starts using > FreedomSponsors? > 2) And what would be the best way to address those problems? > 3) How should FreedomSponsors evolve to best serve the open source > community? > > And forking is one of our concerns as well. It surely fits (1) > We believe that, generally speaking, forking is a bad thing. > > Please take a look at this "Feedback issue" (which is curently an > improvement under develeopment) --> > http://www.freedomsponsors.org/core/issue/7/add-two-checkboxes-to-the-offer-form-1-no-forking-2-require-release > > We want to encourage sponsors to fund the original projects - so the "No > forking" checkbox will come checked by default in the "Sponsor Issue" > screen. > If the user unchecks it, a popup window will be displayed, explaining the > bad effects of forking, and maybe that decision should be reconsidered. > > Hopefully what will happen is that most offers will have "no_forking = > true" on their acceptance criteria. > Developers then will have to actually get involved with the already > well-established OSS communities to have access to bounties. > > If you have more thoughts regarding (1), (2) or (3), we're listening! :-) > > Thanks > Tony Lâmpada > > On 18 July 2012 11:09, Ron Wheeler wrote: > >> The biggest danger is that projects will get funded that do not fit into >> the strategic direction being followed by the ASF committers. >> When the funded artifacts are turned over to the ASF team (assuming that >> they are not doing the work) and they refuse to incorporate the changes >> into an official release, there will be a fork in the project which will be >> supported by the companies that paid for the enhancement. >> >> ASF will have to be very careful not to let egos interfere with good >> long-term management. >> >> On the whole, this could be a good thing for ASF, if it is handled >> properly. >> >> Ron >> >> >> >> >> On 18/07/2012 9:19 AM, Tony Lâmpada wrote: >> >>> Hi Benson >>> >>> Then I think that all will be well indeed. >>> Building that kind of relationship with ASF is very much aligned with our >>> goals. >>> >>> Right now we're working on multiple fronts to improve our service and get >>> a >>> small scale operation going, so we can make the necessary tweaks to make >>> the model actually work. >>> When the time comes, I believe approaching ASF (and Codehaus, JBoss, etc) >>> will come very naturally. And donating part of what we get just makes a >>> lot >>> of sense (even if we were thinking as investors). >>> >>> FreedomSponsors is m
Re: problem in installing/running maven
I also noticed that when issue give command C:\Users\sahil>%JAVA_HOME% 'C:\Program' is not recognized as an internal or external command, operable program or batch file. but i set JAVA_HOME to C:\Program Files\Java\jdk1.6.0_21 that means it is not displaying full java_Home Path On Thu, Jul 19, 2012 at 12:08 AM, rahul bhalla wrote: > when issue the command it gives > C:\Users\sahil>%M2_HOME% > 'D:\springsource\apache-maven-3.0.3' is not recognized as an internal or > external > operable program or batch file. > -- Regards Rahul Bhalla (9953225211)
RE: problem in installing/running maven
Wow! Rahul! You need to learn to crawl before you can learn to walk. This is not a Maven problem. You need to go to your manager or to a co-worker or to your cool friend with the following questions: 1. How do I run commands from a command prompt in Windows? 2. What's the difference between an environment variable and a command or an executable program? 3. What's the PATH environment variable for and how does it relate to my being able to run a program in Windows? That's just for a start. I'm not trying to put you down, we've all been there at one time, but you're going to have a lot of grief trying to learn any tool like Maven without improving your computer literacy first. And you'll start to irritate the folks on this list if you keep coming at them with these types of questions. Matt > -Original Message- > From: rahul bhalla [mailto:urcoolfrien...@gmail.com] > Sent: Wednesday, July 18, 2012 1:00 PM > To: Maven Users List > Subject: Re: problem in installing/running maven > > I also noticed that when issue give command > > C:\Users\sahil>%JAVA_HOME% > 'C:\Program' is not recognized as an internal or external command, > operable program or batch file. > but i set JAVA_HOME to C:\Program Files\Java\jdk1.6.0_21 > > that means it is not displaying full java_Home Path > > On Thu, Jul 19, 2012 at 12:08 AM, rahul bhalla > wrote: > > > when issue the command it gives > > C:\Users\sahil>%M2_HOME% > > 'D:\springsource\apache-maven-3.0.3' is not recognized as an internal > or > > external > > operable program or batch file. > > > > > > -- > Regards > Rahul Bhalla > (9953225211) __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[MVN 3.0.4] Can't download project dependencies
Hi, I have a problem: when I try to build my project I get those errors: http://pastebin.com/RELAPiXC My version info: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: C:\Maven\bin\.. Java version: 1.7.0_05, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_05\jre Default locale: pl_PL, platform encoding: Cp1250 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" MNG-5162 isn't a working solution for me. -- Pozdrowienia, Cysioland
Re: [MVN 3.0.4] Can't download project dependencies
> My version info:
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: C:\Maven\bin\..
> Java version: 1.7.0_05, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_05\jre
> Default locale: pl_PL, platform encoding: Cp1250
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> MNG-5162 isn't a working solution for me.
So you're saying that "Setting MAVEN_OPTS to
-Djava.net.preferIPv4Stack=true" does not fix this for you?
Here is a workaround:
Switch back to JDK6.
Run your project ("mvn clean" may be sufficient) to download dependencies.
Switch back to JDK7 and continue working on your project.
If this is ultimately a problem in JDK7 (as it seems based on the
comments in MNG-5162), I'm unsure what you expect the Maven Users list
to do about it other than tell you to not run JDK7.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[MVN 3.0.4] Can't download project dependencies
Hi, I have a problem: when I try to build my project I get those errors: http://pastebin.com/RELAPiXC My version info: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: C:\Maven\bin\.. Java version: 1.7.0_05, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_05\jre Default locale: pl_PL, platform encoding: Cp1250 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" MNG-5162 isn't a working solution for me. -- Pozdrowienia, Cysioland
Re: [MVN 3.0.4] Can't download project dependencies
How to install JDK6 without getting rid of JDK7?
Re: [MVN 3.0.4] Can't download project dependencies
> How to install JDK6 without getting rid of JDK7? Honestly, this is outside the scope of the Maven Users mailing list. There is nothing in the JDK6 installer to actively delete JDK5 or JDK7 or prevent you from installing even multiple copies of the same JDK into different directories. 1. Download JDK6 and install it into its own directory. (aka not the same one you installed JDK7 into) 2. Set PATH and JAVA_HOME to point to JDK6 rather than JDK7. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [MVN 3.0.4] Can't download project dependencies
Thanks, I'll try this tomorrow
