simple questions - where to put unpackaged config files?

[Richard Sand]

I've several projects that were created before we began using maven and
which we've added maven to subsequently. Obviously these projects were not
created with an archetype. Is there a "standard" folder that is commonly
used in archetypes for holding files such as application configuration files
or templates? The types of files I'm thinking of would not be put into
packaging (e.g. they wouldn't be placed into the jar, war etc. created by
maven) but would potentially be used in the install or deploy lifecycles. A
folder such as "src/main/config"?

If such an animal exists, what property would I used to reference it in a
plugin? e.g. the equivalent of "${project.build.sourceDirectory}". Is there
such a property?

If not, is there a property that references the "src" or "src/main" folder?
${project.build.sourceDirectory} references "src/main/java" - it would seem
to be a hack to use "../config" from there but it would work. 

Thanks!

Richard Sand | CEO
IDF Connect, Inc. 
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA 
Office: +1 302 425 0516 | Fax: +1 856 866 1899
Mobile: +1 267 984 3651



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

opinion on obfuscator plugin default execution phase?

[Richard Sand]

Hi all- I'm writing an obfuscator plugin that invokes the ProGuard open
source java obfuscator. There is that was written several years ago, but I
had problems adapting it to into our projects so decided to write a new one
for Maven 3.0. I've been thinking about whether the plugin should run at the
packaging phase or pre-packaging. I can see it both ways... If it runs at
the packaging phase, it'll start (by default) by processing the packaged
artifact created by the default packaging and either overwriting the
artifact or creating a new one with a classifier (e.g. "-small").
If it runs at the pre-packaging phase, I'd have it start processing on the
output folder from the compile phase.

Any thoughts? I'll have it configurable in any case, so it's the default
behavior I'm trying to reason out. Which makes more sense from a lifecycle
perspective?

Richard Sand | CEO
IDF Connect, Inc. 
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA 
Office: +1 302 425 0516 | Fax: +1 856 866 1899
Mobile: +1 267 984 3651



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

Re: Error of after running 'mvn package' command

[Russell Gold]

Hi,

Do you have a repository configured? You're trying to read artifacts from 
maven.glassfish.org, which is generally intended for glassfish development. You 
should be able to get most of what you want from maven central.

- Russ

On Jul 10, 2013, at 9:46 PM, 邹志勇  wrote:

> Hi,
> After i run the command 'mvn package', then i get the following error message 
> :
> Failed to execute goal org.kohsuke:access-modifier-checker:1.4:enforce 
> (default-enforce) on project javaone-sample: Execution default-enforce of 
> goal org.kohsuke:access-modifier-checker:1.4:enforce failed: Plugin 
> org.kohsuke:access-modifier-checker:1.4 or one of its dependencies could not 
> be resolved: Failed to collect dependencies at 
> org.kohsuke:access-modifier-checker:jar:1.4 -> 
> org.kohsuke:access-modifier-annotation:jar:1.4 -> 
> org.jenkins-ci:annotation-indexer:jar:1.4: Failed to read artifact descriptor 
> for org.jenkins-ci:annotation-indexer:jar:1.4: Could not transfer artifact 
> org.jenkins-ci:annotation-indexer:pom:1.4 from/to m.g.o-public 
> (http://maven.glassfish.org/content/groups/public/): hostname in certificate 
> didn't match:  !=  OR  
> -> [Help 1]
> So, why, am i need to config in somewhere?
> 
> Thanks.

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Error of after running 'mvn package' command

[邹志勇]

Hi,
After i run the command 'mvn package', then i get the following error message :
 Failed to execute goal org.kohsuke:access-modifier-checker:1.4:enforce 
(default-enforce) on project javaone-sample: Execution default-enforce of goal 
org.kohsuke:access-modifier-checker:1.4:enforce failed: Plugin 
org.kohsuke:access-modifier-checker:1.4 or one of its dependencies could not be 
resolved: Failed to collect dependencies at 
org.kohsuke:access-modifier-checker:jar:1.4 -> 
org.kohsuke:access-modifier-annotation:jar:1.4 -> 
org.jenkins-ci:annotation-indexer:jar:1.4: Failed to read artifact descriptor 
for org.jenkins-ci:annotation-indexer:jar:1.4: Could not transfer artifact 
org.jenkins-ci:annotation-indexer:pom:1.4 from/to m.g.o-public 
(http://maven.glassfish.org/content/groups/public/): hostname in certificate 
didn't match:  !=  OR  -> 
[Help 1]
So, why, am i need to config in somewhere?

Thanks.

Re: Failsafe report for website?

[Russell Gold]

OK, found it - the maven-surefire-report-plugin seems to does the trick; only… 
it is not clear to me if it simply has not been maintained much, or something 
is missing from the documentation. 

There are goals for selecting reports, but typically you select reports for 
websites by specifying report names. Can you do that with this plugin?

Thanks,
Russ

On Jul 10, 2013, at 9:14 PM, Russell Gold  wrote:

> Hi,
> 
> If you are running the failsafe plugin for integration tests, and you bind 
> only the integration-test goal and not the verify goal, you can have test 
> failures in your build. Is there a way to report them on the project website?
> 
> Thanks,
> Russ
> -
> Come read my webnovel, Take a Lemon , 
> and listen to the Misfile radio play 
> !
> 
> 
> 
> 

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Failsafe report for website?

[Russell Gold]

Hi,

If you are running the failsafe plugin for integration tests, and you bind only 
the integration-test goal and not the verify goal, you can have test failures 
in your build. Is there a way to report them on the project website?

Thanks,
Russ
-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: Maven site fluido skin and checkstyle

[Spammer Juliano]

Thanks for the feedback, I've managed some success using a  tag
in my pom.  I've created a HelloWorld project and am following the
guidelines at:
http://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html

I'm able to generate a fluido styled checkstyle report and link to it from
my site.xml.  So I must be doing something right.  Not sure why my other
project is unable to claim the same results, but will dig deeper.

Dan

On Wed, Jul 10, 2013 at 4:21 PM, Russell Gold  wrote:

> You are creating the site and THEN running the check style mojo
> independently. You should be specifying the check style plugin in your
> reports section.
>
> On Jul 10, 2013, at 3:26 PM, Spammer Juliano 
> wrote:
>
> > There is a beautiful example of the fluido skin used for site generation
> > including checkstyle report creation out at:
> >
> http://maven.apache.org/skins/maven-fluido-skin/checkstyle-aggregate.html
> >
> > I have been trying to recreate use of fluido with checkstyle to no avail.
> > So I downloaded the fluido code from:
> > http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/
> >
> > At the command line I've run:
> >  mvn clean install site checkstyle:checkstyle
> >
> > It doesn't appear to generate the checkstyle report.  When I look in the
> > target directory I'm not finding checkstyle files there.
> >
> > If I had to guess, there's probably some command line parameters I'm
> > missing, but it's not obvious what I'm missing from the fluido and
> > checkstyle documentation.
> >
> > Help?
> >
> > Dan
>
> -
> Come read my webnovel, Take a Lemon ,
> and listen to the Misfile radio play <
> http://www.gold-family.us/audio/misfile.html>!
>
>
>
>
>

Re: [ANN] Apache Maven War Plugin 2.4 Released

[Thomas Vandahl]

Hi Olivier,

On 09.07.2013 14:27, Olivier Lamy wrote:>  * [MWAR-267] - Maven WAR 
plugin does not copy dependencies of type

> "bundle" into WEB-INF/lib

Thanks for fixing this. It's a great help.

Bye, Thomas.


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

Re: Accessing *reactor* build path in an Ant-Maven-plugin

[Mirko Friedenhagen]

Hello Russel,

thanks, but how do I specify this in Ant-Mojos?

Regards Mirko
-- 
Sent from my mobile
On Jul 10, 2013 2:37 PM, "Russell Gold"  wrote:

> Hi Mirko. If you want the compile class path for the pom executing a
> plugin, you can do this:
>
> 1. Configure the plugin to require compile and runtime dependency
> resolution:
>
> @Mojo( ... requiresDependencyResolution =
> ResolutionScope.COMPILE_PLUS_RUNTIME)
>
> 2. Specify a parameter configured to receive project.compileClassElements
>
>/**
> * Compile classpath of the maven project.
> */
>@Parameter(defaultValue = "${project.compileClasspathElements}")
>private List projectCompileClasspathElements;
>
> On Jul 10, 2013, at 1:12 AM, Mirko Friedenhagen 
> wrote:
>
> > Hello,
> >
> > I inherited a Maven plugin written by an Ant-master which currently execs
> > mvn dependency:build-classpath to inspect files. (Rewrite almost
> impossible
> > as there are no tests).
> >
> > This leads to problems during the first run of verify (e.g. while
> > release:prepare).
> >
> > Any hint how to get the *reactor* class path would be appreciated :-).
> >
> > Regards Mirko
> > --
> > Sent from my mobile
>
> -
> Come read my webnovel, Take a Lemon ,
> and listen to the Misfile radio play <
> http://www.gold-family.us/audio/misfile.html>!
>
>
>
>
>

Re: Maven site fluido skin and checkstyle

[Russell Gold]

You are creating the site and THEN running the check style mojo independently. 
You should be specifying the check style plugin in your reports section.

On Jul 10, 2013, at 3:26 PM, Spammer Juliano  
wrote:

> There is a beautiful example of the fluido skin used for site generation
> including checkstyle report creation out at:
> http://maven.apache.org/skins/maven-fluido-skin/checkstyle-aggregate.html
> 
> I have been trying to recreate use of fluido with checkstyle to no avail.
> So I downloaded the fluido code from:
> http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/
> 
> At the command line I've run:
>  mvn clean install site checkstyle:checkstyle
> 
> It doesn't appear to generate the checkstyle report.  When I look in the
> target directory I'm not finding checkstyle files there.
> 
> If I had to guess, there's probably some command line parameters I'm
> missing, but it's not obvious what I'm missing from the fluido and
> checkstyle documentation.
> 
> Help?
> 
> Dan

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Maven site fluido skin and checkstyle

[Spammer Juliano]

There is a beautiful example of the fluido skin used for site generation
including checkstyle report creation out at:
http://maven.apache.org/skins/maven-fluido-skin/checkstyle-aggregate.html

I have been trying to recreate use of fluido with checkstyle to no avail.
 So I downloaded the fluido code from:
http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/

At the command line I've run:
  mvn clean install site checkstyle:checkstyle

It doesn't appear to generate the checkstyle report.  When I look in the
target directory I'm not finding checkstyle files there.

If I had to guess, there's probably some command line parameters I'm
missing, but it's not obvious what I'm missing from the fluido and
checkstyle documentation.

Help?

Dan

[ANN] Appassembler Maven Plugin 1.4 Released

[Dan Tran]

Hi,

The Mojo team is pleased to announce the release of the
appassembler-maven-plugin version 1.4

The Application Assembler Plugin is a Maven plugin for generating scripts
for starting java applications. All dependencies and the artifact of the
project itself are placed in
a generated Maven repository in a defined assemble directory. All artifacts
(dependencies + the artifact from the project) are added to the classpath
in the generated bin scripts.

http://mojo.codehaus.org/appassembler/appassembler-maven-plugin

To get this update, simply specify the version in your project's plugin
configuration:


org.codehaus.mojo
appassembler-maven-plugin
1.4


Release Notes

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11780&version=18633

Enjoy,

Re: Maven and JPA/EclipseLink Configuration...

[Ron Wheeler]

I agree with a lot of the JCP description of the deployer role.
I also think that they are oriented to a small portion of the deployment 
world.
Most of the time the person doing deployments has a third party product 
from a vendor and does not have the source code and does not even have 
any documentation other than what the vendor provides.


I agree with the separation of church and state that they advocate for 
internally developed applications.
I have always recommended that developers who are doing both roles (in 
small and medium shops), try to remember which hat they are wearing when 
working at the border of development and deployment.
The developer should deliver something that can be deployed in the 
supported environment by someone who is an expert in the operating 
environment but not a programmer and certainly not an expert is the 
middleware on which the system is built.


I will stick with my recommendation that the best way to support 
multiple deployment configurations in a commercial product, is an 
interactive installer that, at deployment time,  can tweak or select 
from a set of configuration files included in the artifacts.

These artifacts should be developed by Maven.

Creating individual Maven artifacts for each deployment combination will 
result in a set that doubles (or more) each time an option is added.


Ron


On 10/07/2013 11:45 AM, Stephen Connolly wrote:
On 10 July 2013 15:52, Ron Wheeler > wrote:


On 10/07/2013 10:06 AM, Stephen Connolly wrote:

Well if it is an interactive installer then it can do the
configuration for you...


It needs to be interactive in some way if you want to handle a
variety of environments.

./configure
make
install
(you hope that you don't end up with something this complex!!!)

or  questions during msi or rpm installs.



But with a JavaEE application you don't know:

1. What application container they have
2. What database they have
3. Where the application container picks up deployed apps
4. How the user wants the app deployed in the application container
...


These are all questions that can be asked and are somewhat limited
by the configurations that your application supports.
I would think that the answer to question 1 limits the possible
responses to 3 and 4.

The application designer  usually limits the supported
configurations in some way so that they do not have to create and
distribute a lot of configuration files if they are using Maven to
build the final war file that has to handle the whole range of
deployment environments.


Well getting back to the OP, they were saying that they are expanding 
the supported list of platforms... so it looks like their designer is 
getting more fast and loose with QA (because QA will only be doing 
touchstone testing on the entire matrix of combinations)


As a frequent deployer and a less frequent developer, I prefer an
installer that encapsulates the developers supported tweaking
rather than a complex process that requires me to manually modify
configuration files based on my understanding of the developers
documentation.


I am not saying you're wrong... I am saying that the JavaEE spec does 
not share your point of view...


The ideal Maven way is one .ear that works for everyone without 
modification. The JavaEE spec and the way application containers are 
implemented makes that harder to achieve for some scopes (e.g. 
persistence.xml)


I generally have very little idea about the internal architecture
since I might have to install 50 packages to get a server set up
and don't have the time to learn each one and read the code and
configuration file documentation to find the things to change.


Take it up with the JCP ;-)

I want to get something that the programmer has tested and will
install on the supported configuration with as few places for me 
to make mistakes, as possible.



Which is why I recommended having Maven do the repacking for them... 
just using one module for each target platform...


Note that this may mean that they have 20 or 30 repack modules... so 
be it!!! Following the Maven way typically results in discovering pain 
at things which are not best practice... the need to have NxM 
repack-ear modules highlights the pain introduced by poor application 
server spec design







I can go on.

The less Windows centric world has installers that basically are
non-interactive, e.g. RPM, DEB, etc

This type of installer typically would be installing both the
application and container... thus the question is moot.

An example of this is the various ways you can install Jenkins:

1. Jenkins.war (as self-executing war file)
2. Jenkins.war in your container of choice
3. RPM
4. DEB
5. PKG
6. Windows installer
7. Mac installer

All except the .

Re: Maven and JPA/EclipseLink Configuration...

[Stephen Connolly]

On 10 July 2013 15:52, Ron Wheeler  wrote:

>  On 10/07/2013 10:06 AM, Stephen Connolly wrote:
>
> Well if it is an interactive installer then it can do the configuration
> for you...
>
>   It needs to be interactive in some way if you want to handle a variety
> of environments.
>
> ./configure
> make
> install
> (you hope that you don't end up with something this complex!!!)
>
> or  questions during msi or rpm installs.
>
>
>  But with a JavaEE application you don't know:
>
>  1. What application container they have
> 2. What database they have
> 3. Where the application container picks up deployed apps
> 4. How the user wants the app deployed in the application container
> ...
>
>
> These are all questions that can be asked and are somewhat limited by the
> configurations that your application supports.
> I would think that the answer to question 1 limits the possible responses
> to 3 and 4.
>
> The application designer  usually limits the supported configurations in
> some way so that they do not have to create and distribute a lot of
> configuration files if they are using Maven to build the final war file
> that has to handle the whole range of deployment environments.
>
>
Well getting back to the OP, they were saying that they are expanding the
supported list of platforms... so it looks like their designer is getting
more fast and loose with QA (because QA will only be doing touchstone
testing on the entire matrix of combinations)


> As a frequent deployer and a less frequent developer, I prefer an
> installer that encapsulates the developers supported tweaking rather than a
> complex process that requires me to manually modify configuration files
> based on my understanding of the developers documentation.
>

I am not saying you're wrong... I am saying that the JavaEE spec does not
share your point of view...

The ideal Maven way is one .ear that works for everyone without
modification. The JavaEE spec and the way application containers are
implemented makes that harder to achieve for some scopes (e.g.
persistence.xml)


> I generally have very little idea about the internal architecture since I
> might have to install 50 packages to get a server set up and don't have the
> time to learn each one and read the code and configuration file
> documentation to find the things to change.
>

Take it up with the JCP ;-)


> I want to get something that the programmer has tested and will install on
> the supported configuration with as few places for me  to make mistakes, as
> possible.
>
>
Which is why I recommended having Maven do the repacking for them... just
using one module for each target platform...

Note that this may mean that they have 20 or 30 repack modules... so be
it!!! Following the Maven way typically results in discovering pain at
things which are not best practice... the need to have NxM repack-ear
modules highlights the pain introduced by poor application server spec
design


>
>
>
>  I can go on.
>
>  The less Windows centric world has installers that basically are
> non-interactive, e.g. RPM, DEB, etc
>
>  This type of installer typically would be installing both the
> application and container... thus the question is moot.
>
>  An example of this is the various ways you can install Jenkins:
>
>  1. Jenkins.war (as self-executing war file)
> 2. Jenkins.war in your container of choice
> 3. RPM
> 4. DEB
> 5. PKG
> 6. Windows installer
> 7. Mac installer
>
>  All except the .WAR based distributions make assumptions about how to
> deploy the application.
>
>  If you want to install Jenkins on RedHat, you grab the RPM and install
> that... but if you don't like the way that configures Jenkins, then you can
> grab your container of choice, grab the .war and deploy that in your
> container using your container's deployment toolchain.
>
>  Installers are not the solution to this problem... in fact to my mind,
> other than windows, they are often an anti-pattern...
>
>  Though with puppet/chef what you typically do is wrap up the application
> you want in an installer that depends on an installer you created for your
> container of choice and then drops the application into the correct
> directory... that simplifies your puppet/chef scripts as they just interact
> with the platform's package management infrastructure... but you are still
> back to the Ops team creating the installer not the dev team
>
>
> On 10 July 2013 14:39, Ron Wheeler  wrote:
>
>> Where does an installer fit in this vision?
>>
>> It seems to me, having installed thousands of programs as a Windows user
>> and Linux system administrator, that a lot of the discussion about
>> deployment issues seem to ignore the role of installers (rpm, msi, izPack,
>> etc.).
>>
>> They are specifically designed to tweak packages during deployment.
>>
>> They can be set up very easily to be very smart about using input from
>> the Application Deployer and Administrator or from the environment
>> directly, to customize the installed applicatio

Re: Maven and JPA/EclipseLink Configuration...

[Ron Wheeler]

On 10/07/2013 10:06 AM, Stephen Connolly wrote:
Well if it is an interactive installer then it can do the 
configuration for you...


It needs to be interactive in some way if you want to handle a variety 
of environments.


./configure
make
install
(you hope that you don't end up with something this complex!!!)

or  questions during msi or rpm installs.


But with a JavaEE application you don't know:

1. What application container they have
2. What database they have
3. Where the application container picks up deployed apps
4. How the user wants the app deployed in the application container
...


These are all questions that can be asked and are somewhat limited by 
the configurations that your application supports.
I would think that the answer to question 1 limits the possible 
responses to 3 and 4.


The application designer  usually limits the supported configurations in 
some way so that they do not have to create and distribute a lot of 
configuration files if they are using Maven to build the final war file 
that has to handle the whole range of deployment environments.


As a frequent deployer and a less frequent developer, I prefer an 
installer that encapsulates the developers supported tweaking rather 
than a complex process that requires me to manually modify configuration 
files based on my understanding of the developers documentation.
I generally have very little idea about the internal architecture since 
I might have to install 50 packages to get a server set up and don't 
have the time to learn each one and read the code and configuration file 
documentation to find the things to change.
I want to get something that the programmer has tested and will install 
on the supported configuration with as few places for me  to make 
mistakes, as possible.






I can go on.

The less Windows centric world has installers that basically are 
non-interactive, e.g. RPM, DEB, etc


This type of installer typically would be installing both the 
application and container... thus the question is moot.


An example of this is the various ways you can install Jenkins:

1. Jenkins.war (as self-executing war file)
2. Jenkins.war in your container of choice
3. RPM
4. DEB
5. PKG
6. Windows installer
7. Mac installer

All except the .WAR based distributions make assumptions about how to 
deploy the application.


If you want to install Jenkins on RedHat, you grab the RPM and install 
that... but if you don't like the way that configures Jenkins, then 
you can grab your container of choice, grab the .war and deploy that 
in your container using your container's deployment toolchain.


Installers are not the solution to this problem... in fact to my mind, 
other than windows, they are often an anti-pattern...


Though with puppet/chef what you typically do is wrap up the 
application you want in an installer that depends on an installer you 
created for your container of choice and then drops the application 
into the correct directory... that simplifies your puppet/chef scripts 
as they just interact with the platform's package management 
infrastructure... but you are still back to the Ops team creating the 
installer not the dev team



On 10 July 2013 14:39, Ron Wheeler > wrote:


Where does an installer fit in this vision?

It seems to me, having installed thousands of programs as a
Windows user and Linux system administrator, that a lot of the
discussion about deployment issues seem to ignore the role of
installers (rpm, msi, izPack, etc.).

They are specifically designed to tweak packages during deployment.

They can be set up very easily to be very smart about using input
from the Application Deployer and Administrator or from the
environment directly, to customize the installed application.

Ron



On 10/07/2013 4:23 AM, Stephen Connolly wrote:

Well the first thing I would look towards is whether you can
use an
application server specific deployment descriptor to tweak the
effective
persistence.xml at deployment time.

I am not saying that the above is possible, but if it is, then
that is
obviously "the way to go" as you then can just bundle all the
application
server specific deployment descriptors into the .ear and you
have one .ear
that works for everyone.

I have a constant battle with people in work who feel that
application
server specific deployment descriptors are an anti-pattern...
and if you
think it is ok to follow the JavaEE spec's vision of the
deployment
process, then that may indeed be a valid view... but the real
world does
not work that way... and hence you need the application server
specific
deployment descriptors.

Ok let's take a step back, and look at where I am coming from.

The JavaEE spec lists a ro

Re: Maven and JPA/EclipseLink Configuration...

[Stephen Connolly]

Well if it is an interactive installer then it can do the configuration for
you...

But with a JavaEE application you don't know:

1. What application container they have
2. What database they have
3. Where the application container picks up deployed apps
4. How the user wants the app deployed in the application container
...

I can go on.

The less Windows centric world has installers that basically are
non-interactive, e.g. RPM, DEB, etc

This type of installer typically would be installing both the application
and container... thus the question is moot.

An example of this is the various ways you can install Jenkins:

1. Jenkins.war (as self-executing war file)
2. Jenkins.war in your container of choice
3. RPM
4. DEB
5. PKG
6. Windows installer
7. Mac installer

All except the .WAR based distributions make assumptions about how to
deploy the application.

If you want to install Jenkins on RedHat, you grab the RPM and install
that... but if you don't like the way that configures Jenkins, then you can
grab your container of choice, grab the .war and deploy that in your
container using your container's deployment toolchain.

Installers are not the solution to this problem... in fact to my mind,
other than windows, they are often an anti-pattern...

Though with puppet/chef what you typically do is wrap up the application
you want in an installer that depends on an installer you created for your
container of choice and then drops the application into the correct
directory... that simplifies your puppet/chef scripts as they just interact
with the platform's package management infrastructure... but you are still
back to the Ops team creating the installer not the dev team


On 10 July 2013 14:39, Ron Wheeler  wrote:

> Where does an installer fit in this vision?
>
> It seems to me, having installed thousands of programs as a Windows user
> and Linux system administrator, that a lot of the discussion about
> deployment issues seem to ignore the role of installers (rpm, msi, izPack,
> etc.).
>
> They are specifically designed to tweak packages during deployment.
>
> They can be set up very easily to be very smart about using input from the
> Application Deployer and Administrator or from the environment directly, to
> customize the installed application.
>
> Ron
>
>
>
> On 10/07/2013 4:23 AM, Stephen Connolly wrote:
>
>> Well the first thing I would look towards is whether you can use an
>> application server specific deployment descriptor to tweak the effective
>> persistence.xml at deployment time.
>>
>> I am not saying that the above is possible, but if it is, then that is
>> obviously "the way to go" as you then can just bundle all the application
>> server specific deployment descriptors into the .ear and you have one .ear
>> that works for everyone.
>>
>> I have a constant battle with people in work who feel that application
>> server specific deployment descriptors are an anti-pattern... and if you
>> think it is ok to follow the JavaEE spec's vision of the deployment
>> process, then that may indeed be a valid view... but the real world does
>> not work that way... and hence you need the application server specific
>> deployment descriptors.
>>
>> Ok let's take a step back, and look at where I am coming from.
>>
>> The JavaEE spec lists a role of application deployer:
>>
>> *# Application Deployer and Administrator
>>
>>> *The application deployer and administrator is the company or person who
>>>
>>> configures and deploys application clients, web applications, Enterprise
>>> JavaBeans components, and Java EE applications, administers the computing
>>> and networking infrastructure where Java EE components and applications
>>> run, and oversees the runtime environment. Duties include setting
>>> transaction controls and security attributes and specifying connections
>>> to
>>> databases.
>>> During configuration, the deployer follows instructions supplied by the
>>> application component provider to resolve external dependencies, specify
>>> security settings, and assign transaction attributes. During
>>> installation,
>>> the deployer moves the application components to the server and generates
>>> the container-specific classes and interfaces.
>>> A deployer or system administrator performs the following tasks to
>>> install
>>> and configure a Java EE application or components:
>>> * Configures the Java EE application or components for the operational
>>> environment
>>> * Verifies that the contents of the EAR, JAR, and/or WAR files are well
>>> formed and comply with the Java EE specification
>>> * Deploys (installs) the Java EE application or components into the Java
>>> EE server
>>>
>>
>> *Source: 
>> http://docs.oracle.com/javaee/**6/tutorial/doc/bnaca.html*
>> *
>>
>> *
>> Now the "vision" is thus that whoever is deploying the application will
>> essentially "crack open" the .ear, tweak the deployment descriptors and
>> then seal it back

Re: Maven and JPA/EclipseLink Configuration...

[Ron Wheeler]

Where does an installer fit in this vision?

It seems to me, having installed thousands of programs as a Windows user 
and Linux system administrator, that a lot of the discussion about 
deployment issues seem to ignore the role of installers (rpm, msi, 
izPack, etc.).


They are specifically designed to tweak packages during deployment.

They can be set up very easily to be very smart about using input from 
the Application Deployer and Administrator or from the environment 
directly, to customize the installed application.


Ron


On 10/07/2013 4:23 AM, Stephen Connolly wrote:

Well the first thing I would look towards is whether you can use an
application server specific deployment descriptor to tweak the effective
persistence.xml at deployment time.

I am not saying that the above is possible, but if it is, then that is
obviously "the way to go" as you then can just bundle all the application
server specific deployment descriptors into the .ear and you have one .ear
that works for everyone.

I have a constant battle with people in work who feel that application
server specific deployment descriptors are an anti-pattern... and if you
think it is ok to follow the JavaEE spec's vision of the deployment
process, then that may indeed be a valid view... but the real world does
not work that way... and hence you need the application server specific
deployment descriptors.

Ok let's take a step back, and look at where I am coming from.

The JavaEE spec lists a role of application deployer:

*# Application Deployer and Administrator

*The application deployer and administrator is the company or person who
configures and deploys application clients, web applications, Enterprise
JavaBeans components, and Java EE applications, administers the computing
and networking infrastructure where Java EE components and applications
run, and oversees the runtime environment. Duties include setting
transaction controls and security attributes and specifying connections to
databases.
During configuration, the deployer follows instructions supplied by the
application component provider to resolve external dependencies, specify
security settings, and assign transaction attributes. During installation,
the deployer moves the application components to the server and generates
the container-specific classes and interfaces.
A deployer or system administrator performs the following tasks to install
and configure a Java EE application or components:
* Configures the Java EE application or components for the operational
environment
* Verifies that the contents of the EAR, JAR, and/or WAR files are well
formed and comply with the Java EE specification
* Deploys (installs) the Java EE application or components into the Java
EE server


*Source: http://docs.oracle.com/javaee/6/tutorial/doc/bnaca.html*
*
*
Now the "vision" is thus that whoever is deploying the application will
essentially "crack open" the .ear, tweak the deployment descriptors and
then seal it back up again (that is meaning of the "Configures the Java EE
application or components for the operational environment" step which comes
*before* deploying to the JavaEE server)

Of course where we hit issues is that we all view letting a human "crack
open", "tweak", and "seal up again" a .ear as error prone, plus the people
we are shipping the application to also view this as scary.

Now if I were the admin for such an app, I would use something like puppet
or chef, etc to automate the open-tweak-seal process... but the biggest
issue is tracablility.

If you have a .ear that is never the same as that shipped from the vendor
(or from the release process) how do you know that it was the one that QA
tested?

Instead of being able to do

sha1sum application.ear

you now have to open up the ear and do a diff of the contents against the
reference .ear and potentially resolve differences in files that are
permitted to have differences.

TL;DR the JavaEE spec vision is not something that you want

So then you decide that you want to release the app pre-configured for each
deployment environment and all the remaining configuration should be picked
up via JNDI or via files deployed to the classpath of the container (or
maybe system properties or environment variables)

In an ideal world you can do it all from JNDI or system properties (JNDI
being better as you do not pollute a global name space)

In the non-ideal world what you do is have your build system take on some
of the roles of application deployer.

You have a module that produces the generic .ear

And then you have modules that unpack-tweak-repack the .ear targetting each
app server/database

That is "the maven way" *but* it is not the way Maven wants you to work...
Maven wants you to only have one .ear that works for all... the app servers
are letting you down, and Maven is delivering pain for not following the
best practice way of working.


On 10 July 2013 08:33, John Patrick  wrote:


On 10 Jul 2013, at 06:05, Baptiste MATHUS 

Re: Accessing *reactor* build path in an Ant-Maven-plugin

[Russell Gold]

Hi Mirko. If you want the compile class path for the pom executing a plugin, 
you can do this:

1. Configure the plugin to require compile and runtime dependency resolution:

@Mojo( ... requiresDependencyResolution = ResolutionScope.COMPILE_PLUS_RUNTIME)

2. Specify a parameter configured to receive project.compileClassElements

   /**
* Compile classpath of the maven project.
*/
   @Parameter(defaultValue = "${project.compileClasspathElements}")
   private List projectCompileClasspathElements;

On Jul 10, 2013, at 1:12 AM, Mirko Friedenhagen  wrote:

> Hello,
> 
> I inherited a Maven plugin written by an Ant-master which currently execs
> mvn dependency:build-classpath to inspect files. (Rewrite almost impossible
> as there are no tests).
> 
> This leads to problems during the first run of verify (e.g. while
> release:prepare).
> 
> Any hint how to get the *reactor* class path would be appreciated :-).
> 
> Regards Mirko
> -- 
> Sent from my mobile

-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: Maven and JPA/EclipseLink Configuration...

[Stephen Connolly]

Well the first thing I would look towards is whether you can use an
application server specific deployment descriptor to tweak the effective
persistence.xml at deployment time.

I am not saying that the above is possible, but if it is, then that is
obviously "the way to go" as you then can just bundle all the application
server specific deployment descriptors into the .ear and you have one .ear
that works for everyone.

I have a constant battle with people in work who feel that application
server specific deployment descriptors are an anti-pattern... and if you
think it is ok to follow the JavaEE spec's vision of the deployment
process, then that may indeed be a valid view... but the real world does
not work that way... and hence you need the application server specific
deployment descriptors.

Ok let's take a step back, and look at where I am coming from.

The JavaEE spec lists a role of application deployer:

*# Application Deployer and Administrator
> *The application deployer and administrator is the company or person who
> configures and deploys application clients, web applications, Enterprise
> JavaBeans components, and Java EE applications, administers the computing
> and networking infrastructure where Java EE components and applications
> run, and oversees the runtime environment. Duties include setting
> transaction controls and security attributes and specifying connections to
> databases.
> During configuration, the deployer follows instructions supplied by the
> application component provider to resolve external dependencies, specify
> security settings, and assign transaction attributes. During installation,
> the deployer moves the application components to the server and generates
> the container-specific classes and interfaces.
> A deployer or system administrator performs the following tasks to install
> and configure a Java EE application or components:
> * Configures the Java EE application or components for the operational
> environment
> * Verifies that the contents of the EAR, JAR, and/or WAR files are well
> formed and comply with the Java EE specification
> * Deploys (installs) the Java EE application or components into the Java
> EE server


*Source: http://docs.oracle.com/javaee/6/tutorial/doc/bnaca.html*
*
*
Now the "vision" is thus that whoever is deploying the application will
essentially "crack open" the .ear, tweak the deployment descriptors and
then seal it back up again (that is meaning of the "Configures the Java EE
application or components for the operational environment" step which comes
*before* deploying to the JavaEE server)

Of course where we hit issues is that we all view letting a human "crack
open", "tweak", and "seal up again" a .ear as error prone, plus the people
we are shipping the application to also view this as scary.

Now if I were the admin for such an app, I would use something like puppet
or chef, etc to automate the open-tweak-seal process... but the biggest
issue is tracablility.

If you have a .ear that is never the same as that shipped from the vendor
(or from the release process) how do you know that it was the one that QA
tested?

Instead of being able to do

sha1sum application.ear

you now have to open up the ear and do a diff of the contents against the
reference .ear and potentially resolve differences in files that are
permitted to have differences.

TL;DR the JavaEE spec vision is not something that you want

So then you decide that you want to release the app pre-configured for each
deployment environment and all the remaining configuration should be picked
up via JNDI or via files deployed to the classpath of the container (or
maybe system properties or environment variables)

In an ideal world you can do it all from JNDI or system properties (JNDI
being better as you do not pollute a global name space)

In the non-ideal world what you do is have your build system take on some
of the roles of application deployer.

You have a module that produces the generic .ear

And then you have modules that unpack-tweak-repack the .ear targetting each
app server/database

That is "the maven way" *but* it is not the way Maven wants you to work...
Maven wants you to only have one .ear that works for all... the app servers
are letting you down, and Maven is delivering pain for not following the
best practice way of working.


On 10 July 2013 08:33, John Patrick  wrote:

> On 10 Jul 2013, at 06:05, Baptiste MATHUS  wrote:
>
> > If those properties are specific to eclipselink, then I think it's ok and
> > simpler to just leave them in the persistence.xml even if they're
> actually
> > not used when EclipseLink isn't the provider. Then package only one ear.
> >
> > Cheers
> >
> >
> > 2013/7/9 John Patrick 
> >
> >> I'm working on a project that uses JPA EclipseLink, everything started
> of
> >> fine with Jetty for developers development and WebLogic and Oracle
> proper
> >> ear deployments.
> >>
> >> EclipseLink has two values that need to be set in pers

Re: Maven and JPA/EclipseLink Configuration...

[John Patrick]

On 10 Jul 2013, at 06:05, Baptiste MATHUS  wrote:

> If those properties are specific to eclipselink, then I think it's ok and
> simpler to just leave them in the persistence.xml even if they're actually
> not used when EclipseLink isn't the provider. Then package only one ear.
>
> Cheers
>
>
> 2013/7/9 John Patrick 
>
>> I'm working on a project that uses JPA EclipseLink, everything started of
>> fine with Jetty for developers development and WebLogic and Oracle proper
>> ear deployments.
>>
>> EclipseLink has two values that need to be set in persistence.xml depending
>> upon your Application Server and Database;
>> eclipselink.target-server
>> eclipselink.target-database
>>
>> This mean we have two profiles, Jetty and Release.
>>
>> Now we support WebSphere and DB2, so have gone to 5 profiles and the need
>> to rebuild the ear 4 times which each profile.
>>
>> Profiles
>> Jetty
>> WLSOracle
>> WLSDB2
>> WASOracle
>> WASDB2
>>
>> I feel I'm doing something wrong...
>>
>> Does someone have any suggestions on what to look at so i could potentially
>> build it once and get all the 4 ears build in one command? I've thought
>> about types or classifiers but unsure if that is just another hack...
>>
>> Thoughts? As we soon might also need to support MySQL and Glassfish so
>> their is another 5 profiles and 5 more builds for a release.
>>
>> John
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !

Mathus I think you miss understood my point. I need to build 4
different ears currently as eclipselink auto detections fails about
once a week and we can reproduce on demand.

each ear has a different combination of values.

ear 1 = WebLogic / Oracle
ear 2 = WebLogic / DB2
ear 3 = WebSphere / Oracle
ear 4 = WebSphere / DB2

I can't build one ear, say ear 1 as the value for the database setting
would be wrong when DB2 is the backend. Also the value for the
application server would be wrong when deployed to WebSphere.

If eclipselink auto detect worked 100% I could create one ear but a
few issues in production which we can't reproduce in test on demand
mean we need to explicitly define application server and database
server.

>From the off list replies it looks like others are having similar
issues and doing similar things.

cheers,
John

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