from:"Ron Wheeler"

Re: Resolving an Artifact from Remote Repository instead of Local

2016-07-21 Thread Ron Wheeler

Took a bit of circling around but it seems like a simple solution was
found in the end!

I am kind of surprised that no one popped up with a solution for OSGi.
Not a rare technology.

Did you look at the maven-bundle-plugin?
http://felix.apache.org/components/bundle-plugin/index.html
http://stackoverflow.com/questions/12996182/indexing-a-jar-using-maven-bundle-plugin

Ron

On 21/07/2016 3:40 PM, Jordan Lewis wrote:

Awesome. That should work for my case.

Thanks!
Jordan

On 7/21/16, 3:02 PM, "Ron Wheeler" wrote:

http://stackoverflow.com/questions/9123004/maven-is-it-possible-to-override-location-of-local-repository-via-the-use-of-co
Even easier - run-time argument to Maven

On 21/07/2016 2:49 PM, Jordan Lewis wrote:

Still not sure why anyone would need an index file. What are they going
to use it for?

We have an OSGi runtime and use OBR to deploy our bundles. OBR needs artifacts
to be indexed so it can find them to satisfy the dependencies of our bundles.
That is what I’m building the index file for. If it contained paths to my local
repositories, it wouldn’t mean anything to people on different machines.

Is there some way to override system.resolveArtifact's understanding of
where to find the local repo.
Then you could give it an empty directory and your problem would be
solved without touching your "real" repo cache.

Very true. I did something like that, but it required changing the indexer
code. Is there a way to change my local repository path using a pom attribute
or settings.xml change?

Thanks,
Jordan

On 21/07/2016 2:10 PM, Jordan Lewis wrote:

Looks like it might be easier to just delete your local repo!

I know that this approach works. It’s just a bit inconvenient to have to do
that.

Perhaps you might want to revisit your ultimate goal.
Describe the use that people will make of the index and see if anyone
has a different way to get what you want.

My ultimate goal is to try to resolve artifacts from a specific remote
repository and ignore the local repository. The URIs in the generated index
file then won’t depend on the local repository path of the machine where the
index file was generated.

Why is your need so different from the normal case that no one else has
ever run into this problem?

I don’t think people are usually concerned with where artifacts are resolved
from because they aren’t building index files that anyone should be able to
use. I know that others have mentioned this problem with the index plugin, but
after looking at the code a bit, it appears like they can’t do anything about
it because the Aether code doesn’t have any options for resolving artifacts
without first checking the local repository manager. I think it would be
beneficial if Aether overloaded the method so that you could pass a parameter
to not check that local repository or provide a new method which accepts a
remote repository and the artifact request, and then tries to resolve the
artifact with that remote repository only.

My real hope was that I was overlooking some code that would already accomplish
what I just described which is what led me to the mailing lists. Is ther
another way to resolve artifacts other than system.resolveArtifact(..) which
always checks the LocalRepositoryManager first?

Thanks,
Jordan

On 21/07/2016 11:46 AM, Jordan Lewis wrote:

Is this, <https://github.com/eclipse/aether-core>, still the code base? I could
make a pull request that would show exactly the part I’m talking about with a
possible solution.

Thanks,
Jordan

On 7/20/16, 1:53 PM, "Jordan Lewis" wrote:

Any update on what mailing list I should be using?

Jordan

On 7/19/16, 2:26 PM, "Jordan Lewis" wrote:

Here is the email I received from them about it.

Hi Jordan,

…

Does anyone have any suggestions for me to resolve this or is there
another email list where this question would fit better?

sadly, Aether has left Eclipse for Apache, to be developed there in
closer collaboration with the Maven core. See [1] here for the details.

I am not aware of an aether-users list at Apache, so I would suggest
asking on users@maven.apache.org or maybe d...@maven.apache.org. Neither
list seems to be a perfect fit though, as you are neither end user or
developer of Maven itself.

Anyway, it would be great if you could reply which list ultimately
answered your question, so future developers can find the answer in the
archives.

Hope that helps.

Andreas

[1]
<https://projects.eclipse.org/projects/technology.aether/reviews/termination-review>

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
aether-users mailing list
aether-us...@eclipse.org
To change your delivery options, retrieve y

Re: Resolving an Artifact from Remote Repository instead of Local

2016-07-21 Thread Ron Wheeler

http://stackoverflow.com/questions/9123004/maven-is-it-possible-to-override-location-of-local-repository-via-the-use-of-co
Even easier - run-time argument to Maven

On 21/07/2016 2:49 PM, Jordan Lewis wrote:

Still not sure why anyone would need an index file. What are they going
to use it for?

Very true. I did something like that, but it required changing the indexer
code. Is there a way to change my local repository path using a pom attribute
or settings.xml change?

Thanks,
Jordan

On 21/07/2016 2:10 PM, Jordan Lewis wrote:

Looks like it might be easier to just delete your local repo!

I know that this approach works. It’s just a bit inconvenient to have to do
that.

Perhaps you might want to revisit your ultimate goal.
Describe the use that people will make of the index and see if anyone
has a different way to get what you want.

Why is your need so different from the normal case that no one else has
ever run into this problem?

Thanks,
Jordan

On 21/07/2016 11:46 AM, Jordan Lewis wrote:

Is this, <https://github.com/eclipse/aether-core>, still the code base? I could
make a pull request that would show exactly the part I’m talking about with a
possible solution.

Thanks,
Jordan

On 7/20/16, 1:53 PM, "Jordan Lewis" wrote:

Any update on what mailing list I should be using?

Jordan

On 7/19/16, 2:26 PM, "Jordan Lewis" wrote:

Here is the email I received from them about it.

Hi Jordan,

…

Does anyone have any suggestions for me to resolve this or is there
another email list where this question would fit better?

sadly, Aether has left Eclipse for Apache, to be developed there in
closer collaboration with the Maven core. See [1] here for the details.

Anyway, it would be great if you could reply which list ultimately
answered your question, so future developers can find the answer in the
archives.

Hope that helps.

Andreas

[1]
<https://projects.eclipse.org/projects/technology.aether/reviews/termination-review>

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
aether-users mailing list
aether-us...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/aether-users

On 7/19/16, 10:27 AM, "Jordan Lewis" wrote:

Correct. However, I used that mailing list that you listed and they pointed me
to your list because you have taken the project over, correct?

Jordan

On 7/19/16, 10:25 AM, "Ron Wheeler" wrote:

Yes.
It does seem that you do not have a Maven problem but have an Aether problem
https://dev.eclipse.org/mailman/listinfo/aether-users

Ron

On 19/07/2016 9:54 AM, Jo

Re: Resolving an Artifact from Remote Repository instead of Local

2016-07-21 Thread Ron Wheeler

Still not sure why anyone would need an index file. What are they going 
to use it for?


Is there some way to override  system.resolveArtifact's understanding of 
where to find the local repo.
Then you could give it an empty directory and your problem would be 
solved without touching your "real" repo cache.


Ron

On 21/07/2016 2:10 PM, Jordan Lewis wrote:

Looks like it might be easier to just delete your local repo!

I know that this approach works. It’s just a bit inconvenient to have to do 
that.


Perhaps you might want to revisit your ultimate goal.
Describe the use that people will make of the index  and see if anyone
has a different way to get what you want.

My ultimate goal is to try to resolve artifacts from a specific remote 
repository and ignore the local repository. The URIs in the generated index 
file then won’t depend on the local repository path of the machine where the 
index file was generated.


Why is your need so different from the normal case that no one else has
ever run into this problem?

I don’t think people are usually concerned with where artifacts are resolved 
from because they aren’t building index files that anyone should be able to 
use. I know that others have mentioned this problem with the index plugin, but 
after looking at the code a bit, it appears like they can’t do anything about 
it because the Aether code doesn’t have any options for resolving artifacts 
without first checking the local repository manager. I think it would be 
beneficial if Aether overloaded the method so that you could pass a parameter 
to not check that local repository or provide a new method which accepts a 
remote repository and the artifact request, and then tries to resolve the 
artifact with that remote repository only.

My real hope was that I was overlooking some code that would already accomplish 
what I just described which is what led me to the mailing lists. Is ther 
another way to resolve artifacts other than system.resolveArtifact(..) which 
always checks the LocalRepositoryManager first?

Thanks,
Jordan


On 21/07/2016 11:46 AM, Jordan Lewis wrote:

Is this, <https://github.com/eclipse/aether-core>, still the code base? I could 
make a pull request that would show exactly the part I’m talking about with a 
possible solution.

Thanks,
Jordan



On 7/20/16, 1:53 PM, "Jordan Lewis"  wrote:


Any update on what mailing list I should be using?

Jordan




On 7/19/16, 2:26 PM, "Jordan Lewis"  wrote:


Here is the email I received from them about it.


Hi Jordan,

…



Does anyone have any suggestions for me to resolve this or is there
another email list where this question would fit better?


sadly, Aether has left Eclipse for Apache, to be developed there in
closer collaboration with the Maven core. See [1] here for the details.

I am not aware of an aether-users list at Apache, so I would suggest
asking on users@maven.apache.org or maybe d...@maven.apache.org. Neither
list seems to be a perfect fit though, as you are neither end user or
developer of Maven itself.

Anyway, it would be great if you could reply which list ultimately
answered your question, so future developers can find the answer in the
archives.

Hope that helps.

Andreas

[1]
<https://projects.eclipse.org/projects/technology.aether/reviews/termination-review>

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
aether-users mailing list
aether-us...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aether-users





On 7/19/16, 10:27 AM, "Jordan Lewis"  wrote:


Correct. However, I used that mailing list that you listed and they pointed me 
to your list because you have taken the project over, correct?

Jordan




On 7/19/16, 10:25 AM, "Ron Wheeler"  wrote:


Yes.
It does seem that you do not have a Maven problem but have an Aether problem
https://dev.eclipse.org/mailman/listinfo/aether-users

Ron

On 19/07/2016 9:54 AM, Jordan Lewis wrote:

Does that all make sense or do you need anything else to make it clearer?

Thanks,
Jordan




On 7/18/16, 3:56 PM, "Jordan Lewis"  wrote:


The plug-in does have a configuration that tries to ignore the local repo, but 
whenever it resolves an artifact using system.resolveArtifact(..), it always 
checks the local repo first.

What is the code to ignore the local repo? Or is there some code that could try 
to resolve an artifact from a specific repo?

Thanks,
Jordan




On 7/18/16, 3:22 PM, "Ron Wheeler"  wrote:


Can you just patch the existing plug-in to create a new plug-in that
ignores the local repo?
Or add a configuration flag to ignore the local repo an

Re: Resolving an Artifact from Remote Repository instead of Local

2016-07-21 Thread Ron Wheeler


Looks like it might be easier to just delete your local repo!

Perhaps you might want to revisit your ultimate goal.
Describe the use that people will make of the index  and see if anyone 
has a different way to get what you want.


Why is your need so different from the normal case that no one else has 
ever run into this problem?


Ron


On 21/07/2016 11:46 AM, Jordan Lewis wrote:

Is this, <https://github.com/eclipse/aether-core>, still the code base? I could 
make a pull request that would show exactly the part I’m talking about with a 
possible solution.

Thanks,
Jordan



On 7/20/16, 1:53 PM, "Jordan Lewis"  wrote:


Any update on what mailing list I should be using?

Jordan




On 7/19/16, 2:26 PM, "Jordan Lewis"  wrote:


Here is the email I received from them about it.


Hi Jordan,

…



Does anyone have any suggestions for me to resolve this or is there
another email list where this question would fit better?



sadly, Aether has left Eclipse for Apache, to be developed there in
closer collaboration with the Maven core. See [1] here for the details.

I am not aware of an aether-users list at Apache, so I would suggest
asking on users@maven.apache.org or maybe d...@maven.apache.org. Neither
list seems to be a perfect fit though, as you are neither end user or
developer of Maven itself.

Anyway, it would be great if you could reply which list ultimately
answered your question, so future developers can find the answer in the
archives.

Hope that helps.

Andreas

[1]
<https://projects.eclipse.org/projects/technology.aether/reviews/termination-review>

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
aether-users mailing list
aether-us...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aether-users





On 7/19/16, 10:27 AM, "Jordan Lewis"  wrote:


Correct. However, I used that mailing list that you listed and they pointed me 
to your list because you have taken the project over, correct?

Jordan




On 7/19/16, 10:25 AM, "Ron Wheeler"  wrote:


Yes.
It does seem that you do not have a Maven problem but have an Aether problem
https://dev.eclipse.org/mailman/listinfo/aether-users

Ron

On 19/07/2016 9:54 AM, Jordan Lewis wrote:

Does that all make sense or do you need anything else to make it clearer?

Thanks,
Jordan




On 7/18/16, 3:56 PM, "Jordan Lewis"  wrote:


The plug-in does have a configuration that tries to ignore the local repo, but 
whenever it resolves an artifact using system.resolveArtifact(..), it always 
checks the local repo first.

What is the code to ignore the local repo? Or is there some code that could try 
to resolve an artifact from a specific repo?

Thanks,
Jordan




On 7/18/16, 3:22 PM, "Ron Wheeler"  wrote:


Can you just patch the existing plug-in to create a new plug-in that
ignores the local repo?
Or add a configuration flag to ignore the local repo and submit your
improvement as an enhancement.


Ron

On 18/07/2016 2:29 PM, Jordan Lewis wrote:

Nexus.

Our remote Nexus repository is available to others, but my local repository is 
obviously not. So whenever I generate the index file, I need to make sure that 
my local paths to the artifacts are never used which they are if the artifact 
can be resolved both locally and remotely. I need it to only resolve from the 
remote repository.

Thanks,
Jordan



On 7/18/16, 2:21 PM, "Ron Wheeler"  wrote:


What repo are you using locally - Nexus, Artifactory,?
Why is it not available to others?

Ron

On 18/07/2016 2:04 PM, Jordan Lewis wrote:

Is this question in the wrong mailing list? Is there a specific Aether mailing 
list?

Thanks,
Jordan




On 7/14/16, 9:41 AM, "Jordan Lewis"  wrote:


Hi All,

This is a question about the Aether API. I’m working on building an index file 
which will point to the resolved artifact using bnd-indexer-maven-plugin. The 
indexer has an option to forbid the use of local URIs and that works fine as 
long as I don’t have the artifact in my local repository. I need the artifact 
to resolve to the remote repository so that anyone can use this index file and 
it won’t depend on my local repository. If the artifact is in my local 
repository though, it resolves to that artifact whenever the indexer code call 
system.resolveArtifact(..). I can get around this by clearing my local 
repository and then the artifact will resolve to the remote repository location 
just fine. I did some digging and it appears like you are always checking the 
localRepositoryManager first and then you check remote repositories.

Is there a way to make it ignore the local repository resoluti

Re: Resolving an Artifact from Remote Repository instead of Local

2016-07-19 Thread Ron Wheeler


Yes.
It does seem that you do not have a Maven problem but have an Aether problem
https://dev.eclipse.org/mailman/listinfo/aether-users

Ron

On 19/07/2016 9:54 AM, Jordan Lewis wrote:

Does that all make sense or do you need anything else to make it clearer?

Thanks,
Jordan




On 7/18/16, 3:56 PM, "Jordan Lewis"  wrote:


The plug-in does have a configuration that tries to ignore the local repo, but 
whenever it resolves an artifact using system.resolveArtifact(..), it always 
checks the local repo first.

What is the code to ignore the local repo? Or is there some code that could try 
to resolve an artifact from a specific repo?

Thanks,
Jordan




On 7/18/16, 3:22 PM, "Ron Wheeler"  wrote:


Can you just patch the existing plug-in to create a new plug-in that
ignores the local repo?
Or add a configuration flag to ignore the local repo and submit your
improvement as an enhancement.


Ron

On 18/07/2016 2:29 PM, Jordan Lewis wrote:

Nexus.

Our remote Nexus repository is available to others, but my local repository is 
obviously not. So whenever I generate the index file, I need to make sure that 
my local paths to the artifacts are never used which they are if the artifact 
can be resolved both locally and remotely. I need it to only resolve from the 
remote repository.

Thanks,
Jordan



On 7/18/16, 2:21 PM, "Ron Wheeler"  wrote:


What repo are you using locally - Nexus, Artifactory,?
Why is it not available to others?

Ron

On 18/07/2016 2:04 PM, Jordan Lewis wrote:

Is this question in the wrong mailing list? Is there a specific Aether mailing 
list?

Thanks,
Jordan




On 7/14/16, 9:41 AM, "Jordan Lewis"  wrote:


Hi All,

This is a question about the Aether API. I’m working on building an index file 
which will point to the resolved artifact using bnd-indexer-maven-plugin. The 
indexer has an option to forbid the use of local URIs and that works fine as 
long as I don’t have the artifact in my local repository. I need the artifact 
to resolve to the remote repository so that anyone can use this index file and 
it won’t depend on my local repository. If the artifact is in my local 
repository though, it resolves to that artifact whenever the indexer code call 
system.resolveArtifact(..). I can get around this by clearing my local 
repository and then the artifact will resolve to the remote repository location 
just fine. I did some digging and it appears like you are always checking the 
localRepositoryManager first and then you check remote repositories.

Is there a way to make it ignore the local repository resolution or set a 
repository priority order where it would check the remote repository before the 
local repository?

Thanks,
Jordan




--
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: Resolving an Artifact from Remote Repository instead of Local

2016-07-18 Thread Ron Wheeler

Can you just patch the existing plug-in to create a new plug-in that 
ignores the local repo?
Or add a configuration flag to ignore the local repo and submit your 
improvement as an enhancement.



Ron

On 18/07/2016 2:29 PM, Jordan Lewis wrote:

Nexus.

Our remote Nexus repository is available to others, but my local repository is 
obviously not. So whenever I generate the index file, I need to make sure that 
my local paths to the artifacts are never used which they are if the artifact 
can be resolved both locally and remotely. I need it to only resolve from the 
remote repository.

Thanks,
Jordan



On 7/18/16, 2:21 PM, "Ron Wheeler"  wrote:


What repo are you using locally - Nexus, Artifactory,?
Why is it not available to others?

Ron

On 18/07/2016 2:04 PM, Jordan Lewis wrote:

Is this question in the wrong mailing list? Is there a specific Aether mailing 
list?

Thanks,
Jordan




On 7/14/16, 9:41 AM, "Jordan Lewis"  wrote:


Hi All,

This is a question about the Aether API. I’m working on building an index file 
which will point to the resolved artifact using bnd-indexer-maven-plugin. The 
indexer has an option to forbid the use of local URIs and that works fine as 
long as I don’t have the artifact in my local repository. I need the artifact 
to resolve to the remote repository so that anyone can use this index file and 
it won’t depend on my local repository. If the artifact is in my local 
repository though, it resolves to that artifact whenever the indexer code call 
system.resolveArtifact(..). I can get around this by clearing my local 
repository and then the artifact will resolve to the remote repository location 
just fine. I did some digging and it appears like you are always checking the 
localRepositoryManager first and then you check remote repositories.

Is there a way to make it ignore the local repository resolution or set a 
repository priority order where it would check the remote repository before the 
local repository?

Thanks,
Jordan


-
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





--
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: Resolving an Artifact from Remote Repository instead of Local

2016-07-18 Thread Ron Wheeler


What repo are you using locally - Nexus, Artifactory,?
Why is it not available to others?

Ron

On 18/07/2016 2:04 PM, Jordan Lewis wrote:

Is this question in the wrong mailing list? Is there a specific Aether mailing 
list?

Thanks,
Jordan




On 7/14/16, 9:41 AM, "Jordan Lewis"  wrote:


Hi All,

This is a question about the Aether API. I’m working on building an index file 
which will point to the resolved artifact using bnd-indexer-maven-plugin. The 
indexer has an option to forbid the use of local URIs and that works fine as 
long as I don’t have the artifact in my local repository. I need the artifact 
to resolve to the remote repository so that anyone can use this index file and 
it won’t depend on my local repository. If the artifact is in my local 
repository though, it resolves to that artifact whenever the indexer code call 
system.resolveArtifact(..). I can get around this by clearing my local 
repository and then the artifact will resolve to the remote repository location 
just fine. I did some digging and it appears like you are always checking the 
localRepositoryManager first and then you check remote repositories.

Is there a way to make it ignore the local repository resolution or set a 
repository priority order where it would check the remote repository before the 
local repository?

Thanks,
Jordan



-
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: How does maven choose which plugin version to use?

2016-07-04 Thread Ron Wheeler


A quick google gets you
https://maven.apache.org/pom.html#Plugin_Management

You can add a plug-in management section to your parent pom to control 
the version used in all of your project poms.


https://maven.apache.org/guides/introduction/introduction-to-the-pom.html

Ron

On 03/07/2016 5:45 PM, Alex Ditu wrote:

Hello,

Can anyone provide some help regarding plugin versions? I want to use
the latest version of maven-war-plugin (or at least one greater than
2.3); so i decided to install the latest version of maven, 3.3.9.
But when I execute "mvn help:effective-pom" I see it still uses 2.3
version of maven-war-plugin.
My first question is: where does maven read wich plugin version to
use, if I don't specify one?
I tought it was in the super-pom, but I didn't find anything
there...Can anyone help me understand what is happening?

Alex

-
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: maven-shade-plugin and Eclipse (m2e)

2016-07-01 Thread Ron Wheeler

http://blog.artifact-software.com/tech/?p=121 and other Maven posts 
might give you some ideas about handling large numbers of third party 
jars in a large project.

We use Eclipse/STS and Maven.

Ron

On 30/06/2016 11:10 AM, Eddie Galvez wrote:

What is the way to use the maven-shade-plugin but, what I think is the
obvious usage then of such a shaded project, to have it in eclipse as a
source project?

In other words - because maven-shade-plugin only does its thing on
package... while you are in Eclipse (your IDE), other projects will not
compile since they are expecting the shaded package names... what's the way
to be able to work with a project that you want to maven-shade-plugin some
third party dependencies in, for use within and inside eclipse?

Cleary I understand you can just package/install the shaded project into a
repository then NOT bring in the source project into the workspace... but
ideally I don't want that.

Thanks!




--
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: Create own Maven repository

2016-05-13 Thread Ron Wheeler


Small technical correction on military notation.

Are you sure that you did not mean FUBARed rather than SNAFU?

Ron

On 13/05/2016 3:16 AM, Barrie Treloar wrote:

A snapshot repository won't behave how you think it will behave.
I recommend not providing one.

As a developer you want your code base to be in a known configured state.
Having a snapshot repository will mean that Maven will pull in a new
snapshot occasionally (you have some control over when they might be) and
if that snapshot is SNAFU then you have just stopped that developer from
being productive. If a developer wants a snapshot let them pull your code
down and built it themselves, then if the code is SNAFU they can choose a
previous revision from source control to use instead.

Since you are talking about a sourceforge project then you are providing an
open source, so you are better off deploying your releases to central.
Your users will thank you for not slowing their build times down with your
custom repo.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: build a maven artifact with a list of jars

2016-03-25 Thread Ron Wheeler


Look at my articles at blog.artifact-software.com/tech on Maven

We do this as a normal way to work with Maven.

Ron
Ron

On 24/03/2016 3:37 PM, Natva, Arun Kumar wrote:

Hi,
I have a list of jars (say around 100) and most of the applications developed 
in my team need these jars. I need to create a maven artifact using these jars 
and upload the artifact into my company's internal nexus repository so that 
other developers can simply add this artifact as a dependency in their projects.

I am looking for help over internet on how to do this, but did not find it so far. 
I cannot use maven-install-file plugin since it works only for one jar file. I am 
trying to experiment with maven-assembly-plugin & assembly descriptor, but 
haven't been successful.

A good example to accomplish the above would be really helpful. Can you please 
take a look at my problem and help me out with this.

Regards,
Arun,
Ph: (980)387-1766(w)

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.




--
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: Error in POM File

2016-03-22 Thread Ron Wheeler



It sounds like - is missing a version in its dependency?




On 22/03/2016 11:30 AM, forjava wrote:

Hi all,

I have created a maven project without any arch-type. I have imported a
Maven ready project from the below mentioned url:-

http://uby.ukp.informatik.tu-darmstadt.de/uby/dkpro-uby-tutorial-aiphes.zip

After importing the project, I am getting error in the POM file.

The error message is as under :-

Project build error: 'dependencies.dependency.version for
--- is missing.

Please tell how to resolve this problem.


  


Thanking you
forjava.



--
View this message in context: 
http://maven.40175.n5.nabble.com/Error-in-POM-File-tp5864130.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
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: Import Submodule into Maven Project in IntelliJ

2016-03-20 Thread Ron Wheeler

I have never used the sub-project structure and as nearly as I can tell 
have suffered no ill-affects for the past 8 + years.


Ron

On 20/03/2016 12:52 PM, Jason Franklin wrote:

I decided to just go with the inelegant solution of building a new
project and adding submodules into which I clicked and dragged the
source code I needed. So the problem is solved.

It looks like this in IDEA now:

-- parent
 -- sub-module 1
 -- sub-module 2
 -- etc.

Perhaps I'm not using Maven in the spirit it was intended... I noticed
in the POM reference that you can declare a parent project and, in the
 element, specify its aggregated projects with a relative
pathname (meaning the modules don't need to be  subdirectories of the
parent). Similarly, I saw that an inheriting pom.xml can use relative
pathnames in its  element.

So, it is possible to "relate" projects strongly without unifying them
into a directory hierarchy of IDEA project files. Then, the user can
import multiple projects that are then shown as a list in the project
explorer. I was hoping that the IDEA Maven plugin would unify all of my
projects for me when I declared the relationship. However, given the
observation in the previous paragraph, there must be situations in which
this behavior is undesirable. And, there are probably very few
situations where this is really required given Maven's ability to relate
projects with such flexibility.

Maven by Example makes it seem as though the directory hierarchy for
parent/submodule projects is highly desirable (if not required).

Correct analysis?




--
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: I want to separate the 3rd party jar in war file.

2016-03-19 Thread Ron Wheeler

http://blog.artifact-software.com/tech/?p=121 Aggregation jars make 
development simpler and wars smaller


http://blog.artifact-software.com/tech/?p=150 Separating Environment 
from Maven Artifacts

This is an earlier approach that is geared towards an internal deployment.
The use of an installer is newer and I have not written a blog article yet.


On 18/03/2016 3:52 PM, Mark Eggers wrote:

Ron,

That is certainly another (and potentially excellent way) of looking at
this problem.

This all works well.
We have been doing this for the last 3 years.
We moved out thrd-party dependencies to "provided"  more than 5 years 
ago (as you can see from the dates on the articles on our blog)
The first project had over 80 wars and jar that we built and included 
about 50 third party libraries.
Not quite as big as the project that started this discussion but big 
enough to test the concept.


The current project is smaller but is much more sophisticated in its 
deployment requirements.
It creates installers for different clients that use the identical code 
but different supporting files.


More comments interspersed below.

1. Use provided
2. Create a deploy job in something like Jenkins
a. Add a dependency to your product WAR
b. Add dependencies to the JARs marked as provided in step 1
c. Deploy the resulting WAR

An installer like IzPack will do this

This has several advantages.

1. Keeps your server generic - easier upgrades
2. Keeps the JARs associated with the appropriate project

And keeps them in your Maven Repo not in your SCM

3. No need to worry about production, UAT, test, dev mismatches

The only drawback I see in this arrangement is keeping the deploy job
dependencies in sync with the provided dependencies in
the product WAR.



You might be able to manage this by using a parent pom with properties
defining the scope in a DependencyManagement section. In your product
WAR pom.xml, set the property to provided. In your deploy pom.xml, set
the property to compile.


Use an installer like IzPack that uses your parent POM to control versions.
Use aggregation jars to reduce the number of jars required to deploy the 
app.





I don't know if the above would work, but if it does then keeping the
versions of the third party JARs in sync becomes much easier (managed by
the parent pom.xml).

. . . . just noodling out loud
/mde/





On 3/18/2016 12:37 PM, Ron Wheeler wrote:

This looks like another case of someone trying to use a build tool as
an installer.

An installer will look after your third party jars and your
production configuration files and keep dev and prod well organized.

This makes the builds much easier (and smaller) while still providing
a repeatable installation that you can test and certify.

It also clearly separates configuration files that are managed
during development from those that are managed by the system
administrator.

The files that are immutable from the System Admin point of view are
part of the "code" and the configuration that depends on the
production or test environment are part of the installer project(s).
You can make as many installer projects as you need to support
different production deployments.

These can be maintained by deployment specialists or people who are
clearly acting as deployment specialists when setting up these
files.

It also allows one to have a good place for resources such as
READMEs, docs, licenses, etc. that are not really part of a coding
project but might be required when the project is put in production.

I use IzPack which builds installers using a maven plug-in which
knows about maven dependencies so you can control versioning as you
normally do (in the parent POM - right?) It also knows about
platforms so developers do not have to worry about mixing up
platform-dependent configuration files. The installer will install
the "right" set of configuration files for Linux or Windows or Mac.

So we write the code and test it until we are ready to deploy to
production. Then we build the installer with Maven and install it or
send it to the client for them to install it.

Makes for a much simpler life.

Ron

On 18/03/2016 10:01 AM, Anders Hammar wrote:

As stated earlier, you need to setup your production environment
similar to your dev environment. So if those 3rd party libs are
part of Tomcat in your dev environment they should be so in prod as
well. Or keep them in your war for dev and prod.

/Anders

On Fri, Mar 18, 2016 at 11:48 AM, pradeepkumar
 wrote:


Thanks Mark and Anders for quick response.

As you guys suggested i have used the provided
for some of my dependencies in pom.xml. Then i generated the war
the jars count was reduced from 165 to 130 (Still i need to add
the scope for all the pom.xml's).

But while deploying the war (only application jars ) i have to
use the 3rd party jars for successful deployment and application
up n running.Without 3rd party jars i cannot use the application/

Re: I want to separate the 3rd party jar in war file.

2016-03-19 Thread Ron Wheeler

This looks like another case of someone trying to use a build tool as an
installer.

An installer will look after your third party jars and your production
configuration files and keep dev and prod well organized.

This makes the builds much easier (and smaller) while still providing a
repeatable installation that you can test and certify.

It also clearly separates configuration files that are managed during
development from those that are managed by the system administrator.

The files that are immutable from the System Admin point of view are
part of the "code" and the configuration that depends on the production
or test environment are part of the installer project(s).
You can make as many installer projects as you need to support different
production deployments.

These can be maintained by deployment specialists or people who are
clearly acting as deployment specialists when setting up these files.

It also allows one to have a good place for resources such as READMEs,
docs, licenses, etc. that are not really part of a coding project but
might be required when the project is put in production.

I use IzPack which builds installers using a maven plug-in which knows
about maven dependencies so you can control versioning as you normally
do (in the parent POM - right?)
It also knows about platforms so developers do not have to worry about
mixing up platform-dependent configuration files. The installer will
install the "right" set of configuration files for Linux or Windows or Mac.

So we write the code and test it until we are ready to deploy to
production.
Then we build the installer with Maven and install it or send it to the
client for them to install it.

Makes for a much simpler life.

Ron

On 18/03/2016 10:01 AM, Anders Hammar wrote:

As stated earlier, you need to setup your production environment similar to
your dev environment. So if those 3rd party libs are part of Tomcat in your
dev environment they should be so in prod as well. Or keep them in your war
for dev and prod.

/Anders

On Fri, Mar 18, 2016 at 11:48 AM, pradeepkumar
wrote:

Thanks Mark and Anders for quick response.

As you guys suggested i have used the provided for some of
my
dependencies in pom.xml.
Then i generated the war the jars count was reduced from 165 to 130 (Still
i
need to add the scope for all the pom.xml's).

But while deploying the war (only application jars ) i have to use the 3rd
party jars for successful deployment and application up n running.Without
3rd party jars i cannot use the application/ even cannot deploy.

Currently all the 3rd party jars are maintaining in SVN (One of the folder
in svn i.e Tomcatconfiguration).

Please help me on this .

--
View this message in context:
http://maven.40175.n5.nabble.com/I-want-to-separate-the-3rd-party-jar-in-war-file-tp5864042p5864046.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
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: I want to separate the 3rd party jar in war file.

2016-03-18 Thread Ron Wheeler

http://blog.artifact-software.com/tech/?p=121 is our experience with 
this approach.

Worked very well.
We had about 80 3rd party jars.

Separating build from install is the next step.

Ron

On 18/03/2016 4:48 AM, Mark Eggers wrote:

As Anders has said, you can use provided for those third
party JARs that you wish to exclude from the WAR file, but still need
when the application runs on your server.

There are few advantages to this and several disadvantages.

The advantages include a smaller WAR file, which means faster
deployment, faster transfers, and a smaller file within your local
repository (you do use a corporate repository, yes?).

As Anders has stated as well, the problem then becomes a configuration
management issue. Your development, testing, user acceptance test, and
production environments must all provide the same versions of the 165
JARs that you currently include in your WAR file. Mismatched versions
can lead to some very subtle issues.

Another problem with using provided is when you run
multiple web applications in one container. They must all use the same
version of common JARs, otherwise issues can arise with incompatible
versions of various libraries. Class loading may minimize this, but
there are 'interesting' edge cases.

Upgrading the shared libraries means that all applications must function
with the upgrade. Also, when you do the upgrade, the server must be shut
down.

In short, using a provided for the 165 JARs (or subset of
those JARs) is workable if you are careful with server configuration
management as well as cross-application compatibility (or you only run
one application per server). Otherwise, you can end up with errors with
the root cause being dependency version incompatibility.

Some people do this, and manage the dependencies at the server level.
Other people manage the dependencies at the application level.

. . . just my (sleepy) 2 cents
/mde/


On 3/18/2016 12:10 AM, Anders Hammar wrote:

If some dependencies are already provided by the runtime (e.g. the app
server) you use scope 'provided'. That will make those dependencies used
during compilation but htey are not included in the war. More details on
the different dependency scopes can be find by googling.
However, using a different setup for local development and production is
strongly discouraged, it will only lead to errors. So if you have some jars
outside of your war during dev (i.e. 'provided') you should do that in
production as well.

/Anders

On Fri, Mar 18, 2016 at 7:43 AM, pradeepkumar 
wrote:


I want to separate the 3rd party jar in war file.
Currently we have 165 jars are  using in our project. Out of this only 27
jars are belongs to Application jars then rest of jars are 3rd party jars.
In our projects our dev team is maintaining the jars in a separate folder
in
one drive as shown below.
C:\Tomcatconfiguration\lib\Jar1 .. jar100
they will make use of those jars through eclipse.

In the same way we have a job which will generate the war lets say Desktop.
in the same Desktop code there are maintaining some jars at
WebContent\WEB-INF\lib level.

But i am adding all the dependencies in all the pom.xmls then war are
generated and working as expected. But the war file size is growing.
When ever i generate the war file all the 165 jars are included in war file
.then the war file  size is growing.
So i want to separate the 3rd party jars from war file.
I don't want to include all the 3rd party jars in WAR and want to use only
application jars.
Whenever i want to deploy i want make use of 3rd party jars.
Can anyone suggest the best way and how can i do this.
right now i am separating the the 3rd party jars by using the scope compile
compile tag in all the pom.xml as shown below .
 
 org.apache.poi
 poi
 3.9
 compile
 true
 

Is this the right approch ? then how to make use of 3rd party jars.

Please suggest .








--
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: Maven does not detect local changes

2016-03-08 Thread Ron Wheeler


More details might help.
Are you using an IDE?
Can you describe where your files are located and show some of the 
console output from Maven.


It seems unlikely that you are compiling the files that you have changed.
Maven has no memory about source files and would not be able to 
reconstruct files that you changed.


Ron

On 07/03/2016 9:02 PM, Gaurav Kanade wrote:

Hi

I am relatively new to Maven;

I am working on a Apache git project and made some local changes but it
seems mvn compile or install is not picking up my changes at all.

To test it out I also added garbage syntax errors to my files to see if it
detects errors but it still doesn't pick these.

Is there something I am missing here ?

Gaurav




--
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: Offlining maven: how to set up the p2 cache?

2016-01-28 Thread Ron Wheeler

The easiest way to do off-line building is to set up a Maven repo on 
your workstation.


/.m2/repository is a cache not a repo and Maven knows that, so it is 
hard to fool it.


If you set up your repo with a free community version of Nexus, you can 
populate it manually with the libraries that you want if security is an 
issue or you can allow Maven and Nexus to populate it by doing a build 
on-line before going off-line.


Nexus is easy to set up. http://www.sonatype.org/nexus/go/

There are other Maven repos 
https://maven.apache.org/repository-management.html


If you have a team using Maven, a repo on a shared server is very 
helpful and makes Maven much easier to use.


You can also deploy your own libraries to it which makes team 
development much easier.


If you look at our blog blog.artifact-software.com/tech you will see a 
few posts about our use of Maven and Nexus.


Bon journée

Ron

On 28/01/2016 3:54 PM, Thibault, Daniel wrote:

I have these two projects that need to be compiled offline.  I thought I 
would first compile them on-line and then transplant the ~/.m2/repository to 
the offline system.  However, something isn't quite right.  I'm using Apache 
Maven 3.3.9 and Java 1.8.0_45.

The two projects (when run with 'mvn --offline') both give a failure along 
the lines of:

[INFO] Adding repository http://download.eclipse.org/tools/cdt/releases/8.8
[ERROR] Failed to resolve target definition <...>.target: Failed to load p2 
metadata repository from location http://download.eclipse.org/tools/cdt/releases/8.8/: 
Repository system is offline and no local cache available for 
http://download.eclipse.org/tools/cdt/releases/8.8 -> [Help 1]

Isn't the p2 cache in ~/.m2/repository/p2 ?

Strangely, the two projects behave differently.

For one, building offline fails as described above while building online 
fetches 15 compositeContent.xml, content.jar, content.xml.xz and p2.index from 
download.eclipse.org before using the cache and completing normally.

For the other, the first offline run caused a Java exception (same error as 
above, somehow not handled).  I then ran it online, successfully (same 
behaviour as the other project).  But running it offline now succeeds as well!

What is the established procedure for setting up the m2 and p2 caches in 
order to ensure maven builds succeed offline?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca<mailto:daniel.thiba...@drdc-rddc.gc.ca> / Tél: 
418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca<mailto:daniel.thiba...@forces.gc.ca> / Tél: 
418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca<mailto:daniel.thiba...@drdc-rddc.gc.ca> / Tel: 
418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca<mailto:daniel.thiba...@forces.gc.ca> / Tel: 
418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale





--
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: Offlining maven: how to set up the p2 cache?

2016-01-28 Thread Ron Wheeler


On 28/01/2016 3:54 PM, Thibault, Daniel wrote:

I have these two projects that need to be compiled offline.  I thought I 
would first compile them on-line and then transplant the ~/.m2/repository to 
the offline system.  However, something isn't quite right.  I'm using Apache 
Maven 3.3.9 and Java 1.8.0_45.

The two projects (when run with 'mvn --offline') both give a failure along 
the lines of:

[INFO] Adding repository http://download.eclipse.org/tools/cdt/releases/8.8
[ERROR] Failed to resolve target definition <...>.target: Failed to load p2 
metadata repository from location http://download.eclipse.org/tools/cdt/releases/8.8/: 
Repository system is offline and no local cache available for 
http://download.eclipse.org/tools/cdt/releases/8.8 -> [Help 1]

Isn't the p2 cache in ~/.m2/repository/p2 ?

Strangely, the two projects behave differently.

For one, building offline fails as described above while building online 
fetches 15 compositeContent.xml, content.jar, content.xml.xz and p2.index from 
download.eclipse.org before using the cache and completing normally.

For the other, the first offline run caused a Java exception (same error as 
above, somehow not handled).  I then ran it online, successfully (same 
behaviour as the other project).  But running it offline now succeeds as well!

What is the established procedure for setting up the m2 and p2 caches in 
order to ensure maven builds succeed offline?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca<mailto:daniel.thiba...@drdc-rddc.gc.ca> / Tél: 
418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca<mailto:daniel.thiba...@forces.gc.ca> / Tél: 
418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca<mailto:daniel.thiba...@drdc-rddc.gc.ca> / Tel: 
418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca<mailto:daniel.thiba...@forces.gc.ca> / Tel: 
418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale





--
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: How to manage dependency "includes"?

2016-01-09 Thread Ron Wheeler


 
   
 group-a
 artifact-a
 1.0

 
   
 group-c
 excluded-artifact
   
 

   

and since Maven 3.2.1 you exclude all transitive dependencies via:


 
   
 group-a
 artifact-a
 1.0

 
   
 *
 *
   
 

   
...

Apart from that...an include does not make sense from my point of view
cause this could lead to the impression that you you could add
dependencies transitively..which makes no sense..

Furthermore changing the pom structure here would break all things
This kind of changed could only be made (may be ...) in Maven 4???


Kind regards
Karl Heinz Marbaise


-
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: AW: AW: AW: How to manage dependency "includes"?

2016-01-09 Thread Ron Wheeler


I was not expecting that you could adopt our solution completely.

I does sound like you have a lot of it already incorporated into your 
processes.
The aggregated POMs would probably fix your remaining issue with 
exclusions and version conflicts and would be easy to add to your 
existing practices.


I suspect that the problem that you will have in getting acceptance of 
the kind of change that you are suggesting is that you seem to want to 
change the definition of the POM schema.
There is a lot of infrastructure and third party tools that might be 
affected and getting a buy-in could take years.


There are people in this forum who are in a better position than me to 
advise you on the possibility of acceptance of this idea.


My opinion is that support from the m2e community would be important and 
Sonatype's support would move your idea a long way forward.


Ron

On 09/01/2016 4:59 AM, Christofer Dutz wrote:

Thanks for that detailed post, but it's still not what I asked for :-(
I just finished the transition of ALL of the projects of a large international 
bank from Ant to Maven. In parallell
what was initially about 70 more or less separate projects, that were assembled 
to one huge monolithic application was changed in order to create modules and 
the ability to assemble several applications, each with different focusses.

It was a huge challenge as you have to coordinate the wishes of uncountable 
project-managers, developers and other stakeholders. We encountered quite a 
large number of serious problems. Everyone that has worked for a Bank knows you 
can't just go there and tell them what the standard is, cause they'll tell you 
what their standard is ;-)

So in the end we prohibited (by maven plugin) providing the version of third 
party libraries, enforced the usage of a company-wide dependencyManagement pom 
that is used in every project. Additionally we enforced the rules of the 
dependency plugin to declare used dependencies and not to rely on transitive 
dependencies. With this a lot of our problems were solved. Even if the 
developers complain every now and then, but I guess that's the price to pay for 
giving them the freedom they need and the flexibility they want. Introducing a 
rather strict policy on the process as you describe, is completely out of the 
question. You can't get 40 project managers to discuss new versions. This 
meeting would probably never, ever end ;-)

So back to the question none has answered yet (would be cool if maybe someone 
on the dev-team of Maven could respond):
Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break 
things, and would it be ok to fix up a Pull request implementing that functionality?

Chris

____
Von: Ron Wheeler 
Gesendet: Freitag, 8. Januar 2016 15:58
An: users@maven.apache.org
Betreff: Re: AW: AW: How to manage dependency "includes"?

In our setup, each project has its own parent POM and set of aggregated
third party libraries. Some sharing is done between products for really
common stuff like Spring, Apache Commons, Tomcat, etc.
The library com.artifact_software.projectA:reporting-library:1.2 might
be different from com.artifact_software.projectB:reporting-library:1.2
if one used BIRT and the other used Jasper Reports.

These should be under the control of the person/team that is responsible
for deciding what version of the third party libraries are to be allowed.
The following might be involved in the selection of a new library or a
request by a developer to upgrade a library.
- Product Manager - legal/licensing, market acceptance, documentation,
functionality issues
- Project manager - scheduling, testing, risk assessment, aggregation
strategy
- Lead developer - risk assessment, alternatives, technical analysis,
aggregation strategy

At the beginning of each development sprint, we review the current
libraries to see what versions should be updated.
This does not completely eliminate changes to versions during the
development process as programmers run into opportunities to use
features from newer versions or discovery of critical bugs that require
a library upgrade in mid-sprint.

This review is pretty short and usually involves the entire team so that
we can estimate the cost of changing a library - what modules will be
affected and require testing even if they are not being modified as part
of the sprint.

Once this is done, the developers do not have to worry about
dependencies. Once the version of
com.artifact_software.projectA:commons-library:1.2 is set, the
developers do not have to worry about what version of each of the Apache
Commons libraries are included and module POMs should not include any
third party libraries unless there is a good reason not to have it under
team management.

This also minimizes the changes to POMs.
The parent POM's dependency management sets the versions for the release
being deve

Re: AW: AW: How to manage dependency "includes"?

2016-01-08 Thread Ron Wheeler

In our setup, each project has its own parent POM and set of aggregated
third party libraries. Some sharing is done between products for really
common stuff like Spring, Apache Commons, Tomcat, etc.
The library com.artifact_software.projectA:reporting-library:1.2 might
be different from com.artifact_software.projectB:reporting-library:1.2
if one used BIRT and the other used Jasper Reports.

These should be under the control of the person/team that is responsible
for deciding what version of the third party libraries are to be allowed.
The following might be involved in the selection of a new library or a
request by a developer to upgrade a library.
- Product Manager - legal/licensing, market acceptance, documentation,
functionality issues
- Project manager - scheduling, testing, risk assessment, aggregation
strategy
- Lead developer - risk assessment, alternatives, technical analysis,
aggregation strategy

At the beginning of each development sprint, we review the current
libraries to see what versions should be updated.
This does not completely eliminate changes to versions during the
development process as programmers run into opportunities to use
features from newer versions or discovery of critical bugs that require
a library upgrade in mid-sprint.

This review is pretty short and usually involves the entire team so that
we can estimate the cost of changing a library - what modules will be
affected and require testing even if they are not being modified as part
of the sprint.

Once this is done, the developers do not have to worry about
dependencies. Once the version of
com.artifact_software.projectA:commons-library:1.2 is set, the
developers do not have to worry about what version of each of the Apache
Commons libraries are included and module POMs should not include any
third party libraries unless there is a good reason not to have it under
team management.

This also minimizes the changes to POMs.
The parent POM's dependency management sets the versions for the release
being developed so once the reference to the parent POM is changed, all
the right versions of everything is automatically included in the
module. This makes life really easy for developers - change one number
in the module POM and start working.

I hope that this helps.

Ron

On 08/01/2016 5:03 AM, Christofer Dutz wrote:

I agree, but this only woks as long as there is "THE" project manager. Here
there are several ones. The central instance that manages libraries and their versions
and handles conflict resolution is simply the one managing the central
dependencyManagement pom. All the project POMs are part of the projects and these are
responsibility of those teams and even live in separate repos.

But coming back to my initial question:
Would maven support of "exclusions" and "inclusions" in dependency management
break anything? If yes - what? I still think that this could solve a lot of problems we were having
and shouldn't have a big impact on Maven itself. If it doesn't break anything and I would implement
something like that ... what would the chances that it gets accepted be?

Chris

________
Von: Ron Wheeler
Gesendet: Donnerstag, 7. Januar 2016 16:06
An: users@maven.apache.org
Betreff: Re: AW: How to manage dependency "includes"?

If you are using Eclipse with the m2e plug-ins (we use Eclipse/STS which
comes with this), it will tell you what versions are being included as
transitive dependencies.

Our approach removed the decision about library versions from the
developers and put it into the project manager's hand so that:
- Adding a library had some management visibility - license
compatibility, vendor/developer stability, avoiding duplication of
functionality, library testing
- Programmers did not have to worry about incorrect or missing dependencies
- Programmers could move to a new project quickly.
- updating a library version updated automatically updated all projects

It took a bit of work once we decided to get organized but it paid off
very quickly in programmer productivity and improved project schedule
stability

Once you have found the source jar for the library and included it in
one of your libraries, it is available for every module.

Ron

On 07/01/2016 9:25 AM, Christofer Dutz wrote:

Hi Ron,

Well I guess that's out of the question.

We were thinking about that, but the normal workflow would be:
- Search in the company nexus which lib provides a given package
- Include that in the pom

That would work around the "managed-pom" approach. So users would have to look
at each dependency, if there is a special pom version in the system. I think that's
definitely not going to work.

In this company there are about 200 developers working on 50-60 different projects, that
are assembled to about 20 different products. Currently we'll live with exc

Re: AW: How to manage dependency "includes"?

2016-01-07 Thread Ron Wheeler

If you are using Eclipse with the m2e plug-ins (we use Eclipse/STS which
comes with this), it will tell you what versions are being included as
transitive dependencies.

- Programmers did not have to worry about incorrect or missing dependencies
- Programmers could move to a new project quickly.
- updating a library version updated automatically updated all projects

It took a bit of work once we decided to get organized but it paid off
very quickly in programmer productivity and improved project schedule
stability

Once you have found the source jar for the library and included it in
one of your libraries, it is available for every module.

Ron

On 07/01/2016 9:25 AM, Christofer Dutz wrote:

Hi Ron,

Well I guess that's out of the question.

We were thinking about that, but the normal workflow would be:
- Search in the company nexus which lib provides a given package
- Include that in the pom

That would work around the "managed-pom" approach. So users would have to look
at each dependency, if there is a special pom version in the system. I think that's
definitely not going to work.

In this company there are about 200 developers working on 50-60 different projects, that
are assembled to about 20 different products. Currently we'll live with excluding stuff
and having users add missing dependencies during the unit-, integration- ,
acceptance-test phases, but it would have been easier with some
"exclusions/inclusions" mechanism.

Chris

____________
Von: Ron Wheeler
Gesendet: Montag, 4. Januar 2016 17:19
An: users@maven.apache.org
Betreff: Re: How to manage dependency "includes"?

You can simplify the problem that you are having by making a module that
includes the correct version of the third party modules and having your
modules depend on that with a "provided" scope.
This also makes all of your jars and wars a lot smaller since only one
copy of each API is included in the whole project rather than having the
code appear in every one of your modules that needs it.

This speeds your builds by a lot and save individual developers from
having to think about the "correct" version of each library. They just
include the aggregated libraries that they need. For example Apache
Commons stuff would be supplied by your module
com.example:myapachecommons:1.0-SNAPSHOT with scope provided.

http://blog.artifact-software.com/tech/?tag=maven might be a useful set
of articles.

Ron
On 04/01/2016 3:38 AM, Christofer Dutz wrote:

Hi,

I am currently cleaning up in the dependencies of a quite big set of big
projects. For this I am making a lot of use of dependency management. One thing
I did come across quite a lot of times is this problem:

Some libs reference undesired libs, mostly API libs (in most cases they reference artifacts that
contain parts of some API packages). To prevent them from being used, we exclude them in the
dependencyManagement section. Now the downside is that now the API packages are missing. In order
to fix this, we now have to manually add dependencies to the API modules wherever the artifact is
used. It would be cool, if there was not only an "exclusion" but also an
"inclusion" mechanism in dependencyManagement, so we could actually manage situations
like this.

Is there a better way of resolving this type of problem? Would adding a feature like the
"inclusions" to Maven be a good idea? If not, what are the problems with it? If
yes, what can I do to help get it in (Would be glad to contribute something like this)?

Chris

--
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

--
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: How to manage dependency "includes"?

2016-01-04 Thread Ron Wheeler

http://blog.artifact-software.com/tech/?tag=maven might be a useful set
of articles.

Ron
On 04/01/2016 3:38 AM, Christofer Dutz wrote:

Hi,

Chris

--
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: [MNG-5947] dependency management: imports and lack of nearest-wins

2016-01-02 Thread Ron Wheeler

Perhaps it might help to describe what you did, what you expected to 
happen and what actually happened.


Ron

On 02/01/2016 10:28 AM, Michał Kowalcze wrote:

Hello!

I've played a bit with maven dependency management section and basically
pom import in dependency management section does not support at all
"nearest-wins" strategy for resolving conflicts. The only one supported
option is first match.
I did not found anything in documentation about this behaviour - is it a
feature or a bug?

best regards,

Michał




--
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: Another yearly issue cleanup in JIRA

2016-01-01 Thread Ron Wheeler

You might want to delay your deadline for a few days to allow people who 
have been on holidays to get back to work.


Ron

On 01/01/2016 3:25 PM, Michael Osipov wrote:
Just wanted you to remember that no issue has been updated since my 
last mail. You still have a couple of days to take a look. Monday is 
deadline.


Am 2015-12-25 um 19:00 schrieb Michael Osipov:

Hi folks,

the previous had a bad wording, so I decided to rerun that.

I'd like to do another issue cleanup in JIRA like a did last year.
We currently have 127 unresolved issues which haven't been updated for
more than three years.

They drill down as follows:
Wish: 3
Task: 4
New Feature: 14
Improvement: 34
Bug: 72

Here is the query for: category = Maven AND updated <= -156w AND
resolution = Unresolved ORDER BY updated DESC

I hardly believe that they will be updated or resolved ever. Maybe they
have been resolved with new versions automatically.
Please have a look whether you see some of yours which are still valid
or anything else. Is an issue worth kept alive, add a validity note to
it. If you don't object, I will go ahead and close them
as won't fix. Let me know by 2 January 2016.

@Hervé Is that an acceptable approach for you?

Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-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: How Maven solves the problem of long builds on large projects?

2015-12-21 Thread Ron Wheeler


Ideas:
- Break your project up into modules that build separately. If you have 
a well structured project that is loosely coupled, individual 
issues/bugs will only affect a few modules.

 We have a project with about 80 modules but never build them all at once.
- Build separately deployable modules so that you are building small 
jars and wars that can be individually replaced in your run-time or test 
environments.
- Build modules with 3rd party libraries so that you only have 1 copy of 
each library in your project rather than a copy in each module. The JVM 
can only use 1 copy of Apache commons-xxx; no point deploying 50 copies.
- Make sure that you have a repo "near" your workstation so that 
downloads of maven components and third party libraries are fast. We use 
the community version of Nexus.
- Use a RAMDrive to hold Maven and your compiler and your build 
temporary files. I have dedicated 2 Gb of RAM on my 6 Gb laptop. makes a 
big difference.
 I also have Eclipse/STS on that drive which makes a big difference in 
working with the IDE. If I had more memory,
 I would put my Maven cache in RAM but it currently has 14,799 files 
and takes 1.81GB. I probably should delete it and let Maven rebuild it 
to get rid of old crap(9 versions of junit).

- Use the latest Maven (including plug-ins) and Java.
- Only clean when you need to. Maven does a pretty good job of figuring 
out what needs to be re-compiled.



The first 3 ideas will give the biggest improvement.
If you have the RAM, the RAMDrive is easiest to do since it does not 
require much thinking.


Ron

On 21/12/2015 8:17 AM, Stephen Connolly wrote:

I doubt it is the compilation that sucks up the time. Try running with test
execution skipped to see the time difference, eg `mvn clean install` vs
`mvn clean install -DskipTests`

If you are using `install` then likely there is no need to rebuild
everything each time and you can use the -pl -am and -and cli options to
tune how much of the reactor to rebuild

On Monday 21 December 2015, Sergey Saraev  wrote:


Hello!

I am developing a project with 67 modules.
I use Apache Maven 3.0.4.

Reassembly of the project take 1 hour and 50 minutes although usually
commit change only one module.

The project is very large. It contains 5948 java classes (Basically, time
spent on their compilation.).
Build command: mvn clean install pmd:pmd checkstyle:checkstyle
cobertura:cobertura

Plugins versions:
maven-compiler-plugin:2.3.2
maven-antrun-plugin:1.6 (use wlappc task:
http://docs.oracle.com/cd/E21764_01/web./e13706/splitbuild.htm#WLPRG224
)
maven-surefire-plugin:2.10
maven-jar-plugin:2.3.2
maven-install-plugin:2.3.1
maven-pmd-plugin:2.7.1
maven-checkstyle-plugin:2.6
cobertura-maven-plugin:2.7

How to speed up the assembly?
(Maybe skip modules, which sources have not changed or something else)

Regards,

Sergey Saraev | Research & Development | Office: +7 (846) 270-7800 ext.
2662 | Mobile: +7 (917) 813-5604 | --www.NetCracker.com--
Proven Partner to Communications Service Providers





The information transmitted herein is intended only for the person or
entity to which it is addressed and may contain confidential, proprietary
and/or privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the material
from any computer.






--
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: How to download/package all versions of artifact

2015-11-30 Thread Ron Wheeler

So these are not project dependencies since only 1 version is allowed as 
a dependency and are not on the classpath since only 1 version is used 
there as well.


As I read your description, you want to include a bunch of jars in a 
resource folder that is not on the classpath of the assembled zip.


Since they are immutable, why would you not just download the stuff that 
you want once and put it in the folder and include the folder in the zip?


Ron


On 30/11/2015 3:54 PM, David Hoffer wrote:

I have a use case where I want to include in a subfolder of my assembled
zip all of the versions of a particular artifact (or even better all within
a range of versions).

What's the best way to do this?

-Dave




--
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: Offline builds nearly impossible

2015-11-13 Thread Ron Wheeler


I certainly would defer to your expertise.

Ron

On 13/11/2015 2:33 PM, Jason van Zyl wrote:

In this case they would not be better and far less convenient. For a 
hermetically sealed build at any rate. The local repository cache cleared of 
the tracking files serves as a perfectly fine remote repository for this use 
case. Most escrow bundles carry all the tools and sources required to build the 
product: packaging a repository manager would probably be a bit much.


On Nov 13, 2015, at 2:09 PM, Ron Wheeler  wrote:


Not sure if the extra work would be worthwhile when you have a number of free 
repo packages that are better in many ways than the maven cache and can be 
installed on Windows or Linux.


Ron

On 13/11/2015 12:44 PM, cody.a.fy...@wellsfargo.com wrote:

I just wanted to weigh in.

This indeed does not function in what I would call an "intuitive" way.

It would be really nice if offline mode meant just provide the switch and 
everything used your local repo. No extra configuration or trickery required.

I know in modern times, the idea of always being connected is the norm, but if 
you KNOW you don't need any updates and you have a lot of deps, this could 
speed up the build a bit. Especially if you are forced to use a 3G connection 
for a build on an emergency basis in your job.

Then again, it would also be nice if Santa Claus were real.

When will Apache have their open source Santa project? ;)

Cody Fyler
Lending Grid Build Team
G=Lending Grid Builds
(515) – 441 - 0814

-Original Message-
From: Paul Benedict [mailto:pbened...@apache.org]
Sent: Friday, November 13, 2015 11:27 AM
To: Maven Users List 
Cc: joerg.schai...@gmx.de
Subject: Re: Offline builds nearly impossible

I think most people, at least once in their life, try to use their local 
repository cache as an offline remote repository. However, the two aren't the 
same in concept though, IIRC, the last time I tried. You still need to keep the 
two separate.

Now it would be interesting if a tool existed to copy the contents of a local repository 
and scrub its local metadata. That would then give you a true "remote offline 
repo".


Cheers,
Paul

On Fri, Nov 13, 2015 at 11:17 AM, Jason van Zyl  wrote:


If this does not work please let me know. This is what I’ve used in
the past and if it doesn’t work I agree it needs to be fixed. I
honestly haven’t tried making a hermetically sealed build in a few
years but last year worked on a project that did no network traversal
aside from using file-based repositories and it all worked fine.


On Nov 13, 2015, at 11:33 AM, Jörg Schaible 

wrote:

Hi Jason,

Jason van Zyl wrote:


Use a file based remote repository instead of trying to build in
offline mode.

You can either use a repository manager to create the remote
repository

or

an empty local repository with a full build. As noted though, you
have

to

remove all local repository metadata and files if you create the
repository locally.

Now that you have the repository that contains everything you need
to build create a settings.xml with a mirror pointing to a
file-based repository. You shouldn’t need to build in offline mode
but using a file-base repository in your mirror will effectively be
the same. This

way

you will not be subject to every Maven plugins potentially flaking
handling of offline mode.

Good idea, thanks! And with a mirror setup to file:/// (except for
that file-based remote repo) we can even verify that no offline
access is required.

Cheers,
Jörg



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


Thanks,

Jason

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

To think is easy. To act is hard. But the hardest thing in the world
is to act in accordance with your thinking.

  -- Johann von Goethe













-
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


Thanks,

Jason

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

Re: Offline builds nearly impossible

2015-11-13 Thread Ron Wheeler



Not sure if the extra work would be worthwhile when you have a number of 
free repo packages that are better in many ways than the maven cache and 
can be installed on Windows or Linux.



Ron

On 13/11/2015 12:44 PM, cody.a.fy...@wellsfargo.com wrote:

I just wanted to weigh in.

This indeed does not function in what I would call an "intuitive" way.

It would be really nice if offline mode meant just provide the switch and 
everything used your local repo. No extra configuration or trickery required.

I know in modern times, the idea of always being connected is the norm, but if 
you KNOW you don't need any updates and you have a lot of deps, this could 
speed up the build a bit. Especially if you are forced to use a 3G connection 
for a build on an emergency basis in your job.

Then again, it would also be nice if Santa Claus were real.

When will Apache have their open source Santa project? ;)

Cody Fyler
Lending Grid Build Team
G=Lending Grid Builds
(515) – 441 - 0814

-Original Message-
From: Paul Benedict [mailto:pbened...@apache.org]
Sent: Friday, November 13, 2015 11:27 AM
To: Maven Users List 
Cc: joerg.schai...@gmx.de
Subject: Re: Offline builds nearly impossible

I think most people, at least once in their life, try to use their local 
repository cache as an offline remote repository. However, the two aren't the 
same in concept though, IIRC, the last time I tried. You still need to keep the 
two separate.

Now it would be interesting if a tool existed to copy the contents of a local repository 
and scrub its local metadata. That would then give you a true "remote offline 
repo".


Cheers,
Paul

On Fri, Nov 13, 2015 at 11:17 AM, Jason van Zyl  wrote:


If this does not work please let me know. This is what I’ve used in
the past and if it doesn’t work I agree it needs to be fixed. I
honestly haven’t tried making a hermetically sealed build in a few
years but last year worked on a project that did no network traversal
aside from using file-based repositories and it all worked fine.


On Nov 13, 2015, at 11:33 AM, Jörg Schaible 

wrote:

Hi Jason,

Jason van Zyl wrote:


Use a file based remote repository instead of trying to build in
offline mode.

You can either use a repository manager to create the remote
repository

or

an empty local repository with a full build. As noted though, you
have

to

remove all local repository metadata and files if you create the
repository locally.

Now that you have the repository that contains everything you need
to build create a settings.xml with a mirror pointing to a
file-based repository. You shouldn’t need to build in offline mode
but using a file-base repository in your mirror will effectively be
the same. This

way

you will not be subject to every Maven plugins potentially flaking
handling of offline mode.

Good idea, thanks! And with a mirror setup to file:/// (except for
that file-based remote repo) we can even verify that no offline
access is required.

Cheers,
Jörg



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


Thanks,

Jason

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

To think is easy. To act is hard. But the hardest thing in the world
is to act in accordance with your thinking.

  -- Johann von Goethe













-
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: Convention for shipped artefacts?

2015-11-04 Thread Ron Wheeler


Two options that I know of:
1) Create a module that creates a single jar containing all of the code 
to be shipped.
2) If you want to ship a number of jars, create a Maven project using 
IzPack to create an installer that collects the jars to be shipped and 
builds an installer that will permit them to be deployed easily.


We have done both in different circumstances.

Ron

On 04/11/2015 4:20 AM, James Green wrote:

Open question:

I am looking at a project that consists of two or three dozen small maven
modules. Out of this we ship maybe six artefacts.

Does anyone have experience of managing this? I'm having difficulty
locating those projects that actually result in a shipped artefact. Perhaps
it's structure, perhaps it's naming.

Thanks,

James




--
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: Java 7 and 8 features

2015-10-27 Thread Ron Wheeler



Switched our internal projects to Java 8
Apache OFBiz is permitting Java 8 source code in the main truck.

No thought  in either case to rewrite existing code unless their is a 
bug or enhancement to be done.


Ron
On 27/10/2015 1:26 PM, Maxim Solodovnik wrote:

We are just moved to java7 and start using new features
I personally don't like the idea of moving all code to new java, I move the
areas I currently work on

On Tue, Oct 27, 2015 at 10:57 PM, Gary Gregory 
wrote:


Hi,

What I see, is that most projects are struggling to move to Java 7, Java 8
seems out of range. There are a lot of opinions and both sides of each Java
version for and against. At the end of the day, it's about user feedback
and committer community involvement. The projects I help on also lack
manpower and maintaining more than one version is not I see folks wanting
to do. For myself, I usually want to work on the current version in
master/trunk and move that along. My work$ development is on Java 7 and
slated to switch to Java 8 in 2016 I would guess.

Gary

On Tue, Oct 27, 2015 at 9:37 AM, Oliver B. Fischer <
o.b.fisc...@swe-blog.net> wrote:


Hi Vinicius,

it is mostly to allow people which are bound (for any reason) to older
JDK versions to use our software. There is a plenty number of projects
which are not able to use newer JDK versions. I know that this is a
  controversial topic I think that the majority of us would like to use all
these features. But we must not forget the people using our software in
their daily work.

BYe,

Oliver

Am 27.10.15 um 16:49 schrieb Vinicius Corrêa de Almeida:


I analized some releases and i noticed that not using java 7 features
like
multi catch and in java 8 do not use lambda expressions and others
features, so i came by this email to know why the developers not using
this
features?



--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fisc...@swe-blog.net
S oliver.b.fischer
J oliver.b.fisc...@jabber.org
X http://xing.to/obf




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory







--
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: Maven profiles vs Archetypes

2015-10-19 Thread Ron Wheeler


On 19/10/2015 1:51 PM, Patrick Sansoucy wrote:

Re,

The installer concept *could* fit the bill with some adjustments, it's just
that the build process is tweaked dependending on the target web
server/deployement type.

Wouldn't the installer get rid of the tweaks?
Are there any in the actual software or are they in configuration files 
and library inclusion/exclusion


If it was up to me, I would stop building a jar that included all the 
shared libraries (use scope "provided") and use the installer to add the 
shared libraries at installation time if the system administrator wanted 
them.

- reduces build time
- makes jars really small
- allows more flexibility in presenting the system administrator with 
choices about which libraries are loaded onto the server with your 
software.




This would require changes which I don't have much
weight to throw at.


Benefits should get developers and customer support on your side.

It is sometimes hard to get developers who have no experience in system 
admin to understand the "real world" of deployment.

I am really old so I have done a lot of both.


Has for the multi pom solution, it's actually the thing that the group
which is pushing the profile solution want to avoid, because this would
require them to build multiple archetype based on the wanted target
deployement.

That's the reason I was pushing to build it directly into the archetype,
thus, having the question asked during the archetype invocation. One
archetype could be built to support all the permutations if bonified with
some additionnal questions (target container and deploiement type) aside
version/groups/artifacts ...

Since I went throught profile hell in another life, I want to avoid their
abuse and am just trying to build a solid, documented argument and solution
that would fit the bill while minimizing the overhead cost. It's a knowned
fact from the community to avoid abusing profiles, there is just not a lot
of 'official documentation' to ggo with it.

Patrick Sansoucy
In theory, there is no difference between theory and practice, but in
practice, there is ...

On Mon, Oct 19, 2015 at 1:12 PM, Ben Podgursky  wrote:


What if your profiles lived in a couple of parent POMs, and the child POMs
inherited from the appropriate parent POMs?  We use this setup for many of
our projects.  It avoids child POM bloat and lets us update the shared
logic without pushing changes to every project.

Only limitation is that maven has no multi-inheritance / mixins so you have
to be careful setting up inheritance trees.

On Mon, Oct 19, 2015 at 9:58 AM, Benson Margulies 
wrote:


If each project picks a style and sticks to it, then archetypes are
appropriate.

On Mon, Oct 19, 2015 at 11:26 AM, Patrick Sansoucy
 wrote:

Re,

Basically, the end result would be to support multiple teams with

multiple

web application servers and setup (shared libs vs non shared libs).

Thus

each internal team does not go back and forth between setups/server.

For

a

vast majority of cases, the decision is done once, at the start of the
project, and you live with it.

As for the question, like I said previously, the release drives a

single

artifact 'type', not a portfolio. The profile idea is basically used

only

to support the initial branching for the teams.

Never thought about the Invoker plugin that way. I had suggested of

using

it to test the templating of the archetypes themselves, but not more.

Since

using profiles means that you have to execute the build itself to

validate,

while using the archetype, you test the structure and content of the
created project, which I find easier.



Patrick Sansoucy
In theory, there is no difference between theory and practice, but in
practice, there is ...

On Mon, Oct 19, 2015 at 11:07 AM, Benson Margulies <

bimargul...@gmail.com>

wrote:


Once you've run an archetype, you have a new project. And you're stuck
with it, in the sense that you have to keep it maintained.

An important question is this: what artifacts do you want to make as
part of a release? If you want a portfolio of artifacts, each for one
of your scenarios, then profiles aren't very useful, but the invoker
plugin might be.

On the other hand, if you never make releases, and you just want to
run various build with various results, then profiles can be
convenient.

The invoker is generally used for testing, and I've never tried it as
a solution to DRY-ing up a build that has to produce multiple small
variations.

-
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
Presid

Re: Maven profiles vs Archetypes

2015-10-19 Thread Ron Wheeler

Sounds like my installer idea will solve your problem and be much easier 
to maintain.
Develop the code in a set of projects that don't care about deployment 
and have one or more projects that know about installation requirements 
and build one or more installers that deal with all of the configuration 
files and directory structures required to support all of the delivery 
platforms that you need to support.


- developers do not have to worry about any run-time other than the one 
used for testing.
- new run-time platforms can be supported without screwing with the 
software build processes.
- experts in the supported platforms can play with the Maven installer 
projects without disrupting the developers.
- the final deliverables will be easier to understand and deploy since 
each installer package supports exactly what it is supposed to and does 
not require any detailed knowledge about the structure of the 
application to install it. (The system adnmin can select the right OS, 
select the library configuration, the container, etc. and the installer 
will assemble the right components and install them in the environment.)
- the installer project is easy to set up and once it is done, it is as 
stable as the configuration files are.


Ron


On 19/10/2015 11:26 AM, Patrick Sansoucy wrote:

Re,

Basically, the end result would be to support multiple teams with multiple
web application servers and setup (shared libs vs non shared libs). Thus
each internal team does not go back and forth between setups/server. For a
vast majority of cases, the decision is done once, at the start of the
project, and you live with it.

As for the question, like I said previously, the release drives a single
artifact 'type', not a portfolio. The profile idea is basically used only
to support the initial branching for the teams.

Never thought about the Invoker plugin that way. I had suggested of using
it to test the templating of the archetypes themselves, but not more. Since
using profiles means that you have to execute the build itself to validate,
while using the archetype, you test the structure and content of the
created project, which I find easier.



Patrick Sansoucy
In theory, there is no difference between theory and practice, but in
practice, there is ...

On Mon, Oct 19, 2015 at 11:07 AM, Benson Margulies 
wrote:


Once you've run an archetype, you have a new project. And you're stuck
with it, in the sense that you have to keep it maintained.

An important question is this: what artifacts do you want to make as
part of a release? If you want a portfolio of artifacts, each for one
of your scenarios, then profiles aren't very useful, but the invoker
plugin might be.

On the other hand, if you never make releases, and you just want to
run various build with various results, then profiles can be
convenient.

The invoker is generally used for testing, and I've never tried it as
a solution to DRY-ing up a build that has to produce multiple small
variations.

-
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: Maven profiles vs Archetypes

2015-10-19 Thread Ron Wheeler


Maven is a great tool but it is not designed to build installation packages.

Would your problem be better solved using one or more installer 
generation projects (in Maven) that gather and package the final set of 
files that are to be used to deploy the app to the run-time environments?


I use IzPack for this.
It has a Maven plug-in that uses dependency management to grab the right 
software from my repos but allows me to specify what I want to deploy to 
the various run-time environments.
If you need to support different OS's or different containers, this 
might be easier than trying to create a bunch of build projects 
controlled with profiles.


Not sure from your description if this is the problem that you are 
trying to solve but it is a recurring theme here.


Ron


On 19/10/2015 11:07 AM, Benson Margulies wrote:

Once you've run an archetype, you have a new project. And you're stuck
with it, in the sense that you have to keep it maintained.

An important question is this: what artifacts do you want to make as
part of a release? If you want a portfolio of artifacts, each for one
of your scenarios, then profiles aren't very useful, but the invoker
plugin might be.

On the other hand, if you never make releases, and you just want to
run various build with various results, then profiles can be
convenient.

The invoker is generally used for testing, and I've never tried it as
a solution to DRY-ing up a build that has to produce multiple small
variations.

-
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: Setting Up Internal Repositories

2015-10-16 Thread Ron Wheeler

Hard to say but checking the checksums from the author's site would be 
one way to vet a release from a third party.
Opening the download and looking inside to see that the artifacts are 
the ones that you were expecting is less secure but could be part of 
vetting.


Ron

On 16/10/2015 12:33 PM, michael.ctr.taru...@faa.gov wrote:

The Maven Introduction to Repositories documentation contains a section that 
describes setting up an internal repository.

In that section is described an option to manually download and vet releases, 
apparently of a remote repo.

What is meant by "vet"?  Can you provide an example of how a repo release would 
be vetted?  I suspect this is highly dependent on the intended use of the repo, but I'm 
just trying to get a general idea of what is involved.

Thank you.

Mike

Michael Tarullo
Contractor (Engility Corp)
Enterprise Architect
NSRR System Administrator
FAA WJH Technical Center
(609)485-5294





--
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: deploy with maven-ant-task

2015-10-16 Thread Ron Wheeler


Sounds like an archiva issue rather than Maven

I don't know archiva but the message seems to say that you can not 
deploy SNAPSHOTs to the repo.


Ron

On 16/10/2015 4:03 AM, m...@mherrn.de wrote:

Hi,

I am preparing an application that is built with ant to be deployed to a
maven repository to be used in applications that are built with maven.

We use apache archiva as repository.

These are the snippets from the build.xml:

/
   
 
   
   
   
   
   
   
 
   

   
 
   
   
   
   http://localhost:5501/repository/internal"/>
   
   
 
   
/

This is the content of the ~/.m2/settings.xml:

/

   
 
   archiva.default
   http://localhost:5501/repository/internal/
   external:*
 
   

   
 
   archiva.default
   admin
   verysecret
 
   


/

And this is the output when calling the ant task "mvn-deploy":

/
$ ant mvn-deploy
Buildfile: /somewhere/build.xml

mvn-deploy:
[artifact:mvn] [INFO] Scanning for projects...
[artifact:mvn] [INFO] Searching repository for plugin with prefix: 'deploy'.
[artifact:mvn] [INFO]

[artifact:mvn] [INFO] Building Maven Default Project
[artifact:mvn] [INFO]task-segment: [deploy:deploy-file]
(aggregator-style)
[artifact:mvn] [INFO]

[artifact:mvn] [INFO] [deploy:deploy-file]
[artifact:mvn] [INFO] Retrieving previous build number from archiva.default
[artifact:mvn] Uploading:
http://localhost:5501/repository/internal/myGroupId/myArtifact/1.0-SNAPSHOT/myArtifact-1.0-20151016.074824-3.jar
[artifact:mvn] 91K uploaded
[artifact:mvn] [INFO] Retrieving previous metadata from archiva.default
[artifact:mvn] [INFO] Uploading repository metadata for: 'artifact
myGroupId:myArtifact'
[artifact:mvn] [INFO] Retrieving previous metadata from archiva.default
[artifact:mvn] [INFO] Uploading repository metadata for: 'snapshot
myGroupId:myArtifact:1.0-SNAPSHOT'
[artifact:mvn] [INFO] Uploading project information for myArtifact
1.0-20151016.074824-3
[artifact:mvn] [INFO]

[artifact:mvn] [INFO] BUILD SUCCESSFUL
[artifact:mvn] [INFO]

[artifact:mvn] [INFO] Total time: 1 second
[artifact:mvn] [INFO] Finished at: Fri Oct 16 09:48:24 CEST 2015
[artifact:mvn] [INFO] Final Memory: 17M/457M
[artifact:mvn] [INFO]


BUILD SUCCESSFUL
Total time: 2 seconds
/

It seems to have worked well. But the artifact cannot be found in the
repo. When building the maven application that depends on myArtifact I
get:

/
Missing:
--
1) myGroupId:myArtifact:jar:1.0-SNAPSHOT
[...]
1 required artifact is missing.

for artifact:
   myGroupId:MyMavenArtifact:jar:1.0-SNAPSHOT

from the specified remote repositories:
   archiva.default (http://localhost:5501/repository/internal/)
/

Also when browing the repository I get this error message in Apache
Archiva: "managed repo is configured for release only"

The "mvn-install" target works as expected.


I do not understand what is the problem here. Any help is appreciated.


Regards
Marco


-
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: Cannot seem to install Maven on Windows 7 64-bit

2015-10-15 Thread Ron Wheeler

I think that we have been using Maven since 2007-2008 and it has not 
caused a problem but I was wondering if we had just been lucky.
We almost always use it from inside Eclipse/STS so that adds a layer of 
protection (or obscurity).
In the Eclipse preferences, we do override the Eclipse built-in Maven 
installation location  with the location of the one (latest) that we 
download and install separately.


From your comment, it could be that Eclipse overrides the Widows 
definition of MAVEN_HOME with its Maven settings.


Thanks for the clarification.
Still learning something new every day!

Ron

On 15/10/2015 5:13 PM, e...@zusammenkunft.net wrote:

Hello Ron,

As far as I understand it maven uses MAVEN_HOME internally. However it will 
deduce and then overwrite the value based on the scripts execution path. So it 
can be pretty confusing when the PATH finds one version and you MAVEN_HOME 
points to another. If both agree, then there is no problem to use it (although  
its not documented to be a possible external config).

(Having said that, I am not sure if things changed since .mvn/  was added to 
the mix. I do think maven-invoker is overwriting it, so at least child mavens 
are robust against a (wrong) HOME).

Gruss
Bernd




--
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: Cannot seem to install Maven on Windows 7 64-bit

2015-10-15 Thread Ron Wheeler


I have always used MAVEN_HOME and added it to the path.
When I switch Maven versions it is easier to find the Environment 
variable rather than looking through several hundred characters in PATH.

Same for all of the other software.
Makes PATH a lot shorter and easier to read.

Any reason why you recommend against this?
Would another name be be better?

Ron

On 15/10/2015 3:50 PM, Karl Heinz Marbaise wrote:

Hi,

first dont use "maven --version" as command cause maven will be called 
by: "mvn --version" instead...


Furthermore you should not use MAVEN_HOME environment variable...only 
add the bin folder of the distribution (apache-maven-3.3.3/bin) to the 
PATH of your windows system


Don't forget to close and reopen the console...and then check it...


Kind regards
Karl Heinz Marbaise
On 10/15/15 9:45 PM, Cai Black wrote:
[RESOLVED] OK, so, apparently this is an issue with Maven 3.3.3, and 
when I downgraded to Maven 3.2.5, everything worked as expected.


Christopher (Cai) Black
Mgr. Software Development

RigNet
1880 S. Dairy Ashford, Suite 300 | Houston, TX  77077- 4760 | USA
Tel: +1.281.674.0717 | Mobile: +1.832.439.8134 | Fax: +1.281.674.0101
Email: christopher.bl...@rig.net<mailto:christopher.bl...@rig.net>
www.rig.net<http://www.rig.net/>

From: Cai Black
Sent: Thursday, 15 October 2015 14:22
To: 'users@maven.apache.org'
Subject: Cannot seem to install Maven on Windows 7 64-bit

Hi, all.

I did the following:

* installed jdk-8u60-windows-x64

"java -version" output:
C:\>java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

* extracted the ZIP into C:\maven
* added the following environment variable: MAVEN_HOME = C:\maven
* appended the following to the PATH: %MAVEN_HOME%\bin

"maven -version" outputs the same thing as "java -help" instead of 
the expected "Apache Maven 3." stuff.


Any thoughts here?

Christopher (Cai) Black
Mgr. Software Development

RigNet
1880 S. Dairy Ashford, Suite 300 | Houston, TX  77077- 4760 | USA
Tel: +1.281.674.0717 | Mobile: +1.832.439.8134 | Fax: +1.281.674.0101
Email: christopher.bl...@rig.net<mailto:christopher.bl...@rig.net>
www.rig.net<http://www.rig.net/>




*** Important Notice *
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended 
recipient of
this e-mail, do not duplicate or redistribute it by any means. Please 
delete it
and any attachments and notify the sender that you have received it 
in error.

Unintended recipients are prohibited from taking action on the basis of
information in this e-mail.

E-mail messages may contain computer viruses or other defects, may 
not be
accurately replicated on other systems, or may be intercepted, 
deleted or
interfered with without the knowledge of the sender or the intended 
recipient.
If you are not comfortable with the risks associated with e-mail 
messages, you

may decide not to use e-mail to communicate with RigNet.

RigNet reserves the right, to the extent and under circumstances 
permitted by
applicable law, to retain, monitor and intercept e-mail messages to 
and from

its systems.




-
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: Best way to lock in .jar versions between releases.

2015-10-13 Thread Ron Wheeler


On 13/10/2015 2:08 PM, Kevin Burton wrote:

I want to lock in the effective classpath for our releases.

So if extra .jars or versions of .jars are changed, I want the build to
fail until I manually approve it.

For some reason, our version of cassandra regressed and broke on release.

Still trying to track this down but in the future it would be nice to just
flat out prevent this from happening.

Thoughts?


How are you doing your builds?
Is there a difference in your snapshot policy and release policy?

How are you controlling versions - parent POM dependency management?

How many people can deploy to your release repo? Snapshot repo?
If you are the only one, then no one else can trigger a release.
What Maven repo are you using?

Sorry for the questions but the answers might prompt some of the smarter 
people to suggest good solutions.


Ron



--
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: publishing sub-modules without requiring the parent module to be published?

2015-10-12 Thread Ron Wheeler

You are probably going to want to make your open source project 
completely separate with its own versions and parent.


If third parties are actually going to file issues,  provide updates and 
create new minor versions as they fix bugs, you are going to either be 
forced to release versions of your private project before you are ready 
or have to fork your own open source project to maintain a consistent 
version between the 2 parts of your product.


Having a successful open source project requires a new way of thinking 
about your baby.


Ron


On 12/10/2015 2:49 AM, Baptiste Mathus wrote:

I'm pretty sure you can't. At least on Central who IIRC checks that kind of
things.
It's indeed needed for the dependency resolution mechanism to work.
Cheers
Le 11 oct. 2015 11:50 PM, "Kevin Burton"  a écrit :


I'm trying to open source a bunch of code in our stack.

Is it possible to have a parent module private, and the child module
public?

The problem I have now is that if our customers or the open source
community imports our modules, it needs to fetch the parent, which is
private.

I assume this is required due to maven inheritance because it needs to
determine dependencies.

I can just not specify a  but that causes other problems like the
maven versions problem skipping it for some reason (though maybe this is a
bug).



--

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
<https://plus.google.com/102718274791889610666/posts>




--
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: Best strategy for using lots of modules/projects with some private and some OSS

2015-09-22 Thread Ron Wheeler

+1 (probably better and more complete than my description)

Has anyone else looked at using an installer like izPack for assembling
test setups?
It integrates with Maven and will pick up all the right versions of jars
and configuration files and build an installer that will drop the whole
set where ever you want to test.
You can build an installer that will install on different OSs so you can
take the same test jar and run it on Windows, Linux or a Mac and get the
"right" configuration files for the target OS.

Uses maven dependency management to get the jars from your repo and uses
a command language in XML to assemble the rest of your supporting data
and configuration files.

A bit smarter than Ant about building application run-time structures
but that is all it does.

Ron

On 22/09/2015 3:43 PM, Curtis Rueden wrote:

Hi Kevin,

My projects opt for independent versioning of modules to facilitate
"release early, release often." To do this for large sets of components
like yours requires a Bill of Materials -- i.e., common parent POM with
dependencyManagement section.

FWIW, the docs we have about our projects that work this way are at:
* http://imagej.net/Architecture

And in particular:
* http://imagej.net/Architecture#Bill_of_Materials
* http://imagej.net/Architecture#How_SciJava_achieves_reproducible_builds
* http://imagej.net/Philosophy#Release_early.2C_release_often

And the BOM stuff is at:
*
https://github.com/scijava/pom-scijava/blob/pom-scijava-8.3.0/pom.xml#L103-L819

The downside, as you point out, of all components being release version
coupled is that it is annoying to have to do a "release cascade" to
propagate a bug fix from the lowest level components to the highest level
ones. We have some tooling to make that easier (I personally live in the
"releases should be as easy/automated/fast as possible" camp), but the
modularity does cost time sometimes. Hopefully a lot less time than
building your huge multi-module project from scratch every time, though!

I also recently wrote a "melting pot" script to do end-to-end testing of
large component collections:

https://github.com/scijava/scijava-scripts/blob/d892adc0092c220ee1e597b9fb5a1fb067e4509b/melting-pot.sh

This script builds and runs unit tests for all components of a large
collection at their respective versions, all in the same Java runtime, to
ensure that everything _really does_ work together at the versions you are
currently deploying to end users.

I would be happy to know about other tooling people have created to help
with this sort of project structure.

Regards,
Curtis

On Tue, Sep 22, 2015 at 12:47 PM, Kevin Burton wrote:

We have a multi-module setup whereby we have about 150 independent modules.

Our build takes a long time and actually slows down development as we have
to do a compile of a LOT of source code to rebuild the project.

Additionally, we have a lot of code that we want to Open Source.

This has meant git submodules the IMO git submodules really don’t work when
using branches. They break and require a whole bunch of custom works and
hack and when they DO break it’s confusing how to resolve them.

This has meant that we’ve not really done a good job of OSSing our code
base as its just too hard.

What we’ve done to date is just have one major version number across all
our projects. So upgrading them and fixing their dependencies means that I
just have to change a version number everywhere and I’m done.

What I was thinking of is changing this strategy to use the maven
"versions:use-latest-versions” plugin.

What i would do is have a parent directory named ‘spinn3r’ which just has a
bunch of git submodules. We NEVER branch in this directory.

It also means that any of our developers can check it out so that they have
all of our source code.

At this point I can use a normal development strategy for each project.
They don’t use submodules which enables us to branch/merge easily.

I can also have a dedicated IntelliJ or Eclipse project for each one and
switch between them.

Now the main issue I have is how do I bump releases easily and make sure
all my code is using the latest version of its sibling projects.

In the parent directory I can just run versions:use-latest-versions … on
each one of the projects so that it automatically pulled in the latest
version after a release.

The only problem here is that there’s a dependency graph that needs to be
considered.

for example, if project A depends on project B, then we have to bump the
version and push project B into maven before we upgrade dependencies on
project A.

This is a frustrating issue…

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
<https://plus.google.com/102718274791889610666/posts>

--
Ron Wheeler
President
Arti

Re: Best strategy for using lots of modules/projects with some private and some OSS

2015-09-22 Thread Ron Wheeler


I turned off the block.

Ron
On 22/09/2015 3:40 PM, Kevin Burton wrote:

Weird. Looks like the blog.artifact-software.com isn’t responding to DNS .
At least on our network..

On Tue, Sep 22, 2015 at 11:29 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


You have clearly given this a lot of thought and your project is just a
bit less than twice as large as ours so I am not sure about giving advice.

http://blog.artifact-software.com/tech/?p=84 is an article that I wrote a
few years ago dealing with our approach to the same problem.

Our solution to the version management problem may not be to your tastes
but it did save us a lot of grief and served us well once we got through
the first few releases where we were touching every piece of source code on
each release.

We essentially started treating our own code as if it was OSS.
This made us think about modularity and functional separation into
projects and changed our ideas about versions.

Ron



On 22/09/2015 1:47 PM, Kevin Burton wrote:


We have a multi-module setup whereby we have about 150 independent
modules.

Our build takes a long time and actually slows down development as we have
to do a compile of a LOT of source code to rebuild the project.

Additionally, we have a lot of code that we want to Open Source.

This has meant git submodules the IMO git submodules really don’t work
when
using branches.  They break and require a whole bunch of custom works and
hack and when they DO break it’s confusing how to resolve them.

This has meant that we’ve not really done a good job of OSSing our code
base as its just too hard.

What we’ve done to date is just have one major version number across all
our projects.  So upgrading them and fixing their dependencies means that
I
just have to change a version number everywhere and I’m done.

What I was thinking of is changing this strategy to use the maven
"versions:use-latest-versions” plugin.

What i would do is have a parent directory named ‘spinn3r’ which just has
a
bunch of git submodules.  We NEVER branch in this directory.

It also means that any of our developers can check it out so that they
have
all of our source code.

At this point I can use a normal development strategy for each project.
They don’t use submodules which enables us to branch/merge easily.

I can also have a dedicated IntelliJ or Eclipse project for each one and
switch between them.

Now the main issue I have is how do I bump releases easily and make sure
all my code is using the latest version of its sibling projects.

In the parent directory I can just run versions:use-latest-versions … on
each one of the projects so that it automatically pulled in the latest
version after a release.

The only problem here is that there’s a dependency graph that needs to be
considered.

for example, if project A depends on project B, then we have to bump the
version and push project B into maven before we upgrade dependencies on
project A.

This is a frustrating issue…



--
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







--
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: Best strategy for using lots of modules/projects with some private and some OSS

2015-09-22 Thread Ron Wheeler

Thanks for pointing that out. I am getting lots of e-mail but perhaps 
not all.
I have some SPAM sites blocked at the firewall for all ports and I may 
have shut out some innocent people.


I was pretty crude in my targeting. Whole /24 nets got blocked.

What is the IP that your browser would be showing?

Perhaps I should accept some SPAM and live with it!

Someone has a system that hijacks various servers to do their mailings. 
I shut down one IP block and a few hours later they start to arrive again.
They come in batches of 4 to me so they are easy to spot even if the 
sender and the subject are slightly different.
I can not imagine who is paying for these because they are getting 
scammed with duplicates to the same address.



Ron

On 22/09/2015 3:40 PM, Kevin Burton wrote:

Weird. Looks like the blog.artifact-software.com isn’t responding to DNS .
At least on our network..

On Tue, Sep 22, 2015 at 11:29 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


You have clearly given this a lot of thought and your project is just a
bit less than twice as large as ours so I am not sure about giving advice.

http://blog.artifact-software.com/tech/?p=84 is an article that I wrote a
few years ago dealing with our approach to the same problem.

Our solution to the version management problem may not be to your tastes
but it did save us a lot of grief and served us well once we got through
the first few releases where we were touching every piece of source code on
each release.

We essentially started treating our own code as if it was OSS.
This made us think about modularity and functional separation into
projects and changed our ideas about versions.

Ron



On 22/09/2015 1:47 PM, Kevin Burton wrote:


We have a multi-module setup whereby we have about 150 independent
modules.

Our build takes a long time and actually slows down development as we have
to do a compile of a LOT of source code to rebuild the project.

Additionally, we have a lot of code that we want to Open Source.

This has meant git submodules the IMO git submodules really don’t work
when
using branches.  They break and require a whole bunch of custom works and
hack and when they DO break it’s confusing how to resolve them.

This has meant that we’ve not really done a good job of OSSing our code
base as its just too hard.

What we’ve done to date is just have one major version number across all
our projects.  So upgrading them and fixing their dependencies means that
I
just have to change a version number everywhere and I’m done.

What I was thinking of is changing this strategy to use the maven
"versions:use-latest-versions” plugin.

What i would do is have a parent directory named ‘spinn3r’ which just has
a
bunch of git submodules.  We NEVER branch in this directory.

It also means that any of our developers can check it out so that they
have
all of our source code.

At this point I can use a normal development strategy for each project.
They don’t use submodules which enables us to branch/merge easily.

I can also have a dedicated IntelliJ or Eclipse project for each one and
switch between them.

Now the main issue I have is how do I bump releases easily and make sure
all my code is using the latest version of its sibling projects.

In the parent directory I can just run versions:use-latest-versions … on
each one of the projects so that it automatically pulled in the latest
version after a release.

The only problem here is that there’s a dependency graph that needs to be
considered.

for example, if project A depends on project B, then we have to bump the
version and push project B into maven before we upgrade dependencies on
project A.

This is a frustrating issue…



--
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







--
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: Best strategy for using lots of modules/projects with some private and some OSS

2015-09-22 Thread Ron Wheeler

You have clearly given this a lot of thought and your project is just a 
bit less than twice as large as ours so I am not sure about giving advice.


http://blog.artifact-software.com/tech/?p=84 is an article that I wrote 
a few years ago dealing with our approach to the same problem.


Our solution to the version management problem may not be to your tastes 
but it did save us a lot of grief and served us well once we got through 
the first few releases where we were touching every piece of source code 
on each release.


We essentially started treating our own code as if it was OSS.
This made us think about modularity and functional separation into 
projects and changed our ideas about versions.


Ron


On 22/09/2015 1:47 PM, Kevin Burton wrote:

We have a multi-module setup whereby we have about 150 independent modules.

Our build takes a long time and actually slows down development as we have
to do a compile of a LOT of source code to rebuild the project.

Additionally, we have a lot of code that we want to Open Source.

This has meant git submodules the IMO git submodules really don’t work when
using branches.  They break and require a whole bunch of custom works and
hack and when they DO break it’s confusing how to resolve them.

This has meant that we’ve not really done a good job of OSSing our code
base as its just too hard.

What we’ve done to date is just have one major version number across all
our projects.  So upgrading them and fixing their dependencies means that I
just have to change a version number everywhere and I’m done.

What I was thinking of is changing this strategy to use the maven
"versions:use-latest-versions” plugin.

What i would do is have a parent directory named ‘spinn3r’ which just has a
bunch of git submodules.  We NEVER branch in this directory.

It also means that any of our developers can check it out so that they have
all of our source code.

At this point I can use a normal development strategy for each project.
They don’t use submodules which enables us to branch/merge easily.

I can also have a dedicated IntelliJ or Eclipse project for each one and
switch between them.

Now the main issue I have is how do I bump releases easily and make sure
all my code is using the latest version of its sibling projects.

In the parent directory I can just run versions:use-latest-versions … on
each one of the projects so that it automatically pulled in the latest
version after a release.

The only problem here is that there’s a dependency graph that needs to be
considered.

for example, if project A depends on project B, then we have to bump the
version and push project B into maven before we upgrade dependencies on
project A.

This is a frustrating issue…




--
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: Reactor projects and ${project.version}

2015-09-16 Thread Ron Wheeler

Why not make three new separate projects that produce the required war 
files.
Only put the minimum configuration in the new projects and let them 
depend on jars that contain the shared code and resources.


Maven prefers to produce 1 artifact per project.


On 16/09/2015 2:29 AM, Neeraj Malik wrote:

Dear All,

I am using maven 3.2.5

i want to use difference property files to build war for diff environments
and deploy it on local, test and prod accordingly based on maven command -
mvn -Plocal clean install


/resources/local/env.properties
/resources/test/env.properties
/resources/prod/env.properties

local env property file -
weblogic.splitDevelopmentDirectoryMode = false
weblogic.targetName = AdminServer
weblogic.protocal = http
weblogic.url = localhost
weblogic.port = 7001
weblogic.user = user
weblogic.password = pass123
weblogic.upload = false
weblogic.remote = false
weblogic.verbose = false
weblogic.debug = false
weblogic.noExit = true
project.build.directory =


Can you please suggest whats wrong with given POM.

Thanks.

Regards
Neeraj


http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
 4.0.0
 com.purchase
 Invoice
 1.0
 war


 

local
 
false
 

 
 

${project.basedir}/src/main/resources
 
 

 
 

${project.basedir}/src/test/resources
 
 

  

 
 com.oracle.weblogic
 weblogic-maven-plugin
 10.3.4

 
 install
 
 deploy
 
 
 
 

  

   


 

 
 weblogic-path
 weblogic-path
 system
 ${WL_HOME}/server/lib/weblogic.jar
 10.3.5
 

 
 log4j
 log4j
 1.2.15
 

 

 
 
 
 src/main/resources
 
 **/*.java
 
 
 
 src/main/webapp
 
 **/*.java
 
 
 

 
 
 maven-compiler-plugin
 3.1
 
 1.6
 1.6
 
 
 
 maven-war-plugin
 2.4
 
 false
 
 

 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 
 
 com.sun
 tools
 1.6
 system

${java.home}/../lib/tools.jar
 
 
  1.7
 


 
 com.maven.plugins
 weblogic-10.3.3.0-maven-plugin
 2.9.1.2

 

${weblogic.splitDevelopmentDirectoryMode}


 ${weblogic.targetName}

${weblogic.protocal}

${weblogic.url}

 ${weblogic.port}
 ${weblogic.user}
 ${weblogic.password}

 ${weblogic.upload}
 ${weblogic.remote}

 false
 false
 true

${project.build.directory}/InvoiceBAS-${version}


 

     
 








--
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: maven jar versus ant jar

2015-09-02 Thread Ron Wheeler

Putting "provided" scope on a dependency tells Maven that you need the 
dependency at compile time but do not need it in the jar since you are 
going to provide the dependency on the classpath yourself.


Very common when you are building a webapp and you have a bunch of jars 
already loaded into the servlet container (tomcat for example) and you 
don't need it in every webapp war file as well.


Ron

On 01/09/2015 5:41 PM, Magnanao, Hector wrote:

I found out why my maven jar is much bigger. It looks like it's including a 
dependency jar inside the SNAPSHOT jar.  I installed this jar locally so I can 
compile but now it's being included in the build itself.  So how do I exclude 
it when I do a mvn package ?

-Original Message-
From: Tobias Hochgürtel [mailto:tobias.hochguer...@googlemail.com]
Sent: Tuesday, September 01, 2015 3:35 PM
To: Maven Users List
Subject: Re: maven jar versus ant jar

You can unpack the jar files to see what they include. This should help
you to find out what they makes fat or slimmer as the other one.

HTH
Tobias

Am 01.09.2015 um 22:29 schrieb Magnanao, Hector:

I was finally able to build my snapshot jar using maven after going thru all 
the missing dependencies.  But what I noticed is that the maven jar is much 
larger than my ant jar.  Can anybody tell me why this is so ?  Should they be 
different in sizes after  converting the build to maven ? what should I be 
looking for causes of differences  ?

Hector Magnanao Jr.
SCM Analyst

Fieldglass, Inc.
O: (331) 702-6142
M: (773) 474-3051
hector.magna...@sap.com
www.fieldglass.com

Fieldglass is now part of SAP

This email contains confidential information.  If you are not the intended 
recipient, do not read, distribute or reproduce this transmission (including 
any attachments). If you have received this email in error, please notify the 
sender by email reply.





--
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: need jar location

2015-08-31 Thread Ron Wheeler


I could not find anything going back to version 3.2.

Did you find early versions?

Ron
On 31/08/2015 6:39 PM, Gail Stewart wrote:

Hector

According to this page
http://www.aspose.com/blogs/aspose-products/aspose-total-product-family/archive/2014/08/12/aspose-for-maven-aspose-cloud-maven-repository.html

The maven repository is
://maven.aspose.com/artifactory/webapp/home.html
<http://maven.aspose.com/artifactory/webapp/home.html>

Gail

On Mon, Aug 31, 2015 at 6:00 PM, Magnanao, Hector 
wrote:


Can anyone point me to a repository where I can find this jar dependency
?  aspose.pdf-3.2.jdk16

Hector Magnanao Jr.
SCM Analyst

Fieldglass, Inc.
O: (331) 702-6142
M: (773) 474-3051
hector.magna...@sap.com
www.fieldglass.com

Fieldglass is now part of SAP

This email contains confidential information.  If you are not the intended
recipient, do not read, distribute or reproduce this transmission
(including any attachments). If you have received this email in error,
please notify the sender by email reply.





--
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: need jar location

2015-08-31 Thread Ron Wheeler


You might try asking here:

http://aspose156.rssing.com/browser.php?indx=8646541&item=268

It does seem  to be an old version and the post identifies a problem 
with the upward compatibility.


You may have to find the source and build your own jar.

Ron

On 31/08/2015 6:00 PM, Magnanao, Hector wrote:

Can anyone point me to a repository where I can find this jar dependency  ?  
aspose.pdf-3.2.jdk16

Hector Magnanao Jr.
SCM Analyst

Fieldglass, Inc.
O: (331) 702-6142
M: (773) 474-3051
hector.magna...@sap.com
www.fieldglass.com

Fieldglass is now part of SAP

This email contains confidential information.  If you are not the intended 
recipient, do not read, distribute or reproduce this transmission (including 
any attachments). If you have received this email in error, please notify the 
sender by email reply.





--
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: how can i upload version 1.1.0.1 of tomcat-jdbc

2015-08-25 Thread Ron Wheeler


It appears that it was never released.
You may want to try the current version of tomcat.s pool or build the 
jar from sources and put it in your local repo as a third-party jar.


You might ask this question in the tomcat forum and get their 
recommendation for this.


It appears that this is not a Maven problem.


Ron

On 25/08/2015 10:40 AM, Magnanao, Hector wrote:

I don't see version 1.1.0.1 in that link that you sent me.

-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Monday, August 24, 2015 11:18 PM
To: Maven Users List
Subject: Re: how can i upload version 1.1.0.1 of tomcat-jdbc

Try this one:
http://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-jdbc/

HTH
Olivier

On 25 August 2015 at 03:18, Magnanao, Hector 
wrote:


I need to compile with 1.1.0.1.  whenever I try to compile with this
version,  it says the
[WARNING] The POM for org.apache.tomcat:tomcat-jdbc:jar:1.1.0.1 is
missing, no dependency information available

Is there another url or group that I can grab this version from ? Or do I
need download this locally ?

Hector Magnanao Jr.
SCM Analyst

Fieldglass, Inc.
O: (331) 702-6142
M: (773) 474-3051
hector.magna...@sap.com
www.fieldglass.com

Fieldglass is now part of SAP

This email contains confidential information.  If you are not the intended
recipient, do not read, distribute or reproduce this transmission
(including any attachments). If you have received this email in error,
please notify the sender by email reply.







--
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: Dependency Best Practices

2015-08-21 Thread Ron Wheeler


It is hard to understand your example.
Can you define "child" and "grandchild" and clarify where the 
dependencies are coming from (Third parties? Other children?)


In general, you use the parent to define properties and define the exact 
versions of dependencies in a dependency management section.

Children define the dependencies that they require but not the versions.

What is the choice that you are trying to make that you think needs to 
follow a "best practice"?
You might want to mention what kind of application you are building 
(language, type of app, target platform).


Ron

On 21/08/2015 5:37 AM, aalok singhvi wrote:

Hello,

Any best practices on how to arrange dependency in multi module maven
project.

Let me give an example

Parent Project
   Child1
   GrandChild1 ( Depedency1, Dependency2, Dependency3)
   GrandChild2 ( Depedency1, Dependency2, Dependency, 4)
   GrandChild3  (Depedency1, Dependency2, Dependency, 5)
   GrandChild4
 (Depedency1, Dependency2, Dependency3, Dependency4, Dependency,
5)
   Child2
   GrandChild1 ( Depedency1, Dependency2, Dependency3)
   GrandChild2 ( Depedency1, Dependency2, Dependency, 4)
   GrandChild3  (Depedency1, Dependency2, Dependency, 5)
   GrandChild4
 (Depedency1, Dependency2, Dependency3, Dependency4, Dependency,
5)

How can you set dependency properly so that it will available to
GrandChild4 as well.

Looking forward to your reply.

Thanks




--
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: Can't connect to Maven to retrieve dependencies

2015-08-19 Thread Ron Wheeler


Perhaps a bit more detail might get a response.
What is the command your are executing? What is the exact error?

URL and page of the manual that you are reading would help.

Ron

On 19/08/2015 8:47 AM, Smith-Gagnon, Mary wrote:


Hello,

I am reading “Maven by Example” and am trying to connect to the Maven 
website. I am trying to do the “simple” project.


I get an IOException when I try to connect. Has anyone run into this 
issue?


I would appreciate any assistance.

Mary



*Mary Smith-Gagnon*
Software Engineer
O: 978.527.1159


/Taxware, Convey, and VAT Resource are now Sovos Compliance/

200 Ballardvale St., Building 1, 4^th  Floor

Wilmington, MA 01887

www.sovos.com <http://www.sovos.com/>



- This message and any attachments thereto contain information that 
may be privileged, confidential or otherwise protected from disclosure 
and is the property of Taxware, LLC. It is intended only for the 
person to whom it is addressed. If you are not the intended recipient, 
you are not authorized to read, print, retain, copy, disseminate, 
distribute, or use this message, any attachments thereto or any part 
thereof. If you receive this message in error, please delete all 
copies of this message and attachments. Taxware, LLC. has implemented 
anti-virus software on its computers and servers, however, it is the 
recipient's own responsibility to ensure that all attachments are 
scanned for viruses prior to usage.


This message has been scanned for malware by Websense. 
www.websense.com <http://www.websense.com/>





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Properties Files

2015-08-18 Thread Ron Wheeler


What is their purpose now if you are not using Ant?

If these are properties for the build, they should be inside the parent 
POM as properties.


Ron

On 18/08/2015 10:02 AM, aalok singhvi wrote:

It's a migration of an ant project. It's java project. Presently ant gets
build properties file on compile time.
On Aug 18, 2015 9:56 AM, "Ron Wheeler" 
wrote:


What are you building?
What language and technology stack?

What are the properties files used for - run-time? If so, where do you
want them to end up when you install your app?
How are you installing it?

Ron

On 18/08/2015 7:02 AM, aalok singhvi wrote:


Hello,

I have a properties files. I have a multi modules project
with 1 parent pom and approx 19 child modules. Where should
i be putting the properties files which can be consumed by all
the child modules.

Thanks



--
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





--
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: Properties Files

2015-08-18 Thread Ron Wheeler


What are you building?
What language and technology stack?

What are the properties files used for - run-time? If so, where do you 
want them to end up when you install your app?

How are you installing it?

Ron

On 18/08/2015 7:02 AM, aalok singhvi wrote:

Hello,

I have a properties files. I have a multi modules project
with 1 parent pom and approx 19 child modules. Where should
i be putting the properties files which can be consumed by all
the child modules.

Thanks




--
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: Bug with Maven 3.2.5 and threaded builds and dependencies? Corrupt maven cache.

2015-08-17 Thread Ron Wheeler

We have a lot of third-party jars (less than 100 probably) and did a bit 
of work to make this work better for building, for managing version 
conflicts and making life easier for developers.


http://blog.artifact-software.com/tech/?p=121

Ron

On 17/08/2015 3:28 PM, Kevin Burton wrote:

Hey guys.

I think there’s a bug with Maven 3.2.5 and threaded builds and dependencies.

We have a LOT of dependencies.  I think 400 or so external .jars (not sure
if we’re an unusual case or not).

Anyway. If we have an empty cache, and do a threaded build, what happens is
there’s a race around downloading a dependency.

Thread A will try to download foo.jar and so will thread B…

There’s no mutual exclusion locking present

This means we see the following issue:

- zero byte .jars with no data (not sure how that ones possible but we see
it).
- file not found when trying to copy the .part to the final .jar because
another thread has done so already.

I haven’t tested 3.3.3 because we’re in a CI environment and I can’t
upgrade maven easily.

This will be hard to write a test for I think.




--
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: Specified destination directory cannot be created

2015-08-17 Thread Ron Wheeler

beans.scr\2.4.0.redhat-620133

Mike


%03B
CB
%1B %1D[  X  ܚX K%08%19K[XZ[
  %1D\ \  ][  X  ܚX P%1BX] [  \%18X %19K ܙ B  ܈%18Y%19%1A]%1A[ۘ[%08%18
[X[ %1C %08%19K[XZ[
  %1D\ \  Z%19[%1C%10%1BX] [  \%18X %19K ܙ B

-
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


-
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: Use 2 pom.xml files with different names

2015-08-10 Thread Ron Wheeler


Everyone needs to do this.
It is the basic concept behind java servlets.
You put all the code in the project that creates the jar and you make 
that jar a dependency in the war which has all your servlet 
configuration and resources.


Ron


On 10/08/2015 9:52 AM, Alex Ditu wrote:

Ok, look what I am trying to achieve: I have a project with 2
profileDeployments (it produces 2 types of artifacts: a jar and a war)
but from the same sources. So, I did the following thing: I have
written 2 pom.xml files with 2 different names (for example: pom.xml
and pom2.xml). When I want to build the .jar artifact I would use the
command 'mvn deploy' when I want the .war artifact I would use: 'mvn
-f pom2.xml' ---> after this, I encounter the problem I mentioned
earlier.

Note that the artifactIds are different.


On Mon, Aug 10, 2015 at 4:38 PM, Greg Trasuk  wrote:

On Aug 10, 2015, at 7:12 AM, Alex Ditu  wrote:

Hello,

I want to use pom.xml files for my project with 2 different names:
pom.xml and pom2.xml.
In order to select wich one to execute/use I use -f  like this:


(…snip…)


P.S. Don't ask me why I want to use 2 pom files, if anyone encountered
this situation and knows how to deal with it, help will be much
appreciated :)


The problem is, it’s kind of like asking “When I try to drive on the railroad 
tracks with my car, I keep falling off the rails - has anyone else encountered 
this problem?”  The fundamental concept of Maven is that an artifact is 
uniquely identified, and the pom file describes the artifact.  As such, when 
Maven puts the artifact into the local repository, it follows the naming 
conventions.

You might be better off to describe what you’re actually trying to achieve, and 
then we can suggest how to do that.

Cheers,

Greg Trasuk



-
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: Finding transitive dependencies imported into our code

2015-08-07 Thread Ron Wheeler


You IDE should do that if it is Maven aware.

Foe example, Eclipse/STS, which the m2e plugin built-in, gives you a 
view in the POM editor that shows the origin of the need for each 
dependency and shows the whole chain of transitive dependencies.

It shows what versions of dependencies will be dropped because of conflicts.

This lets you see the effects of exclusions immediately without having 
to do a build.


This is more useful than a separate cli tool which may be why one does 
not exist.


Ron

On 07/08/2015 6:33 AM, James Green wrote:

Hi,

I want to know about any imports within our package base that are resolved
by a transitive dependency.

There must be a command or tool for this - I'm not sure I've ever seen one
though?

This probably should form a report of warnings during the build...

Thanks,

James




--
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: Why is my maven-compiler-plugin out of date ?

2015-08-05 Thread Ron Wheeler


Can you see where the compiler plugin is added to your build?
Parent pom, project pom

Does this help.
https://maven.apache.org/pom.html#Plugin_Management

On 05/08/2015 10:58 AM, sreya...@yahoo.com.INVALID wrote:

I downloaded the latest version of Maven from their site and am using it in 
Eclipse. But it seems my maven-compiler-plugin is out of date ie. version 3.1 
while according to this page the most recent version is 3.3. First of all if I 
am using the latest version of maven why do I have to use an outdated plugin ? 
Secondly why is it out of date ? I looked up the Super-POM and nothing about 
the compiler plugin was referenced there.







Regards
Sreyan Chakravarty



--
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 error on strutsel

2015-07-27 Thread Ron Wheeler

: Maven Users List
Subject: Re: build error on strutsel

Hi Hector,


I clicked on the link and it returns nothing.
How do I search for it in the repository ?

That's baffling. I see this:

[Inline image 1]

I have no clue why it would be different for you...

Regards,
Curtis

On Fri, Jul 24, 2015 at 12:31 PM, Magnanao, Hector <
hector.magna...@sap.com<mailto:hector.magna...@sap.com>> wrote:
Hi Curtis,

I clicked on the link and it returns nothing.  How do I search for it in
the repository ?

-Original Message-
From: ctrueden.w...@gmail.com<mailto:ctrueden.w...@gmail.com> [mailto:
ctrueden.w...@gmail.com<mailto:ctrueden.w...@gmail.com>] On Behalf Of
Curtis Rueden
Sent: Friday, July 24, 2015 12:17 PM
To: Maven Users List
Subject: Re: build error on strutsel

Hi Hector,


I can't find it in the maven repository.




http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.apache.strutsel.taglib.utils%22

-Curtis

On Fri, Jul 24, 2015 at 12:11 PM, Magnanao, Hector <
hector.magna...@sap.com<mailto:hector.magna...@sap.com>>
wrote:


How do I resolve this package error ?  I can't find it in the maven
repository.

ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project foundation: Compilation failure:

Compilation

failure:
ERROR]


/C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[64,40]

package org.apache.strutsel.taglib.utils does not exist
ERROR]


/C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/bean/MessageTagEl.java:[72,40]

package org.apache.strutsel.taglib.utils does not exist

Hector Magnanao Jr.
SCM Analyst

Fieldglass, Inc.
O: (331) 702-6142
M: (773) 474-3051
hector.magna...@sap.com<mailto:hector.magna...@sap.com>
www.fieldglass.com<http://www.fieldglass.com>

Fieldglass is now part of SAP

This email contains confidential information.  If you are not the

intended

recipient, do not read, distribute or reproduce this transmission
(including any attachments). If you have received this email in error,
please notify the sender by email reply.



-
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


-
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: Fetch all remote dependencies NOT in my pom?

2015-07-22 Thread Ron Wheeler

Could you not just build it once and copy the contents of the local 
cache after it downloads everything?


Ron

On 22/07/2015 11:57 PM, Curtis Rueden wrote:

Hi Kevin,


What I want to do is just download all artifacts not in "com.spinn3r.* “
group ID.

Did you try:

 mvn dependency:go-offline -DexcludeGroupIds=com.spinn3r ...

?

Regards,
Curtis

On Wed, Jul 22, 2015 at 10:50 PM, Kevin Burton  wrote:


What I want to do is just download all artifacts not in "com.spinn3r.* “
group ID.

They aren’t built yet or in any repositories yet.  This is for a continuous
integration systems so I want to pre-cache them.  After this they’re just
restored from cache to build faster.



Is your repo on the same computer as the CI system?



No.. different.



Maven does cache dependencies locally after they are downloaded from your
repo.


Yes.  But this is a hosted CI build system (CircleCI) so everything is a
container and wiped out each time.


--

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>




--
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: Fetch all remote dependencies NOT in my pom?

2015-07-22 Thread Ron Wheeler


What repo are you using?
Is your repo on the same computer as the CI system?

Maven does cache dependencies locally after they are downloaded from 
your repo.


Ron

On 22/07/2015 11:33 PM, Sander Verhagen wrote:

Hi Burtonator,


The "resolve" goal that you mention "works" for me. I put quotes around "works" because your requirements 
aren't quite clear to me. But "resolve" gives me a list of dependencies (not transitive ones, since you specified 
"-DexcludeTransitive=true"). So perhaps you could elaborate on what "doesn't work" means for you.

After your first e-mail I thought you wanted to download the artifacts, rather than list 
them, and thought you'd be a candidate for "dependency:copy-dependencies" 
instead.

Not sure what you're trying to do here precisely. But we all have CI 
environments, so perhaps I can learn from your (attempted) approach!

Best regards,


Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. Please remove verha...@sander.com now 
and start using san...@sanderverhagen.net from now on. Please update your 
address book. Thank  you!



-Original Message-
From: burtonator2...@gmail.com [mailto:burtonator2...@gmail.com] On
Behalf Of Kevin Burton
Sent: Wednesday, July 22, 2015 20:27
To: Maven Users List
Subject: Re: Fetch all remote dependencies NOT in my pom?

I tried the following.. but that doesn’t work.  hm… stumped on this one.

mvn -DexcludeGroupIds=com.spinn3r.artemis -DexcludeTransitive=true
dependency:resolve mvn -DexcludeArtifactIds=artemis -
DexcludeTransitive=true dependency:resolve

On Wed, Jul 22, 2015 at 8:13 PM, Kevin Burton 
wrote:


I need a way to fetch all external dependencies that aren’t just a
submodule in my current project.

So things like junit, mockito, log4j, jetty, etc. I want to pull down
all that stuff.

However, I do NOT want it to include dependencies from the project.
Those aren’t built yet so they’re not in any repo.

This is important for our continuous integration system. I want to
pre-cache these so that they’re local. It will shave 2-5 minutes off
our build time.  We have about 200 external dependencies that we pull
in so this init process takes a long time (and wastes resources).

--

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>




--

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>

-
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: How to delete certain snapshots from Nexus

2015-07-22 Thread Ron Wheeler

Glad you have found a solution even if I can not understand the source 
of the problem.
It does not seem to a general problem which is why you have to develop a 
custom solution.
This is a pretty big mailing list and attracts a lot of experienced 
developers and if there was a general solution, someone would have 
chimed in by now.


Good luck.
Ron


On 22/07/2015 1:11 AM, David Hoffer wrote:

Apparently our communication has broken down, it seems your not
understanding the issue/question.




I did find that Nexus does have an API we can use for this...I sure wish
there was a more 'packaged' solution but I've discussed it with our IT
department and between us I think we can solve this issue using that
approach.  If anyone knows of a better solution please let me know.

-Dave

On Tue, Jul 21, 2015 at 10:32 PM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


If you have SNAPSHOTs specified, you will get SNAPSHOTs in the build.
When you remove the SNAPSHOT from the parent, there should not be any way
for a SNAPSHOT to be included.


I am not sure where the SNAPSHOTS are being brought in to a x.x.x release
unless you are allowing modules to specify the versions of their
dependencies.
Stop that.
Modules should have no versions on an dependency unless it is a reference
to a property in the parent.
Modules should have no references to a version on a dependency that is one
of the modules that your wrote - ${project.version}

Ron


On 21/07/2015 11:40 PM, David Hoffer wrote:


I didn't say x.x.x is the only version in the parent.  I said it is a
SNAPSHOT.  The version varies (of course) but in my prior example I said
it
was 1.0-SNAPSHOT.

-Dave

On Tue, Jul 21, 2015 at 9:36 PM, Ron Wheeler <
rwhee...@artifact-software.com


wrote:
Where are the possible SNAPSHOT versions creeping into the build if x.x.x
is the only versions in your parent and the dependencies do not have any
versions (as I suggested).

Ron


On 21/07/2015 10:54 PM, David Hoffer wrote:

  Yes we use one version for all modules...comes from top level.  What I

mean
is this is a non-release build so by maven definition is a snapshot.
E.g.
x.x.x is built only once at release, x.x.x-SNAPSHOT is built on every CI
build.

-Dave

On Tue, Jul 21, 2015 at 8:38 PM, Ron Wheeler <
rwhee...@artifact-software.com

  wrote:

On 21/07/2015 5:53 PM, David Hoffer wrote:

   I'm not sure I understand your reply.  We use dependency management
to


specify versions (for both external & project dependencies), however
that's
not the issue, we have no problem specifying the version to use for
both
of
those.  What is only in view here are the multi-module project
dependencies
and by definition they are all SNAPSHOTS as we have not released yet.

   What do you mean "by definition"?


If the modules use the parent version as their version, they will be
SNAPSHOTS or releases depending on the parent pom having a version of
x.x.x-SNAPSHOT or x.x.x.
i.e. the module version is missing so that the parent's version is the
version of the module.
Any dependency in another module that is part of the project is set to
${project.version}

   com.example
   anything-core
   ${project.version}
   provided
   

Ron




   Let me give an example that might help.  The multi-module project is


large
and is growing...you start out with these modules (all the versions
are
1.0-SNAPSHOT).

groupId=com.mycompany.myproject
artifactId=artifactA, artifactB, artifactC, artifact1, artifact2,
artifact3

This has been building with your CI system for 1 month when you
realize
you
really want these modules.

groupId=com.mycompany.myproject
artifactId=app-parent

groupId=com.mycompany.myproject.service
artifactId=artifactA, artifactB, artifactC

groupId=com.mycompany.myproject.transform
artifactId=artifact1, artifact2, artifact3

This too builds fine, however in reality somewhere in this new build
is
a
reference to com.mycompany.myproject:artifactA:1.0-SNAPSHOT...perhaps
for
an unpack goal.  The build is fine as Nexus will always have this
artifact
although it was removed from the build during the refactor.

We want to purge all com.mycompany.myproject.* snapshots from Nexus so
the
CI build will fail until the build is correct.

-Dave





On Tue, Jul 21, 2015 at 3:20 PM, Ron Wheeler <
rwhee...@artifact-software.com

   wrote:


Using the parent pom to specify the versions of dependencies solves
this
problem for most people.

If there are no SNAPSHOTS in the parent's properties and the parent
poms
version is not a SNAPSHOT, then your project is not being built with
SNAPSHOTS.

We never worry about the SNAPSHOTs in the repo.

Ron


On 21/07/2015 2:42 PM, David Hoffer wrote:

Yeah it appears our IT group is right...Nexus doesn't have a
UI/feature

  to

do what we want.  What other options are there?

This would seem a common need, major project does a re

Re: How to delete certain snapshots from Nexus

2015-07-21 Thread Ron Wheeler


If you have SNAPSHOTs specified, you will get SNAPSHOTs in the build.
When you remove the SNAPSHOT from the parent, there should not be any 
way for a SNAPSHOT to be included.



I am not sure where the SNAPSHOTS are being brought in to a x.x.x 
release unless you are allowing modules to specify the versions of their 
dependencies.

Stop that.
Modules should have no versions on an dependency unless it is a 
reference to a property in the parent.
Modules should have no references to a version on a dependency that is 
one of the modules that your wrote - ${project.version}


Ron

On 21/07/2015 11:40 PM, David Hoffer wrote:

I didn't say x.x.x is the only version in the parent.  I said it is a
SNAPSHOT.  The version varies (of course) but in my prior example I said it
was 1.0-SNAPSHOT.

-Dave

On Tue, Jul 21, 2015 at 9:36 PM, Ron Wheeler 
wrote:
Where are the possible SNAPSHOT versions creeping into the build if x.x.x
is the only versions in your parent and the dependencies do not have any
versions (as I suggested).

Ron


On 21/07/2015 10:54 PM, David Hoffer wrote:


Yes we use one version for all modules...comes from top level.  What I
mean
is this is a non-release build so by maven definition is a snapshot.  E.g.
x.x.x is built only once at release, x.x.x-SNAPSHOT is built on every CI
build.

-Dave

On Tue, Jul 21, 2015 at 8:38 PM, Ron Wheeler <
rwhee...@artifact-software.com


wrote:
On 21/07/2015 5:53 PM, David Hoffer wrote:

  I'm not sure I understand your reply.  We use dependency management to

specify versions (for both external & project dependencies), however
that's
not the issue, we have no problem specifying the version to use for both
of
those.  What is only in view here are the multi-module project
dependencies
and by definition they are all SNAPSHOTS as we have not released yet.

  What do you mean "by definition"?

If the modules use the parent version as their version, they will be
SNAPSHOTS or releases depending on the parent pom having a version of
x.x.x-SNAPSHOT or x.x.x.
i.e. the module version is missing so that the parent's version is the
version of the module.
Any dependency in another module that is part of the project is set to
${project.version}
   
  com.example
  anything-core
  ${project.version}
  provided
  

Ron




  Let me give an example that might help.  The multi-module project is

large
and is growing...you start out with these modules (all the versions are
1.0-SNAPSHOT).

groupId=com.mycompany.myproject
artifactId=artifactA, artifactB, artifactC, artifact1, artifact2,
artifact3

This has been building with your CI system for 1 month when you realize
you
really want these modules.

groupId=com.mycompany.myproject
artifactId=app-parent

groupId=com.mycompany.myproject.service
artifactId=artifactA, artifactB, artifactC

groupId=com.mycompany.myproject.transform
artifactId=artifact1, artifact2, artifact3

This too builds fine, however in reality somewhere in this new build is
a
reference to com.mycompany.myproject:artifactA:1.0-SNAPSHOT...perhaps
for
an unpack goal.  The build is fine as Nexus will always have this
artifact
although it was removed from the build during the refactor.

We want to purge all com.mycompany.myproject.* snapshots from Nexus so
the
CI build will fail until the build is correct.

-Dave





On Tue, Jul 21, 2015 at 3:20 PM, Ron Wheeler <
rwhee...@artifact-software.com

  wrote:

Using the parent pom to specify the versions of dependencies solves
this
problem for most people.

If there are no SNAPSHOTS in the parent's properties and the parent
poms
version is not a SNAPSHOT, then your project is not being built with
SNAPSHOTS.

We never worry about the SNAPSHOTs in the repo.

Ron


On 21/07/2015 2:42 PM, David Hoffer wrote:

   Yeah it appears our IT group is right...Nexus doesn't have a
UI/feature


to
do what we want.  What other options are there?

This would seem a common need, major project does a refactor of Maven
GA
and want to delete all SNAPSHOTS used by the project to verify the
refactor
is 100% complete.  We have had too many cases where the build is still
pointing to an old artifact that isn't part of the build anymore yet
the
build is happy because old artifacts are still in Nexus.

-Dave

On Tue, Jul 21, 2015 at 12:36 PM, Karl Heinz Marbaise <
khmarba...@gmx.de>
wrote:

Hi David,

  On 7/21/15 6:03 PM, David Hoffer wrote:

We use Nexus as our corporate Maven repository and would like to

  periodically delete certain SNAPSHOT artifacts.  We need to be able

to
filter/select by groupId and by version...so delete all where
groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT.

You can only delete all kind of SNAPSHOT's in Nexus based on a
time

  frame

for example delete all SNAPSHOT's which are older than 30 days etc..



Our use case is that when we refactor part of the build to us

Re: How to delete certain snapshots from Nexus

2015-07-21 Thread Ron Wheeler

Where are the possible SNAPSHOT versions creeping into the build if 
x.x.x is the only versions in your parent and the dependencies do not 
have any versions (as I suggested).


Ron

On 21/07/2015 10:54 PM, David Hoffer wrote:

Yes we use one version for all modules...comes from top level.  What I mean
is this is a non-release build so by maven definition is a snapshot.  E.g.
x.x.x is built only once at release, x.x.x-SNAPSHOT is built on every CI
build.

-Dave

On Tue, Jul 21, 2015 at 8:38 PM, Ron Wheeler 
wrote:
On 21/07/2015 5:53 PM, David Hoffer wrote:


I'm not sure I understand your reply.  We use dependency management to
specify versions (for both external & project dependencies), however
that's
not the issue, we have no problem specifying the version to use for both
of
those.  What is only in view here are the multi-module project
dependencies
and by definition they are all SNAPSHOTS as we have not released yet.


What do you mean "by definition"?
If the modules use the parent version as their version, they will be
SNAPSHOTS or releases depending on the parent pom having a version of
x.x.x-SNAPSHOT or x.x.x.
i.e. the module version is missing so that the parent's version is the
version of the module.
Any dependency in another module that is part of the project is set to
${project.version}
  
 com.example
 anything-core
 ${project.version}
 provided
 

Ron





Let me give an example that might help.  The multi-module project is large
and is growing...you start out with these modules (all the versions are
1.0-SNAPSHOT).

groupId=com.mycompany.myproject
artifactId=artifactA, artifactB, artifactC, artifact1, artifact2,
artifact3

This has been building with your CI system for 1 month when you realize
you
really want these modules.

groupId=com.mycompany.myproject
artifactId=app-parent

groupId=com.mycompany.myproject.service
artifactId=artifactA, artifactB, artifactC

groupId=com.mycompany.myproject.transform
artifactId=artifact1, artifact2, artifact3

This too builds fine, however in reality somewhere in this new build is a
reference to com.mycompany.myproject:artifactA:1.0-SNAPSHOT...perhaps for
an unpack goal.  The build is fine as Nexus will always have this artifact
although it was removed from the build during the refactor.

We want to purge all com.mycompany.myproject.* snapshots from Nexus so the
CI build will fail until the build is correct.

-Dave





On Tue, Jul 21, 2015 at 3:20 PM, Ron Wheeler <
rwhee...@artifact-software.com


wrote:
Using the parent pom to specify the versions of dependencies solves this
problem for most people.

If there are no SNAPSHOTS in the parent's properties and the parent poms
version is not a SNAPSHOT, then your project is not being built with
SNAPSHOTS.

We never worry about the SNAPSHOTs in the repo.

Ron


On 21/07/2015 2:42 PM, David Hoffer wrote:

  Yeah it appears our IT group is right...Nexus doesn't have a UI/feature

to
do what we want.  What other options are there?

This would seem a common need, major project does a refactor of Maven GA
and want to delete all SNAPSHOTS used by the project to verify the
refactor
is 100% complete.  We have had too many cases where the build is still
pointing to an old artifact that isn't part of the build anymore yet the
build is happy because old artifacts are still in Nexus.

-Dave

On Tue, Jul 21, 2015 at 12:36 PM, Karl Heinz Marbaise <
khmarba...@gmx.de>
wrote:

   Hi David,


On 7/21/15 6:03 PM, David Hoffer wrote:

   We use Nexus as our corporate Maven repository and would like to


periodically delete certain SNAPSHOT artifacts.  We need to be able to
filter/select by groupId and by version...so delete all where
groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT.

   You can only delete all kind of SNAPSHOT's in Nexus based on a time


frame
for example delete all SNAPSHOT's which are older than 30 days etc..



   Our use case is that when we refactor part of the build to use new


groupIds
the old ones are not valid anymore however sometimes there is a
lingering
reference to the old groupId, if we can delete all the old SNAPSHOTS
we
could find those errors now instead of when we release.

Any ideas on how to do this are much appreciated.

-Dave


   Kind regards


Karl Heinz Marbaise

-
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


-

Re: How to delete certain snapshots from Nexus

2015-07-21 Thread Ron Wheeler


On 21/07/2015 5:53 PM, David Hoffer wrote:

I'm not sure I understand your reply.  We use dependency management to
specify versions (for both external & project dependencies), however that's
not the issue, we have no problem specifying the version to use for both of
those.  What is only in view here are the multi-module project dependencies
and by definition they are all SNAPSHOTS as we have not released yet.

What do you mean "by definition"?
If the modules use the parent version as their version, they will be 
SNAPSHOTS or releases depending on the parent pom having a version of  
x.x.x-SNAPSHOT or x.x.x.
i.e. the module version is missing so that the parent's version is the 
version of the module.
Any dependency in another module that is part of the project is set to 
${project.version}

 
com.example
anything-core
${project.version}
provided


Ron




Let me give an example that might help.  The multi-module project is large
and is growing...you start out with these modules (all the versions are
1.0-SNAPSHOT).

groupId=com.mycompany.myproject
artifactId=artifactA, artifactB, artifactC, artifact1, artifact2, artifact3

This has been building with your CI system for 1 month when you realize you
really want these modules.

groupId=com.mycompany.myproject
artifactId=app-parent

groupId=com.mycompany.myproject.service
artifactId=artifactA, artifactB, artifactC

groupId=com.mycompany.myproject.transform
artifactId=artifact1, artifact2, artifact3

This too builds fine, however in reality somewhere in this new build is a
reference to com.mycompany.myproject:artifactA:1.0-SNAPSHOT...perhaps for
an unpack goal.  The build is fine as Nexus will always have this artifact
although it was removed from the build during the refactor.

We want to purge all com.mycompany.myproject.* snapshots from Nexus so the
CI build will fail until the build is correct.

-Dave





On Tue, Jul 21, 2015 at 3:20 PM, Ron Wheeler 
wrote:
Using the parent pom to specify the versions of dependencies solves this
problem for most people.

If there are no SNAPSHOTS in the parent's properties and the parent poms
version is not a SNAPSHOT, then your project is not being built with
SNAPSHOTS.

We never worry about the SNAPSHOTs in the repo.

Ron


On 21/07/2015 2:42 PM, David Hoffer wrote:


Yeah it appears our IT group is right...Nexus doesn't have a UI/feature to
do what we want.  What other options are there?

This would seem a common need, major project does a refactor of Maven GA
and want to delete all SNAPSHOTS used by the project to verify the
refactor
is 100% complete.  We have had too many cases where the build is still
pointing to an old artifact that isn't part of the build anymore yet the
build is happy because old artifacts are still in Nexus.

-Dave

On Tue, Jul 21, 2015 at 12:36 PM, Karl Heinz Marbaise 
wrote:

  Hi David,

On 7/21/15 6:03 PM, David Hoffer wrote:

  We use Nexus as our corporate Maven repository and would like to

periodically delete certain SNAPSHOT artifacts.  We need to be able to
filter/select by groupId and by version...so delete all where
groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT.

  You can only delete all kind of SNAPSHOT's in Nexus based on a time

frame
for example delete all SNAPSHOT's which are older than 30 days etc..



  Our use case is that when we refactor part of the build to use new

groupIds
the old ones are not valid anymore however sometimes there is a
lingering
reference to the old groupId, if we can delete all the old SNAPSHOTS we
could find those errors now instead of when we release.

Any ideas on how to do this are much appreciated.

-Dave


  Kind regards

Karl Heinz Marbaise

-
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





--
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: How to delete certain snapshots from Nexus

2015-07-21 Thread Ron Wheeler

Using the parent pom to specify the versions of dependencies solves this 
problem for most people.


If there are no SNAPSHOTS in the parent's properties and the parent poms 
version is not a SNAPSHOT, then your project is not being built with 
SNAPSHOTS.


We never worry about the SNAPSHOTs in the repo.

Ron

On 21/07/2015 2:42 PM, David Hoffer wrote:

Yeah it appears our IT group is right...Nexus doesn't have a UI/feature to
do what we want.  What other options are there?

This would seem a common need, major project does a refactor of Maven GA
and want to delete all SNAPSHOTS used by the project to verify the refactor
is 100% complete.  We have had too many cases where the build is still
pointing to an old artifact that isn't part of the build anymore yet the
build is happy because old artifacts are still in Nexus.

-Dave

On Tue, Jul 21, 2015 at 12:36 PM, Karl Heinz Marbaise 
wrote:


Hi David,

On 7/21/15 6:03 PM, David Hoffer wrote:


We use Nexus as our corporate Maven repository and would like to
periodically delete certain SNAPSHOT artifacts.  We need to be able to
filter/select by groupId and by version...so delete all where
groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT.


You can only delete all kind of SNAPSHOT's in Nexus based on a time frame
for example delete all SNAPSHOT's which are older than 30 days etc..




Our use case is that when we refactor part of the build to use new
groupIds
the old ones are not valid anymore however sometimes there is a lingering
reference to the old groupId, if we can delete all the old SNAPSHOTS we
could find those errors now instead of when we release.

Any ideas on how to do this are much appreciated.

-Dave



Kind regards
Karl Heinz Marbaise

-
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: Using a plugin/project in different builds

2015-07-20 Thread Ron Wheeler

Your final suggestion is a trouble free way to do this and makes it easy
to use the shared artifact in multiple projects.
It turns your code into a shareable library that you can use from any
project that needs the functionality.

On 20/07/2015 8:55 AM, darkphoenix20888 wrote:

Hi @ all,

I have a java-project which I want to use in different Builds, but got some
problems.
First the project was used in a Maven-Tycho-RCP-build as an eclipse plugin.
Now I want to build an JavaFX-application which uses this project as a
plugin. My peference is to build this project in both applications
independently.
Is it possible to build this project as a module in both applications? I
tried it, but had some problems caused by multiple parent-declaration in the
project-pom.
Or is it only possible by building this plugin as standalone(before the
applications) and set only dependency information to this plugin in both
builds?

Thx in advance.
Ray

--
View this message in context:
http://maven.40175.n5.nabble.com/Using-a-plugin-project-in-different-builds-tp5840461.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
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: Need Help of Maveners to prepare for a talk on Maven

2015-07-14 Thread Ron Wheeler


Very good suggestions.
Perhaps Murthy should share a bit about the audience (Maven users who 
want to improve their understanding or Ant users who are interested in 
changing) and what he wants them to know at the end of the presentation.
Is it a technical talk about the way Maven works or a "marketing" talk 
about the benefits of using Maven and how it changes the development 
environment and improves software quality?


Ron

On 14/07/2015 2:04 AM, Sander Verhagen wrote:

Hi Murthy,


I think it's important that you talk about things that you're comfortable with 
yourself. The fact that you're asking for resources in the way you do sounds 
like you're being sent on a quest in partly unknown territory, which may not be 
a great starting point to present (but I might have gotten the wrong impression 
here entirely, sorry if so). If you are still learning Maven while doing a 
major conversion from Ant, or you are an expert Maven user but you're the only 
one in your group, it may be worthwhile to get some expert consultancy so that 
you can adopt some best practices and to help you look good as the person 
driving this project.

When I guided my company from Ant to Maven, I did a lot of separate 
presentations, some of these were specific for our situation, some of these 
were generically about Maven. In the generic presentations I covered subjects 
like this:

Build
 Lifecycle
 Goals
 Plugins
Dependency management
 Artifacts
 Dependencies
 Scopes
 Conflicts
Repositories
Versioning
Modules
Profiles

I would like to particularly call out "lifecycle" and "goals", since these concepts are 
so very basic to Maven that they're easily overlooked, but they are oh-so fundamental and at the same time so 
fundamentally different than Ant. And it's probably also these concepts that make Maven so much more than 
just "an Ant that does dependency management".

Good luck with your presentation!

Feel free to ask for more information!

Best regards, Sander.

P.S.: what's up with your footer?



Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. Please remove verha...@sander.com now 
and start using san...@sanderverhagen.net from now on. Please update your 
address book. Thank  you!



-Original Message-
From: Gandikota, Murthy [mailto:mgandik...@westechmed.com]
Sent: Monday, July 13, 2015 17:59
To: Maven Users List
Subject: Need Help of Maveners to prepare for a talk on Maven

Hi All
I am asked by my org/boss to talk about my maven exploits for about half an
hour in front of our group. Having sought  your help, earlier, for a pathing
jar, I am ready to talk  about it. However, it involves a  lot of ant, as I 
don't
know how to do the  same (copying files, generating manifest, etc.) in
Maven. Can you help me figure out what other topics  can be general
enough for Maveners? I am thinking of Maven plugins, but don't know any
resources. I'd appreciate if you can kindly help me figure this out.

Thanks in anticipation.
B�KKK
KCB��[��X��ܚX�KK[XZ[

�\�\��][��X��ܚX�PX]�[��\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[

�\�\��Z[X]�[��\X�K�ܙ�B

-
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: How to arrange dependency management for maven reactor if child modules are versioned independently?

2015-07-02 Thread Ron Wheeler


I do not like any uncertainty about what is going into a build.
If you are a developer and suddenly your code changes behaviour after 
you have made a change, your natural assumption is that you broke it.


SNAPSHOTS are hard enough to deal with and you need manual policies 
about snapshot deployment to ensure that publishing new snapshots is 
communicated to everyone in the project and holding publishers to an 
implied warranty (they may have to buy the next round if they break 
someone else's code!).


At least the POM tells you if you are depending on a SNAPSHOT.
Having variability in releases just adds to the confusion.

Ron

On 02/07/2015 3:54 AM, Stefan Seidel wrote:

Hi,


So the release of submodule because of this reason is nothing significant
from the point of view of the whole platform and all the internal
dependencies should continue with the highest snapshot versions with as
small effort as possible. I hope this does makes sense.

If I understand this correctly, wouldn't using version ranges solve this? We
also update micro-projects often and so we use limites version ranges within
major releases, so [2,3) will resolve to the latest
snapshot or release of the dependency unless it had received a major upgrade
from, say, 2.8 to 3.0 or even 3.0-SNAPSHOT.

Regards,

Stefan


František
http://calavera.info

   Původní zpráva
Od: Ron Wheeler
Odesláno: středa, 1. července 2015 17:14
Komu: users@maven.apache.org
Odpovědět: Maven Users List
Předmět: Re: How to arrange dependency management for maven reactor if child
modules are versioned independently?

What is the relationship between the "independent" modules?
If a child module gets a new version, should that trigger a change for
other modules that depend on it?
It seems to me from your description, that you do care when a child
module releases a new version.
If this should trigger a change in the dependant modules, then it seems
reasonable that the parent pom should change to make this explicit.

I would take a few seconds to think about how you want SNAPSHOTs to be
handled.
If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
to start to depend on the SNAPSHOT immediately or to continue to use
1.2.3 until 1.2.4 is released?
You may need to separate the dependency versions from the artifact
version if you want to keep A depending on the released version of B.

1.2.4-SNAPSHOT 
1.2.3 


This will also allow the developer of B to test the impact on module A
by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
A prior to releasing B.

Ron

On 01/07/2015 6:35 AM, František Řezáč wrote:

Hi,
I have asked a question on stackoverflow about what I thought should be a
relatively common scenario but I didn't get an answer even though I put a
bounty on it and published it through my social networks to wide audience.
Since it's still unanswered after a long time, I'm sending it here as a
last hope for solution or expert insight.

http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-mana
gement-for-maven-reactor-if-child-modules-are-vers

We have a reactor pom whose child modules are versioned independently, ie.
child module declares it's own version that is independent of the version
of the main pom. There is however a dependency between two child modules.
How should be this dependency configured to always use the version that is
declared by the actual module of the reactor pom?

I would expect that I can set up dependency management in the root pom and
use some implicit properties to determine the version of child modules,
but
the best such option I can find :

${session.projectDependencyGraph.sortedProjects[0].version}

or simply

${reactorProjects[0].version}

looks unreliable because the reactor order may change when new modules or
dependencies are added.

Maybe this usage scenario is discouraged by design and then I would like
to
know why.

As is suggested in comments in original stackoverflow post, declaring a
global properties with child versions in parent POM may be an option for
newer versions of Maven. I would however like to see some analysis with
respect to wider consequences like workflow, releasing, directory and
repository settings, some plugins usage (e.g. version plugin) etc. For
example I think that direct consequence of this approach is that I would
have to release parent module whenever any of child modules are released.
Although this is doable, it would impact the original idea of having an
independent versioning.



--
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: How to arrange dependency management for maven reactor if child modules are versioned independently?

2015-07-01 Thread Ron Wheeler


On 01/07/2015 12:29 PM, František Řezáč wrote:

Your reasoning about the relationship between independent modules is right and 
made me think again really hard to formulate my intuitive disagreement.

The important thing to notice is why a submodule is released. ‎If it's because 
of some new, comprehensive feature set to be used in dependent modules that are 
part of the reactor, then your arguments are right an it should be expressed by 
changing the global parent. We are however releasing much more often because of 
external projects that depends on some submodule of the reactor pom. In fact we 
need to pin some version to the state of the submodule in some particular point 
in time so that external micro projects can release without releasing the whole 
platform.
It sounds like you  have to be prepared to support both reasons for 
releasing modules and to support the everyday building and testing of 
changes to individual modules.


It may be helpful to think about the different versions of the parent 
POM. You need to track each revision that makes it into your SCM and 
make sure that versions are changed and that comments are added to the 
commit so that people can easily download the version that they need.


The version of the parent POM on any individual workstation might be 
different from the versions in the SCM and people have to be careful 
about committing parent POMs to the SCM if they contain local changes - 
I might want to test Module A with my 1.2.4-SNAPSHOT of module B but you 
do not want me to commit that version of my parent POM to the SCM since 
it may not suit others who expect the master POM to have Module A depend 
on 1.2.3 of B until I finishing testing 1.2.4 and it is officially released.


I am not sure why you want to link the modules together so tightly if 
they are really independent.
We have a big project (a Learning Management System) with over 70 Maven 
projects, each with its own version (a lot share the same version as a 
bunch of other modules) and we build each one separately since most of 
the time only a few are being worked on during a release cycle. Release 
1.2.4 might fix a set of bugs and add some enhancements but it only 
involves changes to 5 modules. We upgrade the version on the five 
modules to the same version number but actually code, test and release 
each one separately.


When we make a change to a module that is a dependency for other 
modules, we have to change the version of the dependant module even if 
there is no code change.


For example, if version of Module A is 1.2 and it depends on version 1.4 
of module B and we are changing code in Module B to make version 1.5 of 
B, then we would change the pom of Module A to fix the dependency on B 
and change the version of Module A to 1.5. This might cause a repeat of 
the cycle if other modules depend on A.
This way we have a repeatable build for the whole set of modules and can 
easily see that module A was affected by the 1.5 revision (even if it 
was only a POM change)
We avoid peer dependencies but there are dependencies between layers so 
changes to persistence structures tend to bubble up through the stack.


If you want to get a copy of everything as it was before 1.5 (ie the 1.4 
release) , you can find all of the releases in our Nexus repo by 
selecting the highest release below 1.5 for each module (ie version 1.2 
of Module A, version 1.4 of Module B, ... version 1.2.4 of Module XXX.)


We use a spreadsheet to record and plan each new release and one of the 
planning tasks is to update the version plan to identify all of the new 
versions that will be created.
This acts as a checklist for tasks to be done and helps us by 
identifying potential dependencies that frequently occur (changes to 
Module D potentially affects code in Module F, G and N) so over time we 
get better at estimating the impact of proposed enhancements.


Ron



So the release of submodule because of this reason is nothing significant from 
the point of view of the whole platform and all the internal dependencies 
should continue with the highest snapshot versions with as small effort as 
possible. I hope this does makes sense.

František
http://calavera.info

   Původní zpráva
Od: Ron Wheeler
Odesláno: středa, 1. července 2015 17:14
Komu: users@maven.apache.org
Odpovědět: Maven Users List
Předmět: Re: How to arrange dependency management for maven reactor if child 
modules are versioned independently?

What is the relationship between the "independent" modules?
If a child module gets a new version, should that trigger a change for
other modules that depend on it?
It seems to me from your description, that you do care when a child
module releases a new version.
If this should trigger a change in the dependant modules, then it seems
reasonable that the parent pom should change to make this explicit.

I would take a few seconds to think about how you want SNAPSHOTs to be
handled.
If A depends on B and B

Re: How to arrange dependency management for maven reactor if child modules are versioned independently?

2015-07-01 Thread Ron Wheeler

What is the relationship between the "independent" modules?
If a child module gets a new version, should that trigger a change for
other modules that depend on it?
It seems to me from your description, that you do care when a child
module releases a new version.
If this should trigger a change in the dependant modules, then it seems
reasonable that the parent pom should change to make this explicit.

I would take a few seconds to think about how you want SNAPSHOTs to be
handled.
If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
to start to depend on the SNAPSHOT immediately or to continue to use
1.2.3 until 1.2.4 is released?
You may need to separate the dependency versions from the artifact
version if you want to keep A depending on the released version of B.

1.2.4-SNAPSHOT
1.2.3

This will also allow the developer of B to test the impact on module A
by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
A prior to releasing B.

Ron

On 01/07/2015 6:35 AM, František Řezáč wrote:

Hi,
I have asked a question on stackoverflow about what I thought should be a
relatively common scenario but I didn't get an answer even though I put a
bounty on it and published it through my social networks to wide audience.
Since it's still unanswered after a long time, I'm sending it here as a
last hope for solution or expert insight.

http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-management-for-maven-reactor-if-child-modules-are-vers

We have a reactor pom whose child modules are versioned independently, ie.
child module declares it's own version that is independent of the version
of the main pom. There is however a dependency between two child modules.
How should be this dependency configured to always use the version that is
declared by the actual module of the reactor pom?

I would expect that I can set up dependency management in the root pom and
use some implicit properties to determine the version of child modules, but
the best such option I can find :

${session.projectDependencyGraph.sortedProjects[0].version}

or simply

${reactorProjects[0].version}

looks unreliable because the reactor order may change when new modules or
dependencies are added.

Maybe this usage scenario is discouraged by design and then I would like to
know why.

As is suggested in comments in original stackoverflow post, declaring a
global properties with child versions in parent POM may be an option for
newer versions of Maven. I would however like to see some analysis with
respect to wider consequences like workflow, releasing, directory and
repository settings, some plugins usage (e.g. version plugin) etc. For
example I think that direct consequence of this approach is that I would
have to release parent module whenever any of child modules are released.
Although this is doable, it would impact the original idea of having an
independent versioning.

--
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: AW: Help needed with a strange fixed filename

2015-06-09 Thread Ron Wheeler


This line was what misled me

"if I create an artefact for it in my nexus, the file name is

changed to jarfile-3.x.x"


You might want to add an installer to your deployment process.

I use IzPack to build an installer that puts all the right jars and 
resource files in the right places.


You could add the jarfil3.jar as a resource to be included in the 
deployment.
You could make a dummy class with all of the method signatures that you 
need at compile time as "jarfile3-1.0.0" and mark that as "provided" in 
your POM's dependencies section and provide the "jarfile3.jar" at run-time.
This would at least make life easy during the software development 
stage. Need to make jarfile3.jar available for running tests.


A bit more work than it would be for your vendor to release a proper jar.

You might ask them to package 2 versions of the jar, one "as is- 
jarfile3.jar" and one with a pom and jar that could be used by Maven.
This should be pretty simple and would not impact people who use the 
current jarfile3.jar


Alternatively, they could test the name by ignoring everything after the 
"3" (ie stop at the "-") so that jarfile3.jar and jarfile3-x.x.x.jar are 
treated as the same name.


Neither of these changes would affect their other users.

Ron


On 09/06/2015 1:51 AM, Thomas Klöber wrote:

Hi Ron,

might have not explained it right: jarfile3.jar gets turned into 
jarfile3-x.x.x.jar due to the version number i have to supply when creating the 
artefact in nexus.

I agree it would be easier to either get rid of the version number at build 
time or at least change the naming to jarfile-3.jar.
But unfortunately the vendor refuses to change that.

Hi Curtis,

I fully agree that this is a terrible way of programming. But I asked the vendor why 
they check the file name and thay say "that some other apps would fail if they 
didn't have a fixed jarfile name'. Escapes me why, but again they refuse to cahnge 
that...

Bytecode patching is a no go here :)

Thanks for all your suggestions...


-Ursprüngliche Nachricht-
Von: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Gesendet: Montag, 8. Juni 2015 19:03
An: users@maven.apache.org
Betreff: Re: Help needed with a strange fixed filename

Can you explain how  jarfile3.jar gets turned into jarfile-3.x.x?

Lots of jar file names have numbers as the last character without that
character getting turned into a version in Nexus.

I can see how it would get loaded into Nexus as jarfile3-1.0.0 but not
jarfile-3.1.0.0

Getting rid of the version number at the end of the file name at build
time is an easier task that changing the name.

Ron



On 08/06/2015 12:44 PM, Curtis Rueden wrote:

Hi Thomas,


it's name cannot be changed because during runtime it is checked and
if changed a runtime exception is thrown

IMHO, the fact that your third party JAR does that is incredibly terrible.


Yes, we could change the code with the filename check. But I'm loath
to do it since it is a 3rd party jar file and we had to do this every
time a new version is released...

One "big hammer" way to work around this, and other horrible third party
behaviors, is bytecode manipulation using a library such as Javassist or
ASM. Also called "runtime patching," you can make a surgical change to the
stupid exception thrown by the 3rd party library, which will be resistant
to future upgrades of that library. It does require careful use of
ClassLoaders, though. It would be much more ideal to work with the upstream
vendor/developers to fix the problem there.

Regards,
Curtis

On Mon, Jun 8, 2015 at 8:10 AM, Thomas Klöber <
thomas.kloe...@securintegration.com> wrote:


Hi Karl Heinz,

thanks for your answer.

Yes, we could change the code with the filename check. But I'm loath to do
it since it is a 3rd party jar file and we had to do this every time a new
version is released...

I'm just surprised that there is no other way or means to tell Maven that
a different naming scheme should be used...

Deployment at customer site is no problem, the nexus and naming issue only
affects us during development.


-Ursprüngliche Nachricht-
Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Gesendet: Freitag, 5. Juni 2015 14:34
An: Maven Users List
Betreff: Re: Help needed with a strange fixed filename

Hi Thomas,


That the file is names in Nexus is the default naming schema within a
maven repository so there is no chance to change it.

So first question: Why not changing the code which checks the filename
and follow the naming convention..?

What you can do is to get the appropriate artifact via plugin (like
maven-dependency-plugin) and rename it during the packaging of your
distribution archive (which i assume you have?) Or are we talking about
an EAR file?




On 6/5/15 1:58 PM, Thomas Klöber wrote:

Hi folks'es,

I am having some problems, getting

Re: Help needed with a strange fixed filename

2015-06-08 Thread Ron Wheeler


Can you explain how  jarfile3.jar gets turned into jarfile-3.x.x?

Lots of jar file names have numbers as the last character without that 
character getting turned into a version in Nexus.


I can see how it would get loaded into Nexus as jarfile3-1.0.0 but not 
jarfile-3.1.0.0


Getting rid of the version number at the end of the file name at build 
time is an easier task that changing the name.


Ron



On 08/06/2015 12:44 PM, Curtis Rueden wrote:

Hi Thomas,


it's name cannot be changed because during runtime it is checked and
if changed a runtime exception is thrown

IMHO, the fact that your third party JAR does that is incredibly terrible.


Yes, we could change the code with the filename check. But I'm loath
to do it since it is a 3rd party jar file and we had to do this every
time a new version is released...

One "big hammer" way to work around this, and other horrible third party
behaviors, is bytecode manipulation using a library such as Javassist or
ASM. Also called "runtime patching," you can make a surgical change to the
stupid exception thrown by the 3rd party library, which will be resistant
to future upgrades of that library. It does require careful use of
ClassLoaders, though. It would be much more ideal to work with the upstream
vendor/developers to fix the problem there.

Regards,
Curtis

On Mon, Jun 8, 2015 at 8:10 AM, Thomas Klöber <
thomas.kloe...@securintegration.com> wrote:


Hi Karl Heinz,

thanks for your answer.

Yes, we could change the code with the filename check. But I'm loath to do
it since it is a 3rd party jar file and we had to do this every time a new
version is released...

I'm just surprised that there is no other way or means to tell Maven that
a different naming scheme should be used...

Deployment at customer site is no problem, the nexus and naming issue only
affects us during development.


-Ursprüngliche Nachricht-
Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Gesendet: Freitag, 5. Juni 2015 14:34
An: Maven Users List
Betreff: Re: Help needed with a strange fixed filename

Hi Thomas,


That the file is names in Nexus is the default naming schema within a
maven repository so there is no chance to change it.

So first question: Why not changing the code which checks the filename
and follow the naming convention..?

What you can do is to get the appropriate artifact via plugin (like
maven-dependency-plugin) and rename it during the packaging of your
distribution archive (which i assume you have?) Or are we talking about
an EAR file?




On 6/5/15 1:58 PM, Thomas Klöber wrote:

Hi folks'es,

I am having some problems, getting an external jar-file into my Maven

project.

Here is the issue:

· the jar file has a fixed name, lets say jarfile3.jar (digit 3

is important!)

· it's name cannot be changed because during runtime it is

checked and if changed a runtime exception is thrown

·  if I create an artefact for it in my nexus, the file name is

changed to jarfile-3.x.x

· adding this to my pom.xml as a dependency everything builds

just fine

· however, if I run my application now, it falls over with the

above runtime exception

What would be the best way of incoorporating an external jar into my

project without having hard-coded pathnames?

We are using Eclipse Kepler as IDE and Maven 3

Thanks,
_
SecurIntegration
Thomas Klöber
Software Engineer
Rösrather Str. 702
51107 Köln
Fon: +49 (221) 71 99 00-0
Fax: +49 (221) 71 99 00-23

www.SecurIntegration.com<http://www.SecurIntegration.com>

Amtsgericht Köln HRB 35063
Geschäftsführer: Guido Schneider

Determine your actual SAP license needs<

http://www.securintegration.com/slc>



Kind regards
Karl Heinz Marbaise

-
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: Skill set to maintain a enterprise build system using Maven

2015-05-31 Thread Ron Wheeler


On 30/05/2015 10:44 PM, Dan Tran wrote:

Hi Ron

One person may not be desirable  since he/she may win a lottery :-)
I sell Learning Management Systems that include Talent and Succession 
Planning so I will just say that you should be able to find a backup in 
your pool of potential successors for any key position.:-)


The actual change to a POM is not a high skill job once you have the 
project's policies and initial POMs in place.




Developers should not change the POM who would? RelEng?


It should be set up by a senior architect or architectural team that is 
making and supporting the team's policies for dependency selection and 
release strategy.
We had pretty good success with simple POMs that individual developers 
were not permitted (not much enforcement required) to alter.


If a developer has a need for a new dependency or a change in version, 
it has to be a team decision with the project manager's OK.


Ron




Thanks

-Dan

On Sat, May 30, 2015 at 3:22 PM, Ron Wheeler 
wrote:
On 30/05/2015 1:29 AM, Dan Tran wrote:


Hi


   I would like to ask if the community can share with me what it takes to
maintain an enterprise build system with continuous integration of 100+
developer + QA and growing using Maven.  The build system contains many
components with their own release cycle and they do integrate together.


 - is java skill set to develop plugin a must?


a) Most projects should not need to develop plug-ins.
b) This is a one-time need if it exists and there are companies and
consultants available to do this for you


 - do you have a team or just a few of deep understanding of Maven
developers?


One personwill do.


 - will a none java RelEng able to perform Maven release?


Sure


 - does your RelEng maintains the pom or developers?


developers should not touch POMs


 - what are your challenges?


a) adjusting your project structure and methodology to incorporate "the
maven way"
b) resisting the impulse to try to impose an existing mindset about
development and build processes on Maven

  Thanks

-Dan



--
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





--
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: Skill set to maintain a enterprise build system using Maven

2015-05-30 Thread Ron Wheeler


On 30/05/2015 1:29 AM, Dan Tran wrote:

Hi


  I would like to ask if the community can share with me what it takes to
maintain an enterprise build system with continuous integration of 100+
developer + QA and growing using Maven.  The build system contains many
components with their own release cycle and they do integrate together.


- is java skill set to develop plugin a must?

a) Most projects should not need to develop plug-ins.
b) This is a one-time need if it exists and there are companies and 
consultants available to do this for you

- do you have a team or just a few of deep understanding of Maven
developers?

One personwill do.

- will a none java RelEng able to perform Maven release?

Sure

- does your RelEng maintains the pom or developers?

developers should not touch POMs

- what are your challenges?
a) adjusting your project structure and methodology to incorporate "the 
maven way"
b) resisting the impulse to try to impose an existing mindset about 
development and build processes on Maven



Thanks

-Dan




--
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: Snapshot artifact differentiation

2015-05-28 Thread Ron Wheeler

Can you give each developer their own snapshot repo (perhaps hosted on 
the virtual machine that is running their tests) that their virtual 
machine uses for snapshots?

Releases would come from the central release repo.

This would be easy to do with Nexus and probably easy with other Maven 
repos.


Developer deploys the latest SNAPSHOT to their repo (defined in their 
settings..XML)

Their repo acts as a proxy for the central release repo.
The test VMs use their local repo to resolve both SNAPSHOTs and releases.

The open question is "does developer A want to get SNAPSHOTS from 
Developer B?
Developer A could do this manually by checking out the team SNAPSHOTs 
(developer B's latest committed) and using "mvn deploy" to load the 
SNAPSHOT into developer A's private repo.


Ron
On 28/05/2015 12:54 PM, Morgan Fletcher wrote:

We often have a virtual machine for each developer, where they can deploy
code from their own branch (foo) for testing, in a continuous manner. These
virtual machines use a configuration management tool to pull binaries from
a remote drive, built by a continuous integration build server. The code is
built by maven 3.

We use classic maven versioning, i.e. X.Y-snapshot.

A developer wants to be able to recycle their virtual machine with the
latest code. The virtual machine only knows to get the binaries based on
the version coded into its configuration management instructions, from the
remote drive. Previously we had allowed folders to have the branch name
(foo), but now we have switched to a strict maven model where branch names
are not stored in the remote drive.

The developer branch foo will eventually be merged into the shared branch
that all developers consume, and which is deployed to canonical systems in
a test environment.

In this scenario, how would you recommend the developer either name, or
deliver their binaries to their own virtual machine, so that they don't
share those binaries with their co-workers?

Morgan




--
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: Use of one POM parent or many each for a scope

2015-05-28 Thread Ron Wheeler


Sounds like you are thinking about something similar to what we use.
Works very well and makes life very easy for developers.

http://blog.artifact-software.com/tech/?p=121


Ron

On 28/05/2015 10:30 AM, Mehdi Hayani wrote:

Hello team,


Actually, I'm building a pom parent that all applications under the enitty
where I'm working will have to implement.

The idea is to specify all the dependencies and plugins inside the pom
parent with the version using the dependencyManagement and
pluginManagement, and at the application level, only mention the required
plugin.

Since not all the applications use the same technos, I got the idea of
creating pom parent by scope (for Spring, for JAXRS, ...) and thereafter
include those pom in a global pom parent that will be inherited by each
applications.

I don't know if you've faced this before, but I'm asking which one is
recommended ? using one pom parent that contains declaration of all
dependencies or create mini pom parent by scope and include them in the pom
parent as dependencies ?


hanks in advance for you help.


Regards




--
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: Trouble with excludes

2015-05-26 Thread Ron Wheeler



On 26/05/2015 9:11 PM, Joris Kinable wrote:

testExcludes:
http://maven.apache.org/plugins/maven-compiler-plugin/testCompile-mojo.html#testExcludes
"A list of exclusion filters for the compiler."

It must be a fairly easy task to tell maven to exclude a particular
directory from compiling.

I think there are 2 very simple use cases:
1. your build your project using maven, however the build fails because one
of the unit tests fails: you may want to temporarily disable running the
unit test without deleting the unit test.

Easier to comment out the test.

2. your build fails because your unit test fails to compile: you may want
to temporarily disable compiling the unit test.

Maven can skip all tests at the command line.

So using

   **/**

but I cannot seem to filter for individual directories/classes.

Joris

On Tue, May 26, 2015 at 9:01 PM, Ron Wheeler 
wrote:
Where did you read that this was possible?
Have you scanned some of the manuals and guides to see if you can find a
case like this?

I am not sure that there is a use case for this.

Ron




On 26/05/2015 8:55 PM, Joris Kinable wrote:


Thank you for the suggestion. Nevertheless, I would like to learn how to
remove a particular directory of tests from the compile and run cycle:
This successfully prevents *all* tests from being compiled:

org.apache.maven.plugins
maven-compiler-plugin
3.3

1.8
1.8

**/**




However, I cannot seem to disable just jorlib-core/src/test/java/org/
jorlib/frameworks/columnGeneration/tsp e.g. adding:

**/frameworks/**
**/org/jorlib/frameworks/columnGeneration/tsp/*

doesn't do anything.

Joris

On Tue, May 26, 2015 at 8:44 PM, Ron Wheeler <
rwhee...@artifact-software.com


wrote:
It sounds like they belong in a separate project that includes the Cplex
test sources, possibly with your test sources with a pom to compile and
run
tests with Cplex and  a README about how to compile and test them in
conjunction with your code. This should be used to produce a ZIP or TAR
(or
both).
The pom would include dependencies on your libraries.

Since you are not going to test them, there is not much point in having
them in with your tests.

The maven rule (best practice) of one pom for one output artifact, often
leads to simple solutions for these types of problems.

You might want to consider packaging your final deliverable using an
installer that does the right thing when the sys admin wants to install
with or without  the Cplex option.
This would take all of your artifacts and produce an installer. I use
IzPack which is an open source product but other installers could
probably
do this in a simple way.

Ron

On 26/05/2015 8:22 PM, Joris Kinable wrote:

  The files under

jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
are a useful set of test classes, but unfortunately they rely on
a proprietary, expensive package called Cplex, whereas all the other
test
classes are either self-contained or rely on open-source packages. I
want
the sources of
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
to be preserved, but I don't want to compile or run them. Anyone who
downloads the release still has access to these sources so if he/she
owns
the Cplex package, he/she can manually perform these tests. However, if
you
don't own this package, then you can still compile the code without
running
into dependency issues.
Nevertheless, when I run: mvn compile, everything works great. However,
when I run mvn test or mvn package, maven tries to compile
jorlib-core/src/
*test*/java/org/jorlib/frameworks/columnGeneration/tsp, even though I
added

(and many various thereof):


columnGeneration/tsp/**


to:


org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8

 columnGeneration/tsp/**




Any suggestions are highly welcome!

Joris

On Tue, May 26, 2015 at 7:52 PM, Ron Wheeler <
rwhee...@artifact-software.com

  wrote:

Why are these sources in the project if they don't need to be compiled?
Are they really java sources?
If so, why don't they compile? If not, should they just be resources
rather than sources?

Ron


On 26/05/2015 5:27 PM, Joris Kinable wrote:

   Dear,


I'm trying to set up my first maven project for my code which can be
found
here:
https://github.com/jkinable/jorlib

I have 3 pom files:
https://github.com/jkinable/jorlib/blob/master/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-demo/pom.xml

I would like to exclude all files in the following directory from both
compilation and testing (but the sources need to be retained):
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp

I've tried to include pretty much every  ... 
pattern I
could think of to the following plugins:

org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8


in https://github.com/jkinable/jorlib/blob/master/pom.xml


and


  org.ap

Re: Trouble with excludes

2015-05-26 Thread Ron Wheeler


Where did you read that this was possible?
Have you scanned some of the manuals and guides to see if you can find a 
case like this?


I am not sure that there is a use case for this.

Ron



On 26/05/2015 8:55 PM, Joris Kinable wrote:

Thank you for the suggestion. Nevertheless, I would like to learn how to
remove a particular directory of tests from the compile and run cycle:
This successfully prevents *all* tests from being compiled:

org.apache.maven.plugins
maven-compiler-plugin
3.3

1.8
1.8

   **/**




However, I cannot seem to disable just jorlib-core/src/test/java/org/
jorlib/frameworks/columnGeneration/tsp e.g. adding:

   **/frameworks/**
   **/org/jorlib/frameworks/columnGeneration/tsp/*

doesn't do anything.

Joris

On Tue, May 26, 2015 at 8:44 PM, Ron Wheeler 
wrote:
It sounds like they belong in a separate project that includes the Cplex
test sources, possibly with your test sources with a pom to compile and run
tests with Cplex and  a README about how to compile and test them in
conjunction with your code. This should be used to produce a ZIP or TAR (or
both).
The pom would include dependencies on your libraries.

Since you are not going to test them, there is not much point in having
them in with your tests.

The maven rule (best practice) of one pom for one output artifact, often
leads to simple solutions for these types of problems.

You might want to consider packaging your final deliverable using an
installer that does the right thing when the sys admin wants to install
with or without  the Cplex option.
This would take all of your artifacts and produce an installer. I use
IzPack which is an open source product but other installers could probably
do this in a simple way.

Ron

On 26/05/2015 8:22 PM, Joris Kinable wrote:


The files under
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
are a useful set of test classes, but unfortunately they rely on
a proprietary, expensive package called Cplex, whereas all the other test
classes are either self-contained or rely on open-source packages. I want
the sources of
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
to be preserved, but I don't want to compile or run them. Anyone who
downloads the release still has access to these sources so if he/she owns
the Cplex package, he/she can manually perform these tests. However, if
you
don't own this package, then you can still compile the code without
running
into dependency issues.
Nevertheless, when I run: mvn compile, everything works great. However,
when I run mvn test or mvn package, maven tries to compile
jorlib-core/src/
*test*/java/org/jorlib/frameworks/columnGeneration/tsp, even though I
added

(and many various thereof):


columnGeneration/tsp/**


to:


org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8

columnGeneration/tsp/**




Any suggestions are highly welcome!

Joris

On Tue, May 26, 2015 at 7:52 PM, Ron Wheeler <
rwhee...@artifact-software.com


wrote:
Why are these sources in the project if they don't need to be compiled?
Are they really java sources?
If so, why don't they compile? If not, should they just be resources
rather than sources?

Ron


On 26/05/2015 5:27 PM, Joris Kinable wrote:

  Dear,

I'm trying to set up my first maven project for my code which can be
found
here:
https://github.com/jkinable/jorlib

I have 3 pom files:
https://github.com/jkinable/jorlib/blob/master/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-demo/pom.xml

I would like to exclude all files in the following directory from both
compilation and testing (but the sources need to be retained):
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp

I've tried to include pretty much every  ... 
pattern I
could think of to the following plugins:

org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8


in https://github.com/jkinable/jorlib/blob/master/pom.xml


and


 org.apache.maven.plugins
 maven-jar-plugin
 2.4
 
 



${project.build.outputDirectory}/META-INF/MANIFEST.MF
 
 

in https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml

Yet "mvn package" keeps compiling (and crashing) on files in the
directory
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
Any suggestions on how to solve this?

Thank you,

Joris


  --

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




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---

Re: Trouble with excludes

2015-05-26 Thread Ron Wheeler

It sounds like they belong in a separate project that includes the Cplex 
test sources, possibly with your test sources with a pom to compile and 
run tests with Cplex and  a README about how to compile and test them in 
conjunction with your code. This should be used to produce a ZIP or TAR 
(or both).

The pom would include dependencies on your libraries.

Since you are not going to test them, there is not much point in having 
them in with your tests.


The maven rule (best practice) of one pom for one output artifact, often 
leads to simple solutions for these types of problems.


You might want to consider packaging your final deliverable using an 
installer that does the right thing when the sys admin wants to install 
with or without  the Cplex option.
This would take all of your artifacts and produce an installer. I use 
IzPack which is an open source product but other installers could 
probably do this in a simple way.


Ron

On 26/05/2015 8:22 PM, Joris Kinable wrote:

The files under
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
are a useful set of test classes, but unfortunately they rely on
a proprietary, expensive package called Cplex, whereas all the other test
classes are either self-contained or rely on open-source packages. I want
the sources of 
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
to be preserved, but I don't want to compile or run them. Anyone who
downloads the release still has access to these sources so if he/she owns
the Cplex package, he/she can manually perform these tests. However, if you
don't own this package, then you can still compile the code without running
into dependency issues.
Nevertheless, when I run: mvn compile, everything works great. However,
when I run mvn test or mvn package, maven tries to compile jorlib-core/src/
*test*/java/org/jorlib/frameworks/columnGeneration/tsp, even though I added
(and many various thereof):


columnGeneration/tsp/**


to:


org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8

   columnGeneration/tsp/**




Any suggestions are highly welcome!

Joris

On Tue, May 26, 2015 at 7:52 PM, Ron Wheeler 
wrote:
Why are these sources in the project if they don't need to be compiled?
Are they really java sources?
If so, why don't they compile? If not, should they just be resources
rather than sources?

Ron


On 26/05/2015 5:27 PM, Joris Kinable wrote:


Dear,

I'm trying to set up my first maven project for my code which can be found
here:
https://github.com/jkinable/jorlib

I have 3 pom files:
https://github.com/jkinable/jorlib/blob/master/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-demo/pom.xml

I would like to exclude all files in the following directory from both
compilation and testing (but the sources need to be retained):
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp

I've tried to include pretty much every  ...  pattern I
could think of to the following plugins:

org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8


in https://github.com/jkinable/jorlib/blob/master/pom.xml


and


org.apache.maven.plugins
maven-jar-plugin
2.4




${project.build.outputDirectory}/META-INF/MANIFEST.MF



in https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml

Yet "mvn package" keeps compiling (and crashing) on files in the directory
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
Any suggestions on how to solve this?

Thank you,

Joris



--
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





--
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: Trouble with excludes

2015-05-26 Thread Ron Wheeler


Why are these sources in the project if they don't need to be compiled?
Are they really java sources?
If so, why don't they compile? If not, should they just be resources 
rather than sources?


Ron

On 26/05/2015 5:27 PM, Joris Kinable wrote:

Dear,

I'm trying to set up my first maven project for my code which can be found
here:
https://github.com/jkinable/jorlib

I have 3 pom files:
https://github.com/jkinable/jorlib/blob/master/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml
https://github.com/jkinable/jorlib/blob/master/jorlib-demo/pom.xml

I would like to exclude all files in the following directory from both
compilation and testing (but the sources need to be retained):
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp

I've tried to include pretty much every  ...  pattern I
could think of to the following plugins:

org.apache.maven.plugins
maven-compiler-plugin
3.1

1.8
1.8


in https://github.com/jkinable/jorlib/blob/master/pom.xml


and


   org.apache.maven.plugins
   maven-jar-plugin
   2.4
   
   

  
${project.build.outputDirectory}/META-INF/MANIFEST.MF
   
   

in https://github.com/jkinable/jorlib/blob/master/jorlib-core/pom.xml

Yet "mvn package" keeps compiling (and crashing) on files in the directory
jorlib-core/src/test/java/org/jorlib/frameworks/columnGeneration/tsp
Any suggestions on how to solve this?

Thank you,

Joris




--
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: create one unique directroy for my project with the timestamp format. Please help me

2015-05-16 Thread Ron Wheeler



What are you trying to accomplish?

What configuration files?
What are you trying to build as an application?
What is the purpose of the time stamp?

Ron

On 16/05/2015 10:50 AM, Aitor Iturriondobeitia wrote:

Hello

i am trying, during several days, to buids my proyects, copy my
configurations... to one directory
thsi directory must be unique and the name must to have the timestap format
(MMdd-HH.mm.ss)
i cannot, i am unable to get it. can you help me please?
i have the next project structure.
i must to set one directory, into the parent (proyect parent1) into one
variable ant this variable must to have the timestap value into
MMdd-HH.mm.ss format

if into the project parent2, project parent 3, project parent n i write the
directory using the varaible value alway change it to the compilation time.
how can i load one unique value for this timestap into one property for
usint into all projects?

thanks

*proyect parent1
  |--project parent2
  ||--project1.1
  |  |--project1.2
  |  |--project1.3
  |   |--project1.n
  |--proyect parent3
  ||--project2.1
  ||--project2.2
  |  |--project2.3
  |  |--project2.n
  |--project parentn
   |--projectn.1
   |--projectn.2
   |--projectn.3
|--projectn.n




--
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: Can not understand why maven is ALWAYS choosing a 3rd repo BEFORE my nexus one?

2015-05-08 Thread Ron Wheeler

Is it possible that Maven is having the same trouble as Nexus and can 
not get into the repo and just moves on to the next one since it has no 
idea about which dependency is going to be found in the repo and maybe 
the next one will work better and get it everything that it needs.


It would not make sense to wait forever on a repo that will not talk to 
Maven.


Can you download the artifact manually and add it to your repo and move on.

Ron


On 08/05/2015 3:40 PM, Rick R wrote:

I mention that at the end of the above email... for some reason I'm having
trouble proxing this one ZK repository that requires a username and
password (which I've added in the nexus auth settings.)  I think the error
Nexus mentioned was "remote access not allowed" or something to that
effect.

On Fri, May 8, 2015 at 3:03 PM, Ron Wheeler 
wrote:


Why not have your repo proxy the extra ones so everyone's settings.xml
points to your repo and its is up to the repo manager to set up the
permitted repo.

Ron


On 08/05/2015 2:39 PM, Rick R wrote:


I'm trying to figure out why Maven is choosing a 3rd party repo defined in
my settings xml BEFORE trying to search in our internal Nexus repo.

My settings xml has the following profile which is set as the active one.


  
ncs-main

   

  ZK EE
  https://maven.zkoss.org/repo/zk/ee



  zk repository
  http://mavensync.zkoss.org/maven2



  nexus.repo.all
  
http://dayrhencvp011.enterprisenet.org:8080/nexus/content/groups/public/

  
true
  




  

My project's pom does not have any repositories specified. I tried messing
with the order of the repositories above (flipping them around different
ways) but it always seems to go after one of the ZK ones first:


Downloading:

http://dayrhencvp011.enterprisenet.org:8080/nexus/content/groups/public/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml

Downloading:

http://mavensync.zkoss.org/maven2/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml

Downloading:

https://maven.zkoss.org/repo/zk/ee/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml

Downloaded:

http://dayrhencvp011.enterprisenet.org:8080/nexus/content/groups/public/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml
(769 B at 2.5 KB/sec)

[WARNING] Could not transfer metadata
com.ncs:ncs-data-domain:1.12-SNAPSHOT/maven-metadata.xml from/to ZK EE (
https://maven.zkoss.org/repo/zk/ee): Connection to
https://maven.zkoss.org
refused

[WARNING] Failure to transfer
com.ncs:ncs-data-domain:1.12-SNAPSHOT/maven-metadata.xml from
https://maven.zkoss.org/repo/zk/ee was cached in the local repository,
resolution will not be reattempted until the update interval of ZK EE has
elapsed or updates are forced. Original error: Could not transfer metadata
com.ncs:ncs-data-domain:1.12-SNAPSHOT/maven-metadata.xml from/to ZK EE (
https://maven.zkoss.org/repo/zk/ee): Connection to
https://maven.zkoss.org
refused

Of course it found ncs-data-domain in the 3rd attempt above (form nexus)
but why does it always try the maven ones first?

Even when I switch the order around it's trying zk-ee FIRST.

Very frustrating and can't find any documentation on it.


(Note, if you're wondering why I didn't put this 3rd party repo in Nexus,
I
tried but it was complaining about unable to work with it.. forgot the
exact error.. it has to be authenticated with a username and password and
I
tried adding that to nexus as well, but was having trouble so I left the
definition in my settings.xml)



--
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







--
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: Can not understand why maven is ALWAYS choosing a 3rd repo BEFORE my nexus one?

2015-05-08 Thread Ron Wheeler

Why not have your repo proxy the extra ones so everyone's settings.xml 
points to your repo and its is up to the repo manager to set up the 
permitted repo.


Ron

On 08/05/2015 2:39 PM, Rick R wrote:

I'm trying to figure out why Maven is choosing a 3rd party repo defined in
my settings xml BEFORE trying to search in our internal Nexus repo.

My settings xml has the following profile which is set as the active one.


 
   ncs-main

  
   
 ZK EE
 https://maven.zkoss.org/repo/zk/ee
   

   
 zk repository
 http://mavensync.zkoss.org/maven2
   

   
 nexus.repo.all
 
http://dayrhencvp011.enterprisenet.org:8080/nexus/content/groups/public/

 
   true
 
   

   

 

My project's pom does not have any repositories specified. I tried messing
with the order of the repositories above (flipping them around different
ways) but it always seems to go after one of the ZK ones first:


Downloading:
http://dayrhencvp011.enterprisenet.org:8080/nexus/content/groups/public/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml

Downloading:
http://mavensync.zkoss.org/maven2/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml

Downloading:
https://maven.zkoss.org/repo/zk/ee/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml

Downloaded:
http://dayrhencvp011.enterprisenet.org:8080/nexus/content/groups/public/com/ncs/ncs-data-domain/1.12-SNAPSHOT/maven-metadata.xml
(769 B at 2.5 KB/sec)

[WARNING] Could not transfer metadata
com.ncs:ncs-data-domain:1.12-SNAPSHOT/maven-metadata.xml from/to ZK EE (
https://maven.zkoss.org/repo/zk/ee): Connection to https://maven.zkoss.org
refused

[WARNING] Failure to transfer
com.ncs:ncs-data-domain:1.12-SNAPSHOT/maven-metadata.xml from
https://maven.zkoss.org/repo/zk/ee was cached in the local repository,
resolution will not be reattempted until the update interval of ZK EE has
elapsed or updates are forced. Original error: Could not transfer metadata
com.ncs:ncs-data-domain:1.12-SNAPSHOT/maven-metadata.xml from/to ZK EE (
https://maven.zkoss.org/repo/zk/ee): Connection to https://maven.zkoss.org
refused

Of course it found ncs-data-domain in the 3rd attempt above (form nexus)
but why does it always try the maven ones first?

Even when I switch the order around it's trying zk-ee FIRST.

Very frustrating and can't find any documentation on it.


(Note, if you're wondering why I didn't put this 3rd party repo in Nexus, I
tried but it was complaining about unable to work with it.. forgot the
exact error.. it has to be authenticated with a username and password and I
tried adding that to nexus as well, but was having trouble so I left the
definition in my settings.xml)




--
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

dependency plug-in docs wrong or misleading.

2015-05-07 Thread Ron Wheeler

In 
http://maven.40175.n5.nabble.com/copy-libraries-to-classpath-td110698.html, 
Brian Fox wrote a key response with a reference to an obscure reference 
in the dependency FAQ 
athttps://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html


Buried in the FAQ under copying from the command line it states "you 
must not put the configuration inside the/executions/tag."


This should be added as a configuration and explanation to the main 
examples page  at 
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html



  [...]
  

  
org.apache.maven.plugins
maven-dependency-plugin
2.10

  
copy-dependencies
package

  copy-dependencies


  
${project.build.directory}/alternateLocation
  false
  false
  true

  

  

  
  [...]


If you are running from the command line of from an IDE, you need to change the 
position of the configuration section to be a sibling of the  
element


  [...]
  

  
org.apache.maven.plugins
maven-dependency-plugin
2.10


${project.build.directory}/alternateLocation
false
false
true


  
copy-dependencies
package

  copy-dependencies

  

  

  
  [...]




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Possibly obsolete page in docs

2015-05-07 Thread Ron Wheeler


https://maven.apache.org/plugins/maven-dependency-plugin/examples/preparing-dependencies.html
Is this relevant or can it be removed?
If it must stay could someone update it with references to a current 
version.


Ron

--
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: Adding comments to dependencies in POM

2015-04-23 Thread Ron Wheeler


On 23/04/2015 4:32 AM, Tomasz Borek wrote:

I'm actually quite surprised by this thread. My perspective on adding a
comment tag is different to most here:

A)nother tag in XML *MIGHT* help with letting me know why XYZ was added. IF
people will remember to fill it out. And XYZ removal cuts out the comment
as well, so if somebody removed a dependency / other I was relying on, I'm
no smarter.
If the person read the comment and still deleted the dependency, at 
least they knew what the impact would be on the build.
One has to assume that people who are allowed to change software are 
responsible.

B)loated / bigger XML, another tag to fill in, for each dependency, yay! :/
I would only use it where the need for the dependency is obscure or as 
in my example Use Case 2 the version can not be changed for a known 
reason that might not be known by others.

You are right that putting useless comments would not be helpful.


C)hanges monitoring is what SCM is designed for. Just have your POM under
version control and you'll see when what and why was removed/changed/added.
Hoping to avoid a retrospective analysis and search for a perpetrator by 
letting people know in advance that the pom statements that look like 
they should be fixed, are actually there for a reason.




For me the idea ain't appealing, it's actually slightly on the "no, I don't
want" side.

pozdrawiam,
LAFK

2015-04-21 0:31 GMT+02:00 Jim Klo :


On Apr 20, 2015, at 2:38 PM, Ron Wheeler 
wrote:

On 20/04/2015 4:55 PM, Jim Klo wrote:

Comments inline below..

On Apr 20, 2015, at 10:44 AM, Ron Wheeler mailto:rwhee...@artifact-software.com >>
wrote:

RDF sounds like overkill. There is no reason why a comment could not be a
URI but I am not sure that you want to mandate that.
Use Case 1 link to web resource
http://blog.artifact-software.com/tech/?p=191”>


Having dealt with this sort of thing on other projects, linked comments
sound good at first but ultimately become a very bad idea IMO. This creates
a non-idempotent and brittle link scenario where the comment url is out of
synch with the content in the POM.


Use Case 2 lots of in-line deatils
   
   org.apache.xmlgraphics
   fop
   1.0
   true
   

Use case 3 reference to a full explanation in the description
There is also the description tag which could be used to hold more details
   http://maven.apache.org/comments/1.0.0”>
…

http://example.com/foo-123
)”>



Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec et
vestibulum odio, at porttitor nunc. Donec pulvinar erat quis accumsan
interdum. Nunc at viverra nunc. Mauris purus ipsum, aliquam vitae nisi
eget, faucibus auctor leo. Duis ipsum leo, viverra eleifend viverra in,
tristique vitae tortor. Interdum et malesuada fames ac ante ipsum primis in
faucibus. Suspendisse tempus nisl dui, at rutrum massa porta id.
Suspendisse ultricies est vel pretium egestas. In orci ipsum, vehicula non
accumsan quis, pellentesque ac ipsum. Maecenas maximus ornare tempus. Fusce
libero ligula, tempor mattis pretium et, consectetur ut sapien. Aliquam
rhoncus lorem erat. Nullam et.



Are you proposing that comment tags be allowed inside all tags or just
some.

I would suggest comment attributes on all elements.


I would vote for a comment element to be a child of any tag and a comment
attribute be available on all elements. However when considering a more
global solution, I would think adding a specific namespace for comments
makes a whole lot more sense and would be a more portable solution and
avoid collisions with existing plug-ins. IMO it’s easier to update base
parsers to disregard elements from foreign namespaces than to hope to avoid
collisions with existing plug-ins.  However that’s a gut feeling without
doing any investigation as to what the scope of impact a change like that
would really mean. If it really isn't a huge problem to just add comments
to the POM namespace, that would be my #1 choice.








--
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: maven compiler plugin + toolchains

2015-04-22 Thread Ron Wheeler

Would setting a property ( 1.6 
) in your parent and using the property as the 
value ($java_compliance_version )in the source, work?


Ron


On 22/04/2015 2:42 PM, intel radoux wrote:

Hello,

I wish to set something like this in my parent pom :


 org.apache.maven.plugins
 maven-compiler-plugin
 3.3
 
 1.6
 1.6
 
 
 
 org.apache.maven.plugins
 maven-toolchains-plugin
 1.1
 
 
 

${project.build.pluginsAsMap(org.apache.maven.plugins:maven-compiler-plugin).configuration.children[0].value}

 
 
 
 
 
 
 toolchain
 
 
 
 

so that I can only set the source level in one place. The idea is that I
can set another level in one child module and toolchain will select the
correct JDK.
  
 org.apache.maven.plugins
 maven-compiler-plugin
 3.3
 
 1.7
 1.7
 
 

unfortunatly this don't work has ${project.build... } is not resolved
when set in configuration element.
Do somebody have another idea on how to set this ? (why toolchain doesn't
work hand on hand with compiler plugins ? )

Thank you




--
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: Adding comments to dependencies in POM

2015-04-20 Thread Ron Wheeler


On 20/04/2015 4:55 PM, Jim Klo wrote:

Comments inline below..

On Apr 20, 2015, at 10:44 AM, Ron Wheeler 
<mailto:rwhee...@artifact-software.com>> wrote:


RDF sounds like overkill. There is no reason why a comment could not 
be a URI but I am not sure that you want to mandate that.

Use Case 1 link to web resource
http://blog.artifact-software.com/tech/?p=191”>


Having dealt with this sort of thing on other projects, linked 
comments sound good at first but ultimately become a very bad idea 
IMO. This creates a non-idempotent and brittle link scenario where the 
comment url is out of synch with the content in the POM.




Use Case 2 lots of in-line deatils
   
   org.apache.xmlgraphics
   fop
   1.0
   true

   

Use case 3 reference to a full explanation in the description
There is also the description tag which could be used to hold more 
details

   

I’m not sure I’m seeing a difference between UC 2 & 3. Unless you mean 
something more like this for UC 3:

  
 ...
for the following reasons:….”>


I was thinking that the description might be Note 1: Please 
put all dependency versions in Parent, Note 2:FOP required for PDF 
output


IDE's could show comment attributes on tags in the POM editor or in 
XML outline views.


It seems to be a lot more flexible than adding comment tags and 
probably less intrusive to existing plug-ins.




I think comment tags should still be included.  Inline is great for 
short descriptions, but nothing really beats having a tag element that 
doesn’t require a lot of XML escaping like an attribute would need.


- Jim


You are looking for a lot more machine processing that I was thinking.
I was just considering comments as a way to tell people about the 
choices made.


Your  XML escaping note is a good point.
The IDE will pick up invalid text so it should not be hard to avoid but 
for people without a good IDE, they will get an error. It should only 
happen once to each person editing a pom and POMs are not edited a lot 
in most projects.



Can you give a comment tag solution for each of the use cases.
Are you proposing that comment tags be allowed inside all tags or just some.
I would suggest comment attributes on all elements.

Does anyone know what the impact would be of either solution on existing 
poms or plug-ins?


Ron

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Adding comments to dependencies in POM

2015-04-20 Thread Ron Wheeler

RDF sounds like overkill. There is no reason why a comment could not be 
a URI but I am not sure that you want to mandate that.

Use Case 1 link to web resource
http://blog.artifact-software.com/tech/?p=191";>

Use Case 2 lots of in-line deatils

org.apache.xmlgraphics
fop
1.0
true



Use case 3 reference to a full explanation in the description
There is also the description tag which could be used to hold more details


IDE's could show comment attributes on tags in the POM editor or in XML 
outline views.


It seems to be a lot more flexible than adding comment tags and probably 
less intrusive to existing plug-ins.


Ron


On 20/04/2015 1:26 PM, Robert Scholte wrote:

Would RDF[1][2] be a good option?

[1] http://www.w3.org/RDF/
[2] http://www.w3schools.com/webservices/ws_rdf_intro.asp

Op Mon, 20 Apr 2015 16:03:17 +0200 schreef Ron Wheeler 
:


I could live with this being handled by adding an attribute to the 
elements mentioned below, if that is easier than adding new elements 
to the model.


Ron



On 17/04/2015 12:06 PM, James Green wrote:

Actually I think  ought to be possible within pretty much any
"instruction" within the POM:

A dependency management item
A dependency
A build profile
A build plugin

However the first two are probably the most useful and were my original
desire. Now I can imagine this becoming the start of a more 
descriptive set
of declarations to describe the "whys" of a project but this kicks 
things

off in a pretty generic way.

And it's not just for the reader of an XML file to avoid going down 
a bunch

of upgrades to discover "why" there's a really old pinned library the
project doesn't even directly depend on. It's potentially useful for
interpreters elsewhere: imagine GitHub/IDE decide to provide a POM 
viewer

and it shows the comments within this. Might provide explanations as to
security matters and perceived bloat.



On 17 April 2015 at 16:55, Sander Verhagen 
wrote:


Hi,


I'm wondering how useful it would be to have "a" (one) comment on a
dependency. Would you rather not have commenting be an attribute of 
(yes,
indeed) a dependency, but also more-specifically of an exclusion, a 
scope

designation, etc.?

What would be some of the actual comments that you are thinking of 
here?

Perhaps this would come to life a bit more with a few good examples.

Sander.



Sander Verhagen
[  san...@sanderverhagen.net  ]


-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Friday, April 17, 2015 8:45
To: Maven Users List
Subject: Re: Adding comments to dependencies in POM

+1
Gary

 Original message 
From: James Green 
Date: 04/17/2015  04:58  (GMT-08:00)
To: Maven Users List 
Subject: Re: Adding comments to dependencies in POM

[ Dragging up a really old topic. ]

https://issues.apache.org/jira/browse/MNG-5803

Incidentally I would vote against a different namespace as 
comments are
likely to be of use to readers of Maven POMs even if they are used 
for

visual

purposes.


On 27 August 2014 at 12:03, Robert Scholte  
wrote:



I think it should be solved with a separate namespace, so the model
parsing stays pure without metadata irrelevant for Maven.
And it should already work right now, no need for the pom xsd to
change, since the Maven pom-parser should ignore these kinds of

elements/attributes.

Robert

Op Wed, 27 Aug 2014 12:15:00 +0200 schreef domi :


  +1
I think this would be a good idea, let us know about the issue, 
so we

can vote on it.
Domi

On 27.08.2014, at 09:12, James Green 

wrote:

  I have in the past wasted hours of effort trying to weed out
dependency

issues where something has been added for reasons unknown. Removal
leads to breakage.

It would be helpful if, inside a POM, it were possible to add a
comment element to a dependency. I realise this is possible as an
XML comment, however having a POM field would let documentation
engines record the comment.

The same could be said for dependencies inside

dependencyManagement.

It would of course have the side effect of auto completion within
IDEs showing authors how to "officially" comment on the reason for

that work.

An idea.

James



- 


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






-
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

Re: Adding comments to dependencies in POM

2015-04-20 Thread Ron Wheeler

I could live with this being handled by adding an attribute to the 
elements mentioned below, if that is easier than adding new elements to 
the model.


Ron



On 17/04/2015 12:06 PM, James Green wrote:

Actually I think  ought to be possible within pretty much any
"instruction" within the POM:

A dependency management item
A dependency
A build profile
A build plugin

However the first two are probably the most useful and were my original
desire. Now I can imagine this becoming the start of a more descriptive set
of declarations to describe the "whys" of a project but this kicks things
off in a pretty generic way.

And it's not just for the reader of an XML file to avoid going down a bunch
of upgrades to discover "why" there's a really old pinned library the
project doesn't even directly depend on. It's potentially useful for
interpreters elsewhere: imagine GitHub/IDE decide to provide a POM viewer
and it shows the comments within this. Might provide explanations as to
security matters and perceived bloat.



On 17 April 2015 at 16:55, Sander Verhagen 
wrote:


Hi,


I'm wondering how useful it would be to have "a" (one) comment on a
dependency. Would you rather not have commenting be an attribute of (yes,
indeed) a dependency, but also more-specifically of an exclusion, a scope
designation, etc.?

What would be some of the actual comments that you are thinking of here?
Perhaps this would come to life a bit more with a few good examples.

Sander.



Sander Verhagen
[  san...@sanderverhagen.net  ]


-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Friday, April 17, 2015 8:45
To: Maven Users List
Subject: Re: Adding comments to dependencies in POM

+1
Gary

 Original message 
From: James Green 
Date: 04/17/2015  04:58  (GMT-08:00)
To: Maven Users List 
Subject: Re: Adding comments to dependencies in POM

[ Dragging up a really old topic. ]

https://issues.apache.org/jira/browse/MNG-5803

Incidentally I would vote against a different namespace as comments are
likely to be of use to readers of Maven POMs even if they are used for

visual

purposes.


On 27 August 2014 at 12:03, Robert Scholte  wrote:


I think it should be solved with a separate namespace, so the model
parsing stays pure without metadata irrelevant for Maven.
And it should already work right now, no need for the pom xsd to
change, since the Maven pom-parser should ignore these kinds of

elements/attributes.

Robert

Op Wed, 27 Aug 2014 12:15:00 +0200 schreef domi :


  +1

I think this would be a good idea, let us know about the issue, so we
can vote on it.
Domi

On 27.08.2014, at 09:12, James Green 

wrote:

  I have in the past wasted hours of effort trying to weed out
dependency

issues where something has been added for reasons unknown. Removal
leads to breakage.

It would be helpful if, inside a POM, it were possible to add a
comment element to a dependency. I realise this is possible as an
XML comment, however having a POM field would let documentation
engines record the comment.

The same could be said for dependencies inside

dependencyManagement.

It would of course have the side effect of auto completion within
IDEs showing authors how to "officially" comment on the reason for

that work.

An idea.

James



-
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: Wrong info in "Maven: The Complete Reference", chapter 3.6.1

2015-04-09 Thread Ron Wheeler



http://blog.artifact-software.com/tech/?p=121
Does this help.
We have been doing this for years.

What problems are you having?
Don't be afraid to look inside the JAR files to see if the contents 
match your expectations.

Watch out for duplicate filenames. Only 1 will survive.

Ron


On 09/04/2015 10:19 AM, Alexander Kriegisch wrote:

Hi users and devs.

Am I too stupid to get it working or is the description in chapter 3.6.1, "Grouping 
Dependencies" 
(http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html)
 actually wrong? What is described there does not work at all in Maven 3.x. Did it ever?

Regards



--
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: Computing the maven dependency graph at runtime for unit tests?

2015-04-06 Thread Ron Wheeler



http://blog.artifact-software.com/tech/?p=121 is how we deal with this.
At he beginning of each release cycle we review the versions of the 
third party libraries that we use and update the dependencies in our 
aggregation projects.


Our application modules depend on the current version of the aggregation 
projects so developers can not change the version of a third-party 
library without changing an aggregation project which they are not 
allowed to do without the project manager's approval.
If a new library has to be added to support a new feature, this requires 
a review by the project team.


This makes everyone's life a lot simpler.
Our application projects only have a few dependencies even if we use 
dozens of Apache product as well as a few from other providers.


This also makes testing and QA a lot easier since if something stops 
working, you can be sure that it is not a third-party library getting 
changed by another developer.


We have not had to automate the enforcement of this policy.
However, we do have an SCM with history and I would know who to beat on 
if someone did an unauthorized upgrade.


Ron

On 07/04/2015 2:26 AM, Karl Heinz Marbaise wrote:

Hi Kevin,

On 4/7/15 5:18 AM, Kevin Burton wrote:

I have a few modules that I want to lock down so that I can easily keep
track of dependencies over time.

This way if a developer adds a new dependency, the test will immediately
break and someone will have to approve the change.


Can you explain a little bit more what you like to achieve, cause i'm 
a little bit puzzled that you have unit tests which checks 
dependencies...?




Is this possible? Could I embed this in a unit test or does it have 
to be a

plugin?  ideally something easy…




Kind regards
Karl Heinz Marbaise

-
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: deployment in runtime for "provided" scope jars

2015-04-06 Thread Ron Wheeler

Why not use a proper installer so that the user can run something 
user-friendly that knows how to deploy your jars and do any deploy-time 
configurations so the user does not need to know how your application works.
For example: In Windows, you would like to have your code in Program 
Files and your configuration and data in a folder of the user's choosing.
In Linux, you might want code in /usr/local/myapp with the data under 
/home or /var.



Maven is not going to be able to build you something that will do this.

IzPack is free and supports Maven. It also allows you to build an 
installer that works on different platforms.

Other packages are available to build installers as well.

Maven is a great build system but not the best tool for packaging up 
artifacts for deployment.

This leads to a lot of unhappy people.

Ron


On 06/04/2015 11:28 PM, Lin Ma wrote:

Thanks Christopher,

I am packaging a standalone console application so your suggestion below is
more suitable. Is there an example to refer to how to
configure maven-assembly-plugin to create a tar ball and a launch script?

"If you're trying to package a standalone application, maybe use the
maven-assembly-plugin to create a tarball which includes a README, all the
jars in a lib/ directory, and a launch script in bin/ which sets up the
CLASSPATH and executes java."

regards,
Lin

On Mon, Apr 6, 2015 at 7:11 PM, Christopher  wrote:


To add to what Jörg said, it is my understanding that a dependency of
your project marked as "provided" implies something about how you
intend to package it in the artifacts you create. "provided"
essentially means you don't intend to package (assemble) it (and you
expect it to be provided by the target runtime environment).

I would generally avoid "provided" entirely (because it's typically
misused), and rely on more explicit means of determining what will be
packaged/bundled/assembled into your final artifacts (the notable
exception being the servlet-api, which Jörg already mentioned).

"compile" scope for a dependency simply means that you use that
artifacts' API in your project (for example, perhaps slf4j-api).
"runtime" means that you don't need that dependency's API for your
code to compile, but it will be needed at runtime for your code to
work properly (for example, slf4j-log4j12, or perhaps a codec which is
loaded dynamically by your code, based on an annotation or class
name). "runtime" scoped artifacts can often be made "optional"
(true), because your code may work without them,
and other projects depending on your artifacts do not necessarily need
them.

Regarding "deploy them into runtime", I think you're talking about
packaging. There are several ways you can package your artifacts. You
can package it as a JAR, or a WAR. You could also use the
maven-assembly-plugin to package it into a ZIP or tarball (.tar.gz).
The maven-shade-plugin could be useful for creating a "fat jar", and
there are probably many other options also. To decide, consider what
your target environment needs. If you're trying to package a
standalone application, maybe use the maven-assembly-plugin to create
a tarball which includes a README, all the jars in a lib/ directory,
and a launch script in bin/ which sets up the CLASSPATH and executes
java.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, Apr 6, 2015 at 9:21 PM, Lin Ma  wrote:

Thanks Jörg,

It makes sense. How about for "compile" scope? What is the best practices
to deploy them into runtime along with application code? Thanks.

regards,
Lin

On Mon, Apr 6, 2015 at 6:09 PM, Jörg Schaible 

wrote:

Lin Ma wrote:


Hi Maven expert,

I think Maven is good for build, and not sure if cover runtime

deployment

well. Wondering what is the best practices for deploy "provided" scope
jars?

Currently, I either build a fat jar, or manual copy external

dependencies

jars into class path.

And better solutions is appreciated.

Don't declare them as "provided".

See, "provided" means, such a dependency is already present in the

target

environment of the application. E.g. a web application can assume that

the

application server provides servlet-api if it is compliant with the
specification.

Otherwise, "provided" is simply wrong.

- Jörg


-
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: Maven does not find existing artifacts in local repository because it looks in central where they are not?

2015-03-26 Thread Ron Wheeler


Running Maven with -x and including the relevant part of the log might help.

We are all guessing what you have screwed up.
Of course Maven has to be able to use stuff that is not in Maven Central 
otherwise none of us could ever develop a library or a project with more 
than one piece.


You should install a repo.
Nexus Community version is the one that I use but there are others.
Even if it is just on your workstation, it will help make Maven easier 
to understand and a lot easier to use.


"Free Maven Advice" (http://blog.artifact-software.com/tech/?p=177)  is 
an article that I wrote a few years ago to help people get started.
It reflects the things that we learned as a company developing with 
Maven rather than as people with inside (or very deep) knowledge about 
Maven.


The people in this forum are very helpful and a lot of them really know 
Maven well.


We will get you through this stage in your Maven journey :-)

Ron

On 26/03/2015 8:48 AM, Jörg Schaible wrote:

Hi Christian,

Christian Eugster wrote:


Hi

as I understand, there is a central repository for maven artifacts:
central (http://repo.maven.apache.org/maven2
<http://repo.maven.apache.org/maven2>) and a local one
(${user.home}/.m2/repository. What I do not understand is, why after a mvn
test maven complains about artifacts that are not in local repository. The
named artifacts are in local repository as I checked. And it says, that it
cannot download them from central. Because these artifacts are from my own
project, they are only in the local repository. Why does maven try to
download them, when they are already in local repository? Is there a wrong
setting? Does exist a reasonable documentation for beginners that is able
to explain what is going wrong?

I am thankfully for any hint!

How do you refer those artifacts? Any chance that they are included using an
import scope?

Cheers,
Jörg


-
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: Minimum JDK for mojos

2015-03-20 Thread Ron Wheeler

If you can see where you would have liked this note to appear, you 
should add it.
Documentation added by someone who was originally looking for the info 
is much more likely to be in the right place.


Ron

On 20/03/2015 1:03 AM, offbynull-maven wrote:
I understand that. But, shouldn't this be explicitly stated somewhere? 
Some official guide somewhere essentially saying that if you're 
planning on releasing your mojo publicly...


to support Maven2 you should be using JDK1.5 or lower (don't actually 
know if this is correct)

to support Maven3.0 to 3.2 you should be using JDK1.6 or lower
to support Maven3.3+ you should be using JDK1.7 or lower

On 3/19/2015 9:47 PM, Ron Wheeler wrote:

How else will it work?
If you compile it into Java 8 byte-code, the Java 6 run-time is going 
to have a tough time running it.


Ron
On 20/03/2015 12:31 AM, offbynull-maven wrote:
If the minimum JDK for Maven3 is JDK1.6, should my custom mojo 
always be built against JDK1.6 or lower?


Are there any guidelines around this?

-
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: Minimum JDK for mojos

2015-03-19 Thread Ron Wheeler


How else will it work?
If you compile it into Java 8 byte-code, the Java 6 run-time is going to 
have a tough time running it.


Ron
On 20/03/2015 12:31 AM, offbynull-maven wrote:
If the minimum JDK for Maven3 is JDK1.6, should my custom mojo always 
be built against JDK1.6 or lower?


Are there any guidelines around this?

-
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: Why would maven download a pom and not a jar?

2015-03-11 Thread Ron Wheeler

or


troubleshooting


I'm just focusing on oro-2.0.8.   Neither of my poms declare oro,


so

this

is a sub-dependency somewhere down the chain.  The process can be

reproduced every time,  and I can see from the output that the


oro-2.0.8
pom file is downloaded from the same location (local artifactory)
in

both

cases.


Does anyone know why maven would download a pom file, and then not


attempt


to download the associated jar?


Thanks,
Dan



--
---
Sent from TARDIS. Typos might be a timey whyney thingy.
Enviado da TARDIS, podem existir erros devido à diferenças de
espaço-tempo.

Cintia Del Rio





-
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: Why would maven download a pom and not a jar?

2015-03-11 Thread Ron Wheeler

1) Why not just let maven build you a jar with everything that is needed 
to run the jar? That is the normal case. Having people processing dozens 
of RPMs to run your code seems like a lot of work.


2) Are you using an IDE to develop? Eclipse/STS includes m2e which gives 
you a very clear window showing what dependencies are required and what 
is the reason for each one.


What is so different about your application that requires all this extra 
work?


Ron

On 11/03/2015 11:22 AM, Dan wrote:
Thanks again for the help.  I understand that what I'm doing is not 
standard, but I still have to implement.
So I know if i run dependency:tree on a simple pom with no deps, I 
still get well over 200 artifacts downloaded. So I am also under the 
assumption that the majority are requirements of maven or the dep 
plugin rather then my app.


What I really need is a way to determine only the deps (and sub deps) 
for the application itself.


I have two approaches I'm thinking of taking.
1. (Doesn't meet the all the requirements, but gets me out of a jam 
temporarily).   Instead of creating rpms for every artifact, only 
package up the ones which actually have a jar file in the directory.


2. Parse the output of dependency:tree, and package up only what is 
listed in that visual ascii tree. (ie: grep '^\[INFO\]').  I'm just 
don't know if I can be 100% sure that the tree does in fact list 
everything that I need.




Here are the somewhat sanitized pom files, and the output i'm getting.

# App 1
http://pastebin.com/raw.php?i=Dg3Fbaue
http://pastebin.com/raw.php?i=NEhrtwF4


# App 2
http://pastebin.com/raw.php?i=180zUFLe
http://pastebin.com/raw.php?i=VEueXysC











On 03/11/2015 02:19 AM, Baptiste Mathus wrote:
Oh right, I didn't get your meaning. You're right, could be that, 
indeed.

Should check the plugin sources to be sure.

2015-03-11 7:06 GMT+01:00 Cintia Del Rio :


When you invoke the dependency:tree, maven will download the dependency
tree plugin and all the dependencies it needs to run that plugin.


So I'd expect that every jar you now have in your local repository 
(~/.m2)

is a dependency of the dependency:tree plugin.

On 11 March 2015 at 17:02, Baptiste Mathus  wrote:


Could you rephrase? You think pom.xml is a dependency of the
"dependency:tree" goal? If so, then the answer is no.

Cheers

2015-03-11 6:59 GMT+01:00 Cintia Del Rio :


Isn't it a dependency of the dependency plugin itself?

On 11 March 2015 at 16:51, Baptiste Mathus  
wrote:



Well, in that case, since you're asking for the dependency:tree I'm

even

surprised there's any jar downloaded. Maven would only need pom to

compute

that. Downloading Jars is only done when needed (say for compiling,

etc.)

Btw, do you really type "mvn dependency:tree pom.xml" ? What do you

expect?

The "pom.xml" part is gonna lead to an error since pom.xml is not a

goal

and that's what's supposed to be listed after mvn.

As for your question: I suppose oro is a transitive dependency of 
one

of

the things you depend on. mvn dependency:tree should generally show

it

btw.

Cheers

2015-03-10 15:22 GMT+01:00 D C :


I am trying to download all dependencies from a pom file.  My steps

are:

1. delete .m2/repository
2. mvn dependency:tree pom.xml

Everything looks good, however as I browse the .m2 directory I can

see

that

for some artifacts  maven only downloaded the pom file, and did not
download the associated jar.  I then repeat the process on another

pom

file.  This time the jar file is present for that same artifact.

There are multiple artifacts that this happens on, but for

troubleshooting

I'm just focusing on oro-2.0.8.   Neither of my poms declare oro,

so

this

is a sub-dependency somewhere down the chain.  The process can be
reproduced every time,  and I can see from the output that the

oro-2.0.8

pom file is downloaded from the same location (local artifactory)

in

both

cases.


Does anyone know why maven would download a pom file, and then not

attempt

to download the associated jar?


Thanks,
Dan




--
---
Sent from TARDIS. Typos might be a timey whyney thingy.
Enviado da TARDIS, podem existir erros devido à diferenças de 
espaço-tempo.


Cintia Del Rio







-
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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1283 matches

Mail list logo