Packaging status

[Francesco Vivoli]

Hi all

well, given the topic I could just have said Hi Roman;)

after some frantic activity we are left with some nuts and bolts:

* Packaging of the single modules works, but running package/assembly
from the parent one only
  manages to create a tarball with the module artifacts, that is a jar
and a war.
  Ideally we would ship an atalaya-jetty-bundle containing both the
agent package and the web one.
  How do we do this? If having a tarball with two tarballs inside is
not nice we can always leave them
  uncompressed...Anyway I'm not sure how to achieve this, or if it's
possible just resorting only on the
  assembly plugin; maybe we need an "assembly" module?

* Precompiling jsps: this is a well known one:)

* Externalizing the war configuration: we have changed the
testbed-release bundle so that config
   properties are put into a conf/ dir, so that they are editble. Now,
I couldn't find a way of telling
   maven not to copy the src/main/resources into the war, mostly
because even if I create another
   directory like src/main/config with the properties files, I still
need to declare it as a resource in the pom,
   so that maven filters them. At that point those end up in
target/classes and the war pluging picks them
   up. Filtering with the war plugin doesn't seem to work for
target/classes, but only for other dirs.
   Bottom line: regardless of the properties being twice on the
classpath this setup seems to work, for some
   reason the conf/ dir given with --classpath takes precendence. But
I don't know how reliable is that...

Of these three the first is blocking, so well, let's see if we get it
in place soon:) I'll see if I come up with something
in the meantime.

ciao
F

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

[Roman Kalyakin]

Hi,

On Jan 2, 2008 12:27 PM, Francesco Vivoli <f.vivoli@...> wrote:

well, given the topic I could just have said Hi Roman;)

Hi Francesco. ;)
 

* Packaging of the single modules works, but running package/assembly
from the parent one only
 manages to create a tarball with the module artifacts, that is a jar
and a war.
 Ideally we would ship an atalaya-jetty-bundle containing both the
agent package and the web one.
 How do we do this? If having a tarball with two tarballs inside is
not nice we can always leave them
 uncompressed...Anyway I'm not sure how to achieve this, or if it's
possible just resorting only on the
 assembly plugin; maybe we need an "assembly" module?

Having a separate module is a good idea. However, we can achieve the   same
results storing assembly descriptor in the parent module and disabling recursion.
So that it would create a package from the resources in children modules.

* Precompiling jsps: this is a well known one:)

Yes. The only question is whether we compile them only for 'testbed' package or always?

* Externalizing the war configuration: we have changed the
testbed-release bundle so that config
  properties are put into a conf/ dir, so that they are editble. Now,
I couldn't find a way of telling
  maven not to copy the src/main/resources into the war, mostly
because even if I create another
  directory like src/main/config with the properties files, I still
need to declare it as a resource in the pom,
  so that maven filters them. At that point those end up in
target/classes and the war pluging picks them
  up. Filtering with the war plugin doesn't seem to work for
target/classes, but only for other dirs.
  Bottom line: regardless of the properties being twice on the
classpath this setup seems to work, for some
  reason the conf/ dir given with --classpath takes precendence. But
I don't know how reliable is that...

I don't quite get the problem, but I'll take a look at the code. AFAIR, working with resources
works very good in Maven though.

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

[Francesco Vivoli]

Hi,
welcome back:)


> Having a separate module is a good idea. However, we can achieve the   same
> results storing assembly descriptor in the parent module and disabling
> recursion.
> So that it would create a package from the resources in children modules.
>

ok, it makes sense.

> >
> >
> > * Precompiling jsps: this is a well known one:)
>
> Yes. The only question is whether we compile them only for 'testbed' package
> or always?
>

For the time being I'd only do it for the testbed version. I don't
know if we might end up with compatibility implications doing that always.



> I don't quite get the problem, but I'll take a look at the code. AFAIR,
> working with resources
> works very good in Maven though.

Ok.
if you do mvn war:war (or package) maven will build a war archive,
copying everything it finds under target/classes in WEB-INF/classes.
By default also src/main/webapp gets copied into the war root.

The objective is to create a war without the configuration properties file
within it. and to resort to the classpath to access them.

Right now doing assembly:assembly will re-copy the config files under
a conf/ dir, adding it to the classpath. So there are two sets of properties,
one in the war and one outside, but it happens that the external ones
are picked up first so that works:)

My doubt is: can we rely on this mechanism? or is it better to try not
to include config files in the war?

Another approach would be to read the configuration at the application level,
for example trying to find files under "ext/config" within the
classpath, and otherwise
resorting to the default ones (that would be in the war).
This is what alfresco does AFAIK.

What do you say, our maven master?
:)

ciao
F

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer