Oh!!
I see the point and apologize
Could you create a sample project and attach it to a jira issue, as it
I will add an it test with the groovy compiler use case in the project
to ensure no regression.
2012/5/30 Andrew Eisenberg :
> I produce the groovy-eclipse-compiler, which is implemented as
On Wed, May 30, 2012 at 11:48 AM, KARR, DAVID wrote:
> I'm reading "Continuous Delivery", which is a good book, but I read one
> statement about Maven that seems out of date to me. I'd appreciate a bit of
> fact-checking here.
>
> It said:
>
> "... in its default configuration, it is self-updat
I'm reading "Continuous Delivery", which is a good book, but I read one
statement about Maven that seems out of date to me. I'd appreciate a bit of
fact-checking here.
It said:
"... in its default configuration, it is self-updating. Maven's core is very
small, and in order to make itself func
Yes, I have that.
I believe I fixed this issue by "mvn pdf:pdf -U".
Thanks
Jirong
--
View this message in context:
http://maven.40175.n5.nabble.com/How-to-upload-this-pdf-plugin-on-to-my-internal-company-repository-tp5709832p5710325.html
Sent from the Maven - Users mailing list archive at Nabbl
On Tue, May 29, 2012 at 11:18 PM, Ramesh Ramamoorthy
wrote:
> Hi,
[del]
> [WARNING] Unable to get resource
> 'org.apache.maven.plugins:maven-eclipse-plugin:
> pom:2.8' from repository lt00as30
> (http://lt00as30.opr.statefarm.org/artifactory
> /repo): Authorization failed: Access denied to:
> h
Hi,
I'm trying to run the Archetype plugin command like "mvn -Parchetype
archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app".
Please find the below log:
C:\DEV\LDT Maven>mvn -Parchetype archetype:create -DgroupId=com.mycompany.app -D
artifactId=my-app
[INFO] Scanning for projects
On Tue, May 29, 2012 9:06 am, chad.da...@emc.com wrote:
> We're having problems with a build not being able to download snapshots
> from nexus. We use timestamped snapshots, but I noticed that there are
> also non-timestamped, i.e. they just say myArtifact-1.0.0-SNAPSHOT.jar, in
> there. I belive
I produce the groovy-eclipse-compiler, which is implemented as a
compiler plugin to compile groovy and java code. Up until now, I
haven't had to specify a strict version for which
maven-compiler-plugin to use and this was good because my users have
reasons for using different versions of the maven
Hi
2012/5/30 Andrew Eisenberg :
> Hi all,
>
> It looks like there is a breaking change with plexus-compiler-api 1.9
> from earlier versions of the plugin.
>
> 1.8.1:
> CompilerConfiguration.getCustomCompilerArguments() returns LinkedHashMap
>
> 1.9:
> CompilerConfiguration.getCustomCompilerArgumen
Hi all,
It looks like there is a breaking change with plexus-compiler-api 1.9
from earlier versions of the plugin.
1.8.1:
CompilerConfiguration.getCustomCompilerArguments() returns LinkedHashMap
1.9:
CompilerConfiguration.getCustomCompilerArguments() returns Map
This means that a plugins compi
Have you defined your pluginRepository in your maven settings.xml file?
Something like:
nexus
central
Unfortunately I can't change what max-public has. I already explained why,
because we have a internal central repo and everything is hosted there
instead of using or proxying Maven central. This is not what I can change.
So my question remains the same: why I am getting this error and how to fix
t
>
> I think it's more of a Nexus question as it depends on what's in the maven-
> metadata.xml file. Maven never scraps the folders but uses the metadata.
>
> What error do you get? Why not just remove the non-timestamped
> Snapshots? Or, just wipe all the Snapshots and issue new build of them
I am using a Maven framework another project already setup, and I am also new
to Maven. That's why I don't know much details. the pdf:pdf will generate a
pdf file contains the deployment instruction. I don't even know where is the
source for the pdf file.
Thanks
Jirong
--
View this message in con
The pdf plugin expects some source files to process, you have to add
that yourself, see [1] for a mini guide. As I said, a simple dummy index
file will presumably get you around the error.
Note that not all reports are supported by the pdf plugin [2] and with
maven 3 you won't get any report
Hi folks,
I'm trying to setup the releases plugin in a multi module project but
without success so far. I expect this project to be released to a Nexus
server from which also works as a proxy and is used to fetch dependencies.
In my settings all traffic is redirected to the nexus server through a
I think it's more of a Nexus question as it depends on what's in the
maven-metadata.xml file. Maven never scraps the folders but uses the
metadata.
What error do you get? Why not just remove the non-timestamped
Snapshots? Or, just wipe all the Snapshots and issue new build of them
giving you nice,
On 29 May 2012 16:38, Rolf Lear wrote:
>
> So what this does is
>
>
> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
> wrote:
>> On 29 May 2012 15:26, Rolf Lear wrote:
>>>
>>>
>>> So, being inexperienced, my intention is to find some solution that:
>>>
>>> 1. makes it possible (even if pla
> My site at C:\Sandbox\MDM\CdiServicesParent\target\site is generated by
> "mvn
> site:site" and only contains css and image folder, nothing else.
>
> But my "pdf:pdf" is look for the source of site at
> C:\Sandbox\MDM\CdiServicesParent\src\site. How can I pass this in
> parameters?
Step back for
We're having problems with a build not being able to download snapshots from
nexus. We use timestamped snapshots, but I noticed that there are also
non-timestamped, i.e. they just say myArtifact-1.0.0-SNAPSHOT.jar, in there. I
belive these came from someone doing a "redploy artifacts" from an
My site at C:\Sandbox\MDM\CdiServicesParent\target\site is generated by "mvn
site:site" and only contains css and image folder, nothing else.
But my "pdf:pdf" is look for the source of site at
C:\Sandbox\MDM\CdiServicesParent\src\site. How can I pass this in
parameters?
Thanks
Jirong
--
View thi
So what this does is
On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
wrote:
> On 29 May 2012 15:26, Rolf Lear wrote:
>>
>>
>> So, being inexperienced, my intention is to find some solution that:
>>
>> 1. makes it possible (even if playing exclusion games is needed) to use
>> both JDOM 1.
Do you have some source files for the site or only reports? Try to add a
dummy index.apt or any other site source.
HTH,
-Lukas
hujirong wrote:
I got the error below when run "mvn pdf:pdf". I tried "mvn pdf:pdf
-DsiteDirectory=${basedir}/target/site", still same error.
Thanks
Jirong
[ERRO
On 29 May 2012 15:26, Rolf Lear wrote:
>
>
> So, being inexperienced, my intention is to find some solution that:
>
> 1. makes it possible (even if playing exclusion games is needed) to use
> both JDOM 1.x and 2.x in a maven project (currently it is not).
Well actually it is possible to work arou
I got the error below when run "mvn pdf:pdf". I tried "mvn pdf:pdf
-DsiteDirectory=${basedir}/target/site", still same error.
Thanks
Jirong
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project
CdiServicesParent: Error during document generation
Hibernate might be a good model.
If jdom2 is upward compatible with jdom1 then you have no need to run 2
versions.
It means not changing the behaviour of existing methods except in ways
that all current users will like (remove a bug).
You add new methods to add functionality and you make sure t
So, being inexperienced, my intention is to find some solution that:
1. makes it possible (even if playing exclusion games is needed) to use
both JDOM 1.x and 2.x in a maven project (currently it is not).
2. 'salvages' the current mess as simply as possible for the 'typical'
maven user.
3. is so
Hi Stephen,
> the issue is transitive version resolution. If one of your
> dependencies depends on org.jdom:jdom:1.x and the other depends on
> org.jdom:jdom:2.x then you're going to end up with something broken as
> maven will resolve only one version of org.jdom:jdom... so you will
> end up hav
On 29 May 2012 14:53, Curtis Rueden wrote:
> Hi Rolf,
>
>
>> Unfortunately, there are already some 'third party' packages that depend
>> on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have two
>> different versions of the same jar right? ... which is perhaps worse
>> than not
Hi Rolf,
> Unfortunately, there are already some 'third party' packages that depend
> on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have two
> different versions of the same jar right? ... which is perhaps worse
> than not having it at all ... ;-)
>
Since your goal is to al
30 matches
Mail list logo
