Re: Best way to keep test resources with junit / surefire /maven.

[Jason van Zyl]

In almost all cases I start a new project with actual resources in the files 
system to prototype and make sure a new system is working but this becomes 
untenable fairly quickly for the reasons you mention vis-a-vis refactoring.

Ultimately what I end up with is a small generative utility for the type of 
resource I need. In the recent past that’s been class files, JAR files, Git 
repos, and JSON documents. Whatever resource I happen to need I create a tool, 
test the tool, and have it emit resources into the target directory that are 
used for tests and they get wiped out and regenerated with every clean build. 
In making changes to the generative tools I usually leave all tests intact and 
only make additive changes to the generative tool as not to break the output 
that’s expected.

This is the best method that I’ve found. It takes some time to build the 
generative tool but I find it’s worth it. Trying to manage actual resources as 
your code and tests get more sophisticated get cumbersome very quickly.

> On Oct 3, 2015, at 7:20 PM, Kevin Burton  wrote:
> 
> I'm trying to figure out if there's a better way to do this.
> 
> Java doesn't support "here files" or embedded files so you have to keep
> your resources external.  Usually in 'resources',
> 
> I don't want to have things like HTML code and other things in my tests as
> it makes the tests ugly.
> 
> But the problem is that once I create the resources, they can't participate
> in refactoring.
> 
> At least in intellij... even if it's *OBVIOUS* that the resource is
> associated with a given test.
> 
> Is there a cleaner way to do this?
> 
> Either this whole thing is broken or I'm doing it wrong.
> 
> -- 
> 
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
> 
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

the course of true love never did run smooth ...

 -- Shakespeare













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

Re: Copy-dependencies goal error

[Wayne Fay]

What version of Maven was this process originally built to run against?

Can you roll (Maven) back to that version and try again, to confirm it
still works as it did originally? If it does not work, then you know
it is not Maven but rather another tool in the mix like Nexus etc.

Wayne

On Fri, Oct 2, 2015 at 1:18 PM,   wrote:
> I am currently responsible for a "legacy" POM that copies ZIP files
>
> from the Red Hat JBoss Fuse distro in our Nexus repository manager
>
> to a location on a local worstation.  Several ZIP files are copied
>
> from each of the following Fuse components, ActiveMQ, Camel and CXF.
>
>
>
> To perform the copy operation the legacy POM is using the Maven
>
> copy-dependencies goal or the maven-dependency-plugin.
>
>
>
> When this project is executed by Maven for just the ActiveMQ and
>
> CXF Fuse components the designated files are copied fine.  When,
>
> however we execute the project to copy the Camel files, the process
>
> fails.
>
>
>
> The directory for the failing artifacts is present in our Nexus
>
> repository manager, and is populated with several artifacts.
>
>
>
> What I do not understand is why Maven is even looking for these
>
> artifacts for a simple copy operation?  It appears to me that the
>
> artifacts causing the problem have nothing to do with the copy goal!
>
>
>
> I have posted this problem with Red Hat, who originally helpd our
>
> previous personnel develop this POM.  They believe, and I tend to
>
> agree 100%, that this is a Maven problem.
>
>
>
> I have attached our settings.xml, pom.xml and the text of the error
>
> message.
>
>
>
> Can someone please explain why this is happening and how to fix it?
>
>
>
> Thanks,
>
> Mike
>
>
>
> Michael Tarullo
>
> Contractor (Engility Corp)
>
> Enterprise Architect
>
> NSRR System Administrator
>
> FAA WJH Technical Center
>
> (609)485-5294
>
>
>
>
>
> -
> 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: Is there a cache of version range resolutions?

[Karl Heinz Marbaise]

Hi,

On 10/2/15 11:06 PM, Benson Margulies wrote:

I've just tried version ranges for the first time, and I hit a pothole.

Step 1: set version in dependency to: 7.14.0.c52.2. Run a build.

Step 2: change version in pom to  [7.13.500.c52.2,7.13.600.c52.2).

Now, mvn dependency:whatever shows the correct resolution, but an
actual build stubbornly uses the 7.14.0.c52.2 version in the
karaf-maven-plugin.


Which Maven version do you use?

Kind regards
Karl Heinz Marbaise



Completely wiping ~/.m2/repository fixed this.

Can anyone give me higher-precision coordinates for what data I need
to nuke when this happens?

-
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