You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ian Rowlands <Ia...@sro.vic.gov.au> on 2007/10/10 00:25:04 UTC

Suggested best practice for projects which need duplicated files





I have the following scenario for a bunch of projects I wish to implement:

I have a "Web Project" which acts as a router for web services. It must
contain the web services configuration, the wsdl and the schemas relating
to the wsdl. It will contain the "endpoints" of the web service - which
will be routed to the other projects.

I have a project containing the implementation of the Web Service.

I have a project which is a client of the web service. It will need the
wsdl and schemas from the Web project. This project also needs to be
consistent with the Web Service implementation

I have a EAR project which will collect everything above (it's not that
important in this context).


The concerns I have is what is the best way to do the following:

1.  Keep the schemas and wsdl consistent between the Web Project and the
client project. They must be identical. The wsdl is needed for
documentation, the schema is needed to generate some Java code (using
JAXB).

2.  Ensuring the client project and implementation project stay with
consistent versions, and stay in sync with the Web Project.

Normally I would classpath-type things, but this situation is not really
applicable to classpaths. I'm not convinced the best way is to copy the
files during the build (or even if that is possible via Maven between
projects).

Any ideas would be appreciated!

Thanks,

Ian


Disclaimer: The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 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 your computer.
Privacy: If you are responding to this email or providing personal
information to the SRO for the purposes of one of the Acts it administers,
such information is used only for the purpose for which it was collected
( administration of SRO legislation ) and is protected by the Information
Privacy Act 2000 and secrecy provisions contained in legislation
administered by SRO. It is not disclosed otherwise than in accordance with
the law. If you would like a copy of the SRO Privacy Policy please refer to
SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a
copy.


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


Re: Suggested best practice for projects which need duplicated files

Posted by Michael McCallum <gh...@apache.org>.
think like an OO developer... or a mathemetician... factor out the common 
elements into new artifacts... you might need to tweak plugins to be good 
java tools and work from resources in the classpath but thats not hard

On Wednesday 10 October 2007 11:25, Ian Rowlands wrote:
> I have the following scenario for a bunch of projects I wish to implement:
>
> I have a "Web Project" which acts as a router for web services. It must
> contain the web services configuration, the wsdl and the schemas relating
> to the wsdl. It will contain the "endpoints" of the web service - which
> will be routed to the other projects.
>
> I have a project containing the implementation of the Web Service.
>
> I have a project which is a client of the web service. It will need the
> wsdl and schemas from the Web project. This project also needs to be
> consistent with the Web Service implementation
>
> I have a EAR project which will collect everything above (it's not that
> important in this context).
>
>
> The concerns I have is what is the best way to do the following:
>
> 1.  Keep the schemas and wsdl consistent between the Web Project and the
> client project. They must be identical. The wsdl is needed for
> documentation, the schema is needed to generate some Java code (using
> JAXB).
>
> 2.  Ensuring the client project and implementation project stay with
> consistent versions, and stay in sync with the Web Project.
>
> Normally I would classpath-type things, but this situation is not really
> applicable to classpaths. I'm not convinced the best way is to copy the
> files during the build (or even if that is possible via Maven between
> projects).
>
> Any ideas would be appreciated!
>
> Thanks,
>
> Ian
>
>
> Disclaimer: The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential 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 your computer.
> Privacy: If you are responding to this email or providing personal
> information to the SRO for the purposes of one of the Acts it administers,
> such information is used only for the purpose for which it was collected
> ( administration of SRO legislation ) and is protected by the Information
> Privacy Act 2000 and secrecy provisions contained in legislation
> administered by SRO. It is not disclosed otherwise than in accordance with
> the law. If you would like a copy of the SRO Privacy Policy please refer to
> SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a
> copy.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org

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


RE: Suggested best practice for projects which need duplicated files

Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
You can package them up with assembly:single in a pom project, and then
use dependency:unpack to put the contents where you need them.

-----Original Message-----
From: Ian Rowlands [mailto:Ian.Rowlands@sro.vic.gov.au] 
Sent: Tuesday, October 09, 2007 6:25 PM
To: Maven Users List
Subject: Suggested best practice for projects which need duplicated
files






I have the following scenario for a bunch of projects I wish to
implement:

I have a "Web Project" which acts as a router for web services. It must
contain the web services configuration, the wsdl and the schemas
relating
to the wsdl. It will contain the "endpoints" of the web service - which
will be routed to the other projects.

I have a project containing the implementation of the Web Service.

I have a project which is a client of the web service. It will need the
wsdl and schemas from the Web project. This project also needs to be
consistent with the Web Service implementation

I have a EAR project which will collect everything above (it's not that
important in this context).


The concerns I have is what is the best way to do the following:

1.  Keep the schemas and wsdl consistent between the Web Project and the
client project. They must be identical. The wsdl is needed for
documentation, the schema is needed to generate some Java code (using
JAXB).

2.  Ensuring the client project and implementation project stay with
consistent versions, and stay in sync with the Web Project.

Normally I would classpath-type things, but this situation is not really
applicable to classpaths. I'm not convinced the best way is to copy the
files during the build (or even if that is possible via Maven between
projects).

Any ideas would be appreciated!

Thanks,

Ian


Disclaimer: The information transmitted is intended only for the person
or
entity to which it is addressed and may contain confidential 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 your computer.
Privacy: If you are responding to this email or providing personal
information to the SRO for the purposes of one of the Acts it
administers,
such information is used only for the purpose for which it was collected
( administration of SRO legislation ) and is protected by the
Information
Privacy Act 2000 and secrecy provisions contained in legislation
administered by SRO. It is not disclosed otherwise than in accordance
with
the law. If you would like a copy of the SRO Privacy Policy please refer
to
SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request
a
copy.


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


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